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.

• Building a Modern SOA: Examining Offshoring All Over Again