Mainframe Transactions in an SOA

4 Pages

Service-Oriented Architecture (SOA) continues to draw an increasing amount of attention from the enterprise IT community. The building blocks of an SOA are the services available through well-defined, standardized interfaces such as a Web services interface. As organizations strive to make their IT resources more effective, they’re realizing that achieving factorial savings and gains are possible only if they can make their existing programs available as services that can be reused.

Because many organizations today continue to rely on mainframe systems for high-volume, high-availability transaction processing, it’s natural to associate the mainframe with transactions and to ask for transaction support when service- enabling legacy mainframe assets for use in an SOA.

Rather than define a transaction, this article assumes awareness of the usual transaction scenarios and how information, such as details of a money transfer between two accounts, shouldn’t get lost. We also highlight the challenges of exposing such external transactions to a mainframe and present several possible solutions to these challenges, eventually breaking out of the common perception that standard Web services are required in an SOA.

Why Transactions Must Be ACID

Transactions involve multiple resources and are typically described as being ACID—Atomic, Consistent, Isolated, and Durable. Atomicity requires all resources to either commit or roll back, therefore providing a predictable result. Consistency requires the data source to be in an expected state at any time and guarantees integrity. Isolation prevents concurrent transactions from updating the same data effectively, with the same data integrity in mind. Durability ensures the data gets persisted on the data source. Consistency and isolation are achieved by introducing  a locking mechanism. The data is locked while a decision is made whether to commit or roll back to protect the data source and avoid the data being changed by concurrent transactions.

Such a lock is acceptable when working locally, since actions are typically predictable due to their ACIDity and are extremely fast, especially when looking at transactions running on mainframes. In a Web services context, however, it’s possible to break out of the consistency principle.

Why Standard Web Services Aren’t ACID

Taking a closer look at the locking mechanism, we should first understand how this impacts transactions in the context of only the mainframe. Here, there’s direct interaction between all required parts of the system, including the resource recovery service, such as the transaction coordinator, and the resource managers such as CICS or IMS and DB2. Through this direct interaction, atomicity is guaranteed.

In this situation, the close proximity of the participating resources and their direct control requires that locks be held only for a short time and, therefore, barely affect performance (at least with reasonable load and a proper system configuration). This trust situation is required for efficient local transactions.

Matters are complicated when transactions are extended to include external resources and an external transaction coordinator. In this situation, the common solution is to expose the mainframe resource via a Web service to participate in the SOA. While Web services can be based on any transport, they typically use the HTTP protocol, which is of a stateless nature, or asynchronous messaging.

4 Pages