Transactions ensure end-to-end data integrity across multiple
resources. A robust SOA solution should consider data integrity at
all levels.
Introduction
A transaction
is a unit of activity. Within a transaction, multiple updates to resources
can be made an indivisible unit of work: either all the updates are
made permanent, or none of the updates are made permanent.
If
a transaction involves multiple resource managers, for example multiple
database managers, then an external transaction manager is needed
to coordinate the individual resource managers. A transaction that
spans multiple resource managers is called a global, or distributed,
transaction. WebSphere® Application
Server is a transaction manager that can coordinate global transactions,
and the runtime makes use of the WebSphere Application
Server functionality.
Planning
When planning how to use transactions,
consider the following:
- If you use Web Services Atomic Transaction (WS-AT) to propagate
transactional context from the service requestor, then you might want
to make the mediation flow part of the service requester's transaction.
- When developing your mediation flow, in WebSphere Integration Developer, the default
is that the mediation is not part of a transaction. Therefore, the
mediation does not propagate any transactional context provided by
the service requester.
- Different import and export bindings have different transactional
capabilities. A Web services binding can propagate a transaction from
the service requester. However, a JMS binding cannot propagate a transaction
from the service requester.
- WebSphere Business
Integration Adapters are based on JMS. Therefore, as soon as a message
is put on a message queue it is considered complete, from a transaction
point of view. If a messaging system is defined not to time out, and
the ESB messages are permanent, then the messaging system ensures
that the messages are delivered.
- JCA adapters allow full transactional updates.
Creating a transaction for a Web services request
If
the service requester and provider both have Web services bindings,
and the service requester is using WS-AT, you can make your mediation
flow part of the global transaction. Use WebSphere Integration Developer to define
the following quality of service qualifiers:
- Set the implementation's Transaction qualifer
to Global or Any.
- Set the mediation modules's interface Join transaction qualifer
to True.
- Set the mediation modules's import interface Join transaction qualifer
to True.
Figure 1. Transaction covering service requester, mediation
flow and service provider
.
Controlling individual parts of a mediation flow
Some
mediation primitives have a transaction property, so you can control
whether a particular aspect of a flow takes part in a global transaction.
For example, there might be a business requirement to log certain
events, whether or not the service request completes successfully
or not. In this case you might decide to keep logging, or the emission
of events, outside of the main transaction.
Both the Message
Logger mediation primitive and the Event Emitter mediation primitive
have a Transaction mode property. If the integration
developer promotes these properties, they are visible
at runtime and can be updated by the runtime administrator without
needing to redeploy the EAR file. By default, a Message Logger mediation
primitive is part of any global transaction that you define and, by
default, an Event Emitter mediation primitive uses the default transaction
setting in the CEI emitter. The CEI Emitter is a library that provides
support for applications that report events.