[jboss-svn-commits] JBL Code SVN: r36007 - in labs/jbosstm/trunk/XTS/docs: Transactions_XTS_Administration_And_Development_Guide and 1 other directories.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Wed Nov 17 17:54:35 EST 2010
Author: misty at redhat.com
Date: 2010-11-17 17:54:33 -0500 (Wed, 17 Nov 2010)
New Revision: 36007
Added:
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Administration_And_Development_Guide.ent
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Administration_And_Development_Guide.xml
Removed:
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Development_Guide.ent
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Development_Guide.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/
labs/jbosstm/trunk/XTS/docs/XTS_Installation_And_Administration_Guide/
Modified:
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/About_This_Guide.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Author_Group.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Book_Info.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Chapter.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Getting_Started.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Introduction.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Participant_Crash_Recovery.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Participants.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Preface.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Protocols_Overview.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Revision_History.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Stand_Alone_Coordination.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_Overview.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/XTS_API.xml
labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/publican.cfg
Log:
Renamed XTS Programmer's Guide, added some info at the beginning stating that the guide should be used for installation and administration, as well as development. Deleted the temporary XTS Installation and Administration Guide.
Copied: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide (from rev 36006, labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide)
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/About_This_Guide.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/About_This_Guide.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/About_This_Guide.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,52 +1,62 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter>
<title>About This Guide</title>
<para>
- The XTS Programmer's Guide explains how to add resilience to distributed
- business processes based on web services, making them reliable in the event
- of system or network failures. The &APPSERVER; implements Web
- Services Transactions standards using <firstterm>XTS (XML Transaction
- Service)</firstterm>. XTS supports development and deployment of
- transaction-aware web services. It also enables web service clients to
- create and manage web service transactions from which transactional web
- services can be invoked. XTS ensures that the client and web services
- achieve consistent outcomes even if the systems on which they are running
- crash or temporarily lose network connectivity.
+ The XTS Development Guide explains how to add resilience to distributed business processes based on web services,
+ making them reliable in the event of system or network failures. It covers installation, administration, and
+ development of transactional web services.
</para>
<para>
- XTS is compliant with the <firstterm>WS-Coordination</firstterm>,
- <firstterm>WS-Atomic Transaction</firstterm>, and <firstterm>WS-Business
- Activity</firstterm> specifications. The implementation supports web
- services and clients which are based on the JaxWS standard. XTS is itself
- implemented using services based on JaxWS. While this guide discusses many
- Web Services standards like SOAP and WSDL, it does not attempt to address
- all of their fundamental constructs. However, basic concepts are provided
- where necessary.
+ The &APPSERVER; implements Web Services
+ Transactions standards using <firstterm>XTS (XML Transaction Service)</firstterm>. XTS supports development and
+ deployment of transaction-aware web services. It also enables web service clients to create and manage web service
+ transactions from which transactional web services can be invoked. XTS ensures that the client and web services
+ achieve consistent outcomes even if the systems on which they are running crash or temporarily lose network
+ connectivity.
</para>
+ <para>
+ XTS is compliant with the <firstterm>WS-Coordination</firstterm>, <firstterm>WS-Atomic Transaction</firstterm>, and
+ <firstterm>WS-Business Activity</firstterm> specifications. The implementation supports web services and clients
+ which are based on the JaxWS standard. XTS is itself implemented using services based on JaxWS. While this guide
+ discusses many Web Services standards like SOAP and WSDL, it does not attempt to address all of their fundamental
+ constructs. However, basic concepts are provided where necessary.
+ </para>
<section>
<title>Audience</title>
<para>
- This guide is most relevant for application developers and Web service developers who are interested in building applications and Web services that are transaction-aware. It is also useful for system analysts and project managers who are unfamiliar with transactions as they pertain to Web services.
+ This guide is most relevant for application developers and Web service developers who are interested in building
+ applications and Web services that are transaction-aware. It is also useful for system analysts and project
+ managers who are unfamiliar with transactions as they pertain to Web services.
</para>
</section>
<section>
<title>Prerequisites</title>
<para>
- JBoss Transaction Service uses the Java programming language and this manual assumes that you are familiar with programming in Java. Additional helpful skills are outlined in <xref linkend="prereqs-list" />.
+ JBoss Transaction Service uses the Java programming language and this manual assumes that you are familiar with
+ programming in Java. Additional helpful skills are outlined in <xref linkend="prereqs-list" />.
</para>
<itemizedlist id="prereqs-list">
<title>Prerequisite Skills for XTS Developers</title>
<listitem><para>A Working knowledge of Web Services, including XML, SOAP, and WSDL</para></listitem>
<listitem><para>A general understanding of transactions</para></listitem>
- <listitem><para>A general understanding of WS-Coordination, WS-Atomic Transaction and WS-Business Activity protocols</para></listitem>
+ <listitem><para>A general understanding of WS-Coordination, WS-Atomic Transaction and WS-Business Activity
+ protocols</para></listitem>
</itemizedlist>
<para>
- This guide presents overview information for all of the above. However, to aid in understanding the Web Services component of JBoss Transaction Service, the WS-C<footnote><para><ulink url="http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-tx/WS-Coordination.pdf" /></para></footnote>, WS-Atomic Transaction<footnote><para><ulink url="http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-tx/WS-AtomicTransaction.pdf" /></para></footnote>, and WS-Business Activity<footnote><para><ulink url="http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-tx/WS-BusinessActivity.pdf" /></para></footnote> specifications are discussed in great detail.
+ This guide presents overview information for all of the above. However, to aid in understanding the Web Services
+ component of JBoss Transaction Service, the WS-C<footnote><para><ulink
+ url="http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-tx/WS-Coordination.pdf" /></para></footnote>,
+ WS-Atomic Transaction<footnote><para><ulink
+ url="http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-tx/WS-AtomicTransaction.pdf"
+ /></para></footnote>, and WS-Business Activity<footnote><para><ulink
+ url="http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-tx/WS-BusinessActivity.pdf"
+ /></para></footnote> specifications are discussed in great detail.
</para>
</section>
</chapter>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Author_Group.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Author_Group.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Author_Group.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE authorgroup PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<authorgroup>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Book_Info.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Book_Info.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Book_Info.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,28 +1,29 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Development_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<bookinfo id="book-Transactions_XTS_Development_Guide-Transactions_XTS_Development_Guide">
- <title>Transactions XTS Development Guide</title>
- <subtitle>Using the XTS Module of &PRODUCT; to provide Web Services Transactions</subtitle>
- <productname>JBoss Transactions</productname>
- <productnumber>4.13</productnumber>
- <edition>0</edition>
- <pubsnumber>0</pubsnumber>
- <abstract>
- <para>
- The XTS Development Guide contains information on how to use JBoss Transaction Service to develop service-based applications that use transaction technology to manage business processes.
- </para>
- </abstract>
- <corpauthor>
- <inlinemediaobject>
- <imageobject>
- <imagedata fileref="Common_Content/images/title_logo.svg" format="SVG" />
- </imageobject>
- </inlinemediaobject>
- </corpauthor>
- <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <title>Transactions XTS Administration And Development Guide</title>
+ <subtitle>Using the XTS Module of &PRODUCT; to provide Web Services Transactions</subtitle>
+ <productname>JBoss Transactions</productname>
+ <productnumber>4.13</productnumber>
+ <edition>0</edition>
+ <pubsnumber>0</pubsnumber>
+ <abstract>
+ <para>
+ The XTS Development Guide contains information on how to use JBoss Transaction Service to develop service-based
+ applications that use transaction technology to manage business processes.
+ </para>
+ </abstract>
+ <corpauthor>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata fileref="Common_Content/images/title_logo.svg" format="SVG" />
+ </imageobject>
+ </inlinemediaobject>
+ </corpauthor>
+ <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</bookinfo>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Chapter.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Chapter.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Chapter.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,33 +1,33 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter id="chap-Transactions_XTS_Programmers_Guide-Test_Chapter">
- <title>Test Chapter</title>
- <para>
- This is a test paragraph
- </para>
- <section id="sect-Transactions_XTS_Programmers_Guide-Test_Chapter-Test_Section_1">
- <title>Test Section 1</title>
- <para>
- This is a test paragraph in a section
- </para>
- </section>
-
- <section id="sect-Transactions_XTS_Programmers_Guide-Test_Chapter-Test_Section_2">
- <title>Test Section 2</title>
- <para>
- This is a test paragraph in Section 2
- <orderedlist>
- <listitem>
- <para>
- listitem text
- </para>
- </listitem>
- </orderedlist>
- </para>
- </section>
+ <title>Test Chapter</title>
+ <para>
+ This is a test paragraph
+ </para>
+ <section id="sect-Transactions_XTS_Programmers_Guide-Test_Chapter-Test_Section_1">
+ <title>Test Section 1</title>
+ <para>
+ This is a test paragraph in a section
+ </para>
+ </section>
+
+ <section id="sect-Transactions_XTS_Programmers_Guide-Test_Chapter-Test_Section_2">
+ <title>Test Section 2</title>
+ <para>
+ This is a test paragraph in Section 2
+ <orderedlist>
+ <listitem>
+ <para>
+ listitem text
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ </section>
</chapter>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Getting_Started.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Getting_Started.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Getting_Started.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter>
@@ -19,25 +19,30 @@
<section>
<title>Installing the XTS Service Archive into JBoss Transaction Service</title>
<para>
- XTS, which is the Web Services component of JBoss Transaction Service, provides WS-AT and WS-BA support for Web Services hosted on the &APPSERVER;. The module is packaged as a <firstterm>Service Archive (.sar)</firstterm> located in <filename><replaceable>$JBOSS_HOME</replaceable>/docs/examples/transactions/</filename>. To install it, follow <xref linkend="procedure-install-xts" />.
+ XTS, which is the Web Services component of JBoss Transaction Service, provides WS-AT and WS-BA support for Web
+ Services hosted on the &APPSERVER;. The module is packaged as a <firstterm>Service Archive (.sar)</firstterm>
+ located in <filename><replaceable>$JBOSS_HOME</replaceable>/docs/examples/transactions/</filename>. To install it,
+ follow <xref linkend="procedure-install-xts" />.
</para>
<procedure id="procedure-install-xts">
<title>Installing the XTS Module</title>
<step>
- <para>
- Create a sub-directory in the <filename><replaceable>$JBOSS_HOME</replaceable>/server/[<replaceable>name</replaceable>]/deploy/</filename> directory, called <filename>jbossxts.sar/</filename>.
- </para>
+ <para>
+ Create a sub-directory in the
+ <filename><replaceable>$JBOSS_HOME</replaceable>/server/[<replaceable>name</replaceable>]/deploy/</filename>
+ directory, called <filename>jbossxts.sar/</filename>.
+ </para>
</step>
<step>
- <para>
- Unpack the SAR, which is a ZIP archive, into this new directory.
- </para>
+ <para>
+ Unpack the SAR, which is a ZIP archive, into this new directory.
+ </para>
</step>
<step>
- <para>
- Restart &APPSERVER; to activate the module.
- </para>
+ <para>
+ Restart &APPSERVER; to activate the module.
+ </para>
</step>
</procedure>
</section>
@@ -46,22 +51,33 @@
<title>Creating Client Applications</title>
<para>
- There are two aspects to a client application using XTS, the transaction declaration aspects, and the business logic. The business logic includes the invocation of Web Services.
+ There are two aspects to a client application using XTS, the transaction declaration aspects, and the business
+ logic. The business logic includes the invocation of Web Services.
</para>
<para>
- Transaction declaration aspects are handled automatically with the XTS client API. This API provides simple transaction directives such as <methodname>begin</methodname>, <methodname>commit</methodname>, and <methodname>rollback</methodname>, which the client application can use to initialize, manage, and terminate transactions. Internally, this API uses SOAP to invoke operations on the various WS-C, WS-AT and WS-BA services, in order to create a coordinator and drive the transaction to completion.
+ Transaction declaration aspects are handled automatically with the XTS client API. This API provides simple
+ transaction directives such as <methodname>begin</methodname>, <methodname>commit</methodname>, and
+ <methodname>rollback</methodname>, which the client application can use to initialize, manage, and terminate
+ transactions. Internally, this API uses SOAP to invoke operations on the various WS-C, WS-AT and WS-BA services,
+ in order to create a coordinator and drive the transaction to completion.
</para>
<section>
<title>User Transactions</title>
<para>
- A client uses the <classname>UserTransactionFactory</classname> and <classname>UserTransaction</classname> classes to create and manage WS-AT transactions. These classes provide a simple API which operates in a manner similar to the JTA API. A WS-AT transaction is started and associated with the client thread by calling the <methodname>begin</methodname> method of the <methodname>UserTransaction</methodname> class. The transaction can be committed by calling the <methodname>commit</methodname> method, and rolled back by calling the <methodname>rollback</methodname> method.
+ A client uses the <classname>UserTransactionFactory</classname> and <classname>UserTransaction</classname> classes to
+ create and manage WS-AT transactions. These classes provide a simple API which operates in a manner similar to the
+ JTA API. A WS-AT transaction is started and associated with the client thread by calling the
+ <methodname>begin</methodname> method of the <methodname>UserTransaction</methodname> class. The transaction can be
+ committed by calling the <methodname>commit</methodname> method, and rolled back by calling the
+ <methodname>rollback</methodname> method.
</para>
<para>
- More complex transaction management, such as suspension and resumption of transactions, is supported by the <classname>TransactionManagerFactory</classname> and <classname>TransactionManager</classname> classes.
+ More complex transaction management, such as suspension and resumption of transactions, is supported by the
+ <classname>TransactionManagerFactory</classname> and <classname>TransactionManager</classname> classes.
</para>
<para>
- Full details of the WS-AT APIs are provided in <xref linkend="sec-xts-api" />.
+ Full details of the WS-AT APIs are provided in <xref linkend="sec-xts-api" />.
</para>
</section>
@@ -69,16 +85,24 @@
<title>Business Activities</title>
<para>
- A client creates and manages Business Activities using the <classname>UserBusinessActivityFactory</classname> and <classname>UserBusinessActivity</classname> classes. A WS-BA activity is started and associated with the client thread by calling the <methodname>begin</methodname> method of the <methodname>UserBusinessActivity</methodname> class. A client can terminate a business activity by calling the <methodname>close</methodname> method, and cancel it by calling the <methodname>cancel</methodname> method.
+ A client creates and manages Business Activities using the <classname>UserBusinessActivityFactory</classname> and
+ <classname>UserBusinessActivity</classname> classes. A WS-BA activity is started and associated with the client
+ thread by calling the <methodname>begin</methodname> method of the <methodname>UserBusinessActivity</methodname>
+ class. A client can terminate a business activity by calling the <methodname>close</methodname> method, and cancel it
+ by calling the <methodname>cancel</methodname> method.
</para>
<para>
- If any of the Web Services invoked by the client register for the <systemitem>BusinessActivityWithCoordinatorCompletion</systemitem> protocol, the client can call the <methodname>completed</methodname> method before calling the <methodname>close</methodname> method, to notify the services that it has finished making service invocations in the current activity.
+ If any of the Web Services invoked by the client register for the
+ <systemitem>BusinessActivityWithCoordinatorCompletion</systemitem> protocol, the client can call the
+ <methodname>completed</methodname> method before calling the <methodname>close</methodname> method, to notify the
+ services that it has finished making service invocations in the current activity.
</para>
<para>
- More complex business activity management, such as suspension and resumption of business activities, is supported by the <classname>BusinessActivityManagerFactory</classname> and <classname>BusinessActivityManager</classname> classes.
+ More complex business activity management, such as suspension and resumption of business activities, is supported by
+ the <classname>BusinessActivityManagerFactory</classname> and <classname>BusinessActivityManager</classname> classes.
</para>
<para>
- Full details of the WS-AT APIs are provided in <xref linkend="sec-xts-api" />.
+ Full details of the WS-AT APIs are provided in <xref linkend="sec-xts-api" />.
</para>
</section>
@@ -86,63 +110,68 @@
<title>Client-Side Handler Configuration</title>
<para>
- XTS does not require the client application to use a specific API to perform invocations on transactional Web Services. The client is free to use any appropriate API to send SOAP messages to the server and receive SOAP responses. The only requirements imposed on the client are:
+ XTS does not require the client application to use a specific API to perform invocations on transactional Web
+ Services. The client is free to use any appropriate API to send SOAP messages to the server and receive SOAP
+ responses. The only requirements imposed on the client are:
</para>
<itemizedlist>
- <listitem>
- <para>
- It must forward details of the current transaction to the server when invoking a web service.
- </para>
- </listitem>
- <listitem>
- <para>
- It must process any responses from the server in the context of the correct transaction.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ It must forward details of the current transaction to the server when invoking a web service.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ It must process any responses from the server in the context of the correct transaction.
+ </para>
+ </listitem>
</itemizedlist>
<para>
- In order to achieve this, the client must insert details of the current XTS context into the headers of outgoing SOAP messages, and extract the context details from the headers of incoming messages and associate the context with the current thread. To simplify this process, the XTS module includes handlers which can perform this task automatically. These handlers are designed to work with JAX-WS clients.
+ In order to achieve this, the client must insert details of the current XTS context into the headers of outgoing SOAP
+ messages, and extract the context details from the headers of incoming messages and associate the context with the
+ current thread. To simplify this process, the XTS module includes handlers which can perform this task
+ automatically. These handlers are designed to work with JAX-WS clients.
</para>
<note>
- <para>
- If you choose to use a different SOAP client/server infrastructure for business service invocations, you must provide for header processing. XTS only provides interceptors for or JAX-WS. A JAX-RPC handler is provided only for the 1.0 implementation.
- </para>
+ <para>
+ If you choose to use a different SOAP client/server infrastructure for business service invocations, you must
+ provide for header processing. XTS only provides interceptors for or JAX-WS. A JAX-RPC handler is provided only for
+ the 1.0 implementation.
+ </para>
</note>
<!--
- <section>
- <title>JAX-RPC Client Context Handlers</title>
- <para>
- To register the JAX-RPC client-side context handler used by the client applications, a handler chain must be included in the definition of the <varname>service-ref</varname> in the client's <filename>web.xml</filename> deployment descriptor. Please refer to the example application located in <filename>ddrpc/jboss/client-web-app.xml</filename> for an example of such a handler.
- </para>
- <para>
- You need to instantiate the <classname>com.arjuna.mw.wst11.client.JaxRPCHeaderContextProcessor</classname> class when registering a JAX-RPC client context handler.
- </para>
- <note>
- <para>
- A JAX-RPC client handler is not provided for the 1.1 implementation.
- </para>
- </note>
- </section>
+ <section> <title>JAX-RPC Client Context Handlers</title> <para> To register the JAX-RPC client-side context
+ handler used by the client applications, a handler chain must be included in the definition of the
+ <varname>service-ref</varname> in the client's <filename>web.xml</filename> deployment descriptor. Please refer
+ to the example application located in <filename>ddrpc/jboss/client-web-app.xml</filename> for an example of such a
+ handler. </para> <para> You need to instantiate the
+ <classname>com.arjuna.mw.wst11.client.JaxRPCHeaderContextProcessor</classname> class when registering a JAX-RPC
+ client context handler. </para> <note> <para> A JAX-RPC client handler is not provided for the 1.1
+ implementation. </para> </note> </section>
-->
<section>
- <title>JAX-WS Client Context Handlers</title>
- <para>
- In order to register the JAX-WS client-side context handler, the client application uses the APIs provided by the <classname>javax.xml.ws.BindingProvider</classname> and <classname>javax.xml.ws.Binding</classname> classes, to install a handler chain on the service proxy which is used to invoke the remote endpoint. Refer to the example application client implementation located in the <filename>src/com/jboss/jbosstm/xts/demo/BasicClient.java</filename> file for an example.
- </para>
- <para>
- You can also specify the handlers by using a configuration file deployed with the application. The file is identified by attaching a <systemitem>javax.jws.HandlerChain</systemitem> annotation to the interface class, which declares the JAX-WS client API. This interface is normally generated from the web service WSDL port definition.
- </para>
- <para>
- You need to instantiate the <classname>com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor</classname> class when registering a JAX-WS client context handler.
- </para>
- <!--
- <note>
- <para>
- The class used in the 1.1 implementation is <classname>com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor</classname>.
- </para>
- </note>
- -->
+ <title>JAX-WS Client Context Handlers</title>
+ <para>
+ In order to register the JAX-WS client-side context handler, the client application uses the APIs provided by the
+ <classname>javax.xml.ws.BindingProvider</classname> and <classname>javax.xml.ws.Binding</classname> classes, to
+ install a handler chain on the service proxy which is used to invoke the remote endpoint. Refer to the example
+ application client implementation located in the
+ <filename>src/com/jboss/jbosstm/xts/demo/BasicClient.java</filename> file for an example.
+ </para>
+ <para>
+ You can also specify the handlers by using a configuration file deployed with the application. The file is
+ identified by attaching a <systemitem>javax.jws.HandlerChain</systemitem> annotation to the interface class, which
+ declares the JAX-WS client API. This interface is normally generated from the web service WSDL port definition.
+ </para>
+ <para>
+ You need to instantiate the <classname>com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor</classname> class
+ when registering a JAX-WS client context handler.
+ </para>
+ <!--
+ <note> <para> The class used in the 1.1 implementation is
+ <classname>com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor</classname>. </para> </note>
+ -->
</section>
</section>
</section>
@@ -154,115 +183,138 @@
The two parts to implementing a Web service using XTS are the transaction management and the business logic.
</para>
<para>
- The bulk of the transaction management aspects are organized in a clear and easy-to-implement model by means of the XTS’s <firstterm>Participant API</firstterm>, provides a structured model for negotiation between the web service and the transaction coordinator. It allows the web service to manage its own local transactional data, in accordance with the needs of the business logic, while ensuring that its activities are in step with those of the client and other services involved in the transaction. Internally, this API uses SOAP to invokes operations on the various WS-C, WS-AT and WS-BA services, to drive the transaction to completion.
+ The bulk of the transaction management aspects are organized in a clear and easy-to-implement model by means of
+ the XTS’s <firstterm>Participant API</firstterm>, provides a structured model for negotiation between the web
+ service and the transaction coordinator. It allows the web service to manage its own local transactional data, in
+ accordance with the needs of the business logic, while ensuring that its activities are in step with those of the
+ client and other services involved in the transaction. Internally, this API uses SOAP to invokes operations on the
+ various WS-C, WS-AT and WS-BA services, to drive the transaction to completion.
</para>
<section>
<title>Participants</title>
<para>
- A <firstterm>participant</firstterm> is a software entity which is driven by the transaction manager on behalf of a Web service. When a web service wants to participate in a particular transaction, it must enroll a participant to act as a proxy for the service in subsequent negotiations with the coordinator. The participant implements an API appropriate to the type of transaction it is enrolled in, and the participant model selected when it is enrolled. For example, a Durable2PC participant, as part of a WS-Atomic Transaction, implements the Durable2PCParticipant interface. The use of participants allows the transactional control management aspects of the Web service to be factored into the participant implementation, while staying separate from the the rest of the Web service's business logic and private transactional data management.
+ A <firstterm>participant</firstterm> is a software entity which is driven by the transaction manager on behalf of a
+ Web service. When a web service wants to participate in a particular transaction, it must enroll a participant to act
+ as a proxy for the service in subsequent negotiations with the coordinator. The participant implements an API
+ appropriate to the type of transaction it is enrolled in, and the participant model selected when it is enrolled. For
+ example, a Durable2PC participant, as part of a WS-Atomic Transaction, implements the Durable2PCParticipant
+ interface. The use of participants allows the transactional control management aspects of the Web service to be
+ factored into the participant implementation, while staying separate from the the rest of the Web service's business
+ logic and private transactional data management.
</para>
<para>
- The creation of participants is not trivial, since they ultimately reflect the state of a Web service’s back-end processing facilities, an aspect normally associated with an enterprise’s own IT infrastructure. Implementations must use one of the following interfaces, depending upon the protocol it will participate within: <interfacename>com.arjuna.wst11.Durable2PCParticipant</interfacename>, <interfacename>com.arjuna.wst11.Volatile2PCParticipant</interfacename>, <interfacename>com.arjuna.wst11.BusinessAgreementWithParticipantCompletionParticipant</interfacename>, or <interfacename>com.arjuna.wst11.BusinessAgreementWithCoordinatorCompletionParticipant</interfacename>.
+ The creation of participants is not trivial, since they ultimately reflect the state of a Web service’s back-end
+ processing facilities, an aspect normally associated with an enterprise’s own IT infrastructure. Implementations must
+ use one of the following interfaces, depending upon the protocol it will participate within:
+ <interfacename>com.arjuna.wst11.Durable2PCParticipant</interfacename>,
+ <interfacename>com.arjuna.wst11.Volatile2PCParticipant</interfacename>,
+ <interfacename>com.arjuna.wst11.BusinessAgreementWithParticipantCompletionParticipant</interfacename>, or
+ <interfacename>com.arjuna.wst11.BusinessAgreementWithCoordinatorCompletionParticipant</interfacename>.
</para>
<para>
- A full description of XTS’s participant features is provided in <remark>Fix me</remark>.
+ A full description of XTS’s participant features is provided in <remark>Fix me</remark>.
</para>
<!--
- <note>
- <para>
- The 1.1 XTS implementation expects participants to implement the same APIs as the 1.0 implementation.
- </para>
- </note>
+ <note> <para> The 1.1 XTS implementation expects participants to implement the same APIs as the 1.0
+ implementation. </para> </note>
-->
</section>
<section>
<title>Service-Side Handler Configuration</title>
<para>
- A transactional Web service must ensure that a service invocation is included in the appropriate transaction. This usually only affects the operation of the participants and has no impact on the operation of the rest of the Web service. XTS simplifies this task and decouples it from the business logic, in much the same way as for transactional clients<remark>Add an xref</remark>. XTS provides a handler which detects and extracts the context details from the headers in incoming SOAP headers, and associates the web service thread with the transaction. The handler clears this association when dispatching SOAP responses, and writes the context into the outgoing message headers. This is shown in <xref linkend="fig-context-handlers-registered-with-soap-server" />.
+ A transactional Web service must ensure that a service invocation is included in the appropriate transaction. This
+ usually only affects the operation of the participants and has no impact on the operation of the rest of the Web
+ service. XTS simplifies this task and decouples it from the business logic, in much the same way as for transactional
+ clients<remark>Add an xref</remark>. XTS provides a handler which detects and extracts the context details from the
+ headers in incoming SOAP headers, and associates the web service thread with the transaction. The handler clears this
+ association when dispatching SOAP responses, and writes the context into the outgoing message headers. This is shown
+ in <xref linkend="fig-context-handlers-registered-with-soap-server" />.
</para>
<para>
- The service side handlers for JAX-WS come in two different versions. The normal handler resumes any transaction identified by an incoming context when the service is invoked, and suspends this transaction when the service call completes. The alternative handler is used to interpose a local coordinator. The first time an incoming parent context is seen, the local coordinator service creates a subordinate transaction, which is resumed before the web service is called. The handler ensures that this subordinate transaction is resumed each time the service is invoked with the same parent context. When the subordinate transaction completes, the association between the parent transaction and its subordinate is cleared.
+ The service side handlers for JAX-WS come in two different versions. The normal handler resumes any transaction
+ identified by an incoming context when the service is invoked, and suspends this transaction when the service call
+ completes. The alternative handler is used to interpose a local coordinator. The first time an incoming parent
+ context is seen, the local coordinator service creates a subordinate transaction, which is resumed before the web
+ service is called. The handler ensures that this subordinate transaction is resumed each time the service is invoked
+ with the same parent context. When the subordinate transaction completes, the association between the parent
+ transaction and its subordinate is cleared.
</para>
<note>
- <para>
- The subordinate service side handler is only able to interpose a subordinate coordinator for an Atomic Transaction.
- </para>
+ <para>
+ The subordinate service side handler is only able to interpose a subordinate coordinator for an Atomic Transaction.
+ </para>
</note>
<note>
- <para>
- JAX-RPC is provided for the 1.0 implementation only.
- </para>
+ <para>
+ JAX-RPC is provided for the 1.0 implementation only.
+ </para>
</note>
<!--
<section>
- <title>JAX-RPC Service Context Handlers</title>
+ <title>JAX-RPC Service Context Handlers</title>
- <para>
- In order to register the JAX-RPC server-side context handler with the deployed Web Services, you must include a handler chain in the Web Services deployment descriptor. Please refer to the example application located in the <filename>ddrpc/jboss/webservices.xml</filename> deployment descriptor for an example.
- </para>
- <para>
- When registering a normal JAX-RPC service context handler, you must instantiate the <classname>com.arjuna.mw.wst11.service.JaxRPCHeaderContextProcessor</classname> class. If you need coordinator interposition, you need to employ the <classname>com.arjuna.mw.wst11.service.JaxRPCSubordinateHeaderContextProcessor</classname> instead.
- </para>
- <note>
- <para>
- A JAX-RPC client handler is not provided for the 1.1 implementation.
- </para>
- </note>
- </section>
+ <para> In order to register the JAX-RPC server-side context handler with the deployed Web Services, you must include
+ a handler chain in the Web Services deployment descriptor. Please refer to the example application located in the
+ <filename>ddrpc/jboss/webservices.xml</filename> deployment descriptor for an example. </para> <para> When
+ registering a normal JAX-RPC service context handler, you must instantiate the
+ <classname>com.arjuna.mw.wst11.service.JaxRPCHeaderContextProcessor</classname> class. If you need coordinator
+ interposition, you need to employ the
+ <classname>com.arjuna.mw.wst11.service.JaxRPCSubordinateHeaderContextProcessor</classname> instead. </para> <note>
+ <para> A JAX-RPC client handler is not provided for the 1.1 implementation. </para> </note> </section>
-->
<section>
- <title>JAX-WS Service Context Handlers</title>
- <para>
- To register the JAX-WS server-side context handler with the deployed Web Services, you must install a handler chain on the Server Endpoint Implementation class. The endpoint implementation class annotation, which is the one annotated with a <systemitem>javax.jws.WebService</systemitem>, must be supplemented with a <systemitem>javax.jws.HandlerChain</systemitem> annotation which identifies a handler configuration file deployed with the application. Please refer to the example application configuration file located at <filename>dd/jboss/context-handlers.xml</filename> and the endpoint implementation classes located in <filename>src/com/jboss/jbosstm/xts/demo/services</filename> for an example.
- </para>
- <para>
- When registering a normal JAX-WS service context handler, you must instantiate the <classname>com.arjuna.mw.wst11.service.JaxWSHeaderContextProcessor</classname> class. If you need coordinator interposition, employ the <classname>com.arjuna.mw.wst11.service.JaxWSSubordinateHeaderContextProcessor</classname> instead.
- </para>
- <!--
- <note>
- <para>
- The classes used in the 1.1 implementation are <classname>com.arjuna.mw.wst11.service.JaxWSHeaderContextProcessor</classname> and <classname>com.arjuna.mw.wst11.service.JaxWSSubordinateHeaderContextProcessor</classname>.
- </para>
- </note>
- -->
- <figure id="fig-context-handlers-registered-with-soap-server">
- <title>Context Handlers Registered with the SOAP Server</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-context-handlers-registered-with-soap-server.png" format="PNG"/>
- </imageobject>
- <textobject>
- <para></para>
- </textobject>
- </mediaobject>
- </figure>
+ <title>JAX-WS Service Context Handlers</title>
+ <para>
+ To register the JAX-WS server-side context handler with the deployed Web Services, you must install a handler chain
+ on the Server Endpoint Implementation class. The endpoint implementation class annotation, which is the one
+ annotated with a <systemitem>javax.jws.WebService</systemitem>, must be supplemented with a
+ <systemitem>javax.jws.HandlerChain</systemitem> annotation which identifies a handler configuration file deployed
+ with the application. Please refer to the example application configuration file located at
+ <filename>dd/jboss/context-handlers.xml</filename> and the endpoint implementation classes located in
+ <filename>src/com/jboss/jbosstm/xts/demo/services</filename> for an example.
+ </para>
+ <para>
+ When registering a normal JAX-WS service context handler, you must instantiate the
+ <classname>com.arjuna.mw.wst11.service.JaxWSHeaderContextProcessor</classname> class. If you need coordinator
+ interposition, employ the <classname>com.arjuna.mw.wst11.service.JaxWSSubordinateHeaderContextProcessor</classname>
+ instead.
+ </para>
+ <!--
+ <note> <para> The classes used in the 1.1 implementation are
+ <classname>com.arjuna.mw.wst11.service.JaxWSHeaderContextProcessor</classname> and
+ <classname>com.arjuna.mw.wst11.service.JaxWSSubordinateHeaderContextProcessor</classname>. </para> </note>
+ -->
+ <figure id="fig-context-handlers-registered-with-soap-server">
+ <title>Context Handlers Registered with the SOAP Server</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/fig-context-handlers-registered-with-soap-server.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <para></para>
+ </textobject>
+ </mediaobject>
+ </figure>
</section>
</section>
<!--
- <section>
- <title>Implementing the Web Service Business Logic</title>
- <para>
- Details about the context management that the context processor performs are normally unimportant to the Web service application logic as well as work performed by other protocol-specific context handlers. However, back-end systems used by the Web service application logic, such as databases, need to track the front-end transaction context, in order to map any operations invoked within its scope onto a back-end transaction context.
- </para>
- <para>
- The back-end typically wraps a database driver in a decorator pattern which extends the interface of the original driver to hook into the service-side API, so that it can access the transaction context details. The general architecture for this pattern is shown in <xref linkend="fig-back-end-pattern" />.
- </para>
- <figure id="fig-back-end-pattern">
- <title>General Pattern for Back-End Integration, from the Service Side</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-back-end-pattern.png" format="PNG"/>
- </imageobject>
- </mediaobject>
- </figure>
- <para>
- The missing element in <xref linkend="fig-back-end-pattern" /> is the <systemitem>commit</systemitem> protocol which allows back-end work to be made durable or roll back at the end of a transaction. This is covered in the <remark>Add an xref</remark> participant chapter, which explores the participant/back-end relation.
- </para>
- </section>
+ <section> <title>Implementing the Web Service Business Logic</title> <para> Details about the context management
+ that the context processor performs are normally unimportant to the Web service application logic as well as work
+ performed by other protocol-specific context handlers. However, back-end systems used by the Web service application
+ logic, such as databases, need to track the front-end transaction context, in order to map any operations invoked
+ within its scope onto a back-end transaction context. </para> <para> The back-end typically wraps a database driver
+ in a decorator pattern which extends the interface of the original driver to hook into the service-side API, so that
+ it can access the transaction context details. The general architecture for this pattern is shown in <xref
+ linkend="fig-back-end-pattern" />. </para> <figure id="fig-back-end-pattern"> <title>General Pattern for Back-End
+ Integration, from the Service Side</title> <mediaobject> <imageobject> <imagedata
+ fileref="images/fig-back-end-pattern.png" format="PNG"/> </imageobject> </mediaobject> </figure> <para> The missing
+ element in <xref linkend="fig-back-end-pattern" /> is the <systemitem>commit</systemitem> protocol which allows
+ back-end work to be made durable or roll back at the end of a transaction. This is covered in the <remark>Add an
+ xref</remark> participant chapter, which explores the participant/back-end relation. </para> </section>
-->
</section>
@@ -270,10 +322,16 @@
<title>Summary</title>
<para>
- This chapter gives a high-level overview of each of the major software pieces used by the Web Services transactions component of JBoss Transaction Service. The Web Services transaction manager provided by JBoss Transaction Service is the hub of the architecture and is the only piece of software that user-level software does not bind to directly. XTS provides header-processing infrastructure for use with Web Services transactions contexts for both client applications and Web Services. XTS provides a simple interface for developing transaction participants, along with the necessary document-handling code.
+ This chapter gives a high-level overview of each of the major software pieces used by the Web Services
+ transactions component of JBoss Transaction Service. The Web Services transaction manager provided by JBoss
+ Transaction Service is the hub of the architecture and is the only piece of software that user-level software does
+ not bind to directly. XTS provides header-processing infrastructure for use with Web Services transactions
+ contexts for both client applications and Web Services. XTS provides a simple interface for developing transaction
+ participants, along with the necessary document-handling code.
</para>
<para>
- This chapter is only an overview, and does not address the more difficult and subtle aspects of programming Web Services. For fuller explanations of the components, please continue reading.
+ This chapter is only an overview, and does not address the more difficult and subtle aspects of programming Web
+ Services. For fuller explanations of the components, please continue reading.
</para>
</section>
</chapter>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Introduction.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Introduction.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Introduction.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter>
@@ -25,61 +25,112 @@
<indexterm><primary>WSDL</primary><secondary>Web Services Description Language</secondary></indexterm>
<para>
- The <firstterm>XML Transaction Service (XTS)</firstterm> component of JBoss Transaction Service 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 something 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.
+ The <firstterm>XML Transaction Service (XTS)</firstterm> component of JBoss Transaction Service 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 something 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>
<para>
- JBoss Transaction Service provides the XTS component as a transaction solution for Web Services. Using XTS, business partners can coordinate complex business transactions in a controlled and reliable manner. The XTS API supports a transactional coordination model based on the <firstterm>WS-Coordination</firstterm>, <firstterm>WS-Atomic Transaction</firstterm>, and <firstterm>WS-Business Activity</firstterm> specifications.
+ JBoss Transaction Service provides the XTS component as a transaction solution for Web Services. Using XTS, business
+ partners can coordinate complex business transactions in a controlled and reliable manner. The XTS API supports a
+ transactional coordination model based on the <firstterm>WS-Coordination</firstterm>, <firstterm>WS-Atomic
+ Transaction</firstterm>, and <firstterm>WS-Business Activity</firstterm> specifications.
</para>
<itemizedlist id="protocol-spec-list">
<title>Protocols Included in XTS</title>
<listitem><para>WS-Coordination (WS-C) is a generic coordination framework developed by IBM, Microsoft and BEA.</para></listitem>
- <listitem><para>WS-Atomic Transaction (WS-AT) and WS-Business Activity (WS-BA) together comprise the WS-Transaction (WS-T) transaction protocols that utilize this framework.</para></listitem>
+ <listitem><para>WS-Atomic Transaction (WS-AT) and WS-Business Activity (WS-BA) together comprise the WS-Transaction
+ (WS-T) transaction protocols that utilize this framework.</para></listitem>
</itemizedlist>
<para>
- JBoss Transaction Service implements versions 1.0, 1.1, and 1.2 of these three specifications. Version specifications are available from <ulink url="http://www.oasis-open.org/specs/" />.
+ JBoss Transaction Service implements versions 1.0, 1.1, and 1.2 of these three specifications. Version
+ specifications are available from <ulink url="http://www.oasis-open.org/specs/" />.
</para>
<note>
<para>
- The 1.0, 1.1, and 1.2 specifications only differ in a small number of details. The rest of this document employs version 1.1 of these specifications when providing explanations and example code. On the few occasions where the modifications required to adapt these to the 1.1 specifications are not obvious, an explanatory note is provided.
+ The 1.0, 1.1, and 1.2 specifications only differ in a small number of details. The rest of this document employs
+ version 1.1 of these specifications when providing explanations and example code. On the few occasions where the
+ modifications required to adapt these to the 1.1 specifications are not obvious, an explanatory note is provided.
</para>
</note>
<para>
- <firstterm>Web Services</firstterm> 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 enable customers, suppliers, and trading partners to access Web Services, independent of hardware operating system, or programming environment. The result is a vastly improved collaboration environment as compared to today's EDI and <firstterm>business-to-business (B2B)</firstterm> 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.
+ <firstterm>Web Services</firstterm> 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 enable
+ customers, suppliers, and trading partners to access Web Services, independent of hardware operating system, or
+ programming environment. The result is a vastly improved collaboration environment as compared to today's EDI and
+ <firstterm>business-to-business (B2B)</firstterm> 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 the Web Services model is an attractive development solution are also the same reasons that service-based applications may have drawbacks.
+ Web Services, by themselves, are not fault-tolerant. In fact, some of the reasons that the Web Services model is an
+ attractive development solution are also the same reasons that service-based applications may have drawbacks.
</para>
<itemizedlist>
<title>Properties of Web Services</title>
<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, increasing risk of failure due to increased network travel for invocations.</para></listitem>
+ <listitem><para>Web Services are usually remotely located, increasing risk of failure due to increased network
+ travel for invocations.</para></listitem>
</itemizedlist>
<para>
- Applications that have high dependability requirements need 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 <firstterm>transaction</firstterm>. A transaction is a unit of work which is completed entirely, or in the case of failures is reversed to some agreed consistent state. The goal, in the event of a failure, is normally to appear as if the work had never occurred in the first place. With XTS, transactions can span multiple Web Services, meaning that work performed across multiple enterprises can be managed with transactional support.
+ Applications that have high dependability requirements need 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 <firstterm>transaction</firstterm>. A transaction is a
+ unit of work which is completed entirely, or in the case of failures is reversed to some agreed consistent
+ state. The goal, in the event of a failure, is normally to appear as if the work had never occurred in the first
+ place. With XTS, transactions can span multiple Web Services, meaning that work performed across multiple
+ enterprises can be managed with transactional support.
</para>
<section>
<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. This is because 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.
+ 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. This is because 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>
<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. <xref linkend="example-application" /> demonstrates how an application may manage service-based processes as transactions:
+ 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. <xref linkend="example-application" /> demonstrates how an application may manage service-based processes as
+ transactions:
</para>
<formalpara id="example-application">
<title>An Evening On the Town</title>
<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 re!
motely deployed.
+ 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>
</formalpara>
<para>
- Without the backing of a transaction, an undesirable outcome may occur. For example, the user credit card may be charged, even if one or both of the bookings fail.
+ Without the backing of a transaction, an undesirable outcome may occur. For example, the user credit card may be
+ charged, even if one or both of the bookings fail.
</para>
<para>
- <xref linkend="example-application" /> 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.
+ <xref linkend="example-application" /> 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>
</section>
@@ -87,11 +138,20 @@
<title>Servlets</title>
<para>
- The WS-Coordination, 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. One group of entities, called transaction participants, invoke operations on other entities, such as the transaction coordinator, in order to return responses to requests. 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 <firstterm>active component</firstterm> that allows them to receive unsolicited messages.
+ The WS-Coordination, 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. One group of entities,
+ called transaction participants, invoke operations on other entities, such as the transaction coordinator, in
+ order to return responses to requests. 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 <firstterm>active
+ component</firstterm> that allows them to receive unsolicited messages.
</para>
<para>
<!--
- In XTS, the active component is achieved through the use of <firstterm>Java servlet</firstterm> 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 clients must reside within a domain capable of hosting servlets, such as an application server. In the case of Enterprise Application Platform, JBoss Application Server provides this functionality.-->
+ In XTS, the active component is achieved through the use of <firstterm>Java servlet</firstterm> 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 clients
+ must reside within a domain capable of hosting servlets, such as an application server. In the case of Enterprise
+ Application Platform, JBoss Application Server provides this functionality.-->
In XTS, the active component is achieved through deployment of JaxWS
endpoints. Each XTS endpoint that is reachable through SOAP/XML is
published via JaxWS, without developer intevention. The only requirement
@@ -102,7 +162,7 @@
<note>
<para>
- The XTS 1.0 protocol implementation is based on servlets.
+ The XTS 1.0 protocol implementation is based on servlets.
</para>
</note>
</section>
@@ -111,19 +171,27 @@
<title>SOAP</title>
<para>
- SOAP has emerged as the <foreignphrase>de facto</foreignphrase> 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.
+ SOAP has emerged as the <foreignphrase>de facto</foreignphrase> 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>
<!--
- <para>
- SOAP messages can be divided into two main categories: <firstterm>Remote Procedure Call (RPC)</firstterm> and <firstterm>Document Exchange (DE)</firstterm>. 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, which is a key ingredient of B2B document exchange. XTS is based on the loosely coupled DE style, yet it can support transactions spanning Web service that use either DE or RPC.
- </para>
+ <para> SOAP messages can be divided into two main categories: <firstterm>Remote Procedure Call (RPC)</firstterm> and
+ <firstterm>Document Exchange (DE)</firstterm>. 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, which is a key ingredient of B2B document exchange. XTS is based on the loosely coupled DE
+ style, yet it can support transactions spanning Web service that use either DE or RPC. </para>
-->
</section>
<section>
<title>Web Services Description Language (WDSL)</title>
<para>
- <firstterm>Web Services Description Language (WSDL)</firstterm> 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.
+ <firstterm>Web Services Description Language (WSDL)</firstterm> 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>
</section>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Participant_Crash_Recovery.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Participant_Crash_Recovery.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Participant_Crash_Recovery.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Participants.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Participants.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Participants.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter>
@@ -542,9 +542,9 @@
</para>
<para>
After the XTS service starts, it creates an instance of the application class
- <classname>org.my.ServiceBean</classname> by calling its <methodname>start</methodname>
- method. During &APPSERVER; shutdown, XTS stops the same instance by calling its <methodname>stop</methodname>
- method, prior to shutting down the XTS Service.
+ <classname>org.my.ServiceBean</classname> by calling its <methodname>start</methodname> method. During
+ &APPSERVER; shutdown, XTS stops the same instance by calling its <methodname>stop</methodname> method, prior to
+ shutting down the XTS Service.
</para>
<example id="example-jboss-beans.xml">
<title>Example <filename>jboss-beans.xml</filename></title>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Preface.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Preface.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Preface.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,13 +1,13 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<preface id="pref-Transactions_XTS_Programmers_Guide-Preface">
- <title>Preface</title>
- <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude"><xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- </xi:fallback>
- </xi:include>
+ <title>Preface</title>
+ <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude"><xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ </xi:fallback>
+ </xi:include>
</preface>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Protocols_Overview.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Protocols_Overview.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Protocols_Overview.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter>
@@ -23,59 +23,79 @@
<indexterm><primary>BusinessAgreementWithCoordinatorCompletion</primary></indexterm>
<para>
- This section discusses fundamental concepts associated with the WS-Coordination, WS-Atomic Transaction and WS-Business Activity protocols, as defined in each protocol's specification. Foundational information about these protocols is important to understanding the remaining material covered in this guide.
+ This section discusses fundamental concepts associated with the WS-Coordination, WS-Atomic Transaction and
+ WS-Business Activity protocols, as defined in each protocol's specification. Foundational information about these
+ protocols is important to understanding the remaining material covered in this guide.
</para>
<!-- I don't like this but it's in the original so I'll leave it for now. -->
<note>
<para>
- If you are familiar with the WS-Coordination, WS-Atomic Transaction, and WS-Business Activity specifications you may only need to skim this chapter.
+ If you are familiar with the WS-Coordination, WS-Atomic Transaction, and WS-Business Activity specifications you
+ may only need to skim this chapter.
</para>
</note>
<section>
<title>WS-Coordination</title>
<para>
- In general terms, <firstterm>coordination</firstterm> 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 to reach consensus on a decision by a distributed transaction protocol, or to guarantee that all participants obtain a specific message, such as in a reliable multicast environment. When parties are being coordinated, information, known as the <firstterm>coordination context</firstterm>, 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. It is specific to the type of coordination being performed.
+ In general terms, <firstterm>coordination</firstterm> 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 to
+ reach consensus on a decision by a distributed transaction protocol, or to guarantee that all participants obtain
+ a specific message, such as in a reliable multicast environment. When parties are being coordinated, information,
+ known as the <firstterm>coordination context</firstterm>, 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. It is specific to the type of coordination being
+ performed.
</para>
<para>
- The fundamental idea underpinning <firstterm>WS-Coordination (WS-C)</firstterm> is that a coordination infrastructure is needed in a Web Services environment. The WS-C specification defines a framework that allows different coordination protocols to be plugged in to coordinate work between clients, services, and participants, as shown in <xref linkend="fig-ws-c-architecture" />.
+ The fundamental idea underpinning <firstterm>WS-Coordination (WS-C)</firstterm> is that a coordination
+ infrastructure is needed in a Web Services environment. The WS-C specification defines a framework that allows
+ different coordination protocols to be plugged in to coordinate work between clients, services, and participants,
+ as shown in <xref linkend="fig-ws-c-architecture" />.
</para>
<figure id="fig-ws-c-architecture">
<title>WS-C Architecture</title>
<mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-ws-c-overview.png" format="PNG"/>
- </imageobject>
- <textobject>
- <para>
- The WS-C specification speaks of <firstterm>activities</firstterm>, which are distributed units of work, involving one or more parties. These parties may be services, components, or even objects. At this level, an activity is minimally specified and is simply created, run, and then completed.
- </para>
- </textobject>
+ <imageobject>
+ <imagedata fileref="images/fig-ws-c-overview.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <para>
+ The WS-C specification speaks of <firstterm>activities</firstterm>, which are distributed units of work,
+ involving one or more parties. These parties may be services, components, or even objects. At this level, an
+ activity is minimally specified and is simply created, run, and then completed.
+ </para>
+ </textobject>
</mediaobject>
</figure>
<para>
- Whatever coordination protocol is used, and in whatever domain it is deployed, the same generic requirements are present.
+ Whatever coordination protocol is used, and in whatever domain it is deployed, the same generic requirements are
+ present.
</para>
<itemizedlist id="list-requirements-for-wsc">
<title>Generic Requirements for WS-C</title>
<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>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 the points in <xref linkend="list-requirements-for-wsc" /> are the direct responsibility of WS-C, while the fourth is the responsibility of a third-party entity. The third-party entity is usually the client component of the overall application. These four WS-C roles and their relationships are shown in <xref linkend="fig-wsc-four-roles" />.
+ The first three of the points in <xref linkend="list-requirements-for-wsc" /> are the direct responsibility of
+ WS-C, while the fourth is the responsibility of a third-party entity. The third-party entity is usually the client
+ component of the overall application. These four WS-C roles and their relationships are shown in <xref
+ linkend="fig-wsc-four-roles" />.
</para>
<figure id="fig-wsc-four-roles">
<title>Four Roles in WS-C</title>
<mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-wsc-four-roles.png" format="PNG"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="images/fig-wsc-four-roles.png" format="PNG"/>
+ </imageobject>
</mediaobject>
</figure>
@@ -83,95 +103,99 @@
<title>Activation</title>
<!--
- <para>
- The WS-C framework exposes an Activation Service which supports the creation of coordinators for specific coordination protocols and retrieval of associated contexts. Activation services are invoked asynchronously, and so the specification defines the interfaces of the activation service itself and of the invoking service. This allows the activation service to call back to deliver the results of the activation, which consist of a context that identifies the protocol type and coordinator location. These interfaces are presented in <xref linkend="example-wsc-interfaces" />. The code shows that the activation service has a one-way operation that expects to receive a <systemitem>CreateCoordinationContext</systemitem> message. The service that sends the <systemitem>CreateCoordinationContext</systemitem> message expects to be called back with a <systemitem>CreateCoordinationContextResponse message</systemitem>, or to be notified of a problem via an error message.
- </para>
+ <para> The WS-C framework exposes an Activation Service which supports the creation of coordinators for specific
+ coordination protocols and retrieval of associated contexts. Activation services are invoked asynchronously, and
+ so the specification defines the interfaces of the activation service itself and of the invoking service. This
+ allows the activation service to call back to deliver the results of the activation, which consist of a context
+ that identifies the protocol type and coordinator location. These interfaces are presented in <xref
+ linkend="example-wsc-interfaces" />. The code shows that the activation service has a one-way operation that
+ expects to receive a <systemitem>CreateCoordinationContext</systemitem> message. The service that sends the
+ <systemitem>CreateCoordinationContext</systemitem> message expects to be called back with a
+ <systemitem>CreateCoordinationContextResponse message</systemitem>, or to be notified of a problem via an error
+ message. </para>
-->
<para>
- The WS-C framework exposes an Activation Service which supports the
- creation of coordinators for specific coordination protocols and
- retrieval of associated contexts. Activation services are invoked
- synchronously using an RPC style exchange. So, the service WSDL defines
- a single port declaring a
- <methodname>CreateCoordinationContext</methodname> operation. This
- operation takes an input specfying the details of the transaction to be
- created, including the type of coordination required, timeout, and other
- relevant information. It returns an output containing the details of the
- newly-created transaction context: the transaction identifier,
- coordination type, and registration service URL.
+ The WS-C framework exposes an Activation Service which supports the creation of coordinators for specific
+ coordination protocols and retrieval of associated contexts. Activation services are invoked synchronously using an
+ RPC style exchange. So, the service WSDL defines a single port declaring a
+ <methodname>CreateCoordinationContext</methodname> operation. This operation takes an input specfying the details of
+ the transaction to be created, including the type of coordination required, timeout, and other relevant
+ information. It returns an output containing the details of the newly-created transaction context: the transaction
+ identifier, coordination type, and registration service URL.
</para>
<example id="example-wsc-interfaces">
- <title></title>
- <programlisting role="XML" language="XML"><xi:include href="extras/example-wsc-interfaces.xml" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <title></title>
+ <programlisting role="XML" language="XML"><xi:include href="extras/example-wsc-interfaces.xml" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
</example>
<note>
- <!--
- <para>
- The Activation Coordinator service employs an RPC-style message exchange, so an Activation Requester service is not necessary.
- </para>
- -->
- <para>
- The 1.0 Activation Coordinator service employs an asynchronous message
- exchange comprised of two one-way messages, so an Activation Requester
- service is also necessary.
- </para>
+ <!--
+ <para> The Activation Coordinator service employs an RPC-style message exchange, so an Activation Requester service
+ is not necessary. </para>
+ -->
+ <para>
+ The 1.0 Activation Coordinator service employs an asynchronous message exchange comprised of two one-way messages,
+ so an Activation Requester service is also necessary.
+ </para>
</note>
</section> <!-- <title>Activation</title> -->
<section>
<title>Registration</title>
<!--
- <para>
- The context returned by the activation service includes information which exposes a Registration Service. This service allows participants to register to receive protocol messages from the coordinator which is associated with the context. Depending upon the coordination protocol, more than one choice of participant protocol may be available. Like the activation service, the registration service assumes asynchronous communication. Thus, it specifies WSDL for both registration service and registration requester. See <xref linkend="example-wsc-registration" /> for more information.
- </para>
+ <para> The context returned by the activation service includes information which exposes a Registration
+ Service. This service allows participants to register to receive protocol messages from the coordinator which is
+ associated with the context. Depending upon the coordination protocol, more than one choice of participant
+ protocol may be available. Like the activation service, the registration service assumes asynchronous
+ communication. Thus, it specifies WSDL for both registration service and registration requester. See <xref
+ linkend="example-wsc-registration" /> for more information. </para>
-->
<para>
- The context returned by the activation service includes the URL of a
- Registration Service. When a web service receieves a service request
- accompanied by a transaction context, it contacts the Registration
- Service to enroll as a participant in the transaction. The registration
- request includes a participant protocol defining the role the web
- service wishes to take in the transaction. Depending upon the
- coordination protocol, more than one choice of participant protocol
- may be available.
+ The context returned by the activation service includes the URL of a Registration Service. When a web service
+ receieves a service request accompanied by a transaction context, it contacts the Registration Service to enroll as a
+ participant in the transaction. The registration request includes a participant protocol defining the role the web
+ service wishes to take in the transaction. Depending upon the coordination protocol, more than one choice of
+ participant protocol may be available.
</para>
<para>
- Like the activation service, the registration service assumes
- synchronous communication. Thus, the service WSDL exposes a single port
- declaring a <methodname>Register</methodname> operation. This operation
- takes an input specifying the details of the participant which is to be
- registered, including the participant protocol type. It returns a
- corresponding output response.
+ Like the activation service, the registration service assumes synchronous communication. Thus, the service WSDL
+ exposes a single port declaring a <methodname>Register</methodname> operation. This operation takes an input
+ specifying the details of the participant which is to be registered, including the participant protocol type. It
+ returns a corresponding output response.
</para>
<example id="example-wsc-registration">
- <title>Registration ServiceWSDL Interface</title>
- <programlisting><xi:include href="extras/example-wsc-registration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <title>Registration ServiceWSDL Interface</title>
+ <programlisting><xi:include href="extras/example-wsc-registration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
</example>
<para>
- Once a participant is registered with a coordinator through the registration service, it receives coordination messages from the coordinator. Typical messages include such things as “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.
+ Once a participant is registered with a coordinator through the registration service, it receives coordination
+ messages from the coordinator. Typical messages include such things as “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>
<note>
- <!--
- <para>
- The Registration Coordinator employs an RPC-style message exchange, so a Registration Requester service is not necessary.
- </para>
- -->
- <para>
- The 1.0 Registration Coordinator service employs an asynchronous
- message exchange comprised of two one way messages, so a Registration
- Requester service is also necessary
- </para>
+ <!--
+ <para> The Registration Coordinator employs an RPC-style message exchange, so a Registration Requester service is not
+ necessary. </para>
+ -->
+ <para>
+ The 1.0 Registration Coordinator service employs an asynchronous message exchange comprised of two one way
+ messages, so a Registration Requester service is also necessary
+ </para>
</note>
</section> <!-- <title>Registration</title> -->
<section>
<title>Completion</title>
<para>
- The role of terminator is generally filled by the client application. At an appropriate point, the client asks the coordinator to perform its particular coordination function with any registered participants, to drive the protocol through to its completion. After completion, the client application may be informed of an outcome for the activity. This outcome may take any form along the spectrum from simple success or failure notification, to complex structured data detailing the activity’s status.
+ The role of terminator is generally filled by the client application. At an appropriate point, the client asks the
+ coordinator to perform its particular coordination function with any registered participants, to drive the protocol
+ through to its completion. After completion, the client application may be informed of an outcome for the
+ activity. This outcome may take any form along the spectrum from simple success or failure notification, to complex
+ structured data detailing the activity’s status.
</para>
</section> <!-- <title>Completion</title> -->
</section> <!-- <title>WS-Coordination</title> -->
@@ -179,465 +203,589 @@
<section>
<title>WS-Transaction</title>
<para>
- <firstterm>WS-Transaction (WS-T)</firstterm> comprises the pair of
- transaction coordination protocols, <firstterm>WS-Atomic Transaction
- (WS-AT)</firstterm> and <firstterm>WS-Business Activity
- (WS-BA)</firstterm>, which utilize the coordination framework provided by
- <firstterm>WS-Coordination (WS-C)</firstterm>.
+ <firstterm>WS-Transaction (WS-T)</firstterm> comprises the pair of transaction coordination protocols,
+ <firstterm>WS-Atomic Transaction (WS-AT)</firstterm> and <firstterm>WS-Business Activity (WS-BA)</firstterm>,
+ which utilize the coordination framework provided by <firstterm>WS-Coordination (WS-C)</firstterm>.
</para>
<para>
- <firstterm>WS-Transactions</firstterm> was developed to unify existing traditional transaction processing systems, allowing them to communicate reliably with one another without changes to the systems' own function.
+ <firstterm>WS-Transactions</firstterm> was developed to unify existing traditional transaction processing systems,
+ allowing them to communicate reliably with one another without changes to the systems' own function.
</para>
<section>
<title>WS-Transaction Foundations</title>
<para>
- WS-Transaction is layered upon the WS-Coordination protocol, as shown in as
- shown in <xref linkend="wsc-wst-interop" />.
+ WS-Transaction is layered upon the WS-Coordination protocol, as shown in as shown in <xref linkend="wsc-wst-interop"
+ />.
</para>
<figure id="wsc-wst-interop">
- <title>WS-Coordination, WS-Transaction, and WS-Business Activity</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-wsc-wst-interop.png" format="PNG"/>
- </imageobject>
- <textobject>
- <para></para>
- </textobject>
- </mediaobject>
+ <title>WS-Coordination, WS-Transaction, and WS-Business Activity</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/fig-wsc-wst-interop.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <para></para>
+ </textobject>
+ </mediaobject>
</figure>
<para>
- WS-C provides a generic framework for specific coordination protocols, like WS-Transaction, used in a modular fashion. WS-C provides only context management, allowing contexts to be created and activities to be registered with those contexts. WS-Transaction leverages the context management framework provided by WS-C in two ways.
+ WS-C provides a generic framework for specific coordination protocols, like WS-Transaction, used in a modular
+ fashion. WS-C provides only context management, allowing contexts to be created and activities to be registered with
+ those contexts. WS-Transaction leverages the context management framework provided by WS-C in two ways.
</para>
<orderedlist>
- <listitem>
- <para>
- It extends the WS-C context to create a transaction context.
- </para>
- </listitem>
- <listitem>
- <para>
- It augments the activation and registration services with a number of additional services (Completion, Volatile2PC, Durable2PC, BusinessAgreementWithParticipantCompletion, and BusinessAgreementWithCoordinatorCompletion) 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 of the WS-C protocol infrastructure.
- </para>
- </listitem>
- <listitem>
- <para>
- An important aspect of WS-Transaction that differs from traditional
- transaction protocols is that a synchronous request/response model is
- not assumed. Sequences of one way messages are used to implement
- communications between the client/participant and the coordination
- services appropriate to the transaction's coordination and participant
- protocols. This is significant because it means that the client and
- participant containers must deploy XTS service endpoints to receive
- messages from the coordinator service.
- </para>
- <para>
- This requirement is visible in the details of the
- <methodname>Register</methodname> and
- <methodname>RegisterResponse</methodname> messages declared in the
- Registration Service WSDL in <xref
- linkend="example-wsc-registration" />. The
- <methodname>Register</methodname> message contains the URL of an
- endpoint in the client or web service container. This URL is used
- when a WS-Transaction coordination service wishes to dispatch a
- message to the clinet or web service. Similarly, the
- <methodname>RegisterResponse</methodname> message contains a URL
- iendtifying an endpoint for the protocol-specific WS-Transaction
- coordination service for which the client/web service is registered,
- allowing messages to be addressed to the transaction coordinator.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ It extends the WS-C context to create a transaction context.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ It augments the activation and registration services with a number of additional services (Completion,
+ Volatile2PC, Durable2PC, BusinessAgreementWithParticipantCompletion, and
+ BusinessAgreementWithCoordinatorCompletion) 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 of the WS-C protocol
+ infrastructure.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ An important aspect of WS-Transaction that differs from traditional transaction protocols is that a synchronous
+ request/response model is not assumed. Sequences of one way messages are used to implement communications between
+ the client/participant and the coordination services appropriate to the transaction's coordination and
+ participant protocols. This is significant because it means that the client and participant containers must
+ deploy XTS service endpoints to receive messages from the coordinator service.
+ </para>
+ <para>
+ This requirement is visible in the details of the <methodname>Register</methodname> and
+ <methodname>RegisterResponse</methodname> messages declared in the Registration Service WSDL in <xref
+ linkend="example-wsc-registration" />. The <methodname>Register</methodname> message contains the URL of an
+ endpoint in the client or web service container. This URL is used when a WS-Transaction coordination service
+ wishes to dispatch a message to the clinet or web service. Similarly, the
+ <methodname>RegisterResponse</methodname> message contains a URL iendtifying an endpoint for the
+ protocol-specific WS-Transaction coordination service for which the client/web service is registered, allowing
+ messages to be addressed to the transaction coordinator.
+ </para>
+ </listitem>
</orderedlist>
</section> <!-- <title>WS-Coordination Foundations</title> -->
<section>
<title>WS-Transaction Architecture</title>
<!--
- <para>
- WS-Transaction views 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 <xref linkend="ws-trans-global-view" />.
- </para>
+ <para> WS-Transaction views 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 <xref linkend="ws-trans-global-view" />. </para>
-->
<para>
- WS-Transaction distnguishes the transaction-aware web service in its
- role executing business-logic, from the web service acting as a
- participant in the transaction, communicating with and responding to its
- transaction coordinator. Transaction-aware web services deal with
- application clients using business-level protocols, while the
- participant handles the underlying WS-Transaction protocols, as shown in
- <xref linkend="ws-trans-global-view" />.
+ WS-Transaction distnguishes the transaction-aware web service in its role executing business-logic, from the web
+ service acting as a participant in the transaction, communicating with and responding to its transaction
+ coordinator. Transaction-aware web services deal with application clients using business-level protocols, while the
+ participant handles the underlying WS-Transaction protocols, as shown in <xref linkend="ws-trans-global-view" />.
</para>
<figure id="ws-trans-global-view">
- <title>WS-Transaction Global View</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/ws-trans-global-view.png" format="PNG"/>
- </imageobject>
- </mediaobject>
+ <title>WS-Transaction Global View</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/ws-trans-global-view.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
</figure>
<para>
- A transaction-aware web service encapsulates the business logic or work that needs to be conducted within the scope of a transaction. This work cannot be confirmed by the application unless the transaction also commits. Thus, control is ultimately removed from the application and given to the transaction.
+ A transaction-aware web service encapsulates the business logic or work that needs to be conducted within the scope
+ of a transaction. This work cannot be confirmed by the application unless the transaction also commits. Thus, control
+ is ultimately removed from the application and given to the transaction.
</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 <xref linkend="ws-trans-global-view" />, each web service is shown with one associated participant that manages the transaction protocol messages on behalf of its web service. <xref linkend="ws-trans-services-participants" />, however, shows a close-up view of a single web service, and a client application with their associated participants.
+ 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 <xref linkend="ws-trans-global-view" />, each web service is
+ shown with one associated participant that manages the transaction protocol messages on behalf of its web
+ service. <xref linkend="ws-trans-services-participants" />, however, shows a close-up view of a single web service,
+ and a client application with their associated participants.
</para>
<figure id="ws-trans-services-participants">
- <title>WS-Transaction Web Services and Participants</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-ws-trans-services-participants.png" format="PNG"/>
- </imageobject>
- </mediaobject>
+ <title>WS-Transaction Web Services and Participants</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/fig-ws-trans-services-participants.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
</figure>
<!--
- <para>
- The transaction-aware Web service and its participant both serve a shared transactional resource, and the JAXTX API provides a control relationship between them. In <xref linkend="ws-trans-services-participants" />, the database is assumed to be accessed through a transactional JDBC database driver, where SQL statements are sent to the database for processing via that driver, but where those statements are tentative and only commit if the transaction does. For this to work, the driver/database associates a participant with the transaction. This participant informs 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 has done within the scope of a specific transaction, and either commit or roll back the work.
- </para>
+ <para> The transaction-aware Web service and its participant both serve a shared transactional resource, and the
+ JAXTX API provides a control relationship between them. In <xref linkend="ws-trans-services-participants" />, the
+ database is assumed to be accessed through a transactional JDBC database driver, where SQL statements are sent to
+ the database for processing via that driver, but where those statements are tentative and only commit if the
+ transaction does. For this to work, the driver/database associates a participant with the transaction. This
+ participant informs 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 has done within the scope of a specific transaction, and either commit or roll back the
+ work. </para>
-->
<para>
- The transaction-aware web service employs a back end database accessed
- via a JDBC driver, which sends SQL statements to the database for
- processing. However, those statements should only commit if the
- enclosing web service transaction does. For this to work, the web
- service must employ transaction bridging. Transaction bridging registers
- a participant with the coordinator for the web service transaction and
- creates a matching XA transaction within which it can invoke the driver
- to make tentative changes to the database. The web service ensures that
- service requests associated with a specific web service transaction are
- executed in the scope of the corresponding XA transaction, grouping
- changes common to a given transaction while isolating changes belonging
- to different transactions. The participant responds to prepare, commit,
- or rollback requests associated from the web service transaction
- coordinator by forwarding the same operations to the underlying XA
- transaction coordinator, ensuring that the local outcome in the database
- corresponds with the global outcome of the web service transaction as a
- whole.
+ The transaction-aware web service employs a back end database accessed via a JDBC driver, which sends SQL statements
+ to the database for processing. However, those statements should only commit if the enclosing web service transaction
+ does. For this to work, the web service must employ transaction bridging. Transaction bridging registers a
+ participant with the coordinator for the web service transaction and creates a matching XA transaction within which
+ it can invoke the driver to make tentative changes to the database. The web service ensures that service requests
+ associated with a specific web service transaction are executed in the scope of the corresponding XA transaction,
+ grouping changes common to a given transaction while isolating changes belonging to different transactions. The
+ participant responds to prepare, commit, or rollback requests associated from the web service transaction coordinator
+ by forwarding the same operations to the underlying XA transaction coordinator, ensuring that the local outcome in
+ the database corresponds with the global outcome of the web service transaction as a whole.
</para>
<para>
- Things are less complex for the client. Through its API, the client application registers a participant with the transaction, and uses this participant to control termination of the transaction.
+ Things are less complex for the client. Through its API, the client application registers a participant with the
+ transaction, and uses this participant to control termination of the transaction.
</para>
</section> <!-- <title>WS-Transaction Architecture</title> -->
<section>
<title>WS_Transaction Models</title>
<para>
- It has been established that traditional transaction models are not appropriate for Web Services. No one specific protocol is likely to be sufficient, given the wide range of situations where Web service transactions are likely to be used. The WS-Transaction specification proposes two distinct models, where each supports the semantics of a particular kind of B2B interaction.
+ It has been established that traditional transaction models are not appropriate for Web Services. No one specific
+ protocol is likely to be sufficient, given the wide range of situations where Web service transactions are likely to
+ be used. The WS-Transaction specification proposes two distinct models, where each supports the semantics of a
+ particular kind of B2B interaction.
</para>
<para>
- The following discussion presents the interactions between the client, web service and the transaction coordinator in great detail for expository purposes only. Most of this activity happens automatically behind the scenes. The actual APIs used to initiate and complete a transaction and to register a participant and drive it through the commit or abort process are described in <xref linkend="sec-xts-api" />.
+ The following discussion presents the interactions between the client, web service and the transaction coordinator in
+ great detail for expository purposes only. Most of this activity happens automatically behind the scenes. The actual
+ APIs used to initiate and complete a transaction and to register a participant and drive it through the commit or
+ abort process are described in <xref linkend="sec-xts-api" />.
</para>
<section>
- <title>Atomic Transactions</title>
- <para>
- An <firstterm>atomic transaction (AT)</firstterm> is similar to
- traditional ACID transactions, and is designed 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
- propagated to each enlisted resource via the participant, and the
- appropriate <systemitem>commit</systemitem> or
- <systemitem>rollback</systemitem> actions are taken by each.-->Within
- the scope of an AT, web services typically employ bridging to allow
- them to access XA resources, such as databases and message queues,
- under the control of the web service transaction. When the transaction
- terminates, the participant propagates the outcome decision of the AT
- to the XA resources, and the appropriate commit or rollback actions
- are taken by each.
- </para>
- <para>
- All services and associated participants are expected to provide ACID semantics, and it is expected that any use of atomic transactions occurs in environments and situations where ACID is appropriate. Usually, this environment is a trusted domain, over short durations.
- </para>
- <procedure>
- <title>Atomic Transaction Process</title>
- <step>
- <para>
- To begin an atomic transaction, the client application first locates a WS-C Activation Coordinator web service that supports WS-Transaction.
- </para>
- </step>
- <step>
- <para>
- The client sends a WS-C <systemitem>CreateCoordinationContext</systemitem> message to the service, specifying <ulink url="http://schemas.xmlsoap.org/ws/2004/10/wsat" /> as its coordination type.
- </para>
- </step>
- <step>
- <para>
- The client receives an appropriate WS-Transaction context from the activation service.
- </para>
- </step>
- <step>
- <para>
- The response to the <systemitem>CreateCoordinationContext</systemitem> message, the transaction context, has its <systemitem>CoordinationType</systemitem> element set to the WS-Atomic Transaction namespace, <ulink url="http://schemas.xmlsoap.org/ws/2004/10/wsat" />. It also contains a reference to the atomic transaction coordinator endpoint, the WS-C Registration Service, where participants can be enlisted.
- </para>
- </step>
- <step>
- <para>
- The client normally proceeds to invoke Web Services and complete the transaction, either committing all the changes made by the web services, or rolling them back. In order to be able to drive this completion activity, the client must register itself as a participant for the <systemitem>Completion</systemitem> protocol, by sending a <systemitem>Register</systemitem> message to the Registration Service whose endpoint was returned in the Coordination Context.
- </para>
- </step>
- <step>
- <para>
- Once registered for Completion, the client application then interacts with Web Services to accomplish its business-level work. With each invocation of 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. This ensures that modifications made by the Web service are done within the scope of the same transaction as the client and subject to commit or rollback by the transaction coordinator.
- </para>
- </step>
- <step>
- <para>
- Once all the necessary application-level work is complete, the client can terminate the transaction, with the intent of making any changes to the service state permanent. The completion participant instructs the coordinator to try to commit or roll back the transaction. When the commit or roll-back operation completes, a status is returned to the participant to indicate the outcome of the transaction.
- </para>
- </step>
- </procedure>
+ <title>Atomic Transactions</title>
+ <para>
+ An <firstterm>atomic transaction (AT)</firstterm> is similar to traditional ACID transactions, and is designed 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 propagated
+ to each enlisted resource via the participant, and the appropriate <systemitem>commit</systemitem> or
+ <systemitem>rollback</systemitem> actions are taken by each.-->Within the scope of an AT, web services typically
+ employ bridging to allow them to access XA resources, such as databases and message queues, under the control of
+ the web service transaction. When the transaction terminates, the participant propagates the outcome decision of
+ the AT to the XA resources, and the appropriate commit or rollback actions are taken by each.
+ </para>
+ <para>
+ All services and associated participants are expected to provide ACID semantics, and it is expected that any use of
+ atomic transactions occurs in environments and situations where ACID is appropriate. Usually, this environment is a
+ trusted domain, over short durations.
+ </para>
+ <procedure>
+ <title>Atomic Transaction Process</title>
+ <step>
+ <para>
+ To begin an atomic transaction, the client application first locates a WS-C Activation Coordinator web service
+ that supports WS-Transaction.
+ </para>
+ </step>
+ <step>
+ <para>
+ The client sends a WS-C <systemitem>CreateCoordinationContext</systemitem> message to the service, specifying
+ <ulink url="http://schemas.xmlsoap.org/ws/2004/10/wsat" /> as its coordination type.
+ </para>
+ </step>
+ <step>
+ <para>
+ The client receives an appropriate WS-Transaction context from the activation service.
+ </para>
+ </step>
+ <step>
+ <para>
+ The response to the <systemitem>CreateCoordinationContext</systemitem> message, the transaction context, has
+ its <systemitem>CoordinationType</systemitem> element set to the WS-Atomic Transaction namespace, <ulink
+ url="http://schemas.xmlsoap.org/ws/2004/10/wsat" />. It also contains a reference to the atomic transaction
+ coordinator endpoint, the WS-C Registration Service, where participants can be enlisted.
+ </para>
+ </step>
+ <step>
+ <para>
+ The client normally proceeds to invoke Web Services and complete the transaction, either committing all the
+ changes made by the web services, or rolling them back. In order to be able to drive this completion activity,
+ the client must register itself as a participant for the <systemitem>Completion</systemitem> protocol, by
+ sending a <systemitem>Register</systemitem> message to the Registration Service whose endpoint was returned in
+ the Coordination Context.
+ </para>
+ </step>
+ <step>
+ <para>
+ Once registered for Completion, the client application then interacts with Web Services to accomplish its
+ business-level work. With each invocation of 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. This ensures that modifications made by the Web service are done within the
+ scope of the same transaction as the client and subject to commit or rollback by the transaction coordinator.
+ </para>
+ </step>
+ <step>
+ <para>
+ Once all the necessary application-level work is complete, the client can terminate the transaction, with the
+ intent of making any changes to the service state permanent. The completion participant instructs the
+ coordinator to try to commit or roll back the transaction. When the commit or roll-back operation completes, a
+ status is returned to the participant to indicate the outcome of the transaction.
+ </para>
+ </step>
+ </procedure>
- <para>
- Although this description of the completion protocol seems straightforward, it hides the fact that in order to resolve the transaction to an outcome, several other participant protocols need to be followed.
- </para>
+ <para>
+ Although this description of the completion protocol seems straightforward, it hides the fact that in order to
+ resolve the transaction to an outcome, several other participant protocols need to be followed.
+ </para>
- <variablelist>
- <varlistentry>
- <term>Volatile2pc</term>
- <listitem>
- <para>
- The first of these protocols is the optional <firstterm>Volatile2PC</firstterm> (2PC is an abbreviation referring to the two-phase commit). The Volatile2PC protocol is the WS-Atomic Transaction equivalent of the synchronization protocol discussed earlier. It is typically executed where a Web service needs to flush volatile (cached) state, which may be used to improve performance of an application, to a database prior to the transaction committing. Once flushed, the data is controlled by a two-phase aware participant.
- </para>
- <para>
- When the completion participant initiates a <systemitem>commit</systemitem> operation, all Volatile2PC participants are informed that the transaction is about to complete, via the <systemitem>prepare</systemitem> message. The participants can respond with one of three messages: <systemitem>prepared</systemitem>, <systemitem>aborted</systemitem>, or <systemitem>readonly</systemitem>. A failure at this stage causes the transaction to roll back.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Durable2PC</term>
- <listitem>
- <para>
- The next protocol in the WS-Atomic Transaction is <firstterm>Durable2PC</firstterm>. The Durable2PC protocol is at the core of WS-Atomic Transaction. It brings about the necessary consensus between participants in a transaction, so the transaction can safely be terminated.
- </para>
- <para>
- The Durable2PC protocol ensures atomicity between participants, and is based on the classic technique of <phrase>two-phase commit with presumed abort</phrase>.
- </para>
- <procedure>
- <title>Durable2PC Procedure</title>
- <step>
- <para>
- 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, so these changes can either be rolled back or committed later. None of the original state information can be lost at this point, since the atomic transaction may still roll back. If the participant cannot <systemitem>prepare</systemitem>, it must inform the coordinator, by means of the <systemitem>aborted</systemitem> message. The transaction will ultimately roll back. If the participant is responsible for a service that did not change any of the transaction's data,, it can return the <systemitem>readonly</systemitem> message, causing it to be omitted from the second phase of the commit protocol. Otherwise, the <systemitem>prepared</systemitem> message is sent by the participant.
- </para>
- </step>
- <step>
- <para>
- If no failures occur during the first phase, Durable2PC proceeds to the second phase, in which the coordinator sends the <systemitem>commit</systemitem> message to participants. Participants then make permanent the tentative work done by their associated services, and send a <systemitem>committed</systemitem> message to the coordinator. If any failures occur, the coordinator sends the <systemitem>rollback</systemitem> message to all participants, causing them to discard tentative work done by their associated services, and delete any state information saved to persistent storage at <systemitem>prepare</systemitem>, if they have reached that stage. Participants respond to a rollback by sending an <systemitem>aborted</systemitem> message to the coordinator.
- </para>
- </step>
- </procedure>
- <note>
- <para>
- The semantics of the WS-Atomic Transaction protocol do not include the one-phase commit optimization. A full two-phase commit is always used, even where only a single participant is enlisted.
- </para>
- </note>
- </listitem>
- </varlistentry>
- </variablelist>
- <para>
- <xref linkend="two-pc-participant-state-transitions" /> shows the state transitions of a WS-Atomic Transaction and the message exchanges between coordinator and participant. Messages generated by the coordinator are represented by solid lines, while the participants' messages use dashed lines.
- </para>
- <figure id="two-pc-participant-state-transitions">
- <title>WS-Atomic Two-Phase Participant State Transitions</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-2pc-participant-state-transitions.png" format="PNG"/>
- </imageobject>
- </mediaobject>
- </figure>
+ <variablelist>
+ <varlistentry>
+ <term>Volatile2pc</term>
+ <listitem>
+ <para>
+ The first of these protocols is the optional <firstterm>Volatile2PC</firstterm> (2PC is an abbreviation referring
+ to the two-phase commit). The Volatile2PC protocol is the WS-Atomic Transaction equivalent of the synchronization
+ protocol discussed earlier. It is typically executed where a Web service needs to flush volatile (cached) state,
+ which may be used to improve performance of an application, to a database prior to the transaction
+ committing. Once flushed, the data is controlled by a two-phase aware participant.
+ </para>
+ <para>
+ When the completion participant initiates a <systemitem>commit</systemitem> operation, all Volatile2PC
+ participants are informed that the transaction is about to complete, via the <systemitem>prepare</systemitem>
+ message. The participants can respond with one of three messages: <systemitem>prepared</systemitem>,
+ <systemitem>aborted</systemitem>, or <systemitem>readonly</systemitem>. A failure at this stage causes the
+ transaction to roll back.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Durable2PC</term>
+ <listitem>
+ <para>
+ The next protocol in the WS-Atomic Transaction is <firstterm>Durable2PC</firstterm>. The Durable2PC protocol is at
+ the core of WS-Atomic Transaction. It brings about the necessary consensus between participants in a transaction,
+ so the transaction can safely be terminated.
+ </para>
+ <para>
+ The Durable2PC protocol ensures atomicity between participants, and is based on the classic technique of
+ <phrase>two-phase commit with presumed abort</phrase>.
+ </para>
+ <procedure>
+ <title>Durable2PC Procedure</title>
+ <step>
+ <para>
+ 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, so these changes can either be rolled back or
+ committed later. None of the original state information can be lost at this point, since the atomic
+ transaction may still roll back. If the participant cannot <systemitem>prepare</systemitem>, it must inform
+ the coordinator, by means of the <systemitem>aborted</systemitem> message. The transaction will ultimately
+ roll back. If the participant is responsible for a service that did not change any of the transaction's data,,
+ it can return the <systemitem>readonly</systemitem> message, causing it to be omitted from the second phase of
+ the commit protocol. Otherwise, the <systemitem>prepared</systemitem> message is sent by the participant.
+ </para>
+ </step>
+ <step>
+ <para>
+ If no failures occur during the first phase, Durable2PC proceeds to the second phase, in which the coordinator
+ sends the <systemitem>commit</systemitem> message to participants. Participants then make permanent the
+ tentative work done by their associated services, and send a <systemitem>committed</systemitem> message to the
+ coordinator. If any failures occur, the coordinator sends the <systemitem>rollback</systemitem> message to all
+ participants, causing them to discard tentative work done by their associated services, and delete any state
+ information saved to persistent storage at <systemitem>prepare</systemitem>, if they have reached that
+ stage. Participants respond to a rollback by sending an <systemitem>aborted</systemitem> message to the
+ coordinator.
+ </para>
+ </step>
+ </procedure>
+ <note>
+ <para>
+ The semantics of the WS-Atomic Transaction protocol do not include the one-phase commit optimization. A full
+ two-phase commit is always used, even where only a single participant is enlisted.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ <xref linkend="two-pc-participant-state-transitions" /> shows the state transitions of a WS-Atomic Transaction and
+ the message exchanges between coordinator and participant. Messages generated by the coordinator are represented by
+ solid lines, while the participants' messages use dashed lines.
+ </para>
+ <figure id="two-pc-participant-state-transitions">
+ <title>WS-Atomic Two-Phase Participant State Transitions</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/fig-2pc-participant-state-transitions.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
- <para>
- Once the Durable2PC protocol completes, the <systemitem>Completion</systemitem> protocol that originally began the termination of the transaction can complete, and inform the client application whether the transaction was committed or rolled back. Additionally, the Volatile2PC protocol may complete.
- </para>
- <para>
- Like the <systemitem>prepare</systemitem> phase of Volatile2PC, the final phase is optional and can be used to inform participants about the transaction's completion, so that they can release resources such as database connections.
- </para>
- <para>
- Any registered Volatile2PC participants are invoked after the transaction terminates, and are informed about the transaction's completion state by the coordinator. Since the transaction has terminated, any failures of participants at this stage are ignored, since they have no impact on outcomes.
- </para>
- <para>
- <xref linkend="fig-at-model" /> illustrates the intricate interweaving of individual protocols comprising the AT as a whole.
- </para>
- <figure id="fig-at-model">
- <title></title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-at-model.png" format="PNG"/>
- </imageobject>
- </mediaobject>
- </figure>
+ <para>
+ Once the Durable2PC protocol completes, the <systemitem>Completion</systemitem> protocol that originally began the
+ termination of the transaction can complete, and inform the client application whether the transaction was
+ committed or rolled back. Additionally, the Volatile2PC protocol may complete.
+ </para>
+ <para>
+ Like the <systemitem>prepare</systemitem> phase of Volatile2PC, the final phase is optional and can be used to
+ inform participants about the transaction's completion, so that they can release resources such as database
+ connections.
+ </para>
+ <para>
+ Any registered Volatile2PC participants are invoked after the transaction terminates, and are informed about the
+ transaction's completion state by the coordinator. Since the transaction has terminated, any failures of
+ participants at this stage are ignored, since they have no impact on outcomes.
+ </para>
+ <para>
+ <xref linkend="fig-at-model" /> illustrates the intricate interweaving of individual protocols comprising the AT as
+ a whole.
+ </para>
+ <figure id="fig-at-model">
+ <title></title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/fig-at-model.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
</section> <!-- <title>Atomic Transactions </title> -->
<section>
- <title>Business Activities</title>
- <para>
- Most B2B applications require transactional support in order to guarantee consistent outcome and correct execution. These applications often involve long-running computations, loosely coupled systems, and components that do not share data, location, or administration. It is difficult to incorporate atomic transactions within such architectures.
- </para>
- <para>
- For example, an online bookshop may reserve books for an individual for a specific period of time. However, if the individual does not purchase the books within that period, they become available again for purchase by other customers. Because it is not possible to have an infinite supply of stock, some online shops may seem, from the user's perspective, to reserve items for them, while actually allow others to preempt the reservation. A user may discover, to his disappointment, that the item is no longer available.
- </para>
- <para>
- A <firstterm>Business Activity (BA)</firstterm> is designed specifically for these kinds of long-duration interactions, where it is impossible or impractical to exclusively lock resources.
- </para>
- <procedure>
- <title>BA Process Overview</title>
- <step>
- <para>
- Services are requested to do work.
- </para>
- </step>
- <step>
- <para>
- Where those services have the ability to undo any work, they inform the BA, in case the BA later decides the cancel the work. If the BA suffers a failure. it can instruct the service to execute its <systemitem>undo</systemitem> behavior.
- </para>
- </step>
- </procedure>
- <para>
- The key to BA is that how services do their work and provide compensation mechanisms is not the responsibility of the WS-BA specification. It is delegated to the service provider.
- </para>
- <para>
- The WS-BA defines a protocol for Web Services-based applications to enable existing business processing and work-flow systems to wrap their proprietary mechanisms and interoperate across implementations and business boundaries.
- </para>
- <para>
- Unlike the WS-AT protocol model, where participants inform the coordinator of their state only when asked, a child activity within a BA can specify its outcome to the coordinator directly, without waiting for a request. A participant may choose to exit the activity or may notify the coordinator of a failure at any point. This feature is useful when tasks fail, since the notification can be used to modify the goals and drive processing forward, without the need to wait until the end of the transaction to identify failures. A well-designed Business Activity should be proactive.
- </para>
- <para>
- The BA protocols employ a compensation-based transaction model. When a participant in a business activity completes its work, it may choose to exit the activity. This choice does not allow any subsequent rollback. Alternatively, the participant can complete its activity, signaling to the coordinator that the work it has done can be compensated if, at some later point, another participant notifies a failure to the coordinator. In this latter case, the coordinator asks each non-exited participant to compensate for the failure, giving them the opportunity to execute whatever compensating action they consider appropriate. For instance, participant might credit a bank account which it previously debited. If all participants exit or complete without failure, the coordinator notifies each completed participant that the activity has been closed.
- </para>
- <para>
- Underpinning all of this are three fundamental assumptions, detailed in <xref linkend="wsba-assumptions" />.
- </para>
- <itemizedlist id="wsba-assumptions">
- <title>Assumptions of WS-BA</title>
- <listitem>
- <para>
- All state transitions are reliably recorded, including application state and coordination metadata (the record of sent and received messages).
- </para>
- </listitem>
- <listitem>
- <para>
- All request messages are acknowledged, so that problems are detected as early as possible. This avoids executing unnecessary tasks and can also detect a problem earlier when rectifying it is simpler and less expensive.
- </para>
- </listitem>
- <listitem>
- <para>
- As with atomic transactions, a <firstterm>response</firstterm> is defined as a separate operation, not as the output of the request. Message I/O implementations typically have timeout requirements too short for BA responses. If the response is not received after a timeout, it is re-sent, repeatedly, until a response is received. The receiver discards all but one identical request received.
- </para>
- </listitem>
- </itemizedlist>
+ <title>Business Activities</title>
+ <para>
+ Most B2B applications require transactional support in order to guarantee consistent outcome and correct
+ execution. These applications often involve long-running computations, loosely coupled systems, and components that
+ do not share data, location, or administration. It is difficult to incorporate atomic transactions within such
+ architectures.
+ </para>
+ <para>
+ For example, an online bookshop may reserve books for an individual for a specific period of time. However, if the
+ individual does not purchase the books within that period, they become available again for purchase by other
+ customers. Because it is not possible to have an infinite supply of stock, some online shops may seem, from the
+ user's perspective, to reserve items for them, while actually allow others to preempt the reservation. A user may
+ discover, to his disappointment, that the item is no longer available.
+ </para>
+ <para>
+ A <firstterm>Business Activity (BA)</firstterm> is designed specifically for these kinds of long-duration
+ interactions, where it is impossible or impractical to exclusively lock resources.
+ </para>
+ <procedure>
+ <title>BA Process Overview</title>
+ <step>
+ <para>
+ Services are requested to do work.
+ </para>
+ </step>
+ <step>
+ <para>
+ Where those services have the ability to undo any work, they inform the BA, in case the BA later decides the
+ cancel the work. If the BA suffers a failure. it can instruct the service to execute its
+ <systemitem>undo</systemitem> behavior.
+ </para>
+ </step>
+ </procedure>
+ <para>
+ The key to BA is that how services do their work and provide compensation mechanisms is not the responsibility of
+ the WS-BA specification. It is delegated to the service provider.
+ </para>
+ <para>
+ The WS-BA defines a protocol for Web Services-based applications to enable existing business processing and
+ work-flow systems to wrap their proprietary mechanisms and interoperate across implementations and business
+ boundaries.
+ </para>
+ <para>
+ Unlike the WS-AT protocol model, where participants inform the coordinator of their state only when asked, a child
+ activity within a BA can specify its outcome to the coordinator directly, without waiting for a request. A
+ participant may choose to exit the activity or may notify the coordinator of a failure at any point. This feature
+ is useful when tasks fail, since the notification can be used to modify the goals and drive processing forward,
+ without the need to wait until the end of the transaction to identify failures. A well-designed Business Activity
+ should be proactive.
+ </para>
+ <para>
+ The BA protocols employ a compensation-based transaction model. When a participant in a business activity completes
+ its work, it may choose to exit the activity. This choice does not allow any subsequent rollback. Alternatively,
+ the participant can complete its activity, signaling to the coordinator that the work it has done can be
+ compensated if, at some later point, another participant notifies a failure to the coordinator. In this latter
+ case, the coordinator asks each non-exited participant to compensate for the failure, giving them the opportunity
+ to execute whatever compensating action they consider appropriate. For instance, participant might credit a bank
+ account which it previously debited. If all participants exit or complete without failure, the coordinator notifies
+ each completed participant that the activity has been closed.
+ </para>
+ <para>
+ Underpinning all of this are three fundamental assumptions, detailed in <xref linkend="wsba-assumptions" />.
+ </para>
+ <itemizedlist id="wsba-assumptions">
+ <title>Assumptions of WS-BA</title>
+ <listitem>
+ <para>
+ All state transitions are reliably recorded, including application state and coordination metadata (the record
+ of sent and received messages).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ All request messages are acknowledged, so that problems are detected as early as possible. This avoids
+ executing unnecessary tasks and can also detect a problem earlier when rectifying it is simpler and less
+ expensive.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ As with atomic transactions, a <firstterm>response</firstterm> is defined as a separate operation, not as the
+ output of the request. Message I/O implementations typically have timeout requirements too short for BA
+ responses. If the response is not received after a timeout, it is re-sent, repeatedly, until a response is
+ received. The receiver discards all but one identical request received.
+ </para>
+ </listitem>
+ </itemizedlist>
- <para>
- The BA model has two participant protocols: <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> and <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem>. Unlike the AT protocols which are driven from the coordinator down to participants, this protocol takes the opposite approach.
- </para>
+ <para>
+ The BA model has two participant protocols: <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> and
+ <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem>. Unlike the AT protocols which are driven from
+ the coordinator down to participants, this protocol takes the opposite approach.
+ </para>
- <variablelist>
- <varlistentry>
- <term>BusinessAgreementWithParticipantCompletion</term>
- <listitem>
- <procedure>
- <step>
- <para>
- A participant is initially created in the Active state.
- </para>
- </step>
- <step>
- <para>
- If it finishes its work and it is no longer needed within the scope of the BA (such as when the activity operates on immutable data), the participant can unilaterally decide to exit, sending an <systemitem>exited</systemitem> message to the coordinator. However, if the participant finishes and wishes to continue in the BA, it must be able to compensate for the work it has performed. In this case, it sends a <systemitem>completed</systemitem> message to the coordinator and waits for the coordinator to notify it about the final outcome of the BA. This outcome is either a <systemitem>close</systemitem> message, meaning the BA has completed successfully, or a <systemitem>compensate</systemitem> message indicating that the participant needs to reverse its work.
- </para>
- </step>
- </procedure>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>BusinessAgreementWithCoordinatorCompletion</term>
- <listitem>
- <para>
- The <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem> differs from the <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> protocol in that the participant cannot autonomously decide to complete its participation in the BA, even if it can be compensated.
- </para>
- <procedure>
- <step>
- <para>
- Instead, the completion stage is driven by the client which created the BA, which sends a <systemitem>completed</systemitem> message to the coordinator.
- </para>
- </step>
- <step>
- <para>
- The coordinator sends a <systemitem>complete</systemitem> message to each participant, indicating that no further requests will be sent to the service associated with the participant.
- </para>
- </step>
- <step>
- <para>
- The participant continues on in the same manner as in the BusinessAgreementWithParticipantCompletion protocol.
- </para>
- </step>
- </procedure>
- </listitem>
- </varlistentry>
- </variablelist>
- <para>
- The advantage of the BA model, compared to the AT model, is that is allows the participation of services that cannot lock resources for extended periods.
- </para>
- <para>
- While the full ACID semantics are not maintained by a BA, consistency can still be maintained through compensation. The task of writing correct compensating actions to preserve overall system consistency is the responsibility of the developers of the individual services under control of the BA. Such compensations may use backward error recovery, but forward recovery is more common.
- </para>
- <para>
- <xref linkend="fig-bawpc-state-transitions" /> shows the state transitions of a WS-BA <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> participant and the message exchanges between coordinator and participant. Messages generated by the coordinator are shown with solid lines, while the participants' messages are illustrated with dashed lines.
- </para>
- <figure id="fig-bawpc-state-transitions">
- <title></title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-bawpc-state-transitions.png" format="PNG"/>
- </imageobject>
- </mediaobject>
- </figure>
-
- <para>
- <xref linkend="fig-bawcc-state-transitions" /> shows the state transitions of a WS-BA <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem> participant and the message exchanges between coordinator and participant. Messages generated by the coordinator are shown with solid lines, while the participants' messages are illustrated with dashed lines.
- </para>
- <figure id="fig-bawcc-state-transitions">
- <title></title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-bawcc-state-transitions.png" format="PNG"/>
- </imageobject>
- </mediaobject>
- </figure>
- </section> <!-- <title>Business Activities</title> -->
+ <variablelist>
+ <varlistentry>
+ <term>BusinessAgreementWithParticipantCompletion</term>
+ <listitem>
+ <procedure>
+ <step>
+ <para>
+ A participant is initially created in the Active state.
+ </para>
+ </step>
+ <step>
+ <para>
+ If it finishes its work and it is no longer needed within the scope of the BA (such as when the activity
+ operates on immutable data), the participant can unilaterally decide to exit, sending an
+ <systemitem>exited</systemitem> message to the coordinator. However, if the participant finishes and wishes to
+ continue in the BA, it must be able to compensate for the work it has performed. In this case, it sends a
+ <systemitem>completed</systemitem> message to the coordinator and waits for the coordinator to notify it about
+ the final outcome of the BA. This outcome is either a <systemitem>close</systemitem> message, meaning the BA
+ has completed successfully, or a <systemitem>compensate</systemitem> message indicating that the participant
+ needs to reverse its work.
+ </para>
+ </step>
+ </procedure>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>BusinessAgreementWithCoordinatorCompletion</term>
+ <listitem>
+ <para>
+ The <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem> differs from the
+ <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> protocol in that the participant cannot
+ autonomously decide to complete its participation in the BA, even if it can be compensated.
+ </para>
+ <procedure>
+ <step>
+ <para>
+ Instead, the completion stage is driven by the client which created the BA, which sends a
+ <systemitem>completed</systemitem> message to the coordinator.
+ </para>
+ </step>
+ <step>
+ <para>
+ The coordinator sends a <systemitem>complete</systemitem> message to each participant, indicating that no
+ further requests will be sent to the service associated with the participant.
+ </para>
+ </step>
+ <step>
+ <para>
+ The participant continues on in the same manner as in the BusinessAgreementWithParticipantCompletion protocol.
+ </para>
+ </step>
+ </procedure>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ The advantage of the BA model, compared to the AT model, is that is allows the participation of services that
+ cannot lock resources for extended periods.
+ </para>
+ <para>
+ While the full ACID semantics are not maintained by a BA, consistency can still be maintained through
+ compensation. The task of writing correct compensating actions to preserve overall system consistency is the
+ responsibility of the developers of the individual services under control of the BA. Such compensations may use
+ backward error recovery, but forward recovery is more common.
+ </para>
+ <para>
+ <xref linkend="fig-bawpc-state-transitions" /> shows the state transitions of a WS-BA
+ <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> participant and the message exchanges between
+ coordinator and participant. Messages generated by the coordinator are shown with solid lines, while the
+ participants' messages are illustrated with dashed lines.
+ </para>
+ <figure id="fig-bawpc-state-transitions">
+ <title></title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/fig-bawpc-state-transitions.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+
+ <para>
+ <xref linkend="fig-bawcc-state-transitions" /> shows the state transitions of a WS-BA
+ <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem> participant and the message exchanges between
+ coordinator and participant. Messages generated by the coordinator are shown with solid lines, while the
+ participants' messages are illustrated with dashed lines.
+ </para>
+ <figure id="fig-bawcc-state-transitions">
+ <title></title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/fig-bawcc-state-transitions.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+ </section> <!-- <title>Business Activities</title> -->
</section> <!-- <title>WS-Transaction Models</title> -->
<section>
<title>Application Messages</title>
<para>
- <firstterm>Application messages</firstterm> are the requests and responses sent between parties, that constitute the work of a business process. Any such messages are considered opaque by XTS, and there is no mandatory message format, protocol binding, or encoding style. This means that you are free to use any appropriate Web Services protocol. In XTS, the transaction context is propagated within the headers of SOAP messages.
+ <firstterm>Application messages</firstterm> are the requests and responses sent between parties, that constitute the
+ work of a business process. Any such messages are considered opaque by XTS, and there is no mandatory message format,
+ protocol binding, or encoding style. This means that you are free to use any appropriate Web Services protocol. In
+ XTS, the transaction context is propagated within the headers of SOAP messages.
</para>
<para>
- XTS ships with support for service developers building WS-Transactions-aware services on the &APPSERVER;. Interceptors are provided for automatic context handling at both client and service, which significantly simplifies development, allowing you to concentrate on writing the business logic without being sidetracked by the transactional infrastructure. The interceptors add and remove context elements to application messages, without altering the semantics of the messages themselves. Any service which understands what to do with a WS-C context can use it. Services which are not aware of WS-C, WS-Atomic Transaction and WS-Business Activity can ignore the context. XTS manages contexts without user intervention.
+ XTS ships with support for service developers building WS-Transactions-aware services on the
+ &APPSERVER;. Interceptors are provided for automatic context handling at both client and service, which
+ significantly simplifies development, allowing you to concentrate on writing the business logic without being
+ sidetracked by the transactional infrastructure. The interceptors add and remove context elements to application
+ messages, without altering the semantics of the messages themselves. Any service which understands what to do with
+ a WS-C context can use it. Services which are not aware of WS-C, WS-Atomic Transaction and WS-Business Activity can
+ ignore the context. XTS manages contexts without user intervention.
</para>
<section>
- <title>WS-C, WS-Atomic Transaction, and WS-Business Activity Messages</title>
- <para>
- Although the application or service developer is rarely interested in the messages exchanged by the transactional infrastructure, it is useful to understand what kinds of exchanges occur so that the underlying model can be fitted in to an overall architecture.
- </para>
- <para>
- WS-Coordination, WS-Atomic Transaction and WS-Business Activity-specific messages are transported using SOAP messaging over HTTP. The types of messages that are propagated include instructions to perform standard transaction operations like <systemitem>begin</systemitem> and <systemitem>prepare</systemitem>.
- </para>
- <note>
- <para>
- XTS messages do not interfere with messages from the application, an application need not use the same transport as the transaction-specific messages. For example, a client application might deliver its application-specific messages using SOAP RPC over SMTP, even though the XTS messages are delivered using a different mechanism.
- </para>
- </note>
- </section> <!-- <title>WS-C, WS-Atomic Transaction, and WS-Business Activity Messages</title> -->
+ <title>WS-C, WS-Atomic Transaction, and WS-Business Activity Messages</title>
+ <para>
+ Although the application or service developer is rarely interested in the messages exchanged by the transactional
+ infrastructure, it is useful to understand what kinds of exchanges occur so that the underlying model can be fitted
+ in to an overall architecture.
+ </para>
+ <para>
+ WS-Coordination, WS-Atomic Transaction and WS-Business Activity-specific messages are transported using SOAP
+ messaging over HTTP. The types of messages that are propagated include instructions to perform standard transaction
+ operations like <systemitem>begin</systemitem> and <systemitem>prepare</systemitem>.
+ </para>
+ <note>
+ <para>
+ XTS messages do not interfere with messages from the application, an application need not use the same transport
+ as the transaction-specific messages. For example, a client application might deliver its application-specific
+ messages using SOAP RPC over SMTP, even though the XTS messages are delivered using a different mechanism.
+ </para>
+ </note>
+ </section> <!-- <title>WS-C, WS-Atomic Transaction, and WS-Business Activity Messages</title> -->
</section> <!-- <title>Application Messages</title> -->
</section>
@@ -645,7 +793,14 @@
<section>
<title>Summary</title>
<para>
- XTS provides a coordination infrastructure which allows transactions to run between services owned by different business, across the Internet. That infrastructure is based on the WS-C, WS-Atomic Transaction and WS-Business Activity specifications. It supports two kinds of transactions: atomic transactions and business activities, which can be combined in arbitrary ways to map elegantly onto the transactional requirements of the underlying problem. The use of the whole infrastructure is simple, because its functionality is exposed through a simple transactioning API. XTS provides everything necessary to keep application and transactional aspects of an application separate, and to ensure that a system's use of transactions does not interfere with the functional aspects of the system itself.
+ XTS provides a coordination infrastructure which allows transactions to run between services owned by different
+ business, across the Internet. That infrastructure is based on the WS-C, WS-Atomic Transaction and WS-Business
+ Activity specifications. It supports two kinds of transactions: atomic transactions and business activities, which
+ can be combined in arbitrary ways to map elegantly onto the transactional requirements of the underlying
+ problem. The use of the whole infrastructure is simple, because its functionality is exposed through a simple
+ transactioning API. XTS provides everything necessary to keep application and transactional aspects of an
+ application separate, and to ensure that a system's use of transactions does not interfere with the functional
+ aspects of the system itself.
</para>
</section> <!-- summary -->
</chapter>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Revision_History.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Revision_History.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Revision_History.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,27 +1,27 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<appendix id="appe-Transactions_XTS_Programmers_Guide-Revision_History">
- <title>Revision History</title>
- <simpara>
- <revhistory>
- <revision>
- <revnumber>0</revnumber>
- <date>Mon Jul 12 2010</date>
- <author>
- <firstname>Misty</firstname>
- <surname>Stanley-Jones</surname>
- <email>mstanley at redhat.com</email>
- </author>
- <revdescription>
- <simplelist>
- <member>Initial creation of book by publican</member>
- </simplelist>
- </revdescription>
- </revision>
- </revhistory>
- </simpara>
+ <title>Revision History</title>
+ <simpara>
+ <revhistory>
+ <revision>
+ <revnumber>0</revnumber>
+ <date>Mon Jul 12 2010</date>
+ <author>
+ <firstname>Misty</firstname>
+ <surname>Stanley-Jones</surname>
+ <email>mstanley at redhat.com</email>
+ </author>
+ <revdescription>
+ <simplelist>
+ <member>Initial creation of book by publican</member>
+ </simplelist>
+ </revdescription>
+ </revision>
+ </revhistory>
+ </simpara>
</appendix>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Stand_Alone_Coordination.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Stand_Alone_Coordination.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Stand_Alone_Coordination.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_Overview.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Transactions_Overview.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_Overview.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter>
@@ -24,59 +24,70 @@
<note>
<para>
- This chapter deals with the theory of transactional Web Services. If you are familiar with these principles, consider this chapter a reference.
+ This chapter deals with the theory of transactional Web Services. If you are familiar with these principles,
+ consider this chapter a reference.
</para>
</note>
<para>
- 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 JBoss Transaction Service 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.
+ 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 JBoss
+ Transaction Service 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>
<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.
+ 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 <xref linkend="fig-web-services-transaction" />.
+ The main components involved in using and defining transactional Web Services using XTS are illustrated in <xref
+ linkend="fig-web-services-transaction" />.
</para>
<figure id="fig-web-services-transaction">
<title>Components Involved in an XTS Transaction</title>
<mediaobject>
<imageobject>
- <imagedata fileref="images/fig-web-services-transaction.png" format="PNG"/>
+ <imagedata fileref="images/fig-web-services-transaction.png" format="PNG"/>
</imageobject>
<textobject>
- <variablelist>
- <varlistentry>
- <term>Transaction Service</term>
- <listitem>
- <para>The Transaction Service captures the model of the underlying transaction protocol and coordinates parties affiliated with the transaction according to that model.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Transaction API</term>
- <listitem>
- <para>
- Provides an interface for transaction demarcation and the registration of participants.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>A Participant</term>
- <listitem>
- <para>
- The entity that cooperates with the transaction service on behalf of its associated business logic.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>The Context</term>
- <listitem>
- <para>
- Captures the necessary details of the transaction such that participants can enlist within its scope.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
+ <variablelist>
+ <varlistentry>
+ <term>Transaction Service</term>
+ <listitem>
+ <para>The Transaction Service captures the model of the underlying transaction protocol and coordinates parties affiliated with the transaction according to that model.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Transaction API</term>
+ <listitem>
+ <para>
+ Provides an interface for transaction demarcation and the registration of participants.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>A Participant</term>
+ <listitem>
+ <para>
+ The entity that cooperates with the transaction service on behalf of its associated business logic.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>The Context</term>
+ <listitem>
+ <para>
+ Captures the necessary details of the transaction such that participants can enlist within its scope.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</textobject>
</mediaobject>
</figure>
@@ -85,7 +96,10 @@
<title>The Coordinator</title>
<para>
<!--
- Every transaction is associated with 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 effectively a factory for those coordinators.
+ Every transaction is associated with 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 effectively a
+ factory for those coordinators.
-->
Every transaction is associated with a coordinator, which is responsible
for governing the outcome of the transaction. When a client begins a Web
@@ -100,10 +114,16 @@
</para>
<para>
<!--
- A coordinator communicates with enrolled participants to inform them of the desired termination requirements, such as whether they should accept (confirm) or reject (cancel) the work done within the scope of the given transaction. For example, a decision is needed for whether to purchase the provisionally reserved flight tickets for the user or to release them. An application may wish to terminate a transaction in a number of different ways (confirm or cancel). However, although the coordinator will attempt to terminate in a manner consistent with that desired by the client, the final outcome is ultimately determined by the interactions between the coordinator and the participants.
- </para>
- <para>
- A transaction manager is typically responsible for managing coordinators for many transactions. The initiator of the transaction (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.
+ A coordinator communicates with enrolled participants to inform them of the desired termination requirements, such
+ as whether they should accept (confirm) or reject (cancel) the work done within the scope of the given
+ transaction. For example, a decision is needed for whether to purchase the provisionally reserved flight tickets
+ for the user or to release them. An application may wish to terminate a transaction in a number of different ways
+ (confirm or cancel). However, although the coordinator will attempt to terminate in a manner consistent with that
+ desired by the client, the final outcome is ultimately determined by the interactions between the coordinator and
+ the participants. </para> <para> A transaction manager is typically responsible for managing coordinators for
+ many transactions. The initiator of the transaction (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.
-->
The coordinator is responsible for ensuring that the web services invoked
by the client arrive at a consistent outcome. When the client asks the
@@ -117,63 +137,61 @@
cancel the transaction.
</para>
<para>
- The negotiation between the coordinator and the web services is organized
- to ensure that all services will make their changes permanent, or all of
- them will revert to the previous state, even if the coordinator or one of
- the web services crashes part of the way through the transaction."
+ The negotiation between the coordinator and the web services is organized to ensure that all services will make
+ their changes permanent, or all of them will revert to the previous state, even if the coordinator or one of the
+ web services crashes part of the way through the transaction."
</para>
</section>
<section>
<title>The Transaction Context</title>
<para>
- In order for a transaction to span a number of services, certain
- information has to be shared between those services, to propagate
- information about the transaction. This information is known as the
- <firstterm>Context</firstterm>. The coordination service hands a context
- back to the application client when it begins a transaction. This context
- is passed as an extra, hidden parameter whenever the client invokes a
- transactional web service. The XTS implementation saves and propagates
- this context automatically with only minimal involvement required on the
- part of the client. <!--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,-->
- However, it is still helpful to understand what information is captured in
- a context. This information is listed in <xref linkend="context-contents"
- />.
+ In order for a transaction to span a number of services, certain information has to be shared between those
+ services, to propagate information about the transaction. This information is known as the
+ <firstterm>Context</firstterm>. The coordination service hands a context back to the application client when it
+ begins a transaction. This context is passed as an extra, hidden parameter whenever the client invokes a
+ transactional web service. The XTS implementation saves and propagates this context automatically with only
+ minimal involvement required on the part of the client. <!--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,--> However, it is still helpful to understand what information is captured in a
+ context. This information is listed in <xref linkend="context-contents" />.
</para>
<variablelist id="context-contents">
<title>Contents of a Context</title>
<varlistentry>
- <term>Transaction Identifier</term>
- <listitem>
- <para>
- Guarantees global uniqueness for an individual transaction.
- </para>
- </listitem>
+ <term>Transaction Identifier</term>
+ <listitem>
+ <para>
+ Guarantees global uniqueness for an individual transaction.
+ </para>
+ </listitem>
</varlistentry>
<varlistentry>
- <term>Transaction Coordinator Location</term>
- <listitem>
- <para>
- The endpoint address participants contact to enroll.
- </para>
- </listitem>
+ <term>Transaction Coordinator Location</term>
+ <listitem>
+ <para>
+ The endpoint address participants contact to enroll.
+ </para>
+ </listitem>
</varlistentry>
</variablelist>
<figure>
<title>Web Services and Context Flow</title>
<mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-web-services-context-flow.png" format="PNG"/>
- </imageobject>
- <textobject>
- <para>
- 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 can extract that context using the XTS service-side infrastructure and use it to perform work within the context of a particular transaction, even if 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>
- </textobject>
+ <imageobject>
+ <imagedata fileref="images/fig-web-services-context-flow.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <para>
+ 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 can extract that context using the XTS service-side
+ infrastructure and use it to perform work within the context of a particular transaction, even if 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>
+ </textobject>
</mediaobject>
</figure>
</section>
@@ -181,62 +199,61 @@
<section>
<title>Participants</title>
<para>
- The coordinator cannot know the details of how every transactional service
- is implemented. In fact this knowledge is not even necessary for it to
- negotiate a transactional outcome. It treats each service taking part in a
- transaction as a participant and communicates with it according to some
- predefined participant coordination models appropriate to the type of
- transaction. <!--When a service begins performing work within the scope of
- a transaction it enrolls itself with the coordinator as a participant,
- specifying the participant model it wishes to follow.--> When a web
- service receives its first service request in some given transaction, it
- enrolls with the coordinator as a participant, specifying the participant
- model it wishes to follow. The context contains a URL for the endpoint of
- the coordination service which handles enrollment requests. So, the term
- participant merely refers a transactional service enrolled in a specific
- transaction using a specific participant model.
+ The coordinator cannot know the details of how every transactional service is implemented. In fact this knowledge
+ is not even necessary for it to negotiate a transactional outcome. It treats each service taking part in a
+ transaction as a participant and communicates with it according to some predefined participant coordination models
+ appropriate to the type of transaction. <!--When a service begins performing work within the scope of a
+ transaction it enrolls itself with the coordinator as a participant, specifying the participant model it wishes to
+ follow.--> When a web service receives its first service request in some given transaction, it enrolls with the
+ coordinator as a participant, specifying the participant model it wishes to follow. The context contains a URL for
+ the endpoint of the coordination service which handles enrollment requests. So, the term participant merely refers
+ a transactional service enrolled in a specific transaction using a specific participant model.
</para>
</section>
<section>
<title>ACID Transactions</title>
<para>
- Traditionally, transaction processing systems support <firstterm>ACID</firstterm> properties. ACID is an acronym for <emphasis>A</emphasis>tomic, <emphasis>C</emphasis>onsistent, <emphasis>I</emphasis>solated, and <emphasis>D</emphasis>urable. A unit of work has traditionally been considered transactional only if the ACID properties are maintained, as describe in <xref linkend="acid-properties" />.
+ Traditionally, transaction processing systems support <firstterm>ACID</firstterm> properties. ACID is an acronym
+ for <emphasis>A</emphasis>tomic, <emphasis>C</emphasis>onsistent, <emphasis>I</emphasis>solated, and
+ <emphasis>D</emphasis>urable. A unit of work has traditionally been considered transactional only if the ACID
+ properties are maintained, as describe in <xref linkend="acid-properties" />.
</para>
<variablelist id="acid-properties">
<title>ACID Properties</title>
<varlistentry>
- <term>Atomicity</term>
- <listitem>
- <para>
- The transaction executes completely, or not at all.
- </para>
- </listitem>
+ <term>Atomicity</term>
+ <listitem>
+ <para>
+ The transaction executes completely, or not at all.
+ </para>
+ </listitem>
</varlistentry>
<varlistentry>
- <term>Consistency</term>
- <listitem>
- <para>
- The effects of the transaction preserve the internal consistency of an underlying data structure.
- </para>
- </listitem>
+ <term>Consistency</term>
+ <listitem>
+ <para>
+ The effects of the transaction preserve the internal consistency of an underlying data structure.
+ </para>
+ </listitem>
</varlistentry>
<varlistentry>
- <term>Isolated</term>
- <listitem>
- <para>
- The transaction runs as if it were running alone, with no other transactions running, and is not visible to other transactions.
- </para>
- </listitem>
+ <term>Isolated</term>
+ <listitem>
+ <para>
+ The transaction runs as if it were running alone, with no other transactions running, and is not visible to other
+ transactions.
+ </para>
+ </listitem>
</varlistentry>
<varlistentry>
- <term>Durable</term>
- <listitem>
- <para>
- The transaction's results are not lost in the event of a failure.
- </para>
- </listitem>
+ <term>Durable</term>
+ <listitem>
+ <para>
+ The transaction's results are not lost in the event of a failure.
+ </para>
+ </listitem>
</varlistentry>
</variablelist>
</section>
@@ -245,30 +262,35 @@
<title>Two Phase Commit</title>
<para>
- The classical two-phase commit approach is the bedrock of JBoss Transaction Service, and more generally of Web Services transactions. Two-phase commit provides coordination of parties that are involved in a transaction. The general flow of a two-phase commit transaction is described in <xref linkend="two-phase-commit-overview" />.
+ The classical two-phase commit approach is the bedrock of JBoss Transaction Service, and more generally of Web
+ Services transactions. Two-phase commit provides coordination of parties that are involved in a transaction. The
+ general flow of a two-phase commit transaction is described in <xref linkend="two-phase-commit-overview" />.
</para>
<figure id="two-phase-commit-overview">
<title>Two-Phase Commit Overview</title>
<mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-two-phase-commit-overview.png" format="PNG"/>
- </imageobject>
- <textobject>
- <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 the resources to make all work performed 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>
- </textobject>
+ <imageobject>
+ <imagedata fileref="images/fig-two-phase-commit-overview.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <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 the resources to make all work performed 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>
+ </textobject>
</mediaobject>
</figure>
<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.
+ 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>
@@ -277,78 +299,109 @@
<section>
<title>The Synchronization Protocol</title>
<para>
- Besides the two-phase commit protocol, traditional transaction processing systems employ an additional protocol, often referred to as the <firstterm>synchronization protocol</firstterm>. With the original ACID properties, Durability is important when state changes need to be available despite failures. Applications interact with a persistence store of some kind, such as a database, and this interaction can impose a significant overhead, because disk access is much slower to access than main computer memory.
+ Besides the two-phase commit protocol, traditional transaction processing systems employ an additional protocol,
+ often referred to as the <firstterm>synchronization protocol</firstterm>. With the original ACID properties,
+ Durability is important when state changes need to be available despite failures. Applications interact with a
+ persistence store of some kind, such as a database, and this interaction can impose a significant overhead,
+ because disk access is much slower to access than main computer memory.
</para>
<para>
- One solution to the problem disk access time is to cache the state in main memory and only operate on the cache for the duration of a transaction. Unfortunately, this solution needs a way 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 <firstterm>Synchronization Participants</firstterm>.
+ One solution to the problem disk access time is to cache the state in main memory and only operate on the cache
+ for the duration of a transaction. Unfortunately, this solution needs a way 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 <firstterm>Synchronization Participants</firstterm>.
</para>
<para>
- Synchronizations are informed that a transaction is about to commit. At that point, they can flush cached state, which might be used to improve performance of an application, to a durable representation prior to the transaction committing. The synchronizations are then informed about when the transaction completes and its completion state.
+ Synchronizations are informed that a transaction is about to commit. At that point, they can flush cached state,
+ which might be used to improve performance of an application, to a durable representation prior to the transaction
+ committing. The synchronizations are then informed about when the transaction completes and its completion state.
</para>
<procedure>
<title>The "Four Phase Protocol" Created By Synchronizations</title>
<para>
- Synchronizations essentially turn the two-phase commit protocol into a four-phase protocol:
+ Synchronizations essentially turn the two-phase commit protocol into a four-phase protocol:
</para>
<step>
- <title>Step 1</title>
- <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>
+ <title>Step 1</title>
+ <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>
</step>
<step>
- <title>Steps 2 and 3</title>
- <para>
- The coordinator then conducts the normal two-phase commit protocol.
- </para>
+ <title>Steps 2 and 3</title>
+ <para>
+ The coordinator then conducts the normal two-phase commit protocol.
+ </para>
</step>
<step>
- <title>Step 4</title>
- <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>
+ <title>Step 4</title>
+ <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>
</step>
</procedure>
<para>
- The synchronization protocol does not have the same failure requirements as the traditional two-phase commit protocol. For example, Synchronization participants do not need the ability to recover in the event of failures, because any failure before the two-phase commit protocol completes cause the transaction to roll back, and failures after it completes have no effect on the data which the Synchronization participants are responsible for.
+ The synchronization protocol does not have the same failure requirements as the traditional two-phase commit
+ protocol. For example, Synchronization participants do not need the ability to recover in the event of failures,
+ because any failure before the two-phase commit protocol completes cause the transaction to roll back, and
+ failures after it completes have no effect on the data which the Synchronization participants are responsible for.
</para>
</section>
<section>
<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. <xref linkend="two-phase-variants" /> gives more information about each one.
+ 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. <xref linkend="two-phase-variants" /> gives more
+ information about each one.
</para>
<table id="two-phase-variants">
<title>Variants to the Two-Phase Commit Protocol</title>
<tgroup cols="2">
- <thead>
- <row>
- <entry><para>Variant</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>Presumed Abort</para></entry>
- <entry><para>If a transaction is going to roll back, the coordinator may record this information locally and tell all enlisted participants. Failure to contact a participant has no effect on the transaction outcome. The coordinator is informing participants only 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, no information will be available and the requester can assume that the transaction has aborted. This optimization has the benefit that no information about participants need be made persistent until the transaction has progressed to the end of the <systemitem>prepare</systemitem> phase and decided to commit, since any failure prior to this point is assumed to be an abort of the transaction.</para></entry>
- </row>
- <row>
- <entry><para>One-Phase</para></entry>
- <entry><para>If only a single participant is involved in the transaction, the coordinator does not need to drive it through the <systemitem>prepare</systemitem> phase. Thus, the participant is told to commit, and the coordinator does not need to record information about the decision, since the outcome of the transaction is the responsibility of the participant.</para></entry>
- </row>
- <row>
- <entry><para>Read-Only</para></entry>
- <entry><para>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. Therefore, a read-only participant can be omitted from the second phase of the commit protocol.</para></entry>
- </row>
- </tbody>
+ <thead>
+ <row>
+ <entry><para>Variant</para></entry>
+ <entry><para>Description</para></entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><para>Presumed Abort</para></entry>
+ <entry><para>If a transaction is going to roll back, the coordinator may record this information locally and tell
+ all enlisted participants. Failure to contact a participant has no effect on the transaction outcome. The
+ coordinator is informing participants only 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, no information will be available and the requester can assume that the transaction has aborted. This
+ optimization has the benefit that no information about participants need be made persistent until the transaction
+ has progressed to the end of the <systemitem>prepare</systemitem> phase and decided to commit, since any failure
+ prior to this point is assumed to be an abort of the transaction.</para></entry>
+ </row>
+ <row>
+ <entry><para>One-Phase</para></entry>
+ <entry><para>If only a single participant is involved in the transaction, the coordinator does not need to drive
+ it through the <systemitem>prepare</systemitem> phase. Thus, the participant is told to commit, and the
+ coordinator does not need to record information about the decision, since the outcome of the transaction is the
+ responsibility of the participant.</para></entry>
+ </row>
+ <row>
+ <entry><para>Read-Only</para></entry>
+ <entry><para>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. Therefore, a read-only participant can be omitted from the second phase of the commit
+ protocol.</para></entry>
+ </row>
+ </tbody>
</tgroup>
</table>
<note>
<para>
- The WS-Atomic Transaction protocol does not support the one-phase commit optimization.
+ The WS-Atomic Transaction protocol does not support the one-phase commit optimization.
</para>
</note>
</section>
@@ -356,50 +409,71 @@
<section>
<title>Non-Atomic Transactions and Heuristic Outcomes</title>
<para>
- In order to guarantee atomicity, the two-phase commit protocol is <firstterm>blocking</firstterm>. 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 cannot tolerate this blocking.
+ In order to guarantee atomicity, the two-phase commit protocol is <firstterm>blocking</firstterm>. 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 cannot tolerate this blocking.
</para>
<para>
- To break this blocking nature, participants that are past the <systemitem>prepare</systemitem> phase are allowed to make autonomous decisions about whether to commit or rollback. Such a participant must record its decision, so that it can complete the original transaction if it eventually gets a request to do so. If the coordinator eventually informs the participant of the transaction outcome, and it is the same as the choice the participant made, no conflict exists. If the decisions of the participant and coordinator are different, the situation is referred to as a non-atomic outcome, and more specifically as a <firstterm>heuristic outcome</firstterm>.
+ To break this blocking nature, participants that are past the <systemitem>prepare</systemitem> phase are allowed
+ to make autonomous decisions about whether to commit or rollback. Such a participant must record its decision, so
+ that it can complete the original transaction if it eventually gets a request to do so. If the coordinator
+ eventually informs the participant of the transaction outcome, and it is the same as the choice the participant
+ made, no conflict exists. If the decisions of the participant and coordinator are different, the situation is
+ referred to as a non-atomic outcome, and more specifically as a <firstterm>heuristic outcome</firstterm>.
</para>
<para>
- Resolving and reporting heuristic outcomes to the application is usually the domain of complex, manually driven system administration tools, because attempting an automatic resolution requires semantic information about the nature of participants involved in the transactions.
+ Resolving and reporting heuristic outcomes to the application is usually the domain of complex, manually driven
+ system administration tools, because attempting 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 depends on the specific implementation. Likewise, the choice the participant makes about whether to commit or to roll back depends upon the implementation, and possibly the application and the environment in which it finds itself. The possible heuristic outcomes are discussed in <xref linkend="tbl-heuristic-outcomes"/>.
+ Precisely when a participant makes a heuristic decision depends on the specific implementation. Likewise, the
+ choice the participant makes about whether to commit or to roll back depends upon the implementation, and possibly
+ the application and the environment in which it finds itself. The possible heuristic outcomes are discussed in
+ <xref linkend="tbl-heuristic-outcomes"/>.
</para>
<table id="tbl-heuristic-outcomes">
<title>Heuristic Outcomes</title>
<tgroup cols="2">
- <thead>
- <row>
- <entry><para>Outcome</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>Heuristic Rollback</para></entry>
- <entry><para>The commit operation failed because some or all of the participants unilaterally rolled back the transaction.</para></entry>
- </row>
- <row>
- <entry><para>Heuristic Commit</para></entry>
- <entry><para>An attempted rollback operation failed because all of the participants unilaterally committed. One situation where this might happen is if the coordinator is able to successfully <systemitem>prepare</systemitem> the transaction, but then decides to roll it back because its transaction log could not be updated. While the coordinator is making its decision, the participants decides to commit.</para></entry>
- </row>
- <row>
- <entry><para>Heuristic Mixed</para></entry>
- <entry><para>Some participants commit ed, while others were rolled back.</para></entry>
- </row>
- <row>
- <entry><para>Heuristic Hazard</para></entry>
- <entry><para>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></entry>
- </row>
- </tbody>
+ <thead>
+ <row>
+ <entry><para>Outcome</para></entry>
+ <entry><para>Description</para></entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><para>Heuristic Rollback</para></entry>
+ <entry><para>The commit operation failed because some or all of the participants unilaterally rolled back the
+ transaction.</para></entry>
+ </row>
+ <row>
+ <entry><para>Heuristic Commit</para></entry>
+ <entry><para>An attempted rollback operation failed because all of the participants unilaterally committed. One
+ situation where this might happen is if the coordinator is able to successfully <systemitem>prepare</systemitem>
+ the transaction, but then decides to roll it back because its transaction log could not be updated. While the
+ coordinator is making its decision, the participants decides to commit.</para></entry>
+ </row>
+ <row>
+ <entry><para>Heuristic Mixed</para></entry>
+ <entry><para>Some participants commit ed, while others were rolled back.</para></entry>
+ </row>
+ <row>
+ <entry><para>Heuristic Hazard</para></entry>
+ <entry><para>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></entry>
+ </row>
+ </tbody>
</tgroup>
</table>
<para>
- Heuristic decisions should be used with care and only in exceptional circumstances, since the decision may possibly differ from that determined by the transaction service. This type of difference can lead to a loss of integrity in the system. Try to avoid needing to perform resolution of heuristics, either by working with services and participants that do not cause heuristics, or by using a transaction service that provides assistance in the resolution process.
+ Heuristic decisions should be used with care and only in exceptional circumstances, since the decision may
+ possibly differ from that determined by the transaction service. This type of difference can lead to a loss of
+ integrity in the system. Try to avoid needing to perform resolution of heuristics, either by working with services
+ and participants that do not cause heuristics, or by using a transaction service that provides assistance in the
+ resolution process.
</para>
</section>
@@ -407,24 +481,40 @@
<section>
<title>Interposition</title>
<para>
- <firstterm>Interposition</firstterm> is a scoping mechanism which allows coordination of a transaction to be delegated across a hierarchy of coordinators. See <xref linkend="fig-interpositions" /> for a graphical representation of this concept.
+ <firstterm>Interposition</firstterm> is a scoping mechanism which allows coordination of a transaction to be
+ delegated across a hierarchy of coordinators. See <xref linkend="fig-interpositions" /> for a graphical
+ representation of this concept.
</para>
<figure id="fig-interpositions">
<title>Interpositions</title>
<mediaobject>
- <imageobject>
- <imagedata fileref="images/fig-interpositions.png" format="PNG"/>
- </imageobject>
- <textobject>
- <para>
- The diagram shows a <firstterm>top-level coordinator</firstterm> and an <firstterm>interposed coordinator</firstterm>. The top-level coordinator is responsible for driving the original, top-level transaction to completion or rollback. The interposed coordinator manages its participants in a subordinate transaction, but it cannot act autonomously. From the point of view of the parent coordinator, it appears to be another participant in the top-level transaction. The interposed coordinator operates as an intermediary. It forwards incoming <systemitem>prepare</systemitem> and <systemitem>commit</systemitem>/<systemitem>rollback</systemitem> messages to its participants, combining their responses and returning them back to its parent coordinator.
- </para>
- </textobject>
+ <imageobject>
+ <imagedata fileref="images/fig-interpositions.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <para>
+ The diagram shows a <firstterm>top-level coordinator</firstterm> and an <firstterm>interposed
+ coordinator</firstterm>. The top-level coordinator is responsible for driving the original, top-level transaction
+ to completion or rollback. The interposed coordinator manages its participants in a subordinate transaction, but
+ it cannot act autonomously. From the point of view of the parent coordinator, it appears to be another
+ participant in the top-level transaction. The interposed coordinator operates as an intermediary. It forwards
+ incoming <systemitem>prepare</systemitem> and <systemitem>commit</systemitem>/<systemitem>rollback</systemitem>
+ messages to its participants, combining their responses and returning them back to its parent coordinator.
+ </para>
+ </textobject>
</mediaobject>
</figure>
<para>
- Interposition is particularly useful for Web Services transactions, as a way of limiting the amount of network traffic required for coordination. For example, if communications between the top-level coordinator and a web service are slow because of network traffic or distance, the web service might benefit from executing in a subordinate transaction which employs a local coordinator service. In <xref linkend="fig-interpositions" />,to <systemitem>prepare</systemitem>, the top-level coordinator only needs to send one <systemitem>prepare</systemitem> message to the subordinate coordinator, and receive one <systemitem>prepared</systemitem> or <systemitem>aborted</systemitem> reply. The subordinate coordinator forwards a <systemitem>prepare</systemitem> locally to each participant and combines the results to decide whether to send a single <systemitem>prepared</systemitem> or <systemitem>aborted</systemitem> reply.
+ Interposition is particularly useful for Web Services transactions, as a way of limiting the amount of network
+ traffic required for coordination. For example, if communications between the top-level coordinator and a web
+ service are slow because of network traffic or distance, the web service might benefit from executing in a
+ subordinate transaction which employs a local coordinator service. In <xref linkend="fig-interpositions" />,to
+ <systemitem>prepare</systemitem>, the top-level coordinator only needs to send one
+ <systemitem>prepare</systemitem> message to the subordinate coordinator, and receive one
+ <systemitem>prepared</systemitem> or <systemitem>aborted</systemitem> reply. The subordinate coordinator forwards
+ a <systemitem>prepare</systemitem> locally to each participant and combines the results to decide whether to send
+ a single <systemitem>prepared</systemitem> or <systemitem>aborted</systemitem> reply.
</para>
</section>
@@ -432,26 +522,37 @@
<title>A New Transaction Protocol</title>
<para>
- Many component technologies offer mechanisms for coordinating ACID transactions based on two-phase commit semantics. Some of these are CORBA/OTS, JTS/JTA, and MTS/MSDTC. ACID transactions are not suitable for all Web Services transactions, as explained in <xref linkend="acid-not-suitable" />.
+ Many component technologies offer mechanisms for coordinating ACID transactions based on two-phase commit
+ semantics. Some of these are CORBA/OTS, JTS/JTA, and MTS/MSDTC. ACID transactions are not suitable for all Web
+ Services transactions, as explained in <xref linkend="acid-not-suitable" />.
</para>
<itemizedlist id="acid-not-suitable">
<title>Reasons ACID is Not Suitable for Web Services</title>
<listitem>
- <para>
- 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.
- </para>
- <para>
- 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.
- </para>
+ <para>
+ 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.
+ </para>
+ <para>
+ 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.
+ </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 directives of the transaction manager and only infrequently make unilateral decisions which harm other participants in a transaction.
- </para>
- <para>
- 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>
+ <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 directives of the transaction manager and only
+ infrequently make unilateral decisions which harm other participants in a transaction.
+ </para>
+ <para>
+ 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>
@@ -459,30 +560,36 @@
<title>Transaction in Loosely Coupled Systems</title>
<para>
- Extended transaction models which relax the ACID properties have been proposed over the years. WS-T provides a new transaction protocol to implement these concepts for the Web Services architecture. XTS is designed to accommodate four underlying requirements inherent in any loosely coupled architecture like Web Services. These requirements are discussed in <xref linkend="web-services-requirements" />.
+ Extended transaction models which relax the ACID properties have been proposed over the years. WS-T provides a new
+ transaction protocol to implement these concepts for the Web Services architecture. XTS is designed to accommodate
+ four underlying requirements inherent in any loosely coupled architecture like Web Services. These requirements are
+ discussed in <xref linkend="web-services-requirements" />.
</para>
<itemizedlist id="web-services-requirements">
- <title>Requirements of Web Services</title>
- <listitem>
- <para>
- Ability to handle multiple successful outcomes to a transaction, and 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 expected to suffer outages during their lifetimes, and coordinated work must be able to survive such outages.
- </para>
- </listitem>
- <listitem>
- <para>
- Interoperation using XML over multiple communication protocols. XTS uses SOAP encoding carried over HTTP.
- </para>
- </listitem>
+ <title>Requirements of Web Services</title>
+ <listitem>
+ <para>
+ Ability to handle multiple successful outcomes to a transaction, and 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 expected to suffer outages during their lifetimes, and coordinated work
+ must be able to survive such outages.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Interoperation using XML over multiple communication protocols. XTS uses SOAP encoding carried over HTTP.
+ </para>
+ </listitem>
</itemizedlist>
</section>
</section>
Copied: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Administration_And_Development_Guide.ent (from rev 36006, labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Transactions_XTS_Development_Guide.ent)
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Administration_And_Development_Guide.ent (rev 0)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Administration_And_Development_Guide.ent 2010-11-17 22:54:33 UTC (rev 36007)
@@ -0,0 +1,7 @@
+<!ENTITY PRODUCT "JBoss Transactions">
+<!ENTITY BOOKID "XTS_Development_Guide">
+<!ENTITY VERSION "4.13">
+<!ENTITY YEAR "2010">
+<!ENTITY HOLDER "JBoss.org">
+<!ENTITY APPSERVER "JBoss Application Server">
+<!-- <!ENTITY APPSERVER "Enterprise Application Platform Server"> -->
Copied: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Administration_And_Development_Guide.xml (from rev 36006, labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Transactions_XTS_Development_Guide.xml)
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Administration_And_Development_Guide.xml (rev 0)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Administration_And_Development_Guide.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -0,0 +1,23 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
+%BOOK_ENTITIES;
+]>
+<book>
+ <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <!-- <xi:include href="Chapter.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />-->
+ <xi:include href="About_This_Guide.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Transactions_Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Protocols_Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Getting_Started.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Participants.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="XTS_API.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Stand_Alone_Coordination.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Participant_Crash_Recovery.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+
+ <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <index />
+</book>
+
Deleted: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Development_Guide.ent
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Transactions_XTS_Development_Guide.ent 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Development_Guide.ent 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,7 +0,0 @@
-<!ENTITY PRODUCT "JBoss Transactions">
-<!ENTITY BOOKID "XTS_Development_Guide">
-<!ENTITY VERSION "4.13">
-<!ENTITY YEAR "2010">
-<!ENTITY HOLDER "JBoss.org">
-<!ENTITY APPSERVER "JBoss Application Server">
-<!-- <!ENTITY APPSERVER "Enterprise Application Platform Server"> -->
Deleted: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Development_Guide.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/Transactions_XTS_Development_Guide.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/Transactions_XTS_Development_Guide.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,23 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
-%BOOK_ENTITIES;
-]>
-<book>
- <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <!-- <xi:include href="Chapter.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />-->
- <xi:include href="About_This_Guide.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Transactions_Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Protocols_Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Getting_Started.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Participants.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="XTS_API.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Stand_Alone_Coordination.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Participant_Crash_Recovery.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-
- <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <index />
-</book>
-
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/XTS_API.xml
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/en-US/XTS_API.xml 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/en-US/XTS_API.xml 2010-11-17 22:54:33 UTC (rev 36007)
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Programmers_Guide.ent">
+<!ENTITY % BOOK_ENTITIES SYSTEM "Transactions_XTS_Administration_And_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<chapter id="sec-xts-api">
@@ -22,7 +22,8 @@
<para>
- This chapter discusses the XTS API. You can use this information to write client and server applications which consume transactional Web Services and coordinate back-end systems.
+ This chapter discusses the XTS API. You can use this information to write client and server applications which
+ consume transactional Web Services and coordinate back-end systems.
</para>
<section>
@@ -31,341 +32,364 @@
<section>
<title>Vote</title>
<para>
- During the two-phase commit protocol, a participant is asked to vote on whether it can prepare to confirm the work that it controls. It must return an instance of one of the subtypes of <interfacename>com.arjuna.wst11.Vote</interfacename> listed in <xref linkend="vote-subclasses" />.
+ During the two-phase commit protocol, a participant is asked to vote on whether it can prepare to confirm the work
+ that it controls. It must return an instance of one of the subtypes of
+ <interfacename>com.arjuna.wst11.Vote</interfacename> listed in <xref linkend="vote-subclasses" />.
</para>
<variablelist id="vote-subclasses">
- <title>Subclasses of <interfacename>com.arjuna.wst11.Vote</interfacename></title>
- <varlistentry>
- <term>Prepared</term>
- <listitem>
- <para>
- Indicates that the participant can can prepare if the coordinator requests it. Nothing has been committed, because the participant does not know the final outcome of the transaction.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Aborted</term>
- <listitem>
- <para>
- The participant cannot prepare, and has rolled back. The participant should not expect to get a second phase message.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>ReadOnly</term>
- <listitem>
- <para>
- The participant has not made any changes to state, and it does not need to know the final outcome of the transaction. Essentially the participant is resigning from the transaction.
- </para>
- </listitem>
- </varlistentry>
+ <title>Subclasses of <interfacename>com.arjuna.wst11.Vote</interfacename></title>
+ <varlistentry>
+ <term>Prepared</term>
+ <listitem>
+ <para>
+ Indicates that the participant can can prepare if the coordinator requests it. Nothing has been committed,
+ because the participant does not know the final outcome of the transaction.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Aborted</term>
+ <listitem>
+ <para>
+ The participant cannot prepare, and has rolled back. The participant should not expect to get a second phase
+ message.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ReadOnly</term>
+ <listitem>
+ <para>
+ The participant has not made any changes to state, and it does not need to know the final outcome of the
+ transaction. Essentially the participant is resigning from the transaction.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
<example>
- <title>Example Implementation of 2PC Participant's <methodname>prepare</methodname> Method</title>
- <programlisting language="Java" role="JAVA"><xi:include href="extras/example-prepare-method.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <title>Example Implementation of 2PC Participant's <methodname>prepare</methodname> Method</title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/example-prepare-method.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
</example>
</section>
<section>
<title>TXContext</title>
- <!-- Unsupported in 1.0 and 1.1
- <para>
- A transaction is typically represented by a unique identifier and a reference to the coordinator which manages the transaction. This reference usually takes the form oa URL. With XTS, transactions to be nested in a nested tree structure. Thus, a transaction context may be a set of transactions, with the top-most transaction the root parent.
- </para>
+ <!-- Unsupported in 1.0 and 1.1 <para> A transaction is typically represented by a unique identifier and a
+ reference to the coordinator which manages the transaction. This reference usually takes the form oa
+ URL. With XTS, transactions to be nested in a nested tree structure. Thus, a transaction context may be a set
+ of transactions, with the top-most transaction the root parent. </para>
-->
<para>
- <package>com.arjuna.mw.wst11.TxContext</package> is an opaque representation of a transaction context. It returns one of two possible values, as listed in <xref linkend="TxContext-values" />.
+ <package>com.arjuna.mw.wst11.TxContext</package> is an opaque representation of a transaction context. It returns one
+ of two possible values, as listed in <xref linkend="TxContext-values" />.
</para>
<variablelist id="TxContext-values">
- <title>TxContext Return Values</title>
- <varlistentry>
- <term>valid</term>
- <listitem>
- <para>
- Indicates whether the contents are valid.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>equals</term>
- <listitem>
- <para>
- Can be used to compare two instances for equality.
- </para>
- </listitem>
- </varlistentry>
+ <title>TxContext Return Values</title>
+ <varlistentry>
+ <term>valid</term>
+ <listitem>
+ <para>
+ Indicates whether the contents are valid.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>equals</term>
+ <listitem>
+ <para>
+ Can be used to compare two instances for equality.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
<note>
- <para>
- The corresponding participant interfaces used in the 1.0 protocol
- implementation are located in package <package>com.arjuna.wst</package>.
- </para>
+ <para>
+ The corresponding participant interfaces used in the 1.0 protocol implementation are located in package
+ <package>com.arjuna.wst</package>.
+ </para>
</note>
</section>
<section id="ref-UserTransaction">
<title>UserTransaction</title>
<para>
- <classname>com.arjuna.mw.wst11.UserTransaction</classname> is the class that clients typically employ. Before a client can begin a new atomic transaction, it must first obtain a <classname>UserTransaction</classname> from the <classname>UserTransactionFactory</classname>. This class isolates the user from the underlying protocol-specific aspects of the XTS implementation. A <classname>UserTransaction</classname> does not represent a specific transaction. Instead, it provides access to an implicit per-thread transaction context, similar to the <classname>UserTransaction</classname> in the JTA specification. All of the <classname>UserTransaction</classname> methods implicitly act on the current thread of control.
+ <classname>com.arjuna.mw.wst11.UserTransaction</classname> is the class that clients typically employ. Before a
+ client can begin a new atomic transaction, it must first obtain a <classname>UserTransaction</classname> from the
+ <classname>UserTransactionFactory</classname>. This class isolates the user from the underlying protocol-specific
+ aspects of the XTS implementation. A <classname>UserTransaction</classname> does not represent a specific
+ transaction. Instead, it provides access to an implicit per-thread transaction context, similar to the
+ <classname>UserTransaction</classname> in the JTA specification. All of the <classname>UserTransaction</classname>
+ methods implicitly act on the current thread of control.
</para>
<variablelist>
- <title><classname>userTransaction</classname> Methods</title>
- <varlistentry>
- <term>begin</term>
- <listitem>
- <para>
- Used to begin a new transaction and associate it with the invoking thread.
- </para>
- <variablelist>
- <title>Parameters</title>
- <varlistentry>
- <term>timeout</term>
- <listitem>
- <!--
- <para>
- This optional parameter, measured in milliseconds, causes the <methodname>begin</methodname> method to time out.
- </para>
- -->
- <para>
- This optional parameter, measured in milliseconds, specifies
- a time interval after which the newly created transaction
- may be automatically rolled back by the coordinator
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term><systemitem>WrongStateException</systemitem></term>
- <listitem>
- <para>
- A transaction is already associated with the thread.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>commit</term>
- <listitem>
- <para>
- <!--
- Commits the transaction. The <methodname>commit</methodname> method executes the Volatile2PC and Durable2PC protocols before returning. When complete, the <methodname>commit</methodname> method disassociates the transaction from the current thread, leaving it unassociated with any transactions.
- -->
- Volatile2PC and Durable2PC participants enrolled in the transaction
- are requested first to prepare and then to commit their changes. If
- any of the participants fails to prepare in the first phase then all
- other participants are requested to abort.
- </para>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term><systemitem>UnknownTransactionException</systemitem></term>
- <listitem>
- <para>
- No transaction is associated with the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><methodname>TransactionRolledBackException</methodname></term>
- <listitem>
- <para>
- <!--
- The transaction rolled back, due to another participant.
- -->
- The transaction was rolled back either because of a timeout or
- because a participant was unable to commit.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>rollback</term>
- <listitem>
- <para>
- Terminates the transaction. Upon completion, the <methodname>rollback</methodname> method disassociates the transaction from the current leaving it unassociated with any transactions.
- </para>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term><systemitem>UnknownTransactionException</systemitem></term>
- <listitem>
- <para>
- No transaction is associated with the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
+ <title><classname>userTransaction</classname> Methods</title>
+ <varlistentry>
+ <term>begin</term>
+ <listitem>
+ <para>
+ Used to begin a new transaction and associate it with the invoking thread.
+ </para>
+ <variablelist>
+ <title>Parameters</title>
+ <varlistentry>
+ <term>timeout</term>
+ <listitem>
+ <!--
+ <para> This optional parameter, measured in milliseconds, causes the <methodname>begin</methodname> method to
+ time out. </para>
+ -->
+ <para>
+ This optional parameter, measured in milliseconds, specifies a time interval after which the newly created
+ transaction may be automatically rolled back by the coordinator
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term><systemitem>WrongStateException</systemitem></term>
+ <listitem>
+ <para>
+ A transaction is already associated with the thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>commit</term>
+ <listitem>
+ <para>
+ <!--
+ Commits the transaction. The <methodname>commit</methodname> method executes the Volatile2PC and Durable2PC
+ protocols before returning. When complete, the <methodname>commit</methodname> method disassociates the
+ transaction from the current thread, leaving it unassociated with any transactions.
+ -->
+ Volatile2PC and Durable2PC participants enrolled in the transaction
+ are requested first to prepare and then to commit their changes. If
+ any of the participants fails to prepare in the first phase then all
+ other participants are requested to abort.
+ </para>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term><systemitem>UnknownTransactionException</systemitem></term>
+ <listitem>
+ <para>
+ No transaction is associated with the invoking thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>TransactionRolledBackException</methodname></term>
+ <listitem>
+ <para>
+ <!--
+ The transaction rolled back, due to another participant.
+ -->
+ The transaction was rolled back either because of a timeout or
+ because a participant was unable to commit.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>rollback</term>
+ <listitem>
+ <para>
+ Terminates the transaction. Upon completion, the <methodname>rollback</methodname> method disassociates the
+ transaction from the current leaving it unassociated with any transactions.
+ </para>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term><systemitem>UnknownTransactionException</systemitem></term>
+ <listitem>
+ <para>
+ No transaction is associated with the invoking thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
</variablelist>
</section>
<section>
<title>UserTransactionFactory</title>
<para>
- Call the <methodname>getUserTransaction</methodname> method to obtain a <xref linkend="ref-UserTransaction" /> instance from a <classname>UserTransactionFactory</classname>.
+ Call the <methodname>getUserTransaction</methodname> method to obtain a <xref linkend="ref-UserTransaction" />
+ instance from a <classname>UserTransactionFactory</classname>.
</para>
</section>
<section id="ref-TransactionManager">
<title>TransactionManager</title>
<para>
- Defines the interaction between a transactional web service and the underlying transaction service implementation. A <classname>TransactionManager</classname> does not represent a specific transaction. Instead, it provides access to an implicit per-thread transaction context.
+ Defines the interaction between a transactional web service and the underlying transaction service implementation. A
+ <classname>TransactionManager</classname> does not represent a specific transaction. Instead, it provides access to
+ an implicit per-thread transaction context.
</para>
<variablelist>
- <title>Methods</title>
- <varlistentry>
- <term><methodname>currentTransaction</methodname></term>
- <listitem>
- <para>
- Returns a <systemitem>TxContext</systemitem> for the current transaction, or null if there is no context. Use the <methodname>currentTransaction</methodname> method to determine whether a web service has been invoked from within an existing transaction. You can also use the returned value to enable multiple threads to execute within the scope of the same transaction. Calling the <methodname>currentTransaction</methodname> method does not disassociate the current thread from the transaction.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><methodname>suspend</methodname></term>
- <listitem>
- <para>
- Dissociates a thread from any transaction. This enables a thread to do work that is not associated with a specific transaction.
- </para>
- <para>The <methodname>suspend</methodname> method returns a <systemitem>TxContext</systemitem> instance, which is a handle on the transaction.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><methodname>resume</methodname></term>
- <listitem>
- <para>
- Associates or re-associates a thread with a transaction, using its <systemitem>TxContext</systemitem>. Prior to association or re-association, the thread is disassociated from any transaction with which it may be currently associated. If the <systemitem>TxContext</systemitem> is null, then the thread is associated with no transaction. In this way, the result is the same as if the <methodname>suspend</methodname> method were used instead.
- </para>
- <variablelist>
- <title>Parameters</title>
- <varlistentry>
- <term>txContext</term>
- <listitem>
- <para>
- A TxContext instance as return by <methodname>suspend</methodname>, identifying the transaction to be resumed.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term><systemitem>UnknownTransactionException</systemitem></term>
- <listitem>
- <para>
- The transaction referred to by the <systemitem>TxContext</systemitem> is invalid in the scope of the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- <!--
- <varlistentry>
- <term><systemitem>WrongStateException</systemitem></term>
- <listitem>
- <para>
- The transaction is not in a state that allows participants to be enrolled. For instance, it may be in the process of terminating.
- </para>
- </listitem>
- </varlistentry>
- -->
- </variablelist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><varname>enlistForVolitaleTwoPhase</varname></term>
- <listitem>
- <para>
- Enroll the specified participant with the current transaction, causing it to participate in the Volatile2PC protocol. You must pass a unique identifier for the participant.
- </para>
- <variablelist>
- <title>Parameters</title>
- <varlistentry>
- <term>participant</term>
- <listitem>
- <para>
- An implementation of interface Volatile2PCParticipant whose
- prepare, commit and abort methods are called when the
- corresponding coordinator message is received.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>id</term>
- <listitem>
- <para>
- A unique identifier for the participant. The value of this String
- should differ for each enlisted participant. It should also be
- possible for a given identifier to determine that the participant
- belongs to the enlisting web service rather than some other web
- service deployed to the same container.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term>UnknownTransactionException</term>
- <listitem>
- <para>
- No transaction is associated with the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><systemitem>WrongStateException</systemitem></term>
- <listitem>
- <para>
- The transaction is not in a state that allows participants to be enrolled. For instance, it may be in the process of terminating.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><varname>enlistForDurableTwoPhase</varname></term>
- <listitem>
- <para>
- Enroll the specified participant with the current transaction, causing it to participate in the Durable2PC protocol. You must pass a unique identifier for the participant.
- </para>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term>UnknownTransactionException</term>
- <listitem>
- <para>
- No transaction is associated with the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><systemitem>WrongStateException</systemitem></term>
- <listitem>
- <para>
- The transaction is not in a state that allows participants to be enrolled. For instance, it may be in the process of terminating.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
+ <title>Methods</title>
+ <varlistentry>
+ <term><methodname>currentTransaction</methodname></term>
+ <listitem>
+ <para>
+ Returns a <systemitem>TxContext</systemitem> for the current transaction, or null if there is no context. Use
+ the <methodname>currentTransaction</methodname> method to determine whether a web service has been invoked from
+ within an existing transaction. You can also use the returned value to enable multiple threads to execute
+ within the scope of the same transaction. Calling the <methodname>currentTransaction</methodname> method does
+ not disassociate the current thread from the transaction.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>suspend</methodname></term>
+ <listitem>
+ <para>
+ Dissociates a thread from any transaction. This enables a thread to do work that is not associated with a
+ specific transaction.
+ </para>
+ <para>The <methodname>suspend</methodname> method returns a <systemitem>TxContext</systemitem> instance, which is a handle on the transaction.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>resume</methodname></term>
+ <listitem>
+ <para>
+ Associates or re-associates a thread with a transaction, using its <systemitem>TxContext</systemitem>. Prior to
+ association or re-association, the thread is disassociated from any transaction with which it may be currently
+ associated. If the <systemitem>TxContext</systemitem> is null, then the thread is associated with no
+ transaction. In this way, the result is the same as if the <methodname>suspend</methodname> method were used
+ instead.
+ </para>
+ <variablelist>
+ <title>Parameters</title>
+ <varlistentry>
+ <term>txContext</term>
+ <listitem>
+ <para>
+ A TxContext instance as return by <methodname>suspend</methodname>, identifying the transaction to be resumed.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term><systemitem>UnknownTransactionException</systemitem></term>
+ <listitem>
+ <para>
+ The transaction referred to by the <systemitem>TxContext</systemitem> is invalid in the scope of the invoking
+ thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ <!--
+ <varlistentry> <term><systemitem>WrongStateException</systemitem></term> <listitem> <para> The transaction is
+ not in a state that allows participants to be enrolled. For instance, it may be in the process of terminating.
+ </para> </listitem> </varlistentry>
+ -->
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>enlistForVolitaleTwoPhase</varname></term>
+ <listitem>
+ <para>
+ Enroll the specified participant with the current transaction, causing it to participate in the Volatile2PC
+ protocol. You must pass a unique identifier for the participant.
+ </para>
+ <variablelist>
+ <title>Parameters</title>
+ <varlistentry>
+ <term>participant</term>
+ <listitem>
+ <para>
+ An implementation of interface Volatile2PCParticipant whose prepare, commit and abort methods are called when
+ the corresponding coordinator message is received.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>id</term>
+ <listitem>
+ <para>
+ A unique identifier for the participant. The value of this String should differ for each enlisted
+ participant. It should also be possible for a given identifier to determine that the participant belongs to
+ the enlisting web service rather than some other web service deployed to the same container.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term>UnknownTransactionException</term>
+ <listitem>
+ <para>
+ No transaction is associated with the invoking thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><systemitem>WrongStateException</systemitem></term>
+ <listitem>
+ <para>
+ The transaction is not in a state that allows participants to be enrolled. For instance, it may be in the
+ process of terminating.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>enlistForDurableTwoPhase</varname></term>
+ <listitem>
+ <para>
+ Enroll the specified participant with the current transaction, causing it to participate in the Durable2PC
+ protocol. You must pass a unique identifier for the participant.
+ </para>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term>UnknownTransactionException</term>
+ <listitem>
+ <para>
+ No transaction is associated with the invoking thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><systemitem>WrongStateException</systemitem></term>
+ <listitem>
+ <para>
+ The transaction is not in a state that allows participants to be enrolled. For instance, it may be in the
+ process of terminating.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
</variablelist>
</section>
<section>
<title>TransactionManagerFactory</title>
<para>
- Use the <methodname>getTransactionManager</methodname> method to obtain a <xref linkend="ref-TransactionManager" /> from a <classname>TransactionManagerFactory</classname>.
+ Use the <methodname>getTransactionManager</methodname> method to obtain a <xref linkend="ref-TransactionManager" />
+ from a <classname>TransactionManagerFactory</classname>.
</para>
</section>
</section>
@@ -377,129 +401,129 @@
<section>
<title>Compatibility</title>
<para>
- Previous implementations of XTS locate the Business Activity Protocol classes in the <package>com.arjuna.mw.wst</package> package. In the current implementation, these classes are located in the <package>com.arjuna.mw.wst11</package> package.
+ Previous implementations of XTS locate the Business Activity Protocol classes in the
+ <package>com.arjuna.mw.wst</package> package. In the current implementation, these classes are located in the
+ <package>com.arjuna.mw.wst11</package> package.
</para>
</section>
<section id="ref-UserBusinessActivity">
<title>UserBusinessActivity</title>
<para>
- <classname>com.arjuna.wst11.UserBusinessActivity</classname> is the class that most clients employ. A client begins a new business activity by first obtaining a <classname>UserBusinessActivity</classname> from the <classname>UserBusinessActivityFactory</classname>. This class isolates them from the underlying protocol-specific aspects of the XTS implementation. A UserBusinessActivity does not represent a specific business activity. Instead, it provides access to an implicit per-thread activity. Therefore, all of the <classname>UserBusinessActivity</classname> methods implicitly act on the current thread of control.
+ <classname>com.arjuna.wst11.UserBusinessActivity</classname> is the class that most clients employ. A client begins a
+ new business activity by first obtaining a <classname>UserBusinessActivity</classname> from the
+ <classname>UserBusinessActivityFactory</classname>. This class isolates them from the underlying protocol-specific
+ aspects of the XTS implementation. A UserBusinessActivity does not represent a specific business activity. Instead,
+ it provides access to an implicit per-thread activity. Therefore, all of the
+ <classname>UserBusinessActivity</classname> methods implicitly act on the current thread of control.
</para>
<variablelist>
- <title>Methods</title>
- <varlistentry>
- <term><methodname>begin</methodname></term>
- <listitem>
- <para>
- Begins a new activity, associating it with the invoking thread.
- </para>
- <variablelist>
- <title>Parameters</title>
- <varlistentry>
- <term>timeout</term>
- <listitem>
- <para>
- The interval, in milliseconds, after which an activity times out. Optional.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term><systemitem>WrongStateException</systemitem></term>
- <listitem>
- <para>
- The thread is already associated with a business activity.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
+ <title>Methods</title>
+ <varlistentry>
+ <term><methodname>begin</methodname></term>
+ <listitem>
+ <para>
+ Begins a new activity, associating it with the invoking thread.
+ </para>
+ <variablelist>
+ <title>Parameters</title>
+ <varlistentry>
+ <term>timeout</term>
+ <listitem>
+ <para>
+ The interval, in milliseconds, after which an activity times out. Optional.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term><systemitem>WrongStateException</systemitem></term>
+ <listitem>
+ <para>
+ The thread is already associated with a business activity.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><methodname>close</methodname></term>
- <listitem>
- <!--
- <para>
- Terminates the business activity. The <methodname>close</methodname> method executes the <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> protocol and then returns, dissociating the business activity from the current thread, so that it is not associated with any activity.
- </para>
- -->
- <para>
- First, all Coordinator Completion participants enlisted in the
- activity are requested to complete the activity. Next all
- participants, whether they enlisted for Coordinator or Participant
- Completion, are requested to close the activity. If any of the
- Coordinator Completion participants fails to complete at the first
- stage then all completed participants are asked to compensate the
- activity while any remaining uncompleted participants are requested to
- cancel the activity.
- </para>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term>UnknownTransactionException</term>
- <listitem>
- <para>
- No activity is associated with the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>TransactionRolledBackException</term>
- <listitem>
- <para>
- The activity has been cancelled because one of the
- Coordinator Completion participants failed to complete. This
- exception may also thrown if one of the Participant
- Completion participants has not completed before the client
- calls close.
- </para>
- <!--
- <para>
- The activity has canceled.
- </para>
- -->
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>cancel</term>
- <listitem>
- <!--
- <para>
- Terminates the business activity. After the <methodname>cancel</methodname> method completes,
- </para>
- -->
- <para>
- Terminates the business activity. All Participant Completion
- participants enlisted in the activity which have already completed are
- requested to compensate the activity. All uncompleted Participant
- Completion participants and all Coordinator Completion participants
- are requested to cancel the activity.
- </para>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term><systemitem>UnknownTransactionException</systemitem></term>
- <listitem>
- <para>
- No activity is associated with the invoking thread. Any participants that previous completed are directed to compensate their work.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>close</methodname></term>
+ <listitem>
+ <!--
+ <para> Terminates the business activity. The <methodname>close</methodname> method executes the
+ <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> protocol and then returns, dissociating the
+ business activity from the current thread, so that it is not associated with any activity. </para>
+ -->
+ <para>
+ First, all Coordinator Completion participants enlisted in the activity are requested to complete the
+ activity. Next all participants, whether they enlisted for Coordinator or Participant Completion, are requested
+ to close the activity. If any of the Coordinator Completion participants fails to complete at the first stage
+ then all completed participants are asked to compensate the activity while any remaining uncompleted
+ participants are requested to cancel the activity.
+ </para>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term>UnknownTransactionException</term>
+ <listitem>
+ <para>
+ No activity is associated with the invoking thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>TransactionRolledBackException</term>
+ <listitem>
+ <para>
+ The activity has been cancelled because one of the Coordinator Completion participants failed to
+ complete. This exception may also thrown if one of the Participant Completion participants has not completed
+ before the client calls close.
+ </para>
+ <!--
+ <para> The activity has canceled. </para>
+ -->
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>cancel</term>
+ <listitem>
+ <!--
+ <para> Terminates the business activity. After the <methodname>cancel</methodname> method completes, </para>
+ -->
+ <para>
+ Terminates the business activity. All Participant Completion participants enlisted in the activity which have
+ already completed are requested to compensate the activity. All uncompleted Participant Completion participants
+ and all Coordinator Completion participants are requested to cancel the activity.
+ </para>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term><systemitem>UnknownTransactionException</systemitem></term>
+ <listitem>
+ <para>
+ No activity is associated with the invoking thread. Any participants that previous completed are directed to
+ compensate their work.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
</variablelist>
<!--
- <para>
- In some cases participants in a business activity may register for the <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem> protocol. In this case, the coordinator needs to notify them that all the work that they need to do within the scope of a business activity is complete. When the the client application has finished requesting work to be done by these participants, it must call the <methodname>complete</methodname> method before attempting to call the <methodname>close</methodname> or <methodname>cancel</methodname> methods.
- </para>
+ <para> In some cases participants in a business activity may register for the
+ <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem> protocol. In this case, the coordinator needs
+ to notify them that all the work that they need to do within the scope of a business activity is complete. When
+ the the client application has finished requesting work to be done by these participants, it must call the
+ <methodname>complete</methodname> method before attempting to call the <methodname>close</methodname> or
+ <methodname>cancel</methodname> methods. </para>
-->
</section>
@@ -507,208 +531,210 @@
<section>
<title>UserBusinessActivityFactory</title>
<para>
- Use the <methodname>getuserbusinessActivity</methodname> method to obtain a <xref linkend="ref-UserBusinessActivity" /> instance from a <classname>userBusinessActivityFactory</classname>.
+ Use the <methodname>getuserbusinessActivity</methodname> method to obtain a <xref linkend="ref-UserBusinessActivity"
+ /> instance from a <classname>userBusinessActivityFactory</classname>.
</para>
</section>
<section id="ref-BusinessActivityManager">
<title>BusinessActivityManager</title>
<para>
- <package>com.arjuna.mw.wst11.BusinessActivityManager</package> is the class that web services typically employ. Defines how a web service interacts with the underlying business activity service implementation. A <classname>BusinessActivityManager</classname> does not represent a specific activity. Instead, it provides access to an implicit per-thread activity.
+ <package>com.arjuna.mw.wst11.BusinessActivityManager</package> is the class that web services typically
+ employ. Defines how a web service interacts with the underlying business activity service implementation. A
+ <classname>BusinessActivityManager</classname> does not represent a specific activity. Instead, it provides access to
+ an implicit per-thread activity.
</para>
<variablelist>
- <title>Methods</title>
- <varlistentry>
- <term><methodname>currentTransaction</methodname></term>
- <listitem>
- <para>
- Returns the <systemitem>TxContext</systemitem> for the current business activity, or <literal>NULL</literal> if there is no <systemitem>TxContext</systemitem>. The returned value can be used to enable multiple threads to execute within the scope of the same business activity. Calling the <methodname>currenTransaction</methodname> method does not dissociate the current thread from its activity.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><methodname>suspend</methodname></term>
- <listitem>
- <para>
- Dissociates a thread from any current business activity, so that it can perform work not associated with a specific activity. The <methodname>suspend</methodname> method returns a <systemitem>TxContext</systemitem> instance, which is a handle on the activity. The thread is then no longer associated with any activity.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><methodname>resume</methodname></term>
- <listitem>
- <para>
- Associates or re-associates a thread with a business activity, using its <systemitem>TxContext</systemitem>. Before associating or re-associating the thread, it is disassociated from any business activity with which it is currently associated. If the <systemitem>TxContext</systemitem> is <literal>NULL</literal>, the thread is disassociated with all business activities, as though the <methodname>suspend</methodname> method were called.
- </para>
- <variablelist>
- <title>Parameters</title>
- <varlistentry>
- <term>txContext</term>
- <listitem>
- <para>
- A TxContext instance as returned by <methodname>suspend</methodname>, identifying the transaction to be resumed.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
+ <title>Methods</title>
+ <varlistentry>
+ <term><methodname>currentTransaction</methodname></term>
+ <listitem>
+ <para>
+ Returns the <systemitem>TxContext</systemitem> for the current business activity, or <literal>NULL</literal> if
+ there is no <systemitem>TxContext</systemitem>. The returned value can be used to enable multiple threads to
+ execute within the scope of the same business activity. Calling the <methodname>currenTransaction</methodname>
+ method does not dissociate the current thread from its activity.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>suspend</methodname></term>
+ <listitem>
+ <para>
+ Dissociates a thread from any current business activity, so that it can perform work not associated with a
+ specific activity. The <methodname>suspend</methodname> method returns a <systemitem>TxContext</systemitem>
+ instance, which is a handle on the activity. The thread is then no longer associated with any activity.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>resume</methodname></term>
+ <listitem>
+ <para>
+ Associates or re-associates a thread with a business activity, using its
+ <systemitem>TxContext</systemitem>. Before associating or re-associating the thread, it is disassociated from
+ any business activity with which it is currently associated. If the <systemitem>TxContext</systemitem> is
+ <literal>NULL</literal>, the thread is disassociated with all business activities, as though the
+ <methodname>suspend</methodname> method were called.
+ </para>
+ <variablelist>
+ <title>Parameters</title>
+ <varlistentry>
+ <term>txContext</term>
+ <listitem>
+ <para>
+ A TxContext instance as returned by <methodname>suspend</methodname>, identifying the transaction to be
+ resumed.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term><systemitem>UnknownTransactionException</systemitem></term>
- <listitem>
- <para>
- The business activity to which the <systemitem>TxContext</systemitem> refers is invalid in the scope of the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><varname>enlistForBusinessAgreementWithParticipantCompletion</varname></term>
- <listitem>
- <para>
- Enroll the specified participant with current business activity, causing it to participate in the <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> protocol. A unique identifier for the participant is also required.
- </para>
- <para>
- The return value is an instance of BAParticipantManager which can be
- used to notify the coordinator of changes in the participant state. In
- particular, since the participant is enlisted for the Participant
- Completion protcol it is expected to call the completed method of this
- returned instance when it has completed all the work it expects to do
- in this activity and has made all its changes permanent.
- Alternatively, if the participant does not need to perform any
- compensation actions should some other participant fail it can leave
- the activity by calling the exit method of the returned
- BAParticipantManager instance.
- </para>
- <variablelist>
- <title>Parameters</title>
- <varlistentry>
- <term>participant</term>
- <listitem>
- <para>
- An implementation of interface
- <interfacename>BusinessAgreementWithParticipantCompletionParticipant</interfacename>
- whose <methodname>close</methodname>,
- <methodname>cancel</methodname>, and
- <methodname>compensate</methodname> methods are called when
- the corresponding coordinator message is received.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>id</term>
- <listitem>
- <para>
- A unique identifier for the participant. The value of this String
- should differ for each enlisted participant. It should also be
- possible for a given identifier to determine that the participant
- belongs to the enlisting web service rather than some other web
- service deployed to the same container.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term>UnknownTransactionException</term>
- <listitem>
- <para>
- No transaction is associated with the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>WrongStateException</term>
- <listitem>
- <para>
- The transaction is not in a state where new participants may be enrolled, as when it is terminating.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><varname>enlistForBusinessAgreementWithCoordinatorCompletion</varname></term>
- <listitem>
- <para>
- Enroll the specified participant with current activity, causing it to participate in the <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem> protocol. A unique identifier for the participant is also required.
- </para>
- <para>
- The return value is an instance of
- <interfacename>BAParticipantManager</interfacename> which can be
- used to notify the coordinator of changes in the participant
- state. Note that in this case it is an error to call the
- <methodname>completed</methodname> method of this returned
- instance. With the Coordinator Completion protocol the participant
- is expected to wait until its <methodname>completed</methodname>
- method is called before it makes all its changes
- permanent. Alternatively, if the participant determiens that it
- has no changes to make, it can leave the activity by calling the
- <methodname>exit</methodname> method of the returned
- <interfacename>BAParticipantManager</interfacename> instance.
- </para>
- <variablelist>
- <title>Parameters</title>
- <varlistentry>
- <term>participant</term>
- <listitem>
- <para>
- An implementation of interface
- BusinessAgreementWithCoordinatorCompletionParticipant whose
- completed, close, cancel and compensate methods are called
- when the corresponding coordinator message is received.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>id</term>
- <listitem>
- <para>
- A unique identifier for the participant. The value of this String
- should differ for each enlisted participant. It should also be
- possible for a given identifier to determine that the participant
- belongs to the enlisting web service rather than some other web
- service deployed to the same container.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <variablelist>
- <title>Exceptions</title>
- <varlistentry>
- <term>UnknownTransactionException</term>
- <listitem>
- <para>
- No transaction is associated with the invoking thread.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>WrongStateException</term>
- <listitem>
- <para>
- The transaction is not in a state where new participants may
- be enrolled, as when it is terminating.
- </para>
- </listitem>
- </varlistentry>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term><systemitem>UnknownTransactionException</systemitem></term>
+ <listitem>
+ <para>
+ The business activity to which the <systemitem>TxContext</systemitem> refers is invalid in the scope of the
+ invoking thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>enlistForBusinessAgreementWithParticipantCompletion</varname></term>
+ <listitem>
+ <para>
+ Enroll the specified participant with current business activity, causing it to participate in the
+ <systemitem>BusinessAgreementWithParticipantCompletion</systemitem> protocol. A unique identifier for the
+ participant is also required.
+ </para>
+ <para>
+ The return value is an instance of BAParticipantManager which can be used to notify the coordinator of changes
+ in the participant state. In particular, since the participant is enlisted for the Participant Completion
+ protcol it is expected to call the completed method of this returned instance when it has completed all the
+ work it expects to do in this activity and has made all its changes permanent. Alternatively, if the
+ participant does not need to perform any compensation actions should some other participant fail it can leave
+ the activity by calling the exit method of the returned BAParticipantManager instance.
+ </para>
+ <variablelist>
+ <title>Parameters</title>
+ <varlistentry>
+ <term>participant</term>
+ <listitem>
+ <para>
+ An implementation of interface
+ <interfacename>BusinessAgreementWithParticipantCompletionParticipant</interfacename> whose
+ <methodname>close</methodname>, <methodname>cancel</methodname>, and <methodname>compensate</methodname>
+ methods are called when the corresponding coordinator message is received.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>id</term>
+ <listitem>
+ <para>
+ A unique identifier for the participant. The value of this String should differ for each enlisted
+ participant. It should also be possible for a given identifier to determine that the participant belongs to
+ the enlisting web service rather than some other web service deployed to the same container.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term>UnknownTransactionException</term>
+ <listitem>
+ <para>
+ No transaction is associated with the invoking thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>WrongStateException</term>
+ <listitem>
+ <para>
+ The transaction is not in a state where new participants may be enrolled, as when it is terminating.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>enlistForBusinessAgreementWithCoordinatorCompletion</varname></term>
+ <listitem>
+ <para>
+ Enroll the specified participant with current activity, causing it to participate in the
+ <systemitem>BusinessAgreementWithCoordinatorCompletion</systemitem> protocol. A unique identifier for the
+ participant is also required.
+ </para>
+ <para>
+ The return value is an instance of <interfacename>BAParticipantManager</interfacename> which can be used to
+ notify the coordinator of changes in the participant state. Note that in this case it is an error to call the
+ <methodname>completed</methodname> method of this returned instance. With the Coordinator Completion protocol
+ the participant is expected to wait until its <methodname>completed</methodname> method is called before it
+ makes all its changes permanent. Alternatively, if the participant determiens that it has no changes to make,
+ it can leave the activity by calling the <methodname>exit</methodname> method of the returned
+ <interfacename>BAParticipantManager</interfacename> instance.
+ </para>
+ <variablelist>
+ <title>Parameters</title>
+ <varlistentry>
+ <term>participant</term>
+ <listitem>
+ <para>
+ An implementation of interface BusinessAgreementWithCoordinatorCompletionParticipant whose completed, close,
+ cancel and compensate methods are called when the corresponding coordinator message is received.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>id</term>
+ <listitem>
+ <para>
+ A unique identifier for the participant. The value of this String should differ for each enlisted
+ participant. It should also be possible for a given identifier to determine that the participant belongs to
+ the enlisting web service rather than some other web service deployed to the same container.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <variablelist>
+ <title>Exceptions</title>
+ <varlistentry>
+ <term>UnknownTransactionException</term>
+ <listitem>
+ <para>
+ No transaction is associated with the invoking thread.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>WrongStateException</term>
+ <listitem>
+ <para>
+ The transaction is not in a state where new participants may be enrolled, as when it is terminating.
+ </para>
+ </listitem>
+ </varlistentry>
- </variablelist>
+ </variablelist>
- </listitem>
- </varlistentry>
+ </listitem>
+ </varlistentry>
</variablelist>
</section>
<section>
<title>BusinessActivityManagerFactory</title>
<para>
- Use the <methodname>getBusinessActivityManager</methodname> method to obtain a <xref linkend="ref-BusinessActivityManager" /> instance from a <classname>BusinessActivityManagerFactory</classname>.
+ Use the <methodname>getBusinessActivityManager</methodname> method to obtain a <xref
+ linkend="ref-BusinessActivityManager" /> instance from a <classname>BusinessActivityManagerFactory</classname>.
</para>
</section>
</section>
Modified: labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/publican.cfg
===================================================================
--- labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Programmers_Guide/publican.cfg 2010-11-17 19:12:24 UTC (rev 36006)
+++ labs/jbosstm/trunk/XTS/docs/Transactions_XTS_Administration_And_Development_Guide/publican.cfg 2010-11-17 22:54:33 UTC (rev 36007)
@@ -4,5 +4,5 @@
xml_lang: en-US
type: Book
brand: jboss-community
-tmp_dir: ../build/Transaction_XTS_Programmers_Guide
+tmp_dir: ../build/Transactions_XTS_Administration_And_Development_Guide
More information about the jboss-svn-commits
mailing list