Auction Web application details

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.

This diagram shows the relationships between data, business logic, Web content, and tools.
As the preceding diagram shows, the Web content was developed in parallel with the data and business logic. While the designers developed the style and layout of the Web pages, the Java™ and Web service developers coded the business logic to drive these pages. The following sections describe how these key components were created, and their contribution to the Auction Web application:
  1. Mapping entity beans to database tables with the EJB Mapping editor
  2. Generating a session facade with SDO data objects using the Session Bean Facade wizard
  3. Defining the Web site layout with Web Site Designer
  4. Creating Web page templates with the Page Designer
  5. Adding JavaServer Faces components to JSP pages with Page Designer
  6. Creating the Web service

Mapping entity beans to database tables with the EJB Mapping editor

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.

This diagram shows the relationship between various entity beans.

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.

Generating a session facade with SDO data objects using the Session Bean Facade wizard

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.

Once the facade is created, you can select the EJBs that it manages by selecting Map EJBs from the menu in the tool. The facade generates the necessary SDO components from the entity beans. In the Auction application, there are two facades, based on the two following functional groups:
  • The system facade interfaces with the back-end, system-specific EJBs, such as Category and Role.
  • The user facade encapsulates user-specific data, such as Bid, Item and Role.

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.

This diagram shows the Create Session Bean Facade user interface.

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./.

Defining the Web site layout with Web Site Designer

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.

This diagram shows the Auction JSPs appearing in Web Site Designer.

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.

This diagrams shows the details view of Web Site Designer.

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.

Creating Web page templates with Page Designer

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.

The key elements in the Auction template are the navigation controls. The Auction Web application navigation bar uses two forms of navigation:
  • Navigation tabs: display different sections of the Web site.
  • Navigation trails, or "bread crumbs": display textually where the user is in the Web site, for example, Home > Browse > Listing.
This diagram shows the navigation tabs appearing on the Auction sample pages.

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.

Adding JavaServer Faces components to JSP files with Page Designer

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.

This diagram shows the JSF controls used on the Auction details page.

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.

Creating the Web service

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.

Auction projects organization

The Auction Web application has a number of projects. Each project has a specific purpose. The following list describes each project and how it is used in the Auction sample:
  • The AuctionV60EAR project is the main Enterprise Archive (EAR) file that is deployed to the application server. This project is required for the runtime environment.
  • The AuctionV60EJB project contains the EJBs and the facade classes.
  • The AuctionV60EJBClient project holds generated code, including the SDO classes, and is deployed to the client.
  • The AuctionV60Web project contains all the JSF files, the template, and the business logic for running the JSF files.
  • The AuctionV60WebService project has the Web service WSDL files and the Java source for the Web service.
  • The OIDGenerator project and the OIDGeneratorClient are required for creating the new keys for the database inserts.
Parent topic: Auction Web application

Feedback