Enterprise Application Development

Get Complete Project Material File(s) Now! »

Chapter 4. Detailed Design – RVG Web Application

This chapter discusses the detailed design of the RVG Web application in terms of classes and their interactions. The overall design of RVG Web applications follows the MVC design pattern, while the internal design of its components follows the J2EE patterns, documented in Chapter 3

RVG Web Application Components

The Web application is made up of several types of components:
Enterprise beans
JSPs
Servlets
XML files
Utility & Exception classes
Action classes
ActionForm classes
Message resources
Appendix B lists the components classes.

Class Interactions

This section shows class interactions that take place in two sample scenarios.

Generate Random Variates

The sequence of method calls that take place when the user clicks “Generate RVGs” is shown in Figure 20. Let us consider a situation where the distribution cart contains Beta and Uniform distributions as the requested RVGs. The sequence of method calls are as follows:
The user clicks “Generate RVGs”, thereby invoking doPost () (i.e. service ()) method of ActionServlet.
ActionServlet invokes execute () method of GenerateVariatesAction class, a subclass of Action class.
GenerateVariatesAction class uses the instance of DistCart EJB that is stored in session context, or creates a new instance if none exists, to invoke generateVariates ().
DistCartEJB, which is a stateful session enterprise bean, has the list of requested distributions stored as a member variable, and passes it to the Session Façade – VariateGenerator EJB in invoking generateVariates ()
method of the latter.
VariateGenerator EJB calls Beta EJB, and Uniform EJB, one after the other, and passes the results to DistCart EJB, which in turn passes a value object to GenerateVariatesAction (See Sections 3.5.2 and 4.4.2)
GenerateVariatesAction passes control back to ActionServlet, placing a newly populated value object in session scope (the list of generated distributions), and informing the ActionServlet of the JSP to display.
ActionServlet uses the forward page from GenerateVariatesAction to invoke displayList.jsp, which in turn uses the session-scoped value object to display the list of generated distributions.

View Details of a Generated Distribution

The sequence of method calls that take place when the user clicks a particular generated distribution to view its details is shown in Figure 21. The sequence of method calls are as follows:
The user clicks a hyperlink in the list of generated RVGs, thereby invoking doPost () of ActionServlet.
ActionServlet invokes execute () of DisplayDistAction, a subclass of Action.
DisplayDistAction invokes displayDist () method of DistCart EJB, which returns the details of the specific distribution in a value object to DisplayDistAction.
DisplayDistAction passes control back to ActionServlet, passing the JSP to display, and populating a value object placed that the forward page will use to display the details on the page.
ActionServlet forwards to displayDetail.jsp, as decided by DisplayDistAction.
displayDetail.jsp uses the session-scoped value object to display the details. It also uses the services of two other servlets – RVGDisplayHistogram and RVGDisplayScatterPlot – to embed SVG images in the output page.

Presentation Tier

This section discusses how the RVG Web application implements design patterns of the Presentation Tier, mentioned in Section 3.4.

Front Controller

The Struts framework provides a servlet called ActionServlet that implements the Front Controller design pattern. ActionServlet acts as the main point of entry for Web requests for RVG Web application. All requests that end in *.do are mapped to go through the ActionServlet for processing, by configuring the Web.xml (Web Deployment Descriptor). Struts also provides for ActionForms (which handle user input on input screens) and Action classes (that contain the business logic for the particular incoming request). The job of ActionServlet is to forward the input request to the correct Action class, which does the business logic with the help of enterprise beans, and then returns to the ActionServlet the forward page. The Action class optionally also populates a value object that will be used by the target page to display data. ActionServlet then delegates to the forward page to display the next screen.

View Helper

Both JavaBean helper and custom tag helper strategies have been used to implement View Helper in RVG Web application. Infact, Struts provides a number of view helpers, in the form of JSP tag libraries which are shown in Table 2.
An example of the use of View helpers in RVG Web application is shown in Code Listing 1, which is a code sample from displayList.jsp.
<logic:iterate id= »distParams » name= »<%= RVGConstants.LIST_DIST_KEY%> »> <tr align=left>
<logic:notPresent name= »<%= RVGConstants.DIST_GENERATED_KEY%> »>
<td align= »center »><bean:write name= »distParams » property= »sequence »/></td>
<td align= »center »><bean:write name= »distParams » property= »exptType »/></td>
<td align= »center »><bean:write name= »distParams » property= »stream »/></td>
<td align= »center »><bean:write name= »distParams » property= »seed »/></td>
<td align= »center »><bean:write name= »distParams » property= »number »/></td>
<td align= »center »><bean:write name= »distParams » property= »genHist »/></td>
<td align= »center »><bean:write name= »distParams » property= »genScat »/></td>
<td align= »center »><bean:write name= »distParams » property= »genStat »/></td>
</logic:notPresent>
</tr>
Code Listing 1. Use of JSP tag libraries
Figure 24 illustrates the View Helper pattern through the sequence of method calls that take place when the user is shown the list of requested RVGs in distribution cart, after Beta distribution has been successfully added to the list of requested RVGs. The role of DistParamValueObject is of relevance here, as it acts as a View Helper. BetaSubmitAction () sets this JavaBean in session scope, which is used by displayList.jsp in displaying the list of requested RVGs.

Composite View

Composite View pattern is implemented in RVG Web application through the use of Tiles framework. Essentially, “Tiles builds on the include feature provided by the Java Server Pages specification to provide a full-featured, robust framework for assembling presentation components from component parts” [Tiles 2003].
Figure 25 illustrates the Composite View pattern through the class diagram. Essentially, a CompositeView is made up of an aggregate of BasicView’s, which in turn is specialized by a simple view – View1 – or CompositeView.
Code Listing 2 illustrates the Composite View pattern, by defining a layout that all the pages in RVG Web application must follow. The individual screen definitions are done in separate JSP files, which are gathered together dynamically to form the composite page that is displayed to the user.
<%@ taglib uri= »/WEB-INF/struts-tiles.tld » prefix= »tiles » %>
<table>
<tr><td> <tiles:insert attribute= »header »/></td></tr>
<tr ><td><tiles:insert attribute= »leftMenu »/></td></tr>
<tr><td><tiles:insert attribute= »rightMenu » /></td></tr>
<tr><td><tiles:insert attribute= »body » /></td></tr>
<tr><td><tiles:insert attribute= »footer » /></td></tr>
</table>
Code Listing 2. Code sample illustrating Composite View Pattern

Business Tier

This section discusses how RVG Web application implements the design patterns of the Business Tier (see Section 3.5).

Session Façade

Figure 26 illustrates how Session Façade pattern is implemented in RVG Web application. VariateGenerator EJB acts as the Session Façade in the application, hiding the twenty-seven entity beans that correspond to the twenty-seven probability distributions.
Figure 27 illustrates the class interaction that takes place in the generation of random variates for the RVGs in the distribution cart. The distribution cart has Beta, Binomial and Uniform distributions in the example below.

Value Object/Data Transfer Object

Figure 28 shows the classes that implement the Value Object pattern in the RVG Web application. RVGDistCart EJB returns a value object to the Controller, which in turn creates another value object (essentially a JavaBean of class DistParamValueObject), and places it in session scope. This session-scoped JavaBean is used by the next page being displayed to the user.
Figure 29 illustrates the sequence of messages that flow between classes involved in Figure 28. It is relevant to point out that displayList.jsp uses the Client copy of DistValueParamObject, which has been placed in session scope by BetaSubmitAction.

Server Session State

In J2EE, “the two most common techniques for storing Server Session State are using http session and using a stateful session bean” [Fowler 2002] . RVG Web application makes use of both the techniques.
The http session stores the object in the Web server by a simple ID that can be used to later retrieve the object. RVG Web application makes use of DetailDistValueObject, DistParamValueObject and DistributionBean as value objects, to be stored in session scope for access by multiple pages in the applications. Furthermore, the instance of the distribution cart implemented as a stateful session bean – RVGDistCart EJB – is stored in http session, so that each session has a unique copy of distribution cart.
The distribution cart is implemented as a Stateful Session bean – RVGDistCart EJB – and hence is stored by the EJB container, which handles all persistence and passivation for the enterprise bean.

Integration Tier

This section discusses how the RVG Web application implements design patterns of the Integration Tier, mentioned in Section 3.6.
Domain Model
Building a domain model was perhaps the most significant part of the work, because of the options available and their trade-offs. RVG Web application has different business rules for the 27 probability distributions. There is a need to make some of the fields persistent in the database for later access. There are two ways to handle persistence: using Plain Old Java Objects (POJOs) or using entity beans. The advantages of using POJOs over entity beans are:
POJOs support inheritance, and entity beans do not.
POJOs are generally easier to build and test, as opposed to entity beans.
POJOs incur lesser performance overhead than entity beans
However, RVG Web application uses entity beans to encapsulate business logic and data that needs persistence for the following reasons:
The performance of CMP in EJB 2.0 has been improved vastly over pre-EJB 2.0 implementations. So much so that CMP is actually the preferred approach over Bean Managed Persistence (BMP), both in terms of ease of development and deployment, and in performance. That justifies the use of CMP over BMP in RVG Web application.
Using entity beans with CMP makes the bean free of any SQL or JDBC. JDBC is generated at deployment time by the EJB container. The fields to be mapped to a table of the database, and their persistence properties, are specified declaratively in an XML file.
“Domain model is at its best when you use fine grained objects” [Fowler 2002]. That justifies having twenty-seven entity beans, corresponding to the probability distributions that are supported.
Use of a stateful session bean – VariateGenerator EJB – to act as session façade over the entity beans, as well as use of local interfaces, does away with most of the performance-related issues associated with entity beans.
Last, but certainly not the least, using entity bean with CMP frees the Domain Model from the database, as the CMP approach acts as a Data Mapper [Fowler 2002].
The fields that are made persistent in the database are:
Stream Identifier – primary key
Original Seed
Last Seed
Distribution Name

RVG Web Service

This chapter provides a description of the RVG Web service, created from the RVG Web application.

Overview of WSDL

“Web Services Description Language (WSDL) provides a model and an XML format for describing Web services” [WSDL 2003]. It describes a standard format for specifying interfaces, and essentially works as a contract between the client (Web service requestor) and server (Web service provider). Using a standard XML-based format to specify the interface makes possible the automatic generation of client proxies from the WSDL document in a language- and platform-independent manner.
WSDL Document Structure
The WSDL document can be divided into two sections:
Abstract Definitions – These define the ‘what’ of the functionality that is offered. Abstract definitions define the SOAP messages that flow between the Web service requestor and Web service provider in a language- and platform-independent manner.
Concrete Definitions – These define the ‘how’ and ‘where’ of the functionality that is offered. Concrete descriptions specify the message formats and network protocols for the Web service, and also the endpoint where the Web service is accessible.
The Abstract Definitions section of WSDL document is made up of the following element, in order:
import – This element imports other WSDL documents or XML schemas.
types – This element specifies all application-specific datatypes exchanged between the Web service requestor and provider.
message – This element defines one-way messages, and contains one or more ‘part’ elements that correspond to message parameters or return values.
portType – This element defines the operations of the Web service, and specifies a complete one-way or roundtrip operation. A ‘portType’ element declares the name of the method (using ‘message’ elements mentioned before), and types (using ‘part’ elements defined in ‘message’ element), within one or more ‘operation’ elements.
The Concrete definitions are made up of the following elements, in order:
binding – This element specifies the binding of each ‘operation’ element in ‘portType’ element. Binding refers to the SOAP message formats and serialization schemes.
service – This element specifies the address for invoking the Web service, for example, a URL. In other words, it specifies the address of each ‘binding’ element. A ‘service’ element contains one or more ‘port’ elements, each ‘port’ element corresponding to a Web service.
Figure 30 shows the relationships between the different elements in a WSDL document. The ‘definitions’ element forms the root of all WSDL documents. The order of other elements is: import, types, message, portType, binding, and service.

Table of Contents
Abstract
Acknowledgments
List of Figures
List of Tables
List of Code Listings
List of Acronyms
Chapter 1. Introduction
1.1. Random Variate Generator
1.2. Enterprise Application Development
1.3. Web Services
1.4. Our Work Overall Architecture
1.5. Organization
Chapter 2. Background
2.1. Random Variate Generation
2.2. J2EE Overview
2.3. Web Services
2.4. Scalable Vector Graphics
Chapter 3. High-Level Design – RVG Web Application
3.1. Requirements Specification for the RVG Web Application
3.2. Best Practices
3.3. RVG Web Application Architecture
3.4. Presentation Tier Patterns
3.5. Business Tier Patterns
3.6. Integration Tier Patterns
Chapter 4. Detailed Design – RVG Web Application
4.1. RVG Web Application Components
4.2. Class Interactions
4.3. Presentation Tier
4.4. Business Tier
4.5. Integration Tier
Chapter 5. RVG Web Service
5.1. Overview of WSDL WSDL Document Structure
5.2. Overview of SOAP
5.3. WSDL for RVG Web Service
5.4. Justification for document style in RVG Web Service
5.5. RVG Web Service Client
Chapter 6. Verification and Validation
6.1. Verification
6.2. Validation
Chapter 7. Conclusions and Future Work
7.1. Conclusions
7.2. Contributions
7.3. Future Work
Bibliography
GET THE COMPLETE PROJECT