Design of the WH System

Figure3.7 on the next page illustrates the design of the WH System. The easiest way to explain how this works is by example – the numbered arrows in the fig-ure illustrates the different states the application goes through while processing a request from a user³:

1. The client has opened the search page of the WH web application. He enters some keywords in a search form and pushes the search button. This action launches a HTTP request for the URL http://www.world-heritage.org/result.html.

The keywords are included as POST variables in the request.

2. The Front Controller Servlet intercepts the HTTP request. The front con-troller has a map which maps each possible requests into a Request Handler.

A request handler is a Java class, that is responsible for handling one specific request. The request for “result.html” is mapped to the request handler “Re-sultRequestHandler”, hence the front controller forwards the HTTP request to this request handler.

3. Because the request handler is responsible for only one HTTP request, it

3This is just an example – the URLs and filenames do not necessarily match those in the real application

Client browser

Front Controller Servlet

Request Handlers

XML Database 1.

7.

8.

4.

2.

6.

JSP pages

Enterprise JavaBeans

− (Session Beans) 3.

5.

Figure 3.7: Design of the WH web application

knows exactly what to do. It makes a JNDI⁴ lookup for an Enterprise Jav-aBean (EJB). Then it calls the appropriate search method in the EJB.

4. The EJB contains the business logic which in this case means, that it imple-ments the functionality for performing the keyword search requested by the client. The EJB searches the XML database and generates data (probably information about some sites that matched the keywords), that should be re-turned to the user. Notice that the EJB does not specify how the data should be presented to the user.

Details about how the XML database can be searched is explained in a sec-tion later on.

5. The result is returned to the request handler – possibly as a JavaBean⁵. 6. The request handler now prepares the result for a JSP page. If the EJB did

not create a JavaBean with data, it is created now. The JavaBean is added to the HTTP request as an attribute. The request handler returns the name

“result.jsp” to the front controller.

Typically a request handler can return with to possible outcomes – it can return a the name of whatever JSP page is responsible for presenting a result to the client, or it might return the name of an error page if something went wrong while handling the request.

7. The front controller forwards the HTTP request to the JSP page “result.jsp”, which is responsible for presenting the data.

8. The JSP page extracts the JavaBean from the request. Then it generates an HTML page based on the data. Finally the resulting page is returned to the user.

4JNDI is a service for looking up Java objects based on some unique name, quite similar to how one can use DNS to translate a domain name into an IP address

5Again it should be emphasized, that a JavaBean is simple a class instance containing data and no logics, so do not confuse it with an EJB

The experienced J2EE developer has probably noticed that the EJB’s are so called Session Beans, which are directly connected to the database. This is normally not the best way to interact with a database. Normally one would put in an extra layer in the model between the session beans and the database. This layer would consist of Entity Beans, so that the session beans would communicate with the entity beans and the entity beans would be the only interface to the underlying database.

The problem with entity beans is, that they are designed as representations of rela-tions in a relational database. This is a useful feature in applicarela-tions using RDBMS for data storage, but it is completely useless when using an XML database, and this is why the session beans have to communicate directly with the database.

It is easy to recognize the MVC pattern in the design. The controller consists of the front controller servlet and the request handlers. The model is the EJB’s and the JavaBeans. Notice that the JavaBeans are not components the same way that the front controller and the EJB’s are – they are simply temporary containers for temporary data. Finally the views are the JSP pages.

An excellent quality in the design shown i figure3.7on the preceding page, is the very clear division into components, where each component is responsible for a restricted part of functionality. Because of this, it is very easy to understand how the program works and what “kind” of code to expect in the different components.

It also makes it extremely easy to expand the application with additional function-ality. Suppose that the application should be extended with a new search facility of some kind. The programmer would have to go through the following steps (not necessarily in this order):

1. The programmer creates a new static JSP/HTML page containing a search form, where the user can provide his search criteria.

2. If the result of the new search fits into an existing data model (JavaBean), then this is used for the result. Otherwise a new JavaBean is created for holding the data.

3. The new search method (the business logic) is implemented in an existing EJB.

4. A request handler is created for extracting the user’s search criteria from the HTTP request and calling the appropriate search method in the EJB.

5. If the result fits an existing data model, it will also fit an existing view (JSP page) and this can be used for presenting the result. Otherwise a new JSP page is created for presenting the result for the user.

6. Finally the new type of request has to be mapped into the correct request handler in the front controller.

This may seem like a lot of things to go through, just to add a little functionality, but it really is not. All the steps, except the implementation of the business logic in the EJB, are trivial. The beauty of it is, that it is not necessary to alter any existing code to make it work. It is only necessary to add some code. It is especially nice,

that the request handler is implemented as a whole new Java class, so you can easily find and get an overview of the code, that handles a specific request.