Enterprises are increasingly turning to a service-oriented approach towards implementing an EAI. The goal of this article is to demonstrate transaction control and propagation when using IBM® WebSphere® Process Server as a Service-Oriented Architecture (SOA)-based enterprise integration platform. WebSphere Process Server runs on an underlying IBM WebSphere Application Server platform that provides WebSphere Process Server with core distributed transactional capabilities. The key component types that execute in WebSphere Process Server (for example, Business Process Execution Language [BPEL], human tasks, business rules, and state machines) follow the Service Component Architecture (SCA) specification.
Note: This article assumes that you're familiar with WebSphere Process Server, IBM WebSphere MQ, IBM WebSphere Integration Developer, Enterprise JavaBeans (EJB) components, and Web services.
This solution has been developed and tested on:
- WebSphere Process Server and WebSphere Integration Developer V6.0.2.x
- WebSphere MQ V6.0.2
- IBM DB2® Universal Database V8.1.14.292
- Oracle Database 10g Express Edition Release 10.2.0.1.0
Enterprise integration: a common scenario
Consider the case where you have three systems: A, B, and C.
- System A: Generates an event by putting a message on an WebSphere MQ queue. This event is required to be propagated to systems B and C.
- System B: Upon receiving this event (from system A), system B inserts data into its database. System B provides an EJB interface and uses an DB2 back end.
- System C: Upon receiving the same event (from system A), system C deletes data from its database. System C provides a Web service (WS) interface and uses an Oracle back end.
The success of this scenario depends on both system B and C completing their respective transactions successfully. If that doesn't happen, both systems B and C are required to go back to the original state they were in before they received the event, and the original event data must be moved to a temporary holding queue.
The proposed solution uses the approach of defining an SCA component (BPEL process) as the orchestrator for this integration. It listens for input on a WebSphere MQ queue and then invokes the EJB component and the Web service interfaces exposed by the two systems to which it needs to pass the received data. Figure 1 depicts the proposed solution.
Figure 1. System overview
However, the key for this solution to implement the requirements as stated in the previous section is to use the distributed transactional capabilities in WebSphere. WebSphere acts as the transaction coordinator and manages the above scenario as a single distributed unit of work that's distributed across various resource managers that include DB2, Oracle, and WebSphere MQ.
This article shows you how SCA transaction qualifiers, Java™ 2 Platform, Enterprise Edition (J2EE) transaction specifications, the Web Service Atomic Transaction (WS-AT) specification definitions, and WebSphere MQ setup all work together to create a transactional enterprise integration solution.
As mentioned earlier, the focus of this article is to demonstrate how the various components work under a single transaction. As a result you'll see that very simple data types and component logic have been used. The focus is not to showcase all the features and capabilities of BPEL, business objects, and interface definitions or go into the details of component development. I'm including as a part of this article the project interchange file (see the Download section) that includes all the components that simulate the above systems and demonstrate transaction propagation.
The PIF (project interchange file) contains the following elements:
- SYSTEMA: This J2EE project simulates system A. It contains a servlet that puts a message on a WebSphere MQ queue. Appropriate queue definitions have been created on the WebSphere MQ server and on the WebSphere MQ JMS provider in WebSphere Process Server. An XA WebSphere MQ Connection Factory has been defined on the WebSphere MQ Java Message Service (JMS) provider in WebSphere Process Server to communicate with WebSphere MQ.
- DB Helper: This Java project contains the helper class, which has the actual JDBC code to connect and insert or delete data from the DB2 or Oracle database tables, respectively. This project also has the Data Definition Language (DDL) files for the customer table for both DB2 and Oracle.
- SYSTEMB: This J2EE project simulates system B. It contains an EJB component that uses the Java class in the DB Helper project to insert data into a DB2 database table. An XA data source has been defined on WebSphere Process Server and is used to communicate with DB2.
- SYSTEMC: This J2EE project simulates system C. It contains an EJB implementation exposed as a Web service that uses the Java class in the DB Helper project to delete data from an Oracle database table. An XA data source has been defined on WebSphere Process Server and is used to communicate with Oracle.
- Integrator: This module contains an SCA component implemented as a BPEL process. The SCA component uses a WebSphere MQ JMS export to pick the message from the WebSphere MQ queue. It uses the WS and stateless session bean EJB imports to communicate with the EJB and WS interfaces of system B and system C, respectively.
Solution setup and implementation
In this section, you focus on defining the transactional aspects of the various components defined in the Proposed solution section.
Figure 2 shows the assembly diagram of the module (Integrator) that comprises the Integrator SCA process, which has a WebSphere MQ and JMS export and two imports: one to the stateless session bean (via a mapper) and the other to a Web service.
Figure 2. Assembly diagram
You need to set transaction qualifiers at the interface/operation level and at the implementation level for the SCA components. Set them at the interface/operation level for the imports. Figures 3 through 9 show how these qualifiers are set.
Figure 3. Set transaction qualifiers for the Integrator component interface
Figure 4. Set transaction qualifiers for the Integrator component implementation
Figure 5. Set transaction qualifiers for the SYSTEMBMapper component interface
Figure 6. Set transaction qualifiers for the SYSTEMBMapper component implementation
Figure 7. Set transaction qualifiers for SYSTEMBSSB Import
Figure 8. Set transaction qualifiers for SYSTEMCWS Import
Figure 9. WS-AT is enabled for requests sent from Integrator to the external Web service
Now that you've enabled the transaction settings on the Integrator component, which invokes the system B and system C interfaces, you must ensure that the interfaces to system B and system C can execute under a transaction context as described in the next two subsections.
EJB components and transactions
The transaction model for the EJB components is defined by the J2EE specification. All the J2EE vendors (in this case WebSphere Application Server) implement the specification to provide transaction capabilities for EJB components.
There are two forms of transaction support:
- Container-managed transaction (CMT) involves defining the appropriate transaction settings on the EJB deployment descriptor.
- Bean-managed transaction (BMT) involves using the code in the session or message-driven bean (MDB) to explicitly mark the boundaries of the transaction using the Java Transaction API (JTA).
Note: For more information on the EJB Transaction Model, see the Resources section at the end of this article.
Please note that SYSTEMB provides a stateless session bean interface and uses CMT.
The declarative transaction settings for the stateless session bean are done in the EJB deployment descriptor (ejb-jar.xml). By default, all methods on the EJB remote interface have a transaction setting of TRANSACTION_REQUIRED (see Figure 10).
Figure 10. Declarative transaction using EJB deployment descriptor
In the EJB implementation code, as a part of exception handling, set the
transaction to Rollback, as shown in Figure 11.
Figure 11. Set transaction to Rollback
The stateless session bean uses the DBHelper class (JDBC statements are used) to
perform the database transaction. An XA data source for the DB2 database is defined
and used to execute the JDBC statements.
The transaction model for Web services is defined in the WS-AT specification. (Note: Details of this specification are beyond the scope of this article. See Resources for more information on WS-AT.) Enabling WS-AT support for Web services in WebSphere is declarative. You need to make only simple changes on the deployment descriptor, and there's no coding required. System C provides a Web service interface. This Web service was generated by exposing an EJB component as a Web service. The same Web service could have been a Microsoft® .NET component, because the transaction specification used here is WS-AT, which has been implemented by both WebSphere and .NET.
Open the web.xml deployment descriptor in the SYSTEMCWeb project, and select the Servlets tab. Figure 12 shows the simple setting you need to enable for WS-AT.
Figure 12. Enabling WS-AT
The Web service implementation uses the DBHelper class (JDBC statements are used)
to perform the database transaction. An XA data source for the Oracle database is
defined and used to execute the JDBC statements.
Now let's set up a WebSphere MQ queue manager and two queues:
- The queue on which the message is sent (MQREQUESTQ)
- The temporary backout queue that comes into play if there are transaction failures (ERRORQ)
- Set the backout threshold on the MQREQUESTQ to
1(see Figure 13).
Figure 13. WebSphere MQ setup
- Set up an XA-enabled WebSphere MQ Queue Connection Factory (QCF) on the WebSphere MQ JMS Provider in WebSphere. This QCF is used by SYSTEMA to put a message on the queue and by the Integrator component to pick it off the queue.
- Set up a listener port in WebSphere that allows the Integrator component to
listen to the MQREQUESTQ. Ensure that the Maximum retries field is set to
2. This setting, along with the Backout threshold on the MQREQUESTQ to 1, ensures that on a transaction failure, when a message comes back to the MQREQUESTQ, it's moved to a temporary queue, namely the ERRORQ (see Figure 14).
Figure 14. WebSphere MQ listener port setup
Solution deployment and testing
In this section, you focus on deploying the above artifacts and testing both a success and a failure scenario to demonstrate how the requirements are met.
- The WebSphere Process Server test environment in WebSphere Integration Developer is used as the deployment target.
- All the components, including the integration components and system simulators (SYSTEMA, SYSTEMB, SYSTEMC), are deployed on the same server. In a real environment they would be deployed on different servers.
- Enable TCPMON on the WebSphere Process Server test environment to view the
SOAP message with WS-AT
headers (see Figure 15).
Figure 15. Enable TCPMON
As part of the first test case, you test the success scenario, and at the end, new data has been inserted into the DB2 database and deleted from the Oracle database.
As part of the second test case, you test the failure scenario. You shut down the Oracle database to prevent SYSTEMC from completing the transaction and, therefore, it's roll backed. Data doesn't get inserted into DB2, and a message goes onto the ERRORQ.
Figures 16, 17, and 18 show the state of the systems before the execution of the success scenario. There's no data in the DB2 CUSTOMER tables, but there's data that exists in the Oracle table. There are no messages in the ERRORQ on WebSphere MQ. Follow the figures one after the other; they demonstrate the initial state.
Figure 16. No data in DB2
Figure 17. Existing data in Oracle
Figure 18. No messages on the WebSphere MQ queues
Upon execution of the success scenario, data should get inserted into DB2 and deleted from Oracle as defined by the requirements. Because there are no errors, there are no messages in the WebSphere MQ ERRORQ. The SOAP message shows the WS-AT headers, which demonstrate the propagation of transaction to the WS interface.
Success scenario: Execute the URL http://localhost:9080/SYSTEMAWeb/SystemASimulator?fileName=success_customer.xml. Note: The customer data in the file success_customer.xml is put on the WebSphere MQ queue.
Figure 19. Data inserted into DB2
Figure 20. Data deleted from Oracle
Figure 21. WS-AT SOAP headers
Figures 22 through 25 show the state of the systems after the execution of the failure scenario. This failure is simulated by shutting down the Oracle database. SYSTEMC is unable to complete its transaction. Even though the insert into DB2 was successful, when the overall distributed transaction rolls back, it's ensured that no data that gets inserted into DB2 and the original message is moved into the ERRORQ of WebSphere MQ. The requirement of having the systems in their original state in case of a failure is satisfied, and the original message is kept aside in a WebSphere MQ queue as per the requirements.
Failure scenario: Execute the URL http://localhost:9080/SYSTEMAWeb/SystemASimulator?fileName=failure_customer.xml. Note: The customer data in the file failure_customer.xml is put on the WebSphere MQ queue.
Figure 22. Shut down Oracle
Figure 23. Transaction failure
Figure 24. No new data in DB2
Figure 25. Message on the ERRORQ
EAI involves integrating various applications that support different technology interfaces. Therefore, it's essential that you understand how to implement a transactional integration system that ensures data integrity and consistency in case there's a failure in one of the participants. With tooling and technologies becoming more mature, implementing such a robust solution is becoming increasingly easier—even easier than this demonstration.
| Description | Name | Size | Download method |
|---|---|---|---|
| PI file for this article | article_pif.zip | 65KB | HTTP |
Information about download methods
Learn
- Learn more about
Web
Services Atomic Transaction.
- Get more information about
EJB components and
transactions.
- Check out additional information about
IBM
WebSphere Process Server and WebSphere Integration Developer.
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services
applications.
- Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts.
- Browse for books on these and other technical topics at the
Safari bookstore.
- Check out a quick Web services on demand demo.
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
- Participate in the discussion forum.
- Get involved in the developerWorks community
by participating in developerWorks blogs.
Rajiv Ramachandran is a key member of Prolifics' highly specialized team of IBM WebSphere experts retained to architect, build, and troubleshoot custom WebSphere, Portal and Business Integration solutions. Part of Prolifics' Business Development Team, he specializes in Service-Oriented Architecture, enterprise integration, and business process management.
