Ensuring transactional integrity using Web Services Atomic Transaction support in WebSphere ESB and WebSphere Application Server

This article shows you how to create a sample J2EE application for WebSphere Application Server V7 that acts as a client via JAX-WS Web Services to a mediation running on WebSphere ESB V7. Transactional context is propagated using product configurations and the Web Services Atomic Transaction (WS-AT) protocol. WebSphere Integration Developer V7 is used as a development environment, and the solution also applies to WebSphere Process Server.

Dave Screen (dave.screen@uk.ibm.com), Software Engineer, IBM

Dave Screen is a Software Engineer at the IBM Hursley Software Lab in the UK. His job involves helping customers and IBM colleagues use WebSphere ESB. His experience includes WebSphere, security, transactions, Java runtimes, and Eclipse. You can contact Dave at dave.screen@uk.ibm.com.



08 December 2010

Introduction

This article shows you how to create a sample application for BM® WebSphere® Application Server V7 that acts as a client via JAX-WS Web Services to a mediation running on WebSphere Enterprise Service Bus V7 (hereafter called WebSphere ESB). The Web services consumer running on WebSphere Application Server acts as a transaction coordinator, and the mediation module on WebSphere ESB acts as a transaction participant. The article also describes where this solution applies and alternative configurations. Another runtime option is WebSphere Process Server because it is also a runtime for mediation modules.

Sample projects are provided, and you can download them at the bottom of the article. Projects will be tested using the Web Services Explorer tool and TCP/IP Monitor View in WebSphere Integration Developer. The configuration steps assume that administrative (global) security is disabled on both servers, and the article shows you how to create a secure configuration. The article assumes the use of V7 products, but provides information and downloads for V6.2 also -- for more information, see Alternative configurations below.

Scenario

Figure 1. Scenario diagram
Test client, transaction coordinator, and transaction participant

In this scenario, the functional flow involves an application deployed on WebSphere Application Server sending a Web service request. The server that hosts this application acts as Transaction Coordinator. The request is received by a mediation module on WebSphere ESB that acts as the Transaction Participant. The WebSphere Application Server application is driven by a Web service Test Client.

When WS-AT is configured, additional headers are present in the Web services (SOAP) messages and these do not relate to the functional and business message flow. These extra headers are generated automatically by the runtime and are used to set up the cooperation between the transaction managers on the servers, as described below. The intention is that a transaction scope is set up so that it spans both applications. If either application requires a rollback, then they are both rolled back. Similarly, if both applications can commit, then the global transaction will be committed, including any database updates.

WS-AT protocol messages are sent separately from the Web services (SOAP) messages. This procedure is for communication between the transaction participants and coordinator and is unrelated to the SOAP messages that make up the scenario in a functional sense. These protocol messages need to flow separately from the SOAP request/responses that make up the functional flow, because the transaction rollback/commit decisions can take place after the functional flow completes. An example is if the database rejects the transaction and forces a rollback.

In this example, the Java® Transaction API is used by the WebSphere Application Server application to control whether the transaction commits or rolls back. A Test Client is used to drive the WebSphere Application Server application and instruct it to trigger a commit or a rollback.

To test the transactional outcome, a message is logged in a database table -- a single row is inserted using the message logger mediation primitive. Whether this message is committed or not depends on the test message that is fed into the system by the test client.

Setting up the environment

This section describes the environment for the configuration guide. The port numbers will probably be different on your system and so you will need to take this into account when following the steps. For clarity, the applications are referred to using their roles in the transaction: Transaction Coordinator and Transaction Participant.

Table 1. Server environments and port numbers
RoleServer and versionProfile typeHTTP portIntegrated Solutions Console
Transaction CoordinatorWebSphere Application Server V7.0.0.9standalone profile9080http://localhost:9060/ibm/console
Transaction ParticipantWebSphere ESB V7.0.0.1standalone profile9081http://localhost:9061/ibm/console

The Test Client is the Web Services Explorer tool inside WebSphere Integration Developer.

To verify the WS-AT headers in the SOAP messages between the coordinator and the participant, use the TCP/IP Monitor View in WebSphere Integration Developer by directing the Transaction Coordinator application to make Web service requests via the TCP/IP Monitor instead of directly to the mediation module.

Table 2. TCP/IP Monitor View configuration
Local monitoring portHostnamePort
9090localhost9081

The hostname and port for the TCP/IP monitor match those for the WebSphere ESB server because it will redirect requests to its HTTP address. If you would like to run this sample on other combinations of products, such as a single WebSphere ESB server, see Alternative configurations below. Administrative security is disabled on both servers.

1. Developing the Transaction Coordinator application

The first steps create a dynamic Web project, which is part of the J2EE application that acts as the Transaction Coordinator:

Developing the dynamic Web client

  1. Launch WebSphere Integration Developer.
  2. Import the Project Interchange File (PIF) WSATSample-pif_70.zip into the workspace: Click File => Import => Project Interchange. Do not select the two WSATSample_DynamicWebClient projects -- you will build these. Do select the other four.
  3. In the Business Integration view, open the WSATSample_Library project. This library contains the Web service binding definitions for the mediations. Select MediationEchoService_EchoHttpPort and use the context menu to choose Web Services => Generate Client:
    Figure 2. Selecting the WSDL binding of the mediation to generate a client
    WSDL binding MediationEchoService_EchoHttpPort
  4. Configure the following values (verify against the screen shot below):
    • Server: WebSphere Application Server V7.0
    • Web service runtime: IBM WebSphere JAX-WS
    • Client project: WSATSample_DynamicWebClient
    • Client project type: Dynamic Web Project
    • Client EAR project: WSATSample_DynamicWebClientEAR
    Figure 3. Configuring the MediationEchoService Web services client generation
    Configuring the MediationEchoService Web services client generation
  5. Click Finish.
  6. Next create a Java class inside the generated client project that will invoke the Web service client proxy. First select the WSATSample_DynamicWebClient project and then select New => Class from the menu. The details should be:
    • Package: testservice
    • Name: WASTestService
    • Path: WSATSample_DynamicWebClient\src\testservice\WASTestService.java
  7. Enter the code in Listing 1:
    Listing 1. Sample code WASTestService.java -- A Web services consumer that initiates a transaction
    package testservice;
    
    import javax.naming.InitialContext;
    import javax.transaction.UserTransaction;
    
    import wsatsample_library.echo.binding.EchoFaultMsg;
    import wsatsample_library.echo.binding.MediationEchoService_EchoHttpPortProxy;
    
    public class WASTestService {
        public String test(String input) {
            String fromMediation = null;
            try {
                InitialContext context = new InitialContext();
                UserTransaction ut = (UserTransaction) context
                    .lookup("java:comp/UserTransaction");
                log("begin");
                ut.begin();
                
                MediationEchoService_EchoHttpPortProxy mediationProxy = 
                            new MediationEchoService_EchoHttpPortProxy();
                    try {
                        fromMediation = mediationProxy.echo(input);
                        // invocation of mediation web service returned successfully
                    if (input != null && input.contains("WASCLIENTROLLBACK")) {
                        log("rollback");
                        ut.rollback();
                    } else {
                        log("commit");
                        ut.commit();
                    }
                } catch (EchoFaultMsg e) {
                        fromMediation="Exception: " + e;
                        log("mediation modeled fault, commit. "+fromMediation);
                        ut.commit();
                    }
                log("done");
            } catch (Exception e) {
                // TODO provide exception handling, e.g. rollback()
            }
            String echo = "WASClient[---" + fromMediation + "---]";
            log(echo);
            return echo;
        }    
             
        private void log(String msg) {
            System.out.println("WASClient >>> " + msg);
        }
    }
  8. To test this Web service client while running on WebSphere Application Server, you need a way to drive it. One way to do this is by exposing the Java class as a bottom-up Web service. Select the Java class and select Web Services => Create Web service from the context menu.
  9. Configure the following values (verify against the screen shot below):
    • Server: WebSphere Application Server V7.0
    • Web service runtime: IBM WebSphere JAX-WS
    • Server project: WSATSample_DynamicWebClient
    • Server EAR project: WSATSample_DynamicWebClientEAR
    • Sliding bar on left: Deploy service
    Figure 4. Configuring the Web services service generation for WSATSample_DynamicWebClient
    Configuring the Web services service generation for WSATSample_DynamicWebClient
  10. Click Next.
  11. Check Generate WSDL file into the project.
  12. Click Finish.

Inspect the services: Open the Java EE perspective and Services view. Double-click each client or service to open the Java Editor:

Figure 5. Services view showing generated client and service
Services view showing generated client and service

2. Creating a new policy set for the Transaction Coordinator

The default policy set for WS-AT that comes with WebSphere ESB and WebSphere Application Server uses SSL for transmission of the SOAP messages. For an insecure scenario, create a new policy set that includes WS-AT only (without SSL).

Creating a policy set for the dynamic Web client

WS-Transaction policy options

When editing the policy set, the WS-Transaction policy can be configured with options Mandatory, Supports, and Never. The default is Supports, which means if WS-AT context is available, then consumers can send it and providers can use it. Use the defaults.

  1. Start WebSphere Application Server.
  2. Open the Integrated Solutions Console (ISC) at http://localhost:9060/ibm/console.
  3. Go to Services => Policy sets => Application policy sets.
  4. Click New to create a new policy set named WSATSample_WS-AT_insecurePolicySet. This alias will be used later in the development project to bind to the runtime during deployment.
  5. Click Apply and then Add to add the WS-Transaction policy.
  6. Click OK and then Save to save changes to the master configuration.
  7. Click the check box next to the policy set and click Export to save the new policy set to the local file system.

Later, before deployment, the article will show you how to repeat this configuration for WebSphere ESB.

3. Configuring the Transaction Coordinator

You can attach the new policy set to the J2EE client and WebSphere ESB module at deployment time. However, you will import the policy set into WebSphere Integration Developer and then this configuration can be completed at development time. The policy set is supplied as an alias in the project and is automatically bound to the policy set already defined on the server during deployment.

Configuring the dynamic Web client

  1. In WebSphere Integration Developer, select File => Import.
  2. Select Web services => WebSphere Policy Sets.
  3. Locate the zip file of the policy set that you saved to the local file system and finish the wizard. The Preferences view will now list the custom policy set. The next step is to attach the policy set to the J2EE client.
  4. Restart WebSphere Integration Developer, which is necessary for the mediation tooling later.
  5. In the Services view, select the Web service client and use the context menu to select Manage policy set attachment.
  6. Click Next.
  7. Click Add and then select the new policy set WSATSample_WS-AT_insecurePolicySet in the drop-down and specify Binding as the Default binding. Click OK:
    Figure 6. Configure client side policy set and binding
    Configure client side policy set and binding dialog
  8. Click Finish

The client is now ready to go and can send transactional SOAP requests using WS-AT.

4. Configuring the mediation module

The mediation module is already set up to use the new WS-AT policy set (assuming it is named WSATSample_WS-AT_insecurePolicySet) and join an incoming transaction. These steps will verify this configuration:

Inspecting the transaction participant -- WSATSample_MediationService mediation module

  1. Open the Assembly Diagram for the WSATSample_MediationService mediation module.

    The Turnaround component is the transaction-enabled mediation. Opening the mediation flow will reveal a message logger mediation primitive named LogRequest that logs the Service Message Object to the message logger database table. The DatabaseQuery component is not part of the scenario but included for testing and validation purposes:

    Figure 7. Assembly diagram for the mediation module
    Assembly diagram for the mediation module
  2. Open the MediationEchoService Export in the Properties view and select Binding => Policy Sets. Observe that the new policy set is selected (if it is not, then a restart is needed after importing the policy set into WebSphere Integration Developer).
  3. Verify the following qualifiers by using the Properties view on the Turnaround Mediation Flow Component:
Table 3. Configuration for mediation module to participate in incoming transaction
PanelQualifierExpected Value
Details => Interfaces => Echo => QualifiersJoin transactionTrue
Implementation => QualifiersTransactionAny
Figure 8. QoS qualifiers for turnaround SCA component
QoS Qualifiers for Turnaround SCA component

This QoS can be verified along with others: Select Assembly Diagram and view Properties on it, as shown in Figure 9 below. The Join transaction qualifier determines whether or not to participate in an existing global transaction incoming from the client. The value Any for the component's Transaction qualifier on the implementation panel can be interpreted as using an existing incoming global transaction, or otherwise use a local transaction (no transaction). The value Global creates a new global transaction if one is not already present.

Figure 9. All qualifiers view showing QoS for transactional configuration
All qualifiers view showing transactional configuration

5. Running the sample

Set up the TCP/IP Monitor view inside WebSphere Integration Developer, which lets you inspect the SOAP messages between the J2EE client and the WebSphere ESB server. Point the client at the TCP/IP monitor, and it will pass the requests to the WebSphere ESB server (and similarly relay the responses back). The TCP/IP monitor will start listening using port 9090 and redirect to the WebSphere ESB server, which has a HTTP port of 9081.

The J2EE client code has a special testing input value that causes a transaction rollback. Use the DatabaseQueryService Web service running on WebSphere ESB to verify whether the database update that is part of the mediation flow was committed. Administrative security is disabled on both servers.

Expected test results

The table describes two tests. In both, the mediation returns a normal "happy" response (HTTP 200). In the case of using the special WASCLIENTROLLBACK input value, the database update is not committed:

String input value supplied to WASTestService in WSATSample_DynamicWebClientNormal SOAP response from WSATSample_MediationService mediation module’s MediationEchoService service ?Database row committed ?
HAPPYYESYES
WASCLIENTROLLBACKYESNO

Deployment and testing

These steps drive the J2EE application on WebSphere Application Server using a testing client and then verify the results by checking for the presence of database updates:

  1. Select Window => Show View => TCP/IP Monitor.
  2. In the drop-down at the top right, click Properties.
  3. Click Add and specify:
    • Local monitoring port : 9090
    • Hostname : localhost
    • Port : 9081 (The port of the WebSphere ESB server profile)

    Ensure that the monitor is started by checking the Status column. then configure the Web services client in the J2EE application on WebSphere Application Server to make requests to port 9090 instead of directly to the WebSphere ESB server.

  4. Open the Services view.
  5. Open the Clients folder, select the service, and select Show => WSDL Interface.
  6. Click Yes at the pop-up prompt to open in the WSDL Editor.
  7. Switch to the Source tab and override the location field to use Port 9090. The element should be given a value such as:
    <soap:address location="http://localhost:9090/WSATSample_MediationServiceWeb/
    sca/MediationEchoService"/>
  8. The WebSphere ESB server also requires a new policy set for WS-AT before deploying the application. First, open the ISC for the WebSphere ESB server at http://localhost:9061/ibm/console. Then there are two ways to create the policy set. Either:
    • Repeat the steps in Creating a new policy set for the transaction coordinator for the WebSphere ESB server, or
    • Use the Import option on the Policy sets panel in the ISC and import the policy set that was exported earlier. This option assumes the policy set is being imported into a product with major version that matches that of the product that exported it.
  9. You are now ready to run. Add the appropriate module to each server by using the Servers view, the context menus, and Add/Remove projects.
    Listing 2. Example SystemOut.log outputs from starting applications
    J2EE Client App on WebSphere Application Server
    
    WSVR0200I: Starting application: WSATSample_DynamicWebClientEAR
    ...
    SRVE0250I: Web Module WSATSample_DynamicWebClient has been bound 
         to default_host[*:9080,*:80,*:9443,*:5060,*:5061,*:443].
    ...
    WSVR0221I: Application started: WSATSample_DynamicWebClientEAR
    
    Mediation module on WebSphere ESB server
    
    WSVR0200I: Starting application: WSATSample_MediationServiceApp
    ...
    SRVE0250I: Web Module WSATSample_MediationServiceWeb has been bound 
        to default_host[*:9081,*:80,*:9444,*:5063,*:5062,*:443].
    ...
    WSVR0221I: Application started: WSATSample_MediationServiceApp

    If the policy sets are not available on the server, the following warning may appear during application deployment:

    CWPST0148W:  policyset of WSATSample_WS-AT_insecurePolicySet not defined in server.
    You may need to manually import or define policyset to make your application work.

    Or a message like the one below with an FFDC file created:

    FFDC Incident emitted on ...filename.txt... com.ibm.ws.policyset.admin.commands.
    CreatePolicySetAttachment FFDC-2

    To test whether the database table is updated, use the DatabaseQuery service to check how many rows exist in the message logger table. This service contains bespoke Java code for use as a testing utility. The binding definition is in the library, but the Java code is in an SCA Java component inside the mediation module installed on the WebSphere ESB server.

  10. Select the Web service binding from the WSATSample_Library that corresponds to the DatabaseQueryService and select Web Services => Test with Web Services Explorer:
    Figure 10. Selecting the DatabaseQueryService binding in the Business Integration view to use with the Web Services Explorer
    Selecting the DatabaseQueryService binding to use with the Web Services Explorer
  11. The endpoint is at Port 9090 and that is redirected to the WebSphere ESB server using the TCP/IP Monitor.
  12. Click getNumberOfRows link under Operations and then click Go. The figure shows an example response in the bottom of the Status pane:
    Figure 11. Response from DatabaseQueryService indicating the number of message logger database table rows
    Response from DatabaseQueryService indicating number of message logger database table rows

    If no valid response is received, look in the TCP/IP Monitor view for the return code. Check the port numbers and that the module is deployed successfully (you will get HTTP code 404 if the endpoint is unavailable). If you see HTTP code 500 (failure), then remove the module from the server, clean, rebuild, and redeploy.

    Make a note of the number (-1 is an error and you will need to check the Console view for errors). Typical errors include a mismatch of the JNDI and table name values compared with the actual message logger database. Check the implementation of the SCA Java component DatabaseQuery (Java class DatabaseQueryImpl.java)

    .
  13. Open the Services view.
  14. Select WASTestService and click Test with Web Services Explorer:
    Figure 12. Testing the J2EE application through the JAX-WS Web service binding
    Testing the J2EE application through the JAX-WS Web service binding
  15. You may need to override the endpoint port (9080 for WebSphere Application Server in this case).
  16. Click Test under Operations.
  17. Click Add and enter a string value such as HAPPY.
  18. Click Go:
    Figure 13. Successful response from the J2EE application
    Successful response from the J2EE application

    The response string is formed from the input value ("HAPPY"), the mediation flow processing ("Mediation"), and the J2EE application ("WASClient"). If your response differs, see Troubleshooting below.

Example messages

The TCP/IP Monitor view can used to observe with the WS-AT headers. These figures show example messages that demonstrate some of the WS-AT headers. The actual protocol messages are not captured because they are sent directly from server to server and do not pass through the TCP/IP monitor.

Figure 14. Request from J2EE application as the transaction coordinator to mediation module showing SOAP headers containing transaction propagation
Request with WS-AT SOAP headers
Figure 15. Response from mediation module demonstrates registering as a transaction participant
Request with WS-AT SOAP headers

If these headers are missing, then check the policy set configuration and see Troubleshooting.

Testing commit and rollback

  1. To check that a database row was created, rerun the DatabaseQueryService using the Web Services Explorer. The number returned should be one greater than before. In Figure 11 there were three rows initially, so four are expected if the transaction commits, because the mediation inserts one row in the database table.
  2. To test a rollback, run the WASTestService service again and use the input value WASCLIENTROLLBACK.

The Web service invocation is successful and a response will be received by the Web Services Explorer test client. The WebSphere Application Server logs show a transport chain being opened to Port 9081 (in bold below) for the WS-AT protocol messages (the SOAP request was sent to the WebSphere ESB server using Port 9090). This message appears only on the first occasion. If this line is missing, then it indicates a configuration issue. Check the Troubleshooting section and verify that policy sets are installed.

Listing 3. Example SystemOut.log outputs from J2EE application when controlling transaction
WASClient >>> begin
WASClient >>> rollback
CHFW0019I: The Transport Channel Service has started 
    chain HttpOutboundChain:9.196.143.238:9081.
WASClient >>> done
WASClient >>> WASClient[---Mediation(---WASCLIENTROLLBACK---)---]

Now run the DatabaseQueryService Web service to confirm that a database update was not performed.

These steps have demonstrated that a mediation module can participate in a container-managed transaction. The mediation flow returns successfully in both tests in this example, but the runtime container is in control of the resources that are part of the global transaction. In the case where the J2EE application forces a rollback, then the WebSphere ESB server does not commit the changes for the resources that are participating in the global transaction.

Another situation that would cause a rollback is if the mediation causes an unmodeled fault, such as a system or runtime failure or the use of a Fail mediation primitive.

If the mediation returns a modeled fault (one defined on the service interface), then this would be normal application behaviour and would not inherently cause a rollback. This can be tested with the sample artifacts by using a special input value of fault that causes the mediation flow to return a modeled fault, using a branch in the flow using an XPath condition and a message filter mediation primitive that detects the special value. The database update is committed because the logic in the J2EE application still calls commit().

Troubleshooting

If a response like WASClient >>> WASClient[---null---] is seen, then the J2EE application experienced a failure invoking the service on WebSphere ESB. In this case, check the logs in the Console view. A possible cause is that the mediation is not deployed or that it cannot be invoked via Web services from the J2EE application, possibly because the TCP/IP Monitor is using an incorrect forwarding port to WebSphere ESB, or because the Web Service client is not connecting to the TCP/IP Monitor.

If the WebSphere Application Server or WebSphere ESB logs show a message like the one below, then the cause is a missing WS-AT policy attachment:

javax.xml.ws.soap.SOAPFaultException: Must Understand check failed for headers: 
{http://schemas.xmlsoap.org/ws/2004/10/wscoor}CoordinationContext

Check for the WS-AT SOAP headers. If they are not present on both the request and response, then the policy set configuration may be incomplete. Check for both the service provider (response) and service client (request) that the policy set attachments are present. For example, for the service provider, open the ISC and look at Services => Service providers and check that there is an Attached policy set. If the headers are present but the behaviour is not as described, there is a failure in the protocol messages, which could have a number of causes. First, make sure the host names or IP addresses used in the SOAP headers are resolvable between each machine.

An error like WTRN0127E: Operation blocked by policy type configuration. indicates a problem with policy set configuration. The cause could be mismatched versions, such as exporting a policy set from V6.2 and importing it into V7. To fix this error, re-create the policy set on the server in the ISC and attach to the service directly in the ISC.

Also check the configuration of the WS-Transaction policy. You can access this configuration through the panel for the WSATSample_WS-AT_insecurePolicySet policy set. See Figure 16 for the default settings:

Figure 16. WS-Transaction policy configuration defaults
WS-Transaction policy configuration defaults

Scan the log for records of FFDC files being created. The root cause of configuration errors is captured in the first instance of the problem.

For information about applicable versions, see Previous versions below.

Alternative configurations

The described configuration uses WebSphere Application Server to run the Transaction Coordinator J2EE application. It could also be deployed to a WebSphere ESB server that supports J2EE applications or other applications that deploy to WebSphere Application Server. Similarly, either of the applications can be deployed to WebSphere Process Server, because it also can run mediation modules. You can run everything on a single WebSphere ESB server profile, but some of the protocol messages will not be observed during testing due to an optimization for co-located transaction participants and coordinators. So to observe the headers, run the steps using at least two distinct server profiles.

Previous versions

The downloads include a version of the projects for WebSphere Integration Developer V6.2. The only difference is that the projects have slightly different table names inside the DatabaseQuery component for the database lookup, which reflects product differences related to the default schema name. The following product versions are recommended for use with this scenario:

  • WebSphere Application Server V6.1.0.25 and Web Services Feature Pack (WSFP) or later
  • WebSphere Application Server V7.0.0.5 or later
  • WebSphere ESB or WebSphere Process Server V6.2.0.2 (includes WebSphere Application Server ND V6.1.0.25 and WSFP) or later
  • WebSphere ESB or WebSphere Process Server V7.0.0.1 (includes WebSphere Application Server ND V7.0.0.7) or later

Fix pack levels

A fix may be required for the server acting as a transaction coordinator. It is included in WebSphere Application Server V6.1.0.23 and V7.0.0.5 and hence in the recommended levels. See the support downloads: Fixes by version for WebSphere Application Server. The fix is PK83525 6.1.0.23: Time out with WebSphere Enterprise Service Bus WS-AT. The symptom includes the log message:

FFDC Incident emitted on com.ibm.ws.wsaddressing.EndpointReferenceManagerImpl.
    EndpointReferenceManagerImpl
FFDC Incident emitted on com.ibm.ws.wstx.handler.WSATGenerator.processResponse

and a failure to complete the transaction before time-out.

Security

The steps above do not describe a secure configuration, which would include the security of the Web services message and also the security of the WS-AT protocol messages. These aspects are independent. There are also choices for how to secure the Web services message -- message-level security (such as WS-Security), and/or transport level security (such as HTTPS/SSL).

When server administrative (global) security is enabled, extra configuration is needed so that the protocol messages (exchanged behind the scenes) can flow. In this case, some additional steps are needed for the scenario to function as it does without security. One reason is that the protocol messages are always sent using HTTPS when administrative security is enabled. These steps will allow the WS-AT protocol messages to operate:

  1. On each server, disable Transaction coordination authorization under Servers => Server types => WebSphere Application Servers => server_name => [Container Settings] Container Services => Transaction Service.
  2. Optionally, create a new transport chain for the protocol messages, or use the default HTTPS channel. The default SSL settings use the default personal certificate and default trust store.
  3. On each server, import the other server's signer certificate into the default trust store by going to SSL certificate and key management => Key stores and certificates => NodeDefaultTrustStore => Signer certificates, using Retrieve from port, and entering the HTTPS port on the other server. This step is recommended only for self-signed certificates.
  4. Restart both servers.

On WebSphere Application Server V6.1 based products, there is another step -- see Configuring Web Services Transaction support in a secure environment in the WebSphere Application Server V6.1 information center. If there are problems, such as transaction timeouts, then check the logs and the contents of FFDC files.

Conclusion

This article showed you how to create a distributed two-phase commit transaction between two WebSphere Application Server based servers. You can use this technique to ensure that updates take place in an atomic manner. You can also involve many resources in a single transaction, but there is a cost associated with doing so, because each participant must lock resources while waiting for the transaction outcome. For this reason it is recommended that you use distributed transactions sparingly.

It is most appropriate to use WS-AT when the interactions are short-lived and the participants are close by and connected by reliable networks. For longer-lived interactions, WS-BusinessActivity might be more applicable. A compensation-based approach might also be desirable when actions are optimistically performed and then undone if necessary.

The article used WebSphere Application Server as a coordinator and WebSphere ESB as a participant. Other combinations are equally valid, such as using two WebSphere ESB instances, one as coordinator and one as participant. For example, a mediation component could initiate a global transaction and then propagate it through a Web service import binding to another SCA component in another module. Interoperability is also possible with other third-party products that support XA transactions and WS-AT.

The example used bean-managed transactions in the J2EE application (Java code) to control the transaction outcome, primarily for demonstration purposes and to simplify testing. If you connect two WebSphere ESB mediations, then the transaction management takes place automatically (container-managed transaction). Failure to commit the transaction in either runtime (for example, a database issue or an unmodeled fault from mediation logic) will cause each participant in the global transaction scope to roll back.

In summary, using WS-AT with WebSphere ESB requires a small amount of configuration of the applications and the runtime during deployment. Transactions are then handed automatically at runtime without user code.

Acknowledgements

The author would like to thank IBM colleagues Jon Hawkes and Callum Jackson for reviewing this article.


Downloads

DescriptionNameSize
Source artifacts (PIF) for V6.2.0.2 or later1WSATSample-pif_62.zip63KB
Source artifacts (PIF) for V7.0.0.1 or later2WSATSample-pif_70.zip67KB

Notes

  1. Project interchange file containing artifacts for use with WebSphere Integration Developer V6.2.0.2 or later
  2. Project interchange file containing artifacts for use with WebSphere Integration Developer 7.0.0.1 or later

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=599583
ArticleTitle=Ensuring transactional integrity using Web Services Atomic Transaction support in WebSphere ESB and WebSphere Application Server
publish-date=12082010