ActionBazaar is a simple online auctioning system like eBay. Sellers dust off the treasures hidden away in basement corners, take a few out-of-focus pictures, and post their item listings on ActionBazaar. Eager buyers get in the competitive spirit and put exorbitant bids against each other on the hidden treasures with the blurry pictures and misspelled descriptions. Winning bidders pay for the items. Sellers ship sold items. Everyone is happy, or so the story goes.
As much as we would like to take credit for it, the idea of ActionBazaar was first introduced in Hibernate in Action by Christian Bauer and Gavin King (Manning, 2004) as the CaveatEmptor application. Hibernate in Action primary dealt with developing the persistence layer using the Hibernate object-relational mapping (ORM) framework. The idea was later used by Patrick Lightbody and Jason Car-reira in WebWork in Action (Manning, 2005) to discuss the open source presentation-tier framework. We thought this was a pretty good idea to adopt for EJB 3.
The next two parts of this topic roughly follow the course of developing each layer of the ActionBazaar application as it relates to EJB 3. We’ll use EJB 3 to develop the business logic tier in part 2, and then the persistence tier in part 3. We’ll deal with the presentation layer as necessary as well.
This section will introduce you to the ActionBazaar application. We start with a subset of the architecture of ActionBazaar, and then we’ll design a solution based on EJB 3 and JPA. After this section, the rest of the topic explores some of the important features of EJB 3, using examples from the ActionBazaar application to introduce you to the various bean types and show how they are used.
Let’s begin by taking a look at the requirements and design of our example.
Starting with the architecture
For the purposes of introducing all three EJB 3 component types across the business logic and persistence layers, let’s focus on a small subset of ActionBazaar functionality in this topic—starting from bidding on an item and ending with ordering the item won. This set of application functionality is shown in figure 2.2.
The functionality represented in figure 2.2 encompasses the "essentials" of ActionBazaar. The major functionalities not covered are: posting an item for sale, browsing items, and searching for items. We’ll save these pieces of functionality for parts 2 and 3. This includes presenting the entire domain model, which we’ll discuss in topic 7 when we start talking about domain modeling and persistence using JPA.
Figure 2.2 A chain of representative ActionBazaar functionality used to quickly examine a cross section of EJB 3. The bidder bids on a desired item, wins the item, orders it, and instantaneously receives confirmation. Parallel with order confirmation, the user is billed for the item. Upon successful receipt of payment, the seller ships the item.
The chain of actions in figure 2.2 starts with the user deciding to place a bid on an item. Our user, Jenny, spots the perfect Christmas gift for Grandpa and quickly puts down a starting bid of $5.00. After the timed auction ends, the highest bidder wins the item. Jenny gets lucky and no one else bids on the item, so she wins it for the grand sum of $5.00. As the winning bidder, Jenny is allowed to order the item from the seller, Joe. An order includes all the items we’ve come to expect from online merchants—shipping information, billing details, a total bill with calculated shipping and handling costs, and so on. Persuasive Jenny gets Mom to foot the bill with her credit card and has the order shipped directly to Grandpa’s address. Not unlike many e-businesses such as Amazon.com and eBay, ActionBa-zaar does not make the user wait for the billing process to finish before confirming an order. Instead, the order is confirmed as soon as it is reasonably validated and the billing process is started in parallel in the background. Jenny gets an order confirmation number back as soon as she clicks the Order button. Although Jenny doesn’t realize it, the process to charge Mom’s credit card starts in the background as she is receiving the confirmation. After the billing process is finished, both Jenny and the seller, Joe, are sent e-mail notifications. Having been notified of the receipt of the money for the order, Joe ships the item, just in time for Grandpa to get it before Christmas!
In the next section, you’ll see how the business logic and persistence components for this set of actions can be implemented using EJB 3. Before peeking at the solution diagram in the next section, you should try to visualize how the components might look with respect to an EJB-based layered architecture. How do you think session beans, MDBs, entities, and the JPA API fit into the picture, given our discussion? Chances are, with the probable exception of the messaging components, your design will closely match ours.
An EJB 3-based solution
Figure 2.2 shows how the ActionBazaar scenario in the previous section can be implemented using EJB 3 in a traditional four-tier layering scheme. For our purposes, the presentation tier is essentially an amorphous blob that generates business-tier requests in response to user actions. If you examine the scenario in figure 2.2, you’ll see that only two processes are triggered by the user—adding a bid to an item and ordering items won. One more process might be apparent: the background billing process to charge the order, triggered by order confirmation. If you guessed that the billing process is triggered through a message, you guessed right. As you can see in figure 2.3, the bidding and ordering processes are implemented as session beans (PlaceBidBean and PlaceOrderBean) in the business logic tier. On the other hand, the billing process is implemented as an MDB (OrderBillingMDB) since it is triggered by a message sent from the PlaceOrderBean instead of a direct user request.
All three of the processes persist data. The PlaceBidBean needs to add a bid record to the database. Similarly, the PlaceOrderBean must add an order record. Alternatively, the OrderBillingMDB updates the order record to reflect the results of the billing process. These database changes are performed through two entities in the JPA-managed persistence tier—the Bid and Order entities. While the PlaceBidBean uses the Bid entity, the PlaceOrderBean and OrderBillingMDB use the Order entity.
Figure 2.3 The ActionBazaar scenario implemented using EJB 3. From the EJB 3 perspective, the presentation layer is an amorphous blob that generates business-tier requests. The business-logic tier components match up with the distinct processes in the scenario—putting a bid on an item, ordering the item won, and billing the user. The billing MDB is triggered by a message sent by the order confirmation process. The business-tier components use JPA entities to persist application state into the database.
Recall that although JPA entities contain ORM configuration, they do not persist themselves. As you’ll see in the actual code solutions, the business-tier components have to use the JPA EntityManager API to add, delete, update, and retrieve entities as needed.
If your mental picture matches up with figure 2.3 pretty closely, it is likely the code we are going to present next will seem intuitive too, even though you don’t know EJB 3.
In the following sections, we explore each of the EJB 3 component types using our scenario. Without further ado, we can now begin our whirlwind tour of EJB 3 component types, starting with the session beans in the business-logic tier.
