Importing Java Transactions from an External EIS Using JCA 1.5 Transaction Inflow
- Introduction
- Sharing Transactions
- Crash Recovery
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Transactions are the backbone of enterprise systems, and the introduction of inbound transactions in the Java Connector Architecture (JCA) 1.5 specification is a great step toward seamless integration of heterogeneous systems. Transaction inflow contracts provide a mechanism for importing external transactional contexts, for transaction completion, and for crash recovery. But implementing these contracts is a complex and challenging task. This article explores the process of implementing contracts, explaining the contract in detail and designing a resource adapter capable of importing transacted messages originating from an external enterprise information system (EIS).This article has attempted to explain the transaction inflow, discussing the theory behind the inflow contract and implementing a resource adapter to import a transaction.
Introduction
Let's consider a travel company called MoonTravel, which has an in-house application called the Flight Reservation System (FRS). This system provides travel agencies with the capability of creating flight reservations, allowing travel agents to access MoonTravel's flight inventory in real time. MoonTravel doesn't intend to port this legacy application to the J2EE platform.
Recently, MoonTravel's Operations and Research departments have developed a revenue management system (RMS) that can vary ticket prices based on booking patterns coupled with geographic, seasonal, and other factors. The RMS is a semi-automated J2EE application that can add supplements to flight prices based on recommendations from the application's intelligence process. These recommendations are executed on a nightly basis. The RMS depends on the FRS for real-time booking feeds. Whenever a booking is confirmed, the FRS should update the RMS systems so that pointers to the booking patterns can be added to the RMS databases.
Integration of these two systems is a challenging task for MoonTravel's developers. A major requirement is to include external workflow in current transactions.
Whenever a travel agent confirms a booking, the FRS has a finite workflow:
- Add the order.
- Update the customer database and the order status.
- Update the agency revenue database.
- Update the flight inventory database.
- Bill the customer.
- Send a message to the RMS and update the operational database.
- Send a confirmation to the parties involved.
All of these tasks must be performed in a transaction. Step 6, sending a message to the RMS and updating the operational database, is the point where the two heterogeneous systems interact. That is, a legacy EIS stretches its transaction boundaries to the application server.
Until the advent of the Java Connector Architecture, there weren't any standards to transactionalize the workflow between disparate systems. Connector architecture has come a long way in developing standards for integrating the enterprise.