About the basicWSTX Example

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

  1. 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.
  2. After the client-side code commits or aborts the JTA transaction, the client confirms that all operations in the transaction succeeded or failed via 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:

  1. SimpleService, a web service implemented as a Java servlet with transacted operations

    The "Edit Web Service Attributes" feature in the NetBeans WSIT plug-in is used to configure Transaction Attributes of each web service operation.
  2. SimpleServiceASCMTEJB, a web service implemented as container-managed transaction Enterprise bean (CMT EJB)

    No configuration is necessary for this case.
  3. LibraryFacadeWebServiceBean, a web service that uses the Java Persistence API (JPA) with two JDBC resources
  4. Managed Java EE resources participating in a distributed transaction having its transacted updates all committed or rolled back

    5. 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, described in XXX.

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. We explain how to run the example in two domains so both protocols, WS-Coordination and WS-AtomicTransaction (WS-AT), are used, as shown in Figure 11-1.

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

We also provide the msclient client, which is the equivalent of the client servlet shown in Domain 2.

Figure 11-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 11-2 Components in the basicWSTX Example

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

The SimpleService web service uses two JMS resources that are created in domain1:

The client servlet, which runs in domain2, initiates the transaction.