To understand how event sequencing works, consider a situation
in which a source application (Component A) asynchronously invokes a target
application (Component B) to create new orders, and then updates those orders
with revised data.
Component A looks up Component B and invokes the create method to create
an order, using the Order business object. The Order business object has the
following attributes:
Attribute |
Type |
ID |
string |
customer |
string |
productName |
string |
quantity |
integer |
Component A then calls the update method to update the data in the
newly created order.
In this example, assume there are five separate events that have been sent
from Component A to Component B in the order specified below:
- Create1 – This invocation calls the create method and passes the Order
business object with an ID of 1 and quantity of 10.
- Create2 – This invocation calls the create method and passes the Order
business object with an ID of 2 and a quantity of 8.
- Update1 – This invocation calls the update method and passes the Order
business object with an ID of 1 and a quantity of 15.
- Update2 - The third invocation calls the update method and passes the
Order business object with an ID of 1 and a quantity of 12.
- Update3 – This invocation calls the update method and passes the Order
business object with an ID of 2 and a quantity of 10.
For each event, a message is put onto a service integration bus destination
in the same order as the invocations. A Message Driven Bean (MDB) reads the
message and sends it to the target component (in this case, Component B) for
processing. Although there is only one MDB per module, there are multiple
instances of that MDB and these five messages are processed in parallel. It
is possible that the MDB thread that is processing the message for Update2
will complete before the thread that is processing the message for the Create1
event; if this happens, the Update2 event will fail because the order has
not yet been created.
To prevent these sorts of errors, this example implements event sequencing.
In the sample component definition below, event sequencing qualifiers are
specified for both the create and update methods. Both of these methods use
the same event sequencing key (set to the ID attribute of the Order business
object) and are placed into the same event sequencing group. The third method,
retrieve, is not sequenced.
<interfaces>
<interface xsi:type="wsdl:WSDLPortType" portType="ns1:ProcessOrder">
<method name="create">
<scdl:interfaceQualifier xsi:type="es.EventSequencingQualifier">
<es:eventSequencing sequencingGroup="default" conintueOnError="true">
<keySpecification>
<parameter name="Order">
<xpath>ID</xpath>
</parameter>
</keySpecification>
</es:eventSequencing>
</scdl:interfaceQualifier>
</method>
<method name="update"/>
<scdl:interfaceQualifier xsi:type="es:EventSequencingQualifier">
<es.eventSequencing sequencingGroup="default' continueOnError="true">
<keySpecification>
<parameter name="Order">
<xpath>ID</xpath>
</parameter>
</keySpecification>
</es:eventSequencing>
</scdl:interfaceQualifier>
<method name="retrieve/">
</interface>
</interfaces>
With event sequencing enabled, the five events in this example are processed
as follows:
- Component A sends the Create1 request. It is placed on the destination
and handled by an instance of the MDB.
- The Create1 event acquires a lock and is sent to Component B for processing.
- Component A sends the Update1 request. It is placed on the destination
and handled by an instance of the MDB.
- The Update1 event tries to acquire a lock. If the Create1 event (which
shares the same event sequencing key value as Update1) still has the lock,
processing for this event is suspended until the lock on Create1 is released.
- Component A sends the Create2 request. It is placed on the destination
and handled by an instance of the MDB.
- The Create2 request (which has a different value for the event sequencing
key) acquires a lock and is sent to Component B for processing.
- Component A sends the Update2 request. It is placed on the destination
and handled by an instance of the MDB.
- The Update2 event tries to acquire a lock. If either the Create1 or Update1
event (which share the same event sequencing key value as Update2) still holds
a lock, processing for this event is suspended. It will not be processed until
the Update1 event has acquired the lock, been processed, and the lock has
been released.
- Component A sends the Update3 request. If the Create2 event (which shares
the same event sequencing key value as Update3) still has the lock, processing
for this event is suspended until the lock on Create2 is released.
Last updated: Wed 06 Dec 2006 07:08:08
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)