11.2 A Tale of Two Architectures

Two architectures are included in the SRF: one based on the J2EE and the other based on B2B integration. Although they may be complementary, the two architectures address different needs. As a result, it is necessary to understand when we should prefer one architecture to the other.

In this chapter, we evaluate both architectures and supporting technologies against RSS requirements. Because working implementations of each approach are unlikely to be available at this point in the process, it is necessary to perform an architecture-level analysis, using an approach akin to the architectural trade-off analysis method (ATAM) [Clements 01]. Specifically, we generate scenarios based on RSS requirements. According to the authors of ATAM:

A scenario is a short statement describing an interaction of one of the stakeholders with the system. A user would describe using the system to perform some task; his scenarios would very much resemble use cases in object-oriented parlance. A maintainer's scenario would describe making a change to the system, such as upgrading the operating system in a particular way or adding a specific new function. A developer's scenario might talk about using the architecture to build the system or predict its performance. A customer's scenario might describe how the architecture is to be re-used for a second product in a product line. [Kazman 01, p. 13]

Each architecture is evaluated to determine how well it supports each scenario. Order placement is an example of a scenario derived from RSS. In order placement, inventory is checked when an order is placed. If stock is available, it is placed on reserve and will not be decreased until the order is shipped. If stock is not available, the Regional Supply Center is notified and a requisition created for the item(s) out of stock. An order does not get created in the system and stock is not placed on reserve until fund availability is verified . If the order creation is successful, the warehouse system is notified.

Data from the architectural evaluation is analyzed to determine where and how each architecture should be applied in a modernization effort. Before beginning this evaluation, we provide a brief description of both architectures in the following sections.

J2EE Architecture

J2EE applications are typically transactional systems that implement components as enterprise beans running in an EJB server. These components communicate using synchronous method calls [J2EE 02], although binding does not occur until runtime. ^[1] The J2EE implementation specified in the SRF is IBM WebSphere. We use this product as an example of a J2EE architecture, although our analysis of this architecture is largely product independent.

^[1] J2EE also supports asynchronous messaging between components through the Java Message Service (JMS). Here, however, we are considering only the synchronous communication mechanism provided by RMI/IIOP.

Figure 11-1 illustrates the sequence of interactions involved in implementing order placement using a J2EE-style architecture. The entire sequence takes place within a transaction context, so the entire transaction can be rolled back if any operation fails. This architecture greatly simplifies handling error conditions.

Figure 11-1. Order placement scenario in the J2EE architecture

B2B Architecture

The second method is based on the nontransactional, integration approach represented by business-to-business integration (B2B). A fairly broad range of integration approaches falls under the category of B2B. For our purposes, we consider only B2B integration that involves

• Asynchronous message passing using some form of message-oriented middleware (MOM)

• Business objects that communicate using a common, standardized business data “interchange format, such as those proposed by ebXML, OAGIS, or RosettaNet.

In particular, we use IBM MQSeries as a MOM implementation and OAGIS as a business data “interchange format because both are specified in the SRF.

Figure 11-2 illustrates the sequence of activities required to implement the order placement scenario in a B2B architecture. Although the possibility exists that an asynchronous message may time out and not be processed , this error condition is not depicted in the sequence diagram, for clarity. Nevertheless, the system/business object sending the BSR must include logic to react appropriately to this situation: for example, roll back a transaction, send a message to a log file, or request user intervention. CONFIRM messages occur only if confirmation is specified. ^[2]

^[2] Because each BOD in the OAGIS is named after the information contained in the BSR, we have decided to use the term BSR to indicate a message containing an OAGIS BOD.

Figure 11-2. Order placement scenario in the B2B architecture

The B2B sequence is significantly different from the J2EE sequence because of the lack of a transaction context. In the B2B scenario, the entire order placement use case must be implemented as a sequence of operations that can be rolled back using compensating operations. To a large extent, this requires the business object that initiates the transaction to keep track of the state of the transaction. The business object must also know how to reverse the results of any previous successful operations at each point of failure.

Significant trade-offs exist in performance, modifiability, data integrity, and other business and system qualities between the J2EE and B2B architectures. The remainder of this chapter evaluates these trade-offs.