About the basicWSTX Example

The basicWSTX example shows the following on the client-side:

Developers use existing Java Transaction APIs (JTA). Invocations
of transacted web service operations flow transactional context from client
to web service. Persistent resources updated with client-created transactions
are all committed or rolled back as a single atomic transaction.

After the client-side code commits or aborts the JTA transaction,
the client confirms that all operations in the transaction succeeded or failed
by using calls to verify methods on the transacted web
service.

SampleServiceClient, a WSIT servlet that
initiates the transaction, and msclient, a client that
performs the same operations but runs on the Microsoft side, both interact
with the following components running on the service-side:

SimpleService, a web service implemented
as a Java servlet with transacted operations. The Edit Web Service Attributes
feature in the NetBeans IDE WSIT plug-in is used
to configure Transaction Attributes of each web service operation.

SimpleServiceASCMTEJB, a web service implemented
as container-managed transaction enterprise bean (CMT EJB). No configuration
is necessary for this case.

LibraryFacadeWebServiceBean, a web service
that uses the Java Persistence API (JPA) with two JDBC resources

Managed Java EE resources participating in a distributed transaction
having its transacted updates all committed or rolled back

The servlet and CMT EJB transacted web service operations manipulate
two JMS resources:

jms/ConnectionFactory, an XATransaction connection factory

jms/Queue, a JMS queue

The LibraryFacadeWebServiceBean web service operations
manipulate the JDBC resources:

connectionPool, an XATransaction JDBC
connection pool

jdbc/javaProgrammingLibrary, a JDBC connection
resource

This example shows how to use XATransaction -enabled
JMS and JDBC. The first version of this example, showing WSIT-to-WSIT operations,
has the SampleServiceClient client configured to run on
one GlassFish instance and the service running on the other GlassFish instance.
Either the Java client or the Java web service could be replaced by a semantically
equivalent Microsoft implementation. The Java client is, in fact, replaced
by a Microsoft WCF client in the more advanced version of the example.

With the SampleServiceClient client, the WS-Coordination/WS-AtomicTransaction
protocol messages flow back and forth between the two GlassFish instances
just as they do in the Microsoft-to-Sun transaction interoperability scenario
with the msclient client.

The basicWSTX example was initially designed so it
could be run in either one or in two GlassFish domains. If you run the example
in one domain, only one coordinator is used; no WS-Coordination protocol messages
will be exchanged. This chapter explains how to run the example in two domains
so both protocols, WS-Coordination and WS-AtomicTransaction (WS-AT), are used,
as shown in Figure 12–1.

Figure 12–1 WS-Coordination and WS-AtomicTransaction Protocols
in Two GlassFish Domains

The example also provides the msclient client, which
is the equivalent of the client servlet shown in Domain 2.

Figure 12–2 shows the components
that make up the two domain example. Again, the msclient client
would be equivalent to the client servlet in Domain 2 in this figure as well.

Figure 12–2 Components in the basicWSTX Example

The service, which runs in domain1, is comprised of two components:

SimpleService, a web service that is implemented
as a servlet with transacted operations