From the Desk of Mohamad Afshar, PhD

Mohamad Afshar

Subscribe to Mohamad Afshar: eMailAlertsEmail Alerts
Get Mohamad Afshar: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, XML Magazine, SOA & WOA Magazine, ERP Journal on Ulitzer


SOA in Action Case Study: LibGo Travel

Experiences with caching, transactions, and security in a highly distributed, networked SOA in the travel and leisure industry

For LibGo, caching is a business necessity to meet performance requirements and avoid transaction costs. If you're developing an SOA, we strongly recommend that you consider multiple caching strategies to implement a better SOA. Always remember to cache your system codes. As long as you have management rules to avoid overcaching, caching will produce great returns.

Compensating Transactions Are Here to Stay
Remember the ACID properties of transactions (atomic, consistent, isolated, durable) and rollbacks in the database context? How about XA-based transaction managers that enable distributed transaction management across a number of platforms?

LibGo's business transactions are inherently distributed: travel bookings are usually packages, with each component provided by a different vendor. Early on we realized that most of our partners didn't offer sophisticated transactional interfaces to LibGo. Each time a customer request for a complete travel package (airline, hotel, car, and tickets to attractions) was processed, the NGTS system had to ensure that all constituent parts were available before committing the transaction. While standards bodies are addressing the general need to relax ACID properties and manage more complex business transactions within the context of Web services and SOAs, a pragmatic approach to manage our business transactions was needed. The idea to implement an all-purpose Web services transaction manager was quickly dismissed. Instead, LibGo decided to build a custom transaction manager and leverage existing transaction capabilities within their packaged applications, and at the same time, delay compensating transactions to the end of a serial transaction flow.

Avoid Compensating Transactions Where Possible
Our scheme was simple: easy-to-roll-back transactions would be executed up front, while the partner transactions would be delayed until the very end. Since the ERP system had sophisticated transaction capabilities, including rollbacks, LibGo decided that when building the composite application, the ERP-specific steps in the overall process are carried out first. If the ERP transaction didn't fail, the next gating steps would be executed - bookings across partner systems for airline and hotels. The model of sequentially ordered transactions minimizes the number of compensating transactions.

Work with Partners to Implement Compensating Transaction Logic Where Necessary
Some business transactions will need to be compensated. For this purpose, LibGo worked with partners to implement a scheme using unique transaction IDs that were passed in the XML request or SOAP header of each communication. The transaction ID would be set by the booking engine in NGTS each time a booking was to be made. Then, each partner system would append this unique transaction ID with its own information denoting the transaction path. This way, if part of a transaction failed, the compensation handler in the NGTS system has an audit trail that could be used to perform multistep compensating actions. This isn't necessary in the case of internal systems because these typically implement the rollbacks themselves, and so compensating transactions aren't necessary.

Here are LibGo's ground rules for distributed transactions in SOA:

  • If only one component can potentially break any two-phase transaction agreement, move it to the end of the execution chain. For example, ERP services provided by E-Business Suite cannot be called from within another transaction because they implement commit and rollback logic internally. Another example is a Web service that does not implement rollback logic. By using this scheme, the chances are that compensating transaction logic will not be executed unless all previous steps that participate in the transaction have completed successfully.
  • If more than one component is involved in breaking the two-phase transactions - for instance, both the hotel and airline bookings fail - the (custom) transaction manager must execute a compensating transaction. In the case of remote Web services, that amounts to sending a reverse message. If the compensating transaction also fails (after n attempts), then the transaction manager should generate a notification for manual recovery.
  • For components that are not designed for two-phase transactions (such as PL/SQL-stored procedures, which are transactional themselves), wrappers written as Java objects must be written. The wrapper participates in container-managed transaction (CMT) and acts as the transaction resource. If a rollback is necessary, the wrapper is responsible for the reverse/cancel action logic because the component doesn't support rollback. In case of failure, all of the Java (wrapper) objects participating in CMT need to implement the compensation logic. For example, the transaction that creates a customer, creates the lead in the Sales Online application, and places it on the queue, may fail at the final step. Since the customer creation and lead creation activities are transactions in themselves, it's necessary to write wrappers that implement the compensation logic for each of these.
  • For those components that support transactions but can't participate in CMT (for example, an external Web service for airline bookings), the transaction should be pushed in the wrapper, which is responsible for implementing transaction logic, including rollbacks. In case of failure, the wrapper needs to issue the rollback command to the underlying component that then implements the rollback. Since the component supports transactions, this is a cleaner model than the point mentioned directly above; however, many systems do not support rollback logic, and instead need to implement compensating transaction logic.
The transaction ID also helps deal with communication failure; for example, if a transaction acknowledgement from a partner is lost in the network, NGTS, which performs automated retries, would resend the communication with the same transaction ID. The partner's system would look up the transaction ID from a local hash map and resend the acknowledgement to NGTS if it had already performed the action, or would carry out the task in the case that it didn't receive the original communication. Implementing standards such as WS-RX for reliable messaging in middleware stacks from the likes of Oracle will also go a ways in making life simpler for practitioners who need reliable messaging.

LibGo also decided on one additional small upgrade: to place timestamps in the SOAP header or XML payload, depending on the service, and to require partners to implement a clock synchronization mechanism along with LibGo. This has greatly helped troubleshoot the complex transactions and pinpoint bottlenecks as part of the distributed transaction environment. In a distributed environment with multiple Web services, it's always hard to pinpoint the performance bottlenecks. However with the timestamp regime (you'll need a common time server), issues are resolved more quickly because it's possible to pinpoint the culprit right away.

Don't be intimidated by the new challenges of Web services transactions. Yes, you will have to worry about compensating transactions if partners don't participate in a transaction model, but often, a sequential approach to complex business transactions will minimize the chances of compensation. Don't try to solve world hunger; rather, find smart ways to leverage the context of your specific use case to delay compensating partner transactions to the very end. Make a unique transaction ID and a timestamp part of your transaction's SOAP header. Then, you'll be well prepared to execute compensation logic step-by-step to perform transaction playback.

Of course, standards will evolve for handling transaction semantics: WS-BusinessActivity, which formalizes undo semantics for long-running transactions, such as our booking transaction; WS-Coordination, which formalizes transaction IDs used across two or more transaction monitors; and WS-AtomicTransactions, which has stricter transaction semantics than WS-BusinessActivity and ensures strict, guaranteed atomic actions (such as writing a record to both a database and message queue). At LibGo, we continue to have a view to standards when implementing our SOA.

More Stories By Mohamad Afshar

Mohamad Afshar, PhD, is VP of Product Management at Oracle. He has product management responsibilities for Oracle's middleware portfolio and is part of the team driving Oracle's investments in SOA on Application Grid - which brings together SOA and data grid technologies to ensure predictable low latency for SOA applications. Prior to joining Oracle, he founded Apama, a complex event processing vendor acquired by Progress Software. He has a PhD in Parallel Systems from Cambridge University, where he built a system for processing massive data sets using a MapReduce framework.

More Stories By Armughan Rafat

Armughan Rafat is the lead architect of LibGo?s Next-Generation Travel System (NGTS). Rafat, who has been building large distributed systems for more than 10 years, holds an MS in Software Engineering and Technology Management and is certified for the Microsoft, Sun, and Oracle platforms. Prior to working at LibGo, he led projects at AT&T and Lucent as a lead architect. He specializes in creating Enterprise Architectures for large-scale projects and writes a blog on Enterprise Architecture.

More Stories By Markus Zirn

Markus Zirn is a senior director of product management for Oracle Fusion Middleware. He heads the Strategic Customer Program, where he works with Oracle's most innovative middleware customers. Recently, he produced the "SOA Best Practices-The BPEL Cookbook" series on Oracle Technology Network. He has practical experience designing and optimizing business processes - conducting multiple business process re-engineering projects while a consultant with Booz Allen Hamilton. He holds a master's degree in electrical engineering from the University of Karlsruhe, Germany; the University of Southampton, U.K.; and ESIEE, France.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
SOA Web Services Journal News Desk 10/26/05 11:48:42 AM EDT

Web Services Journal - SOA in Action Case Study: LibGo Travel. LibGo Travel, one of the largest privately held travel companies in the U.S., provides vacation packages through its retail stores and wholesale distribution channels to consumers, partners, travel agents, and stores. The company wanted to expand its offerings by adding dynamic, branded, and personalized packages. To help execute this idea, LibGo had to bring together our travel partners, including airlines, hotels, and travel aggregators, as well as LibGo Travel's existing heterogeneous systems environment. As a result, LibGo's Next-Generation Travel System (NGTS) is among the most sophisticated booking systems that are currently being implemented. Instead of building one-off interfaces for each partner - a time-consuming, expensive, and brittle solution -- LibGo adopted a modern SOA with shared business services and Web services: data interchange would be XML-based, and WSDL would be the single interface definition standard.