8.2. Order Processing Center Architecture and Design
We start the examination of the order processing center architecture and design with the problem statement. We then look at the key design choices that were made to solve the problem.
8.2.1. Web Service Interaction and Message Exchange
The key architectural problem that the adventure builder enterprise must solve is the communication and interaction among different entities or applications, both internal and external entities. (Refer to Figure 8.2 on page 343, which shows the lines of communication between the application entities.) These entities and applications must communicate with each other, often exchanging messages such of documents of various types across numerous boundaries, and work together in a coordinated fashion to solve particular business problems.
Let's take a closer look at the message exchanges that occur during the order fulfillment process, starting with the communication between the customer and the customer Web site, and then from that Web site to the order processing center. Such communication is fairly typical of most Web services-based applications.
Clients or customers communicate with the customer Web site via a Web browser.
Once a customer places an order, the customer Web site communicates a purchase order to the order processing center.
The customer Web site also follows up with the order processing center to ascertain the current status of an order.
The order processing center sends credit card processing details for verification to the credit card service.
The order processing center sends purchase orders to suppliers and receives invoices from these suppliers.
Within the order processing center module, different application entities handle such functions as receiving, tracking, and processing orders. These entities need to interact with each other to coordinate the processing of an order. Other application entities handle requests for order status.
Since you are building an application that enables different entities to communicate and interact to accomplish a set of tasks, you need to make design choices that foster this interaction. These choices center around communication technologies and message formats.
8.2.1.1. Communication Technologies
You must decide on the best communication technology for your application. Recall from “Communication” on page 23 that, when developing on the J2EE platform, you can use such communication technologies as JMS, RMI/IIOP, Web services, and so forth. Each technology is appropriate for different circumstances. For each interaction among the order processing center entities, we chose a particular communication technology.
For adventure builder, we chose to use Web services as the technology for communication between the order processing center and entities external to the order processing center, such as for the exchange of purchase orders and invoices with external partners and suppliers. We made this choice because we are primarily interested in achieving the greatest degree of interoperability among all modules and among all types of clients.
It is important for adventure builder to be able to integrate its functionality with that of its numerous partners, since they actually provide the services adventure builder offers to customers. Web services with its emphasis on interoperability gives these partners the greatest degree of flexibility in the technologies that they use. Web services also provide a good interface for separating and decoupling software systems. This is important for adventure builder since it is building on existing systems and modules developed and owned by different departments within the enterprise.
For communication between the order processing center and entities external to the order processing center, we chose to use Web services.
Within the order processing center module, the communication among sub-modules primarily uses JMS. Since the order processing center controls the entire environment within the module, communication can be more tightly coupled. Most of the communication is between the order processing center workflow manager and the various department sub-modules, and all sub-modules are within this environment. Given the control over the environment and that most communication is asynchronous, using JMS is appropriate. Also, since there is additional overhead to using Web services, an application should use it only when it requires the benefits of Web services. For the communication among the entities within the order processing center, the overhead of Web services outweigh its benefits.
We chose to use JMS for communications among entities within the order processing center.
Generally, Web services are a good choice for communication external to the enterprise, but they can also be applied to internal situations. The order processing center and customer Web sites are within the same enterprise, albeit different departments, and they use Web services rather than JMS. The order processing center module makes its services available as a Web service to the customer Web site—that is, the Web site uses the order processing center's Web service to fulfill an order. There are advantages to this implementation. For one, the Web site for the order processing center module may be hosted outside the firewall in a demilitarized zone (DMZ), even though the order processing center module itself is always inside the firewall. The Web site may conveniently use the HTTP port available on the firewall to communicate with the order processing center. Also, Web services allow both client and server to be on different hardware and software platforms. This makes Web services a natural choice, since the adventure builder Web site may be hosted on a different hardware platform (and software platform) from the order processing center module. Developers may want this platform flexibility since the Web site is on the Internet and may need to scale to handle very large loads. Furthermore, the Web site must be responsive to customers, whereas the order processing center module, since it works asynchronously, is concerned with achieving high throughput.
8.2.1.2. Message Format
The adventure builder business problem involves the exchange of many different types of messages, whose payloads contain documents such as purchase orders and invoices from different suppliers. Some of these message payloads adhere to an internal format and others follow standard formats. Since the system must handle multiple message types, we use XML as the message payload format.
While we can pass information either as XML documents or as Java objects, the choice of communication technology has implications for how information is passed through the system. Primarily, we use XML documents for communication on the edges on the enterprise, especially for messages exchanged with trading partners.
But since we also use JMS internally within the order processing center, we had to choose to either pass XML documents between sub-modules or to convert documents to Java objects. Since we are modelling a document-oriented system, and since the sub-modules represent different departments, we decided to pass XML documents among them. By passing information in this format, internally each department has control over binding to the particular Java objects they need within their module. Had we bound from XML documents to Java objects at the edges of the enterprise, then this sub-module independence would not be the case. Passing XML documents also plays well for our particular architecture, which has a centralized workflow coordinator or manager that keeps the individual sub-modules and departments from directly communicating. In short, this keeps our department sub-modules more loosely coupled.
We chose XML to be the message format for communication with internal as well as external entities.
8.2.2. Communication Architecture
Figure 8.4 shows the architecture of the communication infrastructure for adventure builder.
The order processing center uses a workflow manager, which contains all process rules and flow logic, to coordinate processing of the orders. The workflow manager also keeps track of the current state of each order while it is processed.
Each participant knows its business functionality and how to execute its own step in the workflow; it does not need to know other steps in the process.
Generally, each order processing center participant (such as the order filler) has a JMS resource and receives XML documents. The JMS resource is the integration point between the manager and each work module.
A centralized endpoint manages the interactions between the suppliers and the order processing center. Rather than having a separate Web service endpoint for each message, all interactions between the order processing center and suppliers are grouped together and handled by a common endpoint and interaction layer.
Other parts of the order processing center may act directly as clients to Web services without using the centralized endpoint. For example, the finance module uses the credit card service.
The order processing center internally uses a hub-and-spoke model where the workflow manager coordinates the participants in the order fulfillment process. Each participant receives an XML document from the workflow manager, processes the XML document by applying its portion of the business logic, and returns the result to the workflow manager. The workflow manager determines the next step to execute in the workflow and dispatches the appropriate request, by sending an XML document, to the proper participant. Each individual participant executes their part of the business functionality and has no need to know the overall process of the workflow.
The Web service endpoints, used on the edges of the order processing center for interactions between the order processing center and its external entities, have different considerations. You should consider each endpoint design individually, based on its particular interactions. Sometimes, to make communication more manageable, it's possible to group together sets of interactions into a simplified structure. See the next section for more details about endpoint considerations and choices. See “Web Service Communication Patterns” on page 358 for a discussion of more complex Web service interactions, as well as how to provide structure to Web service communications.