Section 16.2. Architecture

16.2. Architecture

As it is often the case in intra-enterprise integration scenarios, most of the applications that provide each of the validation steps already exist and have been implemented using various technologies and on different platforms. This situation makes a perfect example for a Web services integration solution. The basic service-oriented architecture approach is to identify the core constituent services and then develop compositions and integrations of those services into additional services and the full solution.

In this case, because each of the steps of the verification and purchase processes is self-contained, typically implemented by separate applications, it is natural to model each one as a service. It is possible to model the actual ordering process as a self-standing service with two main operations: one for validating the service packs that were selected, and a second one to purchase the service pack. Both operations could be implemented as BPEL processes, although this example does not provide a BPEL implementation of the service. The overall architecture of the integrated systems is shown in Figure 16-1.

Figure 16-1. Service pack application as a service composition.

Each input request might contain multiple orders. The validate operation is a straightforward process that first iterates over the list of ordered items. and, for each item, over the service packs included with the order. For each service pack, a set of tests is executed by invoking the services that the existing applications expose for that purpose. The different tests mentioned in the previous section are sequentially performed for each service pack. As the figure shows, some tests are run against the line item as a whole (validate country and machine model), whereas others are run against individual service packs for each order.

The second operation of this service is a purchase operation that charges the cost of each purchased item (machine plus service packs) to the customer account and updates the customer profile with the purchase, a necessary step to ensure delivery and service and to monitor customer purchasing activity. These two steps are directly related and must be performed atomically as a unit. To do so, the service code starts an atomic transaction before accessing the two backend services; the coordinator of the transaction at the aggregator service interacts with coordinators at each back-end service to ensure the all or none semantics and to roll back completed work as necessary in case of failure.

WS-Security protocols protect the interaction with the client. In the case of the validation operation, messages are signed to ensure integrity; when purchasing the service pack, the messages exchanged are also encrypted. The interaction with back-end services does not require this level of protection because it takes place in a secure environment. The atomic transaction protocol that is specified in WS-AtomicTransactions supports the execution of the purchase operation, as explained previously.