10.3 Contingency Planning

A fundamental technique of component-based software engineering is contingency-based design. Simply put, contingency-based design pursues multiple design options in parallel. This technique is especially critical when using commercial components , because their evolution is driven by the marketplace , and their implementations are typically opaque to the architect.

Several technologies included in the SRF seemed able to maintain the transaction context between the legacy COBOL system and the modernized system. This section presents design alternatives based on these technologies, along with our initial evaluation of their feasibility.

MQSeries

Existing RSS modernization plans call for the use of MQSeries to communicate between the legacy COBOL and modernized EJB systems. IBM's MQSeries provides asynchronous communications and uses independent queues to relay messages between communicating processes, as shown in Figure 10-3. MQSeries was discussed in some detail in Section 9.3.

Figure 10-3. MQSeries messaging

MQSeries provides limited support for transactions. For example, let's assume that application A in Figure 10-3 represents the legacy system code written in Micro Focus COBOL. Application B represents a modernized component developed as an EJB and deployed in the WebSphere application server. The queue is an input queue for the modernized component. We assume that the legacy code passes a message via MQSeries to the modernized component to perform a function. We also assume that this function must be accomplished as part of a transaction. To do this, the Micro Focus COBOL program element must start a transaction and pass a message. However, once the EJB component removes the message from the queue, the transaction context is no longer maintained . This means that any database operations performed by the EJB component takes place outside the transaction context.

Because of this limitation in transaction propagation, we did not develop MQSeries further as a solution to the model problem. However, we maintained it as a possible design contingency in case an asynchronous, message-oriented approach became a requirement.

Object Transaction Service

Object Transaction Service (OTS) is a distributed transaction-processing service specified by the Object Management Group (OMG). This specification extends the CORBA model and defines a set of interfaces to perform transaction processing across multiple CORBA objects. CORBA uses IIOP as an interoperable protocol for communication between distributed objects.

As of the EJB v1.1 specification, RMI over IIOP has become the standard mechanism for supporting communication between a client and EJBs and between EJB containers. IIOP is well suited for this purpose because it supports the propagation of both a transaction and a security context.

To use OTS as a solution, we would need to find COBOL-language bindings to a CORBA and OTS implementation. The optimal solution would be to use ComponentBroker, IBM's OTS implementation. Because this product is an integral component of WebSphere, we could be confident that it would work in our target environment. Unfortunately, IBM ComponentBroker did not have a Micro Focus COBOL interface.

Although this approach appears to have potential, we had difficulty identifying a Micro Focus COBOL-to-CORBA binding. A possible workaround was to use a Java CORBA binding, accessed through a Micro Focus COBOL-to-Java language interface. However, we decided not to develop an OTS model problem at this time but maintained it as a potentially viable design contingency.

Oracle Pro*COBOL

The Pro*COBOL precompiler is a programming tool that supports embedded SQL statements in high-level programming languages. It accepts the program as input, translates the embedded SQL statements into standard Oracle runtime library calls, and generates a source program that can be compiled, linked, and executed.

Although it claims to be compatible with Micro Focus Object COBOL, Pro*COBOL does not provide a solution for transaction management. Pro*COBOL is used primarily to preserve business logic in legacy COBOL programs when data is migrated to an Oracle database. Although Pro*COBOL supports transactions in embedded SQL statements, it does not solve the problem of maintaining a transaction context between legacy and modernized components. As a result, we eliminated this contingency as a possible design solution.

Net Express

Micro Focus Net Express is an integrated development environment (IDE) for developing procedural COBOL/Object COBOL-based applications. Net Express provides mixed-language programming support for procedural COBOL, Object COBOL, and Java mixed-language programming, as well as WebSphere distributed-transaction technologies.

For mixed-language programs, Net Express supports calling Java code from Micro Focus COBOL, as well as calling Micro Focus COBOL from Java code. Net Express also supports wrapping Micro Focus COBOL within an EJB. Because each approach supports mixed-language programs, we examined each.

Wrapping COBOL Code

Wrapping COBOL code within EJBs would allow the system to be migrated quickly to a J2EE environment, although not one consisting of 100% Pure Java code. To implement this approach, each legacy program element must be wrapped as an EJB, and all the internal calls must be converted to invoke the new Java methods , requiring the COBOL code inside the Java code to call Java again. This approach has several apparent consequences.

Turning legacy program elements into EJBs guarantees that the legacy architecture is maintained, because the decomposition of the system remains constant, and the calls between program elements remain the same. As a result, this approach is incompatible with the RSS desire to migrate to a new target architecture.
The majority of the modernized system, especially the business logic, is still implemented in COBOL. This means that any maintenance problems that existed will remain and be further complicated by the problems associated with maintaining a multilanguage system.
Modernizing the system in this manner is not conducive to incremental development and would require a big-bang deployment of COBOL-filled EJBs.
The primary advantage of this approach is that it is a relatively inexpensive way to create a componentized system. However, the characteristics of this modernized system would not be very different from those of the legacy system. As a result, we eliminated this approach as a possible design contingency.

Calling Java from COBOL

The second approach using Net Express is to call Java directly from the Micro Focus COBOL program elements. This approach would invoke EJB methods directly from Micro Focus COBOL and support WebSphere distributed transactions. As this approach appears to satisfy our requirements, we decided to construct a model problem to evaluate this design contingency.

Figure 10-4 illustrates the results of the contingency-planning process. We have eliminated two contingencies: wrapping COBOL code using Net Express and using Oracle Pro*COBOL. Of the remaining three contingencies, we decided to implement a single model problem using Net Express to call Java from COBOL.