[jboss-cvs] JBossAS SVN: r74371 - projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Jun 11 02:18:01 EDT 2008
Author: irooskov at redhat.com
Date: 2008-06-11 02:18:01 -0400 (Wed, 11 Jun 2008)
New Revision: 74371
Modified:
projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/Introduction.xml
projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/Transactions_Overview.xml
projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/WS-C_WS-Atomic_Transaction_and_WS-Business_Activity_Overview.xml
Log:
half way through the conversion of Web Services Programmers Guide
Modified: projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/Introduction.xml
===================================================================
--- projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/Introduction.xml 2008-06-11 05:34:17 UTC (rev 74370)
+++ projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/Introduction.xml 2008-06-11 06:18:01 UTC (rev 74371)
@@ -2,24 +2,83 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<chapter id="Transactions_Web_Services_Programmers_Guide-Test">
- <title>Test</title>
+<chapter id="Transactions_Web_Services_Programmers_Guide-Introduction">
+ <title>Introduction</title>
<para>
- This is a test paragraph
</para>
- <section id="Transactions_Web_Services_Programmers_Guide-Test-Section_1_Test">
- <title>Section 1 Test</title>
+ <section id="Transactions_Web_Services_Programmers_Guide-introduction-JBossTS_Web_Services_transactions_overview">
+ <title>JBossTS Web Services transactions overview</title>
<para>
- Test of a section
+ The XML transaction service component of JBossTS (shorthand referred to as XTS) supports the coordination of private and public Web services in a business transaction. Therefore, to understand XTS, you must be familiar with Web services, and also understand a little about transactions. This chapter introduces XTS and provides a brief overview of the technologies that form the Web services standard. Additionally, this chapter explores some of the fundamentals of transactioning technology and how it can be applied to Web services. Much of the content presented in this chapter is detailed throughout this guide; however, only overview information about Web services is provided. If you are new to creating Web services, please see consult your Web services platform documentation.
</para>
- </section>
-
- <section id="Transactions_Web_Services_Programmers_Guide-Test-Section_2_Test">
- <title>Section 2 Test</title>
<para>
- Test of a section
+ JBossTS provides as the XTS component a transaction solution for Web services. Using XTS, business partners can coordinate complex business transactions in a controlled and reliable manner. The JBossTS Web Services API supports a transactional coordination model based on the WS-C, WS-Atomic Transaction and WS-Business Activity specifications. WS-C is a generic coordination framework developed by IBM, Microsoft and BEA, WS-Atomic Transaction and WS-Business Activity are transaction protocols that utilize this framework.
</para>
+ <para>
+ Web services are modular, reusable software components that are created by exposing business functionality through a Web service interface. Web services communicate directly with other Web services using standards-based technologies such as SOAP and HTTP. These standards-based communication technologies allow Web services to be accessed by customers, suppliers, and trading partners, independent of hardware operation system or programming environment. The result is a vastly improved collaboration environment as compared to today's EDI and business-to-business (B2B) solutions—an environment where businesses can expose their current and future business applications as Web services that can be easily discovered and accessed by external partners.
+ </para>
+ <para>
+ Web services, by themselves, are not fault tolerant. In fact, some of the reasons that make it an attractive development solution are also the same reasons that service-based applications may have drawbacks:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Application components that are exposed as Web services may be owned by third parties, which provides benefits in terms of cost of maintenance, but drawbacks in terms of having exclusive control over their behavior;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Web services are usually remotely located which increases risk of failure due to increased network travel for invocations.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Applications that have high dependability requirements, must find a method of minimizing the effects of errors that may occur when an application consumes Web services. One method of safeguarding against such failures is to interact with an application’s Web services within the context of a transaction. A transaction is simply a unit of work which is completed entirely, or in the case of failures is reversed to some agreed consistent state – normally to appear as if the work had never occurred in the first place. With XTS, transactions can span multiple Web services which mean that work performed across multiple enterprises can be managed with transactional support.
+ </para>
+ <formalpara>
+ <title>Managing Service-Based Processes</title>
+ <para>
+ XTS allows you to create transactions that drive complex business processes spanning multiple Web services. Current Web services standards do not address the requirements for a high-level coordination of services since in today’s Web services applications, which use single request/receive interactions, coordination is typically not a problem. However, for applications that engage multiple services among multiple business partners, coordinating and controlling the resulting interactions is essential. This becomes even more apparent when you realize that you generally have little in the way of formal guarantees when interacting with third-party Web services.
+ </para>
+ </formalpara>
+ <para>
+ XTS provides the infrastructure for coordinating services during a business process. By organizing processes as transactions, business partners can collaborate on complex business interactions in a reliable manner, insuring the integrity of their data - usually represented by multiple changes to a database – but without the usual overheads and drawbacks of directly exposing traditional transaction-processing engines directly onto the web. The following example demonstrates how an application may manage service-based processes as transactions:
+ </para>
+ <para>
+ The application in question allows a user to plan a social evening. This application is responsible for reserving a table at a restaurant, and reserving tickets to a show. Both activities are paid for using a credit card. In this example, each service represents exposed Web services provided by different service providers. XTS is used to envelop the interactions between the theater and restaurant services into a single (potentially) long-running business transaction. The business transaction must insure that seats are reserved both at the restaurant and the theater. If one event fails the user has the ability to decline both events, thus returning both services back to their original state. If both events are successful, the user’s credit card is charged and both seats are booked. As you may expect, the interaction between the services must be controlled in a reliable manner over a period of time. In addition, management must span several third-party services that are !
remotely deployed.
+ </para>
+ <caution>
+ <para>
+ Without the backing of a transaction, an undesirable outcome may occur. For example, the user credit card may be charged, even though one or both of the bookings may have failed.
+ </para>
+ </caution>
+ <para>
+ This simple example describes the situations where XTS excels at supporting business processes across multiple enterprises. This example is further refined throughout this guide, and appears as a standard demonstrator (including source code) with the XTS distribution.
+ </para>
+ <formalpara>
+ <title>Servlets</title>
+ <para>
+ The WS-C, WS-Atomic Transaction and WS-Business Activity protocols are based on one-way interactions of entities rather than traditional synchronous request/response RPC style interactions. Entities (for example, transaction participants) invoke operations on other entities (for example, the transaction coordinator) in order to return responses to requests. What this means is that the programming model is based on peer-to-peer relationships, with the result that all services, whether they are participants, coordinators or clients, must have an active component that allows them to receive unsolicited messages.
+ </para>
+ </formalpara>
+ <para>
+ In the current implementation of XTS, the active component is achieved through the use of Java servlet technology. Each endpoint that can be communicated with via SOAP/XML is represented as a servlet (and published within JNDI). Fortunately for the developer, this use of servlets occurs transparently. The only drawback is that (currently) clients must reside within a domain capable of hosting servlets, i.e., an application server. It is our intention that future versions of XTS will provide configurable deployment options, allowing servlets where required, but not mandating them.
+ </para>
+ <formalpara>
+ <title>SOAP</title>
+ <para>
+ SOAP has emerged as the de-facto message format for XML-based communication in the Web services arena. It is a lightweight protocol that allows the user to define the content of a message and to provide hints as to how recipients should process that message.
+ </para>
+ </formalpara>
+ <para>
+ SOAP messages can be divided into two main categories: Remote Procedure Call (RPC) and Document Exchange (DE). The primary difference between the two categories is that the SOAP specification defines encoding rules and conventions for RPC. The document exchange model allows the exchange of arbitrary XML documents - a key ingredient of B2B document exchange. XTS is based on the loosely coupled document-exchange style, yet it can support transactions spanning Web service that use either document-exchange or RPC.
+ </para>
+ <formalpara>
+ <title>Web Services Description Language (WSDL)</title>
+ <para>
+ WSDL is an XML-based language used to define Web service interfaces. An application that consumes a Web service parses the service’s WSDL document to discover the location of the service, the operations that the service supports, the protocol bindings the service supports (SOAP, HTTP, etc), and how to access them (for each operation, WSDL describes the format that the client must follow).
+ </para>
+ </formalpara>
</section>
-
</chapter>
Modified: projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/Transactions_Overview.xml
===================================================================
--- projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/Transactions_Overview.xml 2008-06-11 05:34:17 UTC (rev 74370)
+++ projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/Transactions_Overview.xml 2008-06-11 06:18:01 UTC (rev 74371)
@@ -2,24 +2,301 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<chapter id="Transactions_Web_Services_Programmers_Guide-Test">
- <title>Test</title>
+<chapter id="Transactions_Web_Services_Programmers_Guide-Transactions_Overview">
+ <title>Transactions Overview</title>
<para>
- This is a test paragraph
+ Transactions have emerged as the dominant paradigm for coordinating interactions between parties in a distributed system, and in particular to manage applications that require concurrent access to shared data. Much of the JBossTS Web Service API is based on contemporary transaction APIs whose familiarity will enhance developer productivity and lessen the learning curve. While the following section provides the essential information that you should know before starting to use XTS for building transactional Web Services, it should not be treated as a definitive reference to all transactional technology.
</para>
- <section id="Transactions_Web_Services_Programmers_Guide-Test-Section_1_Test">
- <title>Section 1 Test</title>
+ <para>
+ A classic transaction is a unit of work that either completely succeeds, or fails with all partially completed work being undone. When a transaction is committed, all changes made by the associated requests are made durable, normally by committing the results of the work to a database. If a transaction should fail and is rolled back, all changes made by the associated work are undone. Transactions in distributed systems typically require the use of a transaction manager that is responsible for coordinating all of the participants that are part of the transaction.
+ </para>
+ <para>
+ The main components involved in using and defining transactional Web Services using XTS are illustrated in Figure 1.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ A Transaction Service: The Transaction Service captures the model of the underlying transaction protocol and coordinates parties affiliated with the transaction according to that model.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A Transaction API: Provides an interface for transaction demarcation and the registration of participants.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A Participant: The entity that cooperates with the transaction service on behalf of its associated business logic.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The Context: Captures the necessary details of the transaction such that participants can enlist within its scope.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/Web_Services.png" format="PNG"/>
+ </imageobject>
+ <caption>Web Services and XTS</caption>
+ </mediaobject>
+ <formalpara>
+ <title>The Coordinator</title>
<para>
- Test of a section
+ Associated with every transaction is a coordinator, which is responsible for governing the outcome of the transaction. The coordinator may be implemented as a separate service or may be co-located with the user for improved performance. Each coordinator is created by the transaction manager service, which is in effect a factory for those coordinators.
</para>
- </section>
-
- <section id="Transactions_Web_Services_Programmers_Guide-Test-Section_2_Test">
- <title>Section 2 Test</title>
+ </formalpara>
+ <para>
+ A coordinator communicates with enrolled participants to inform them of the desired termination requirements, for instance, whether they should accept (for example, confirm) or reject (for example, cancel) the work done within the scope of the given transaction. For example, whether to purchase the (provisionally reserved) flight tickets for the user or to release them. An application/client may wish to terminate a transaction in a number of different ways (for example, confirm or cancel). However, although the coordinator will attempt to terminate in a manner consistent with that desired by the client, it is ultimately the interactions between the coordinator and the participants that will determine the actual final outcome.
+ </para>
+ <para>
+ A transaction manager is typically responsible for managing coordinators for many transactions. The initiator of the transaction (for example, the client) communicates with a transaction manager and asks it to start a new transaction and associate a coordinator with the transaction. Once created, the context can be propagated to Web services in order for them to associate their work with the transaction.
+ </para>
+ <formalpara>
+ <title>The Transaction Context</title>
<para>
- Test of a section
+ In order for a transaction to span a number of services, certain information has to be shared between those services in order to propagate information about the transaction. This information is known as the Context. Using XTS, the context is automatically propagated and processed by transaction-aware components of an application. Though XTS removes most of the work associated with propagating contexts, it is still instructive to understand what information is captured in a context:
</para>
- </section>
-
+ </formalpara>
+ <itemizedlist>
+ <listitem>
+ <para>
+ A transaction identifier which guarantees global uniqueness for an individual transaction;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The transaction coordinator location or endpoint address so participants can be enrolled.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/Context_Flow.png" format="PNG"/>
+ </imageobject>
+ <caption>Web Services and Context Flow</caption>
+ </mediaobject>
+ <para>
+ As shown in Figure 2, whenever an application message is sent, the XTS Client API automatically creates a context and embeds it into the message. Similarly, any transaction-aware services are able to extract that context using the XTS service-side infrastructure and use it to perform work within the context of a particular transaction – even though that transaction was initiated elsewhere on the Web! The value of this approach is that the business logic contained within the client application and services are not peppered with transaction-processing code.
+ </para>
+ <formalpara>
+ <title>ACID Transactions</title>
+ <para>
+ Traditionally, transaction processing systems support ACID properties. ACID is an acronym for Atomic, Consistent, Isolated, and Durable. A unit of work has traditionally been considered transactional only if the ACID properties are maintained:
+ </para>
+ </formalpara>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Atomicity: The transaction executes completely or not at all.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Consistency: The effects of the transaction preserve the internal consistency of an underlying data structure.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Isolated: The transaction runs as if it were running alone with no other transactions running and is not visible to other transactions.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Durable: the transaction’s results will not be lost in the event of a failure.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <formalpara>
+ <title>Two-Phase Commit</title>
+ <para>
+ The classical two-phase commit approach is the bedrock of JBossTS (and more generally of Web Services transactions). Two-phase commit provides coordination of parties that are involved in a transaction. In general, the flow of a two-phase commit transaction is as follows:
+ </para>
+ </formalpara>
+ <itemizedlist>
+ <listitem>
+ <para>
+ A transaction is started, and some work is performed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Once the work is finished, the two-phase commit begins.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The coordinator (transaction manager) of the transaction asks each resource taking part in the transaction whether it is prepared to commit.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If all resources respond positively, the coordinator instructs all work performed to be made durable (usually committed to a database).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If not, all work performed is rolled back (undone) such that the underlying data structures are in their original states.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/Commit_Protocol.png" format="PNG"/>
+ </imageobject>
+ <caption>The Two-Phase Commit Protocol</caption>
+ </mediaobject>
+ <note>
+ <para>
+ During two-phase commit transactions, coordinators and resources keep track of activity in non-volatile data stores so that they can recover in the case of a failure.
+ </para>
+ </note>
+ <formalpara>
+ <title>The synchronization protocol</title>
+ <para>
+ As well as the two-phase commit protocol, traditional transaction processing systems employ an additional protocol, often referred to as the synchronization protocol. If you recall the original ACID properties, then you’ll remember that Durability is important in the case where state changes have to be available despite failures. What this means is that applications interact with a persistence store of some kind (e.g., a database) and this can impose a significant overhead – disk access is orders of magnitude slower than access to main computer memory.
+ </para>
+ </formalpara>
+ <para>
+ One apparently obvious solution to this problem would be to cache the state in main memory and only operate on that for the duration of a transaction. Unfortunately you’d then need some way of being able to flush the state back to the persistent store before the transaction terminates, or risk losing the full ACID properties. This is what the synchronization protocol does, with Synchronization participants.
+ </para>
+ <para>
+ Synchronizations are informed that a transaction is about to commit, so they can, for example, flush cached state, which may be being used to improve performance of an application, to a durable representation prior to the transaction committing. They are then informed when the transaction has completed and in what state it completed.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Synchronizations essentially turn the two-phase commit protocol into a four-phase protocol:
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Before the transaction starts the two-phase commit, all registered Synchronizations are informed. Any failure at this point will cause the transaction to roll back.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The coordinator then conducts the normal two-phase commit protocol.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Once the transaction has terminated, all registered Synchronizations are informed. However, this is a courtesy invocation because any failures at this stage are ignored: the transaction has terminated so there’s nothing to affect.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Unlike the two-phase commit protocol, the synchronization protocol does not have the same failure requirements. For example, Synchronization participants don’t need to make sure they can recover in the event of failures; this is because any failure before the two-phase commit protocol completes means the transaction will roll back, and failures after it has completed can’t affect the data the Synchronization participants were managing.
+ </para>
+ <formalpara>
+ <title>Optimizations to the protocol</title>
+ <para>
+ There are several variants to the standard two-phase commit protocol that are worth knowing about because they can have an impact on performance and failure recovery. We shall briefly describe those that are the most common variants on the protocol:
+ </para>
+ </formalpara>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Presumed abort: if a transaction is going to roll back then it may simply record this information locally and tell all enlisted participants. Failure to contact a participant has no affect on the transaction outcome; the transaction is effectively informing participants as a courtesy. Once all participants have been contacted the information about the transaction can be removed. If a subsequent request for the status of the transaction occurs there will be no information available and the requestor can assume that the transaction has aborted (rolled back). This optimization has the benefit that no information about participants need be made persistent until the transaction has decided to commit (i.e., progressed to the end of the prepare phase), since any failure prior to this point will be assumed to be an abort of the transaction.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ One-phase: if there is only a single participant involved in the transaction, the coordinator need not drive it through the prepare phase. Thus, the participant will simply be told to commit and the coordinator need not record information about the decision since the outcome of the transaction is solely down to the participant.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Read-only: when a participant is asked to prepare, it can indicate to the coordinator that no information or data that it controls has been modified during the transaction. Such a participant does not need to be informed about the outcome of the transaction since the fate of the participant has no affect on the transaction. As such, a read-only participant can be omitted from the second phase of the commit protocol.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <formalpara>
+ <title>Non-atomic transactions and heuristic outcomes</title>
+ <para>
+ In order to guarantee atomicity, the two-phase commit protocol is necessarily blocking. What this means is that as a result of failures, participants may remain blocked for an indefinite period of time even if failure recovery mechanisms exist. Some applications and participants simply cannot tolerate this blocking.
+ </para>
+ </formalpara>
+ <para>
+ To break this blocking nature, participants that have got past the prepare phase are allowed to make autonomous decisions as to whether they commit or rollback: such a participant must record this decision in case it is eventually contacted to complete the original transaction. If the coordinator eventually informs the participant of the transaction outcome and it is the same as the choice the participant made, then there’s no problem. However, if it is contrary, then a non-atomic outcome has obviously happened: a heuristic outcome.
+ </para>
+ <para>
+ How this heuristic outcome is reported to the application and resolved is usually the domain of complex, manually driven system administration tools, since in order to attempt an automatic resolution requires semantic information about the nature of participants involved in the transactions.
+ </para>
+ <para>
+ Precisely when a participant makes a heuristic decision is obviously implementation dependant. Likewise, the choice the participant makes (to commit or to roll back) will depend upon the implementation and possibly the application/environment in which it finds itself. The possible heuristic outcomes are:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Heuristic rollback: the commit operation failed because some or all of the participants unilaterally rolled back the transaction.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Heuristic commit: an attempted rollback operation failed because all of the participants unilaterally committed. This may happen if, for example, the coordinator was able to successfully prepare the transaction but then decided to roll it back (for example, it could not update its log) but in the meanwhile the participants decided to commit.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Heuristic mixed: some updates (participants) were committed while others were rolled back.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Heuristic hazard: the disposition of some of the updates is unknown. For those which are known, they have either all been committed or all rolled back.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Heuristic decisions should be used with care and only in exceptional circumstances since there is the possibility that the decision will differ from that determined by the transaction service and will thus lead to a loss of integrity in the system. Having to perform resolution of heuristics is something you should try to avoid, either by working with services/participants that don’t cause heuristics, or by using a transaction service that provides assistance in the resolution process.
+ </para>
+ <formalpara>
+ <title>A New Transaction Protocol</title>
+ <para>
+ Many component technologies offer mechanisms for coordinating ACID transactions based on two-phase commit semantics (i.e., CORBA/OTS, JTS/JTA, MTS/MSDTC). ACID transactions are not suitable for all Web services transactions since:
+ </para>
+ </formalpara>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Classic ACID transactions are predicated on the idea that an organization that develops and deploys applications does so using their own infrastructure, typically an Intranet. Ownership meant transactions operated in a trusted and predictable manner. To assure ACIDity, potentially long-lived locks could be kept on underlying data structures during two-phase commit. Resources could be used for any period of time and released when the transaction was complete. In the Web services arena, these assumptions are no longer valid. One obvious reason is that the owners of data exposed through a Web service will refuse to allow their data to be locked for extended periods since to allow such locks invites denial-of-service.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 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 will of the transaction manager and only infrequently decide to make unilateral decisions which will hamper other participants in a transaction. On the contrary, 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.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <formalpara>
+ <title>Adressing the Problems of Transactioning in Loosely Coupled Systems</title>
+ <para>
+ Though extended transaction models which relax the ACID properties have been proposed over the years, to implement these concepts for the Web services architecture WS-T provides a new transaction protocol. XTS is designed to accommodate four underlying requirements inherent in any loosely coupled architecture like Web services:
+ </para>
+ </formalpara>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Ability to handle multiple successful outcomes to a transaction, with the ability to involve operations whose effects may not be isolated or durable;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Coordination of autonomous parties whose relationships are governed by contracts rather than the dictates of a central design authority;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Discontinuous service, where parties are anticipated to suffer outages during their lifetime, and coordinated work must be able to survive such outages;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Interoperation using XML over multiple communication protocols – XTS chooses to use SOAP encoding carried over HTTP for the first release and other SOAP-friendly transports for future releases.
+ </para>
+ </listitem>
+ </itemizedlist>
</chapter>
Modified: projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/WS-C_WS-Atomic_Transaction_and_WS-Business_Activity_Overview.xml
===================================================================
--- projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/WS-C_WS-Atomic_Transaction_and_WS-Business_Activity_Overview.xml 2008-06-11 05:34:17 UTC (rev 74370)
+++ projects/docs/enterprise/4.3/Transactions/Transactions_Web_Services_Programmers_Guide/en-US/WS-C_WS-Atomic_Transaction_and_WS-Business_Activity_Overview.xml 2008-06-11 06:18:01 UTC (rev 74371)
@@ -2,24 +2,243 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<chapter id="Transactions_Web_Services_Programmers_Guide-Test">
- <title>Test</title>
+<chapter id="Transactions_Web_Services_Programmers_Guide-WS-C_WS-Atomic_Transaction_and_WS-Business_Activity_Overview">
+ <title>WS-C, WS-Atomic Transaction and WS-Business Activity Overview</title>
<para>
- This is a test paragraph
</para>
- <section id="Transactions_Web_Services_Programmers_Guide-Test-Section_1_Test">
- <title>Section 1 Test</title>
+ <section id="Transactions_Web_Services_Programmers_Guide-WS-C_WS-Atomic_Transaction_and_WS-Business_Activity_Overview-Introduction">
+ <title>Introduction</title>
<para>
- Test of a section
+ This section provides fundamental concepts associated with WS-C, WS-Atomic Transaction and WS-Business Activity. All of these concepts are defined in the WS-C, WS-Atomic Transaction and WS-Business Activity specifications. WS-C, WS-Atomic Transaction and WS-Business Activity principles are discussed throughout this guide.
</para>
+ <note>
+ <para>
+ If you are well versed in the WS-C, WS-Atomic Transaction and WS-Business Activity specifications then you may want to just skim through this part of the manual.
+ </para>
+ </note>
</section>
- <section id="Transactions_Web_Services_Programmers_Guide-Test-Section_2_Test">
- <title>Section 2 Test</title>
+ <section id="Transactions_Web_Services_Programmers_Guide-WS-C_WS-Atomic_Transaction_and_WS-Business_Activity_Overview-WS-Coordination">
+ <title>WS-Coordination</title>
<para>
- Test of a section
+ In general terms, coordination is the act of one entity (known as the coordinator) disseminating information to a number of participants for some domain-specific reason. This reason could be in order to reach consensus on a decision like in a distributed transaction protocol, or simply to guarantee that all participants obtain a specific message, as occurs in a reliable multicast environment. When parties are being coordinated, information known as the coordination context is propagated to tie together operations which are logically part of the same coordinated work or activity. This context information may flow with normal application messages, or may be an explicit part of a message exchange and is specific to the type of coordination being performed.
</para>
+ <para>
+ The fundamental idea underpinning WS-Coordination is that there is a generic need for a coordination infrastructure in a Web services environment. The WS-Coordination specification defines a framework that allows different coordination protocols to be plugged-in to coordinate work between clients, services and participants, as shown in Figure 4.
+ </para>
+ <para>
+ At this level, an activity is minimally specified and is simply created, made to run, and then completed.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/WS-C_Architecture.png" format="PNG"/>
+ </imageobject>
+ <caption>WS-C architecture</caption>
+ </mediaobject>
+ <para>
+ Whatever coordination protocol is used, and in whatever domain it is deployed, the same generic requirements are present:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Instantiation (or activation) of a new coordinator for the specific coordination protocol, for a particular application instance;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Registration of participants with the coordinator, such that they will receive that coordinator’s protocol messages during (some part of) the application’s lifetime;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Propagation of contextual information between Web services that comprise the application;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ An entity to drive the coordination protocol through to completion.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ The first three of these points are directly the concern of WS-Coordination while the fourth is the responsibility of a third-party entity, usually the client application that controls the application as a whole. These four WS-Coordination roles and their interrelationships are shown in Figure 5.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/WS-C_Infrastructure.png" format="PNG"/>
+ </imageobject>
+ <caption>WS-C infrastructure</caption>
+ </mediaobject>
+ <formalpara>
+ <title>Activation</title>
+ <para>
+ The WS-Coordination framework exposes an Activation Service which supports the creation of coordinators for specific protocols and their associated contexts. The process of invoking an activation service is done asynchronously, and so the specification defines both the interface of the activation service itself, and that of the invoking service, so that the activation service can call back to deliver the results of the activation – namely a context that identifies the protocol type and coordinator location. These interfaces are presented in Figure 6, where the activation service has a one-way operation that expects to receive a <code>CreateCoordinationContext</code> message and correspondingly the service that sent the <code>CreateCoordinationContext</code> message expects to be called back with a <code>CreateCoordinationContextResponse</code> message, or informed of a problem via an <code>Error</code> message.
+ </para>
+ </formalpara>
+<screen>
+<!-- Activation Service portType Declaration -->
+<wsdl:portType name="ActivationCoordinatorPortType">
+ <wsdl:operation name="CreateCoordinationContext">
+ <wsdl:input
+ message="wscoor:CreateCoordinationContext"/>
+ </wsdl:operation>
+</wsdl:portType>
+
+<!-- Activation Requester portType Declaration -->
+<wsdl:portType name="ActivationRequesterPortType">
+ <wsdl:operation
+ name="CreateCoordinationContextResponse">
+ <wsdl:input
+ message="wscoor:CreateCoordinationContextResponse"/>
+ </wsdl:operation>
+ <wsdl:operation name="Error">
+ <wsdl:input message="wscoor:Error"/>
+ </wsdl:operation>
+</wsdl:portType>\
+</screen>
+ <formalpara>
+ <title>Registration</title>
+ <para>
+ Once a coordinator has been instantiated and a corresponding context created by the activation service, a Registration Service is created and exposed. This service allows participants to register to receive protocol messages associated with a particular coordinator. Like the activation service, the registration service assumes asynchronous communication and so specifies WSDL for both registration service and registration requester, as shown below.
+ </para>
+ </formalpara>
+<screen>
+<!-- Registration Service portType Declaration -->
+<wsdl:portType name="RegistrationCoordinatorPortType">
+ <wsdl:operation name="Register">
+ <wsdl:input message="wscoor:Register"/>
+ </wsdl:operation>
+</wsdl:portType>
+
+<!-- Registration Requester portType Declaration -->
+<wsdl:portType name="RegistrationRequesterPortType">
+ <wsdl:operation name="RegisterResponse">
+ <wsdl:input message="wscoor:RegisterResponse"/>
+ </wsdl:operation>
+ <wsdl:operation name="Error">
+ <wsdl:input message="wscoor:Error"/>
+ </wsdl:operation>
+</wsdl:portType>
+</screen>
+ <para>
+ When a participant is registered with a coordinator through the registration service, it receives messages that the coordinator sends (for example, “prepare to complete” and “complete” messages if a two-phase protocol is used); where the coordinator’s protocol supports it, participants can also send messages back to the coordinator.
+ </para>
+ <formalpara>
+ <title>Completion</title>
+ <para>
+ The role of terminator is generally played by the client application, which at an appropriate point will ask the coordinator to perform its particular coordination function with any registered participants – to drive the protocol through to its completion. On completion, the client application may be informed of an outcome for the activity which may vary from simple succeeded/failed notification through to complex structured data detailing the activity’s status.
+ </para>
+ </formalpara>
</section>
-
+ <section id="Transactions_Web_Services_Programmers_Guide-WS-C_WS-Atomic_Transaction_and_WS-Business_Activity_Overview-WS-Transaction">
+ <title>WS-Transaction</title>
+ <para>
+ In the past, making traditional transaction systems talk to one another was a holy grail that was rarely achieved. With the advent of Web services, there is an opportunity to leverage an unparalleled interoperability technology to splice together existing transaction processing systems that already form the backbone of enterprise level applications.
+ </para>
+ <formalpara>
+ <title>WS-Coordination Foundations</title>
+ <para>
+ An important aspect of WS-Transaction that differentiates it from traditional transaction protocols is that a synchronous request/response model is not assumed. This model derives from the fact that WS-Transaction is, as shown in the figure below, layered upon the WS-Coordination protocol whose own communication patterns are asynchronous by default.
+ </para>
+ </formalpara>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/WS-Coordination_Foundations.png" format="PNG"/>
+ </imageobject>
+ <caption>WS-Coordination WS-Atomic Transaction and WS-Business Activity</caption>
+ </mediaobject>
+ <para>
+ Web Services Coordination provides a generic framework for specific coordination protocols, like WS-Transaction, to be plugged in. Recall that WS-Coordination provides only context management – it allows contexts to be created and activities to be registered with those contexts. WS-Transaction leverages the context management framework provided by WS-Coordination in two ways. Firstly it extends the WS-Coordination context to create a transaction context. Secondly, it augments the activation and registration services with a number of additional services (Completion, CompletionWithAck, PhaseZero, 2PC, OutcomeNotification, BusinessAgreement, and BusinessAgreementWithComplete) and two protocol message sets (one for each of the transaction models supported in WS-Transaction) to build a fully-fledged transaction coordinator on top the WS-Coordination protocol infrastructure.
+ </para>
+ <formalpara>
+ <title>WS-Transaction Architecture</title>
+ <para>
+ WS-Transaction supports the notion of the service and participant as distinct roles, making the distinction between a transaction-aware service and the participants that act on behalf of the service during a transaction: transactional services deal with business-level protocols, while the participants handle the underlying WS-Transaction protocols, as shown above.
+ </para>
+ </formalpara>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/WS-Transaction_Global_View.png" format="PNG"/>
+ </imageobject>
+ <caption>WS-Transaction Global View</caption>
+ </mediaobject>
+ <para>
+ A transaction-aware service encapsulates the business logic or work that is required to be conducted within the scope of a transaction. This work cannot be confirmed by the application unless the transaction also commits and so control is ultimately removed from the application and placed into the transaction’s domain.
+ </para>
+ <para>
+ The participant is the entity that, under the dictates of the transaction coordinator, controls the outcome of the work performed by the transaction-aware Web service. In the figure above each service is shown with one associated participant that manages the transaction protocol messages on behalf of its service, while in the figure below, there is a close-up view of a single service, and a client application with their associated participants.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/Transactional_Service_and_Participant.png" format="PNG"/>
+ </imageobject>
+ <caption>Transactional Service and Participant</caption>
+ </mediaobject>
+ <para>
+ The transaction-aware Web service and its participant both serve a shared transactional resource, and there is a control relationship between them through some API - which on the Java platform is JAXTX. In the example shown in the figure above, it is assumed that the database is accessed through a transactional JDBC database driver, where SQL statements are sent to the database for processing via that driver, but where those statements will be tentative and only commit if the transaction does. In order to do this, the driver/database will associate a participant with the transaction which will inform the database of the transaction outcome. Since all transactional invocations on the Web service carry a transaction context, the participant working with the database is able to identify the work that the transactional service did within the scope of a specific transaction and either commit or rollback the work.
+ </para>
+ <para>
+ At the client end, things are less complex. Through its API, the client application registers a participant with the transaction through which it controls transaction termination.
+ </para>
+ <formalpara>
+ <title>WS-Transaction Models</title>
+ <para>
+ Given that traditional transaction models are not appropriate for Web services, the following question must be posed, “what type of model or protocol is appropriate?” The answer to that question is that that no one specific protocol is likely to be sufficient, given the wide range of situations that Web service transactions are likely to be deployed within. Hence the WS-Transaction specification proposes two distinct models, where each supports the semantics of a particular kind of B2B interaction. The following sections shall discuss these two WS-Transaction models.
+ </para>
+ </formalpara>
+ <note>
+ <para>
+ As with WS-Coordination, the two WS-Transaction models are extensible allowing implementations to tailor the protocols as they see fit (for example, to suit their deployment environments).
+ </para>
+ </note>
+ <formalpara>
+ <title>Atomic Transactions (AT)</title>
+ <para>
+ An atomic transaction or AT is similar to traditional ACID transactions and intended to support short-duration interactions where ACID semantics are appropriate. Within the scope of an AT, services typically enroll transaction-aware resources, such as databases and message queues, indirectly as participants under the control of the transaction. When the transaction terminates, the outcome decision of the AT is then propagated to each enlisted resource via the participant, and the appropriate commit or rollback actions are taken by each.
+ </para>
+ </formalpara>
+ <para>
+ This protocol is very similar to those employed by traditional transaction systems that already form the backbone of an enterprise. It is assumed that all services (and associated participants) provide ACID semantics and that any use of atomic transactions occurs in environments and situations where this is appropriate: in a trusted domain, over short durations.
+ </para>
+ <para>
+ To begin an atomic transaction, the client application firstly locates a WS-Coordination coordinator Web service that supports WS-Transaction. Once located, the client sends a WS-Coordination CreateCoordinationContext message to the activation service specifying http://schemas.xmlsoap.org/ws/2004/10/wsat as its coordination type and will get back an appropriate WS-Transaction context from the activation service. The response to the CreateCoordinationContext message, the transaction context, has its CoordinationType element set to the WS-Atomic Transaction namespace, http://schemas.xmlsoap.org/ws/2004/10/wsat, and also contains a reference to the atomic transaction coordinator endpoint (the WS-Coordination registration service) where participants can be enlisted.
+ </para>
+ <para>
+ After obtaining a transaction context from the coordinator, the client application then proceeds to interact with Web services to accomplish its business-level work. With each invocation on a business Web service, the client inserts the transaction context into a SOAP header block, such that each invocation is implicitly scoped by the transaction – the toolkits that support WS-Atomic Transaction-aware Web services provide facilities to correlate contexts found in SOAP header blocks with back-end operations.
+ </para>
+ <para>
+ Once all the necessary application level work has been completed, the client can terminate the transaction, with the intent of making any changes to the service state permanent. To do this, the client application first registers its own participant for the Completion protocol. Once registered, the participant can instruct the coordinator either to try to commit or rollback the transaction. When the commit or rollback operation has completed, a status is returned to the participant to indicate the outcome of the transaction.
+ </para>
+ <para>
+ While the completion protocol is straightforward, they hide the fact that in order to resolve to an outcome that several other protocols need to be executed.
+ </para>
+ <para>
+ The first of these protocols is the optional Volatile2PC. The Volatile2PC protocol is the WS-Atomic Transaction equivalent of the synchronization protocol we discussed earlier. It is typically executed where a Web service needs to flush volatile (cached) state, which may be being used to improve performance of an application, to a database prior to the transaction committing. Once flushed, the data will then be controlled by a two-phase aware participant.
+ </para>
+ <para>
+ All Volatile2PC participants are told that the transaction is about to complete (via the prepare message) and they can respond with either the prepared, aborted or readonly message; any failures at this stage will cause the transaction to rollback.
+ </para>
+ <para>
+ After Volatile2PC prepare, the next protocol to execute in WS-Atomic Transaction is Durable2PC. The Durable2PC (an abbreviation of the term two-phase commit) protocol is at the very heart of WS-Atomic Transaction and is used to bring about the necessary consensus between participants in a transaction such that the transaction can safely be terminated.
+ </para>
+ <para>
+ The two-phase commit protocol is used to ensure atomicity between participants, and is based on the classic two-phase commit with presumed abort technique. During the first phase, when the coordinator sends the prepare message, a participant must make durable any state changes that occurred during the scope of the transaction, such that these changes can either be rolled back or committed later. That is, any original state must not be lost at this point as the atomic transaction could still roll back. If the participant cannot prepare then it must inform the coordinator (via the aborted message) and the transaction will ultimately roll back. If the participant is responsible for a service that did not do any work during the course of the transaction, or at least did not do any work that modified any state, it can return the readonly message and it will be omitted from the second phase of the commit protocol. Otherwise, the prepared message is sent by the participant.
+ </para>
+ <para>
+ Assuming no failures occurred during the first phase, in the second phase the coordinator sends the commit message to participants, who will make permanent the tentative work done by their associated services.
+ </para>
+ <para>
+ If a transaction involves only a single participant, WS-Atomic Transaction supports a one-phase commit optimization. Since there is only one participant, its decisions implicitly reach consensus, and so the coordinator need not drive the transaction through both phases. In the optimized case, the participant will simply be told to commit and the transaction coordinator need not record information about the decision since the outcome of the transaction is solely down to that single participant.
+ </para>
+ <para>
+ The figure below<footnote><para>Redrawn from the WS-Atomic Transaction specification.</para></footnote> shows the state transitions of a WS-Atomic Transaction and the message exchanges between coordinator and participant; the coordinator generated messages are shown in the solid line, whereas the participant messages are shown by dashed lines.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/Commit_State_Transitions.png" format="PNG"/>
+ </imageobject>
+ <caption>Two-Phase Commit State Transitions</caption>
+ </mediaobject>
+ </section>
</chapter>
More information about the jboss-cvs-commits
mailing list