Better Faster Lighter Java-10.1 A Brief Look at the Existing Search Feature

10.1 A Brief Look at the Existing Search Feature

The search feature that comes with jPetStore takes one or more keywords separated by spaces and returns a list of animals with a name or category that includes the term. A search for "dog" turns up six results, while a search for "snake" nets one. However, a search for "venomless" gets no results, even though animal EST-11 is called the Venomless Rattlesnake. Even worse, none of the other pages (such as the Help page) shows up in the search at all; neither will any other pages you might add, unless they're an animal entry in the database.

The search feature has the following architecture (shown in Figure 10-1):

Any page of the jPetStore application may contain a search entry box with Search button.
Clicking the button fires a request (for /shop/searchProducts.do) passing the keywords along as part of the request.
petstore-servlet.xml, the configuration file for the MVC portion of the jPetStore Spring application, has the following definition:
```
<bean name="/shop/searchProducts.do" 
class="org.springframework.samples.jpetstore.web.spring.SearchProductsController">
    <property name="petStore"><ref bean="petStore"/></property>    
</bean>
```
This creates a handler for the "/shop/searchProducts.do" request and maps it to an instance of SearchProductsController, passing along an instance of petStoreImpl called petStore.
SearchProductsController instantiates an instance of a class that implements the ProductsDao interface, asking it to search the database for the specified keywords.
ProductsDao queries the database and creates an instance of Product for each returned row.
ProductDao passes a HashMap containing all of the Product instances back to SearchProductsController.
SearchProductsController creates a new ModelAndView instance, passing in the name of the JSP page to display the results (SearchProducts) and the HashMap of values. The JSP page then renders the results using the PagedListHolder control (a list/table with built-in paging functionality).

Figure 10-1. The original jPetStore search architecture

Only the ProductsDao knows how to interact with the underlying data. Product is a straightforward class with information about each product, and the view (SearchProducts.jsp) simply iterates through the returned results to create the output page.

10.1.1 Deciding on the Spider

We've identified how the current search feature works and its limitations: the search feature only searches products in the database, not the site as a whole, and even then it doesn't search all available data about the products. The results it returns are extremely limited—though well-formatted.

The Simple Spider is a crawler-based search feature instead of focusing on the database: it searches everywhere on the site, not just the products table, and it treats any textual information visible to users as part of the search domain. The Spider does have a major limitation—since it is based on a web crawler, it can only catalog pages linked to other pages on the site. If a page is only accessible via some server-side logic (for instance, selecting a product from a drop-down list and submitting the form to the server, which returns a client-side or server-side redirect), the crawler never reaches that page and it won't be part of the search.

With a problem like this, in which a feature of the application is too limited to be of much service to our users, we have to decide between refining the existing service or replacing it entirely. The limitation of the jPetStore search is partly due to the fundamental nature of the service (it searches the database, not the site). Refining it to accomplish the full-site search would be horribly inefficient. The Spider is the obvious solution, but we must consider what we are already dealing with (remember, you are what you eat). If jPetStore uses a lot of server-side logic to handle navigation, the Spider simply won't be able to provide a complete catalog. In this case, though, all the navigation on the site is handled client-side, so the Spider is a perfect fit for solving our problem and coexisting with our current application.

10.1.2 Extending jPetStore

We have decided that an existing service layer of the application is unsuited to our current needs. Additionally, we have decided that replacing the service with a new one is the appropriate solution. This situation is a perfect test of extension: how easy will it be to replace this service? Will it involve new code? Changes to existing code? Or just changes to our configuration services?

In order to replace the existing functionality with the Simple Spider, we need to change the output formatting a little (our returns will display full URLs instead of product instances), write a new controller that knows to launch the Simple Spider instead of the ProductsDao object, and change our mapping layer to point to the new controller. Finally, we'll use Spider's configuration service so Spider works better with the new web site.

Looking at these requirements, we can already see we'll need to write fewer than 100 lines of code and make only minor configuration changes in order to get this to work. It's a reasonable price to pay for the end result we want. Because jPetStore and the Simple Spider were designed to allow for extension in the first place, they fit together well with minimal work.

Conversely, we could write much less code and in fact do almost no work at all if we chose to connect to the Spider through the existing web service interface rather than integrating it directly with the jPetStore. Since the web service interface already exists, it might be construed as a violation of the "do one thing, and do it well" principle to add another, seemingly useless interface. In this instance, though, the added cost of sending a bloated message (XML/SOAP) over a slow transport mechanism (HTTP) is too heavy, especially given the minimal amount of work it will take to get a faster, more efficient integration.

< Day Day Up >