Requires Free Membership to View
When it comes to transaction management, the key limitation in many Web services-based implementations is performing cross-service transactions. As long as a service is at the root of a transaction and the scope of the transaction is limited to activities that are performed by the service's underlying solution logic, there is no need for cross-service transaction functionality, and the transaction can be managed by whatever proprietary technology (component-based, legacy, or otherwise) it encapsulates. However, as the amount of services in an environment grows, the need to span transactions across those services increases. To address this requirement a set of WS-* specifications were developed a while ago.
First, the WS-Coordination specification provides a context management mechanism implemented through a set of stateful system services capable of logging information about and tracking the status of an on-going activity performed by a set of services that have registered to participate within this activity. Two supplementary specifications, WS-AtomicTransaction and WS-BusinessActivity, were developed to work in conjunction with WS-Coordination by providing business protocols to its generic context management features.
These protocols dictate the terms of the activity. WS-AtomicTransaction, for example, provides protocols for ACID-type transactions with two-phase capability. WS-BusinessActivity provides protocols for long-running transactions with compensation processes (as opposed to a rollback). Adoption of these specifications has been slow and gradual. They are expected to become increasingly important in the next 1-2 years. Microsoft's Indigo, for example, has already been promoted as supporting WS-AtomicTransaction.
This was first published in October 2005
Join the conversationComment
Share
Comments
Results
Contribute to the conversation