More about the Web Interface
A Web-based interface of some type will need to be positioned between the Web page and the Business Services layer. This interface will consist of a front-end component built as a servlet and JavaServer Pages (JSP) that will reside in a servlet container product. We will use both Apache Tomcat (at jakarta.apache.org) and the container services provided by BEA's WebLogic. However, the servlet and JSP architecture will support any Web server that can implement either their own implementation of servlets and JSP or a third-party JSP enabler (such as Allaire's JRun or the reference implementation from the Jakarta Project, Tomcat). The servlet and JSP will act as both the interface and controller of the process. The servlet will have to broker the request from the browser and then send the message to the appropriate beans, which in turn will allow the servlet to forward the appropriate JSP to return information suitable for building an HTML reply. Figure 8-6 is an overview of the Internet architecture.
Figure 8-6. Remulak Internet strategy
In Chapter 2 we introduced the UML component diagram, which depicts software components and their relationships (dependencies). Figure 8-7 is a component diagram showing the software units that will implement the Remulak solution without using Enterprise JavaBeans.
Figure 8-7. Remulak component strategy without Enterprise JavaBeans
Let's follow the stages of this architecture by referring to the circled numbers in Figure 8-7:
Step 1. |
The HTML form requests a resource. This resource request is mapped to a servlet. |
Step 2. |
The servlet instantiates a control class that is a JavaBean. On the basis of the action requested by the HTML form, the servlet invokes a message on the controller bean. |
Step 3. |
The controller bean's sole mission is to implement the pathways of the use-case. There will be one control class for each use-case (how's that for traceability?). As an example, in the case of Remulak there will be a controller called UCMaintainRltnshp that contains an operation called rltnCustomerInquiry(). The sole mission of this operation is to send messages to other beans with the hopes of returning information about a customer. |
Step 4. |
A value object (more on these in Chapter 9) eventually finds its way back to the servlet, where it is inserted into the request scope of the servlet. The servlet then forwards the request to the appropriate JavaServer Page. |
Step 5. |
The Java Server page, using the object(s) recently placed in the servlet's request scope, formats a return page of HTML bound as a reply to the initiating browser. |
The case of Enterprise JavaBeans as a solution is illustrated in Figure 8-8. There aren't too many differences.
Figure 8-8. Remulak component strategy with Enterprise JavaBeans
Let's follow the stages of this architecture by referring to the circled numbers in Figure 8-8:
Step 1. |
The HTML form requests a resource. This resource request is mapped to a servlet. |
Step 2. |
The servlet instantiates a control class that is a session EJB. On the basis of the action requested by the HTML form, the servlet invokes a message on the controller bean. |
Step 3. |
The controller bean's sole mission is to implement the pathways of the use-case. There will be one controller session bean for each use-case. As an example, in the case of Remulak there will be a controller called UCMaintainRltnshp that contains an operation called rltnCustomerInquiry(). The sole mission of this operation is to send messages to other entity EJBs with the hopes of returning information about a customer. |
Step 4. |
A value object eventually finds its way back to the servlet, where it is inserted into the request scope of the servlet. The servlet then forwards the request to the appropriate JavaServer Page. |
Step 5. |
The JavaServer Page, using the object(s) recently placed in the servlet's request scope, formats a return page of HTML bound as a reply to the initiating browser. |
Note that with this architecture, the only difference between the two solutions is from the controller backward. The HTML and JSPs are absolutely identical. The servlet varies only slightly, in the way it gets a reference to its companion controller. In the case of EJB, the servlet uses the Java Naming and Directory Interface (JNDI) to look up the session bean's home interface. With some smart planning and the use of interfaces, it would be relatively easy to create a factory class that would return to the servlet the controller and would also be none the wiser about whom it was talking to.