We begin with an examination of the adventure builder application from a high-level, business perspective. Once we have outlined the application's functions, we shift to examining the architecture and design of the application itself.
Recall that the adventure builder enterprise provides customers with a catalog of adventure packages, accommodations, and transportation options. From a browser, customers select from these options to build a vacation, such as an Adventure on Mt Kilimanjaro. Building a vacation includes selecting accommodations, mode of transport, and adventure activities, such as mountaineering, mountain biking to a hidden waterfall, and hiking the mountain. After assembling the vacation package, the customer clicks the submit order option. The customer Web site builds a purchase order and sends it to the order processing center (OPC). The order processing center, which is responsible for fulfilling the order, interacts with its internal departments and the external partners and suppliers to complete the order.
In essence, the adventure builder enterprise consists of a front-end customer Web site, which provides a face to its customers, and a back-end order processing center, which handles the order fulfillment processing. See Figure 8.1.
As you can see from this diagram, there are four types of participants in adventure builder's business process:
Order processing center— The order processing center (OPC) is at the heart of the adventure builder enterprise, responsible for coordinating all activities necessary to fulfil a customer order. It interacts with:
The customer Web site to handle order-related matters
Customers, sending them e-mail notifications regarding orders
A credit card service to collect payment
Suppliers to fulfill the items in an order
Internal adventure builder departments to support and manage the order fulfillment process
The business problem for adventure builder is to ensure that these participants interact successfully so that it can sell and fulfill adventure packages. To solve this problem, the enterprise must architect, design, and build appropriate J2EE applications that provide the needed business functionality and tie the application modules together. Since the order processing center is the core module of the application, let's look at it in more detail, starting with its responsibilities for coordinating and communicating with other business units to fulfill orders. (Since this book is about Web services, we do not cover the design of the customer Web site in detail. Other books, particularly Designing Enterprise Applications with the J2EE Platform, Second Edition, address this area. See “References and Resources” on page xx.)
The order processing center module needs to perform the following functions:
Receive customer orders from the customer Web site and process these orders
Coordinate activities according to the business workflow rules
Track an order's progress through the steps of the order fulfillment process
Manage customer relations, including tracking customer preferences and updating customers on the status of an order. This includes sending formatted e-mails to customers about order status.
Manage financial information, including verifying and obtaining approval for payment
Interact with business partners—airlines, hotels, and adventure or activity providers—to fulfill a customer's adventure package.
Provide and maintain a catalog of adventures and allow customers to place orders. The order processing center catalog manager needs to interact with external suppliers and also keep its customer offerings up to date.
First, let's examine the order processing center by decomposing it into its logical sub-modules. Figure 8.2 shows the main sub-modules of the order processing center and their relationships to the other participants.
Order Receiver— Accepts purchase orders from the customer Web site. This sub-module starts the order fulfillment processing in the back end of the enterprise. Each order is identified by a unique ID.
Workflow Manager— Enforces the process flow rules within the adventure builder application and tracks the state of each order during its processing. The workflow manager interacts with the internal departments and coordinates all the participants in the business process.
Finance— Interacts with external banks and credit card services that collect payments, and manages financial information.
Customer Relations Manager (CRM)— Provides order tracking information to the customer Web site application. This sub-module also sends formatted e-mail notices about order status directly to clients.
Order Filler— Exchanges messages with the various external suppliers to fulfill purchase orders. Messages include supplier purchase orders and invoices.
Keeping the picture of the various sub-modules in mind, let's map out the processing flow that occurs when a customer places an order. In particular, it is important to trace the messages and documents exchanged among participants.
A purchase order flows from the customer Web site to the order processing center.
The finance department and the credit card services exchange credit card payment requests and verifications.
The order processing center order filler and the external suppliers exchange supplier purchase orders, invoices, and other documents.
The workflow manager and other departments or sub-modules within the order processing center exchange internal messages.
Figure 8.3 shows the order fulfillment workflow. When it receives an order for an adventure package from a customer, the order processing center persists a purchase order. Before proceeding, it verifies that the customer has the available funds or credit for the purchase. If not, the order processing center cancels the order, notifies the customer, and updates the order status. Otherwise, it proceeds to fulfill the order, which entails breaking the entire adventure package order into sub-orders (such as a sub-order for a hotel room, another sub-order for airline reservations, and so forth). It sends the sub-orders to the appropriate suppliers, who fulfill these portions of the order and return invoices. The order processing center then joins these invoices for sub-orders so that the entire order is invoiced. The order processing center also updates the status of the order and notifies the customer.