10.2 Model Problem: Retail Supply System

A model problem describes the design context. Two roles are involved in the description of the process: the architect and the engineer. The architect is the technical lead on the project and is responsible for overall design decisions. The engineer executes the model problem at the direction of the architect.

1. The architect and the engineer identify a design question. This question initiates the model problem and addresses an unknown that is expressed as a hypothesis.

2. The architect and the engineer define the starting evaluation criteria. These criteria will be used to determine whether the model solution will support or contradict the hypothesis.

3. The architect and the engineer define the implementation constraints. These constraints specify the fixed, or inflexible , part of the design context. They may include platform requirements, component versions, and business rules.

4. The engineer produces a model solution within the design context. The model solution is a minimal application that uses only those features of a component (or components ) necessary to support or contradict the hypothesis.

5. The engineer identifies ending evaluation criteria, which include the starting criteria and criteria discovered as a by-product of implementing the model solution.

6. Finally, the architect evaluates the model solution against the ending criteria. Although the evaluation could result in rejecting or adopting the design solution, it often leads to generating new design questions that must be resolved in a similar fashion.

Modernizing the Retail Supply System (RSS) consists of replacing legacy program elements with functionally equivalent EJBs. These beans are then deployed on a J2EE platform: in this case, the IBM WebSphere application server.

As modernized functionality is deployed incrementally, transactions that were processed entirely in COBOL may now be distributed across both legacy and modernized components. Figure 10-1 shows the system after incrementally deploying some modernized components. This illustration indicates that both the legacy COBOL code and the modernized EJBs may update or access the database.

Figure 10-1. The operational system during modernization

Figure 10-2 shows an operation involving both legacy code and modern components. In this diagram, the legacy COBOL module updates Table 2 by means of an SQL UPDATE. The COBOL module then invokes a method in a modernized component via an adapter that results in an SQL UPDATE to Table 1. Because the RSS modernization strategy maintains records in a single Oracle database, two-phase commit does not need to be supported in this scenario.

Figure 10-2. Transactional update of database records

To perform these updates within a transaction context, it is necessary to start and commit the transaction. Some scenarios might suggest starting or committing transactions in either the legacy or the modernized components. For simplicity, we assume that transactions are always started and committed from the legacy COBOL system. The problem is how to maintain transactional integrity across the COBOL-to-EJB interface. Several possible solutions are presented in the following section.