17.10. A New Transaction Protocol
Reasons ACID is Not Suitable for Web Services
- Classic ACID transactions assume that an organization that develops and deploys applications owns the entire infrastructure for the applications. This infrastructure has traditionally taken the form of an Intranet. Ownership implies that transactions operate in a trusted and predictable manner. To assure ACIDity, potentially long-lived locks can be kept on underlying data structures during two-phase commit. Resources can be used for any period of time and released when the transaction is complete.In Web Services, these assumptions are no longer valid. One obvious reason is that the owners of data exposed through a Web service refuse to allow their data to be locked for extended periods, since allowing such locks invites denial-of-service attacks.
- All application infrastructures are generally owned by a single party. Systems using classical ACID transactions normally assume that participants in a transaction will obey the directives of the transaction manager and only infrequently make unilateral decisions which harm other participants in a transaction.Web Services participating in a transaction can effectively decide to resign from the transaction at any time, and the consumer of the service generally has little in the way of quality of service guarantees to prevent this.
17.10.1. Transaction in Loosely Coupled Systems
Requirements of Web Services
- Ability to handle multiple successful outcomes to a transaction, and to involve operations whose effects may not be isolated or durable.
- Coordination of autonomous parties whose relationships are governed by contracts, rather than the dictates of a central design authority.
- Discontinuous service, where parties are expected to suffer outages during their lifetimes, and coordinated work must be able to survive such outages.
- Interoperation using XML over multiple communication protocols. XTS uses SOAP encoding carried over HTTP.