Mastering Enterprise JavaBeans™ and the Java 2 Platform, Enterprise Edition - Roman E.

J2EE in the Real World: Designing an E-Commerce Object Model 351

Customers

Next, we need to represent information about Jasmine’s customers. A customer represents an end user—perhaps an individual or a corporation that purchases goods from our Web site. Our Customer abstraction contains the following data:

■■Customer ID

■■The customer’s name (also used as the customer’s login name for our Web site)

■■The customer’s address

■■The customer’s password (used to verify the customer’s identify)

There are many ways new Customers, Products, and so on could be added to the system. Jasmine could have users log in through a separate Web site and input their name, address information, password, and other profile data. We could also develop a custom maintenance tool (stand-alone or Web-based) for adding new Products. To keep this example simple, we’ll manually insert direct database data, but feel free to extend this for your purposes.

Quotes

Next, we need to keep track of the selections a customer has made while navigating our catalog. Essentially, we need the abstraction of a “shopping cart,” which is a temporary selection of goods and their prices. We’ll call this shopping cart a quote because a shopping cart embodies a price quote on goods. As the user traverses the Web site, he or she adds or removes goods from the quote.

Each customer who’s logged in should have his or her own temporary and separate quote in which to work. Therefore, our quotes will need to hold client-specific state in them. They should not be persistent because the user can always cancel the quote.

This naturally lends itself to the stateful session bean paradigm. Each Quote stateful session bean will hold conversational state about the user’s current quote. It will allow us to treat the entire quote as one coarse-grained object. A new Quote would need to be generated every time a user logged in. Each Quote bean will contain the following information:

■■The Customer (entity bean) who we authenticated at the login screen. We need to store Customer information so that we know who to bill, what discounts to apply, and where to ship the manufactured products.

■■The products and quantities that the Customer currently has selected. This data is best represented in its own separate bean, called a Quote Line Item, described later.

Go back to the first page for a quick link to buy this book online!

352 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

■■The subtotal for the quote, taking into account all the prices of the products the user wants, as well as any discounts the user gets.

■■The taxes charged. This is added to the subtotal for the final grand total.

In addition to this data, the Quote beans will be smart and will know how to generate a permanent Order from themselves. We describe Orders a bit later.

Our deployment uses an enterprise bean, called a Quote bean, to store the user’s current shopping cart information. One alternative to this is to keep the user’s current selections at the presentation tier (i.e., at the Web server), to reduce the number of round trips between tiers. You can accomplish this by using regular JavaBeans in the Web server to hold the shopping cart data.

Quote Line Items

As the user navigates the Web site, he or she will be adding products to the Quote. For convenience of manipulation, we’d like to separate a Quote into individual line items, where each line item represents data pertaining to a single product the user has currently selected. A Quote has a 1:N relationship with its constituent line items.

Quote Line Items contain the following data:

■■The ID of the line item

■■The Product (entity bean) that the user wants to buy

■■The quantity of that Product

■■Any discounts the customer gets from the base price of the Product

Again, since a Quote Line Item is specific to one customer and is not persistent, it is best modeled as a stateful session bean.

Pricers

Because Jasmine wants customized pricing, we need the concept of a Pricer— a component that takes a Quote as input and calculates the price of that Quote based on a set of pricing rules. A pricing rule might be “Customer X gets a 5 percent discount” or “If you purchase 10 motherboards you get a 15 percent discount.” These pricing rules could be read in from a database or set via properties.

Our Pricer will take a Quote as input and compute the subtotal (before taxes) of that Quote. It figures out the subtotal by computing a discount for each Quote line item in that bean and subtracting the discounts from the total price.

Our Pricer will work on any Quote and holds no client-specific state—once the Pricer has computed a price on a Quote, it is available to perform another computation

Go back to the first page for a quick link to buy this book online!

J2EE in the Real World: Designing an E-Commerce Object Model 353

on a different Quote. It is also not a persistent object (it would not make sense to save a Pricer because a Pricer simply performs logic, and holds no state). This means our Pricer fits into the EJB world best as a stateless session bean.

Orders

Next, we need to model a permanent order for goods. We’ll define an Order abstraction for this purpose. An Order is a Quote that has been converted into a work request. An Order represents a real business action that needs to take place, such as the production of goods. Generating an Order and billing a Customer go hand-in-hand.

An Order contains the following information:

■■The ID of this Order (which the user can use to check on order status)

■■The Customer (entity bean) for which this Order is generated (used for shipping address information)

■■The products and quantities that should be ordered (as with Quotes, best represented as separate information—contained in Order line items, described later)

■■The subtotal and taxes on the order

■■The date the order was placed

Orders are permanent, persistent objects. You want an Order’s state to be around if your deployment crashes for any reason because an Order means money. Therefore, Orders are best depicted as entity beans. In comparison, Quotes are not permanent—they represent temporary interactions with the customer. You don’t want to write a Quote’s data to a database during a customer interaction, but you do want to keep track of the user’s information—hence the stateful session bean is best applied for Quotes.

Our notion of an Order can be easily extended to include order status, such as “Manufacturing” or “Shipping”, and other order fulfillment information. It would also be interesting to e-mail the order status to the end user, using the JavaMail API. Since we do not fulfill orders, we leave this as an exercise to the reader.

Order Line Items

For convenience of manipulation, we break up our notion of an Order into individual line items, where each line-item represents data pertaining to a single product the user has ordered. An Order has a 1:N relationship with its constituent line items. Our Order Line Item abstraction contains the following data:

■■ The ID of this Order Line Item

Go back to the first page for a quick link to buy this book online!

354 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

■■The Product that this Order Line Item represents (used by manufacturing to reveal which product to make)

■■The quantity of the Product that should be manufactured

■■The discount that the customer received on this Product

Because Order Line Items are permanent, persistent objects, they are best represented as entity beans.

Bank Accounts

Next, Jasmine needs functionality to bill a customer, such as by charging a credit card account or mailing an invoice. In a real deployment, you will need to use such mechanisms. But for illustrative purposes, we’ll rely on withdrawing directly from the customer’s bank account. In Chapter 8, we developed an entity bean for just such a purpose—a Bank Account entity bean. A Bank Account

EJB Design Strategies

Session Beans as a Facade to Entity Beans

One problem with multi-tier development is that you need to be aware of network roundtrip issues. When Java servlets (or other client code) call enterprise beans across the network, a potential bottleneck could ensue. For example, if a servlet had to call across the network for every get/set method on an entity bean, the network would be flooded in no time.

To keep performance high, you should design your system to minimize the number of network round trips. One way to do this is to use session beans to perform bulk operations on entity beans. Rather than going across the network for every get/set method on an entity bean, your client code (such as Java servlet code) should call a session bean that performs a bulk operation on behalf of that servlet.

For example, our Bank Teller session bean serves as a wrapper for our Bank Account entity bean. The Bank Teller performs bulk operations on Bank Accounts. For example, our Bank Teller can transfer funds from one Bank Account to another. A transfer operation involves two Bank Account entity beans, yet it can be done in one network call by a Bank Teller session bean.

The design pattern of a session bean wrapping an entity bean is a common one that you will see in many EJB deployments. Not only does it minimize network round trips, but it promotes reuse of your entity beans. You can design your entity beans to be very simple and then wrap them with session beans whose logic can change and be customized. This results in high reuse of entity beans, which is necessary because they model permanent data that should not be changed often.

Go back to the first page for a quick link to buy this book online!

J2EE in the Real World: Designing an E-Commerce Object Model 355

represents a user’s permanent, persistent Bank Account information. This is data such as the following:

■■The Bank Account number

■■The name of the Bank Account holder

■■The current balance of the Bank Account

We’ll reuse this Bank Account entity bean in our e-commerce deployment.

Bank Account Tellers

Finally, our last Enterprise JavaBean is a Bank Account Teller. A Teller represents a “virtual person” with whom you interact to modify a bank account. For example, our Teller will be able to transfer funds from one Bank Account (entity bean) to another.

Our Teller is not itself a persistent object—the notion of “saving” a Teller to disk means nothing. Our Teller will be a generic, stateless object, and it will be reusable for multiple clients. Therefore, it fits into the EJB world as a stateless session bean.

Business Logic Tier Object Model Summary

This completes our object model design for our business logic tier. The static relationships between our enterprise beans are depicted in Figure 12.7.

Object Model for the Presentation Tier

Our next task is to design our presentation tier, which displays the graphical user interface to the end user. For our presentation tier, we will use a few Java servlets to interact with a client over HTTP.

What Are Servlets?

A servlet is a module that runs within a request/response–oriented server. A request is a call from a client, perhaps remotely located. Requests contain data that the client wants to send to the server. A response is data that the server wants to return to the client to answer the request. A servlet is a Java object that takes a request as input, parses its data, performs some logic, and then issues a response back to the client. This is shown in Figure 12.8.

Servlets work on the same concept as CGI scripts. A CGI script is a program that takes data from standard input, performs some logic, and then sends data to standard output. It doesn’t matter what language you write a CGI script in,

Go back to the first page for a quick link to buy this book online!

Figure 12.7 Component diagram of our e-commerce enterprise beans.

so long as it follows this convention of reading data from standard input and writing data to standard output. This is shown in Figure 12.9.

The problem with CGI is that your server must restart the CGI script every time a new request is issued. This means every time a client communicates, your server needs to begin a new process. Starting and stopping processes are expensive operations.

2: perform logic

Figure 12.8 The basic servlet paradigm.

Go back to the first page for a quick link to buy this book online!

J2EE in the Real World: Designing an E-Commerce Object Model 357

2: perform logic

Figure 12.9 CGI scripts.

This is where servlets have an edge over CGI. Servlets are Java objects that function the same way as CGI scripts—taking in data (a request), performing some logic, and writing out data (a response). The difference between CGI and servlets is that CGI scripts must be restarted for every request, where servlets are pooled and reused over and over again to service many requests. This means you don’t have to restart a process every time a new request comes over the network. This greatly enhances performance. Servlets are pooled by an external manager called a servlet engine in the same way that enterprise beans are pooled by an EJB container.

Web servers are a specific type of server that communicates with clients using the HTTP protocol. A Web server is responsible for accepting HTTP requests and sending back HTTP responses. An HTTP servlet is a servlet that works using the HTTP protocol. This is shown in Figure 12.10. Note that you can define other types of servlets as well—the concept of servlets is protocol-independent.

3: perform logic

Figure 12.10 HTTP servlets.

Go back to the first page for a quick link to buy this book online!

358 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Servlets in Our E-Commerce Deployment

Our e-commerce deployment will make extensive use of servlets for our presentation tier. To fulfill Jasmine’s requirements, we’ll define the following servlets.

A Login servlet. The Login servlet will be the first servlet the user deals with when going to Jasmine’s Web site. It’s responsible for reading in the user’s name and then retrieving the appropriate Customer entity bean that matches that name. It then compares the user’s submitted password with the permanent password stored with the Customer entity bean.

If the passwords match, a new shopping cart (or quote) needs to be created for that user. Hence, a Quote stateful session bean is started on behalf of this customer. The Customer information is stored in the Quote so that the Quote will contain the user’s billing and shipping information. As the user navigates the store, the Quote will serve as a shopping cart to which the user can add and remove products.

If the passwords don’t match, an error is displayed and the user is given another chance to enter a password.

A Web Storefront servlet. Once the user gets through the Login servlet, he or she will be redirected to the Web Storefront, which is the main page for Jasmine’s store. This is the main navigation page for Jasmine’s store. It links to the Catalog servlet and the View Quote servlet.

A Catalog servlet. To start adding products to the Quote, the user can browse the list of products available by going to the catalog servlet. He or she can also view details of a particular product, in which case the Catalog servlet will direct the user to the Product Detail servlet, described later.

A Product Base servlet. Many of our servlets need to work with Product entity beans. It would be very inefficient to have each servlet communicate across the tier boundary every time a Product needed to be found. Therefore, we cache our entire product line in a Product Base servlet. The Product Base servlet never interacts directly with the user. It’s simply a servlet that other servlets can call when they need to retrieve Products.

A Product Detail servlet. When the user wants information about a particular product in the catalog, the Product Detail servlet shows that information. From this screen, the user can add the Product to his or her Quote.

A Quote View servlet. The user is able to view and modify the Quote at any time by going to a separate page, manifested by the Quote View servlet. The user can view each of his or her selections from this page, as well as change the desired quantities of the selected products. Every time the user changes something, our Quote View servlet recalculates the price of the Quote by calling the Pricer stateless session bean.

Go back to the first page for a quick link to buy this book online!

J2EE in the Real World: Designing an E-Commerce Object Model 359

A Purchasing servlet. Finally, when the user is happy, he or she can convert the Quote stateful session bean into an Order entity bean. When generating the Order, this Purchasing servlet contacts a Bank Teller stateless session bean to transfer funds to Jasmine’s account. The user is then shown his or her Order Number, which is extracted from the Order bean.

Presentation Tier Object Model Summary

This completes our object model design for our presentation tier. The flow of control for our servlets is depicted in Figure 12.11.

print receipt

Purchasing

Servlet

make the purchase via Teller bean, and generate the Order

Used behind the scenes to store references to

Add Product

Product entity beans.

to user's Quote

Figure 12.11 State diagram for our e-commerce servlets.

Go back to the first page for a quick link to buy this book online!

360 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Summary

In this chapter, we’ve painted a picture of how our e-commerce system should behave. Now that we’ve made the proper abstractions, our components should fall into place very easily. By performing this high-level analysis, we can be confident that our final product will be extensible and reusable for some time to come.

Go back to the first page for a quick link to buy this book online!