The Auction Web application is made up of several components, illustrated in the following diagram. This is not a tutorial on how to build the entire application. Instead, this document highlights important development and design points that leverage different tools provided with the workbench, so you can apply that knowledge to your own Web applications.
Enterprise JavaBeans™ (EJB) offers a convenient way for Java applications to access data held in relational databases. Entity beans can be developed using bean-managed persistence (BMP) or container-managed persistence (CMP). CMP allows for more flexibility than using BMP because the EJB container makes all the database-specific calls, as directed by the bean. By default, the tools in the Rational® workbench generate entity beans using CMP. The CMP entity bean contains no access SQL code. This allows you to deploy the bean on other J2EE servers that use different databases, with no need to rewrite the code.
There are different approaches for mapping objects to relational databases, such as top-down, bottom-up, and meet-in-the-middle. A top-down approach works from existing objects, then defines increasingly detailed layers as required, and then designs the database as the final step. The bottom-up approach uses an existing database schema, and then designs the dependent layers, which define the objects. The meet-in-the-middle approach uses an existing database and existing objects, and then develops the intermediate layers to match the objects to the corresponding database tables.
The Auction application used a bottom-up approach in developing the entity EJBs. The Derby database existed initially, and contained tables that closely matched the EJBs that were needed. After creating a connection to the database using the Database Connection wizard, we used the EJB to RDB Mapping wizard to create EJBs that mapped from one or more tables, with some exceptions. The following figure shows the entity EJBs used in the Auction application, and the relationships connecting them.
Entity beans in the Auction application are not accessed directly by the remote client. All requests and responses are handled by session facades, and the beans are used to access the back-end data. This allows server-side shared access to the persistent data store. The next section discusses session facades in more depth.
For more information on mapping entity beans, see the Generating a bottom-up mapping help topic.
The session facade is the interface between the client and the back end that provides communication to the Service Data Object (SDO) components and ultimately the database. A session facade is useful when the client sends requests that require several objects to execute. Sending these requests individually to the objects can increase network traffic and latency. The session facade acts as a buffer between the two ends, taking a general request from the client, and then sending specific requests to the necessary objects. This reduces traffic and simplifies developing the client.
By grouping the EJBs and using two different facades, you can increase the performance of the application because users access only the EJBs that they need. The entity beans that control the function of the Web site itself, such as Category, are controlled by the system facade.
The EJBs that are referenced by a facade are chosen one at a time, using the Create Session Bean Facade wizard, as shown in the following diagram. An EJB can be referenced in more than one facade if necessary. This was not done in the Auction application.
You can add additional functions by adding methods to the facades. For example, in the user facade, there is one method that returns a list of users, and another method that returns a list of the active users. Using these methods as an example, another method could be added to the user facade that returns a list of all users who are marked as inactive.
More information on session facades can be found in the "Design Patterns: Session Facade" discussion paper at http://java.sun.com./.
The Navigation view of the Web Site Designer tool provides a visual representation of how the site is laid out. It shows the individual pages and their hierarchical organization, and is useful for maintaining the layout and organization of the pages within the site. When you drag and drop pages in the editor, the navigation controls in the page templates are automatically updated. For example, with the Auction navigation structure shown in the following diagram, you could change the order of the navigation tabs by moving the Sell page before the Browse page. Web Site Designer automatically generates the tabs in the correct order on all the pages. To make the changes visible in the running application, resave each page that uses the navigation template.
In addition to the Navigation view just described, Web Site Designer provides a Detail view that organizes additional page elements in a convenient, editable table, as shown in the next figure. This table makes it easy to update page properties, such as title, author, and navigation label.
For more information on using Web Site Designer to manage the Web site layout, refer to the Creating a Web site structure topic in the online help.
The workbench comes with a visual designer for developing page templates, as well as the Web pages themselves.
Page templates are reusable pieces of content code that provide a common look or behavior for sections of a Web site. To share a common look and feel, Web pages need only reference the templates. Using templates benefits both the user, who can navigate the Web site easily, and the developer, who needs only to write code specific to a particular page.
Page templates also allow for easy maintenance of Web site content. Changes to the template file are automatically reflected in every page that references it. For example, in the Auction Web application, the template maintemplate.jtpl, provides the general layout for the Auction pages. Web page elements can be added to the template by using the palette in Page Designer, which allows you to drag and drop elements onto the Web page. The required HTML code is generated automatically. The Auction template can be easily modified in this way, to include, for example, the current date and time in the footer.
By inserting a tag that calls the template rather than hard-coding the navigation, you can include the same navigation bar on all pages of the site. The Template Mapping editor inserts references to the template into a Web page.
Dynamic templates take this technology a step further, for example by altering the Web page content based on the users' roles or capabilities, or by inserting user-specific information in a Web page. The Auction sample uses dynamic templates to provide administrative links in the navigation bar for only those users logged in as administrators, and to change the "Login" button to read "Logout" once the user has successfully logged in.
For more information on creating Web page templates, refer to the help topic on Creating a page template.
JavaServer Faces (JSF) is a technology that assists in building user interfaces for dynamic Web applications that run on an application server. JSF is an open standard language and uses a JavaServer Faces standard tag library. The tags are inserted into the HTML code to create dynamic Web pages.
The JSF framework manages user interface states across server requests and offers a simple development model to handle the server-side events that are activated by the client. For example, a JSF can have a specified behavior for different events, like a button click. Page Designer has built-in functions, displayed visually in the palette, which you can drag and drop onto the Web page. These drag and drop functions make it easy to use JSF, HTML, and other scripting elements. This is useful for not only controlling the basic functions of a field, such as the value type of a text field (integer, alphanumeric), but also enables setting validation rules. In Page Designer, the JSF controls can be bound to the SDO data associated with each page.
The Page Designer palette can be used to add additional functions to JSF pages. For example, a "Buy It Now" button could be added to the item details page to allow a user to buy the item at the value the seller set for the item.
The following figure shows the JSF controls for the Auction details page. The newbid inputText field is restricted to only accept integers with the Integer only check box, as seen in the lower right corner of the figure. The inputText field has additional settings for Validation, Behavior, and Accessibility, as defined in the tabs below h:inputText on the lower left of the figure. The Validation tab is where specific validation rules are defined using Java. For example, valid input for the newbid inputText field is an integer that is not null, is greater than the starting bid, and is greater than the current bid plus one.
The following code was generated for the newbid inputText field on the itemdetails page of the Auction application.
<h:inputText styleClass="inputText" id="newbid" required="true" size="14"> <f:convertNumber integerOnly="true" /> <f:validateLongRange minimum="#{pc_Itemdetail.userFacadeLocalGetFindHighestBidResultBean==null ? pc_Itemdetail.userFacadeLocalGetBidItemSDOByKeyResultBean.startingbid : pc_Itemdetail.userFacadeLocalGetFindHighestBidResultBean.currentbid+1}"> </f:validateLongRange> </h:inputText>
For more information on developing Faces JSP files, refer to the help topic on JavaServer Faces.
The Web service was developed in parallel with the Web application because it is not dependent on the Web application - the Web service is another means of accessing the business logic, and does not include all the functionality of the Web application. See the Web service section for a more detailed description of this piece of the Auction application.