Level: Intermediate Rajiv Ramachandran (rramachandran@prolifics.com), Solution Architect, Business Development, Prolifics
10 Apr 2008 In the world of enterprise application integration (EAI), it's essential
that all participating systems operate under an overarching global transaction so
that these systems all return to a consistent state in case of a
failure. With the various systems supporting different protocols, the transaction
semantics must be propagated across these protocols so they
can seamlessly participate in the global transaction. This article walks you through the steps
required to make an example of a common integration scenario a transactional integration.
Introduction
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.
Proposed solution
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.
SCA And transactions
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.
Web services and transactions
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.
WebSphere MQ setup
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.
Deployment
- 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
Testing
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.
Initial state
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
Summary
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.
Download | Description | Name | Size | Download method |
|---|
| PI file for this article | article_pif.zip | 65KB | HTTP |
|---|
Resources Learn
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
About the author  | 
| | 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. |
Rate this page
| 
