test

The WSIT Tutorial

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 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:

  1. 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.

  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

    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

Diagram of 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

Diagram showing 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 LibraryFacadeWebServiceBean web service uses the Java Persistence API (JPA) with two JDBC resources that are created in domain1:

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