Event driven composites

One of the new features in SOA 11g is the event driven notifications. As the documentation describes it is not about messaging but sending events to the SOA 11g Server. Within a composite (SCA) you are able to define events. These events are described in a name and the payload. The payload is based on a message structure (XSD).

To use this event, the composite to subscribe to this event or use this event for publishing. Using this event can be defined in the mediator.
The mediator can me subsribed to this event or publish an event.

Thinking more in this event behaviour, what is the purpose? Before the 11g release we act on 'events' via queues (AQ / JMS) or via database (Polling) of file system. So why should we use it? This question I was asking myself.... and I found the answer. Apart of the event definition language (EDL) , standardization etc, there is a good reason to use this mechanism by default in your SCA applications.

Think about the next 'old' business flow, simplified. In this example 2 systems deliver data to the application. This data is handled in the BPEL process in chich the data is enriched, checked and transformed to a canonical data format. Then the message is put on the message bus and routed further.

If we need to add an new system, for example system C , we need to create a new BPEL process or service and add a routing rule in the message to handle this message.

With event driven architecture, we can make service independent of each other, guaranteed delivered and are decoupled. But the biggest advantage is that we are able to add composites that need to be handled without touching the other composite.

This is the EventProvider, simplied, it accepts a message that message is passed as an event to SOA 11g Server.

System A

System B

This is the EventHandler, it is subscribed to an event, then the payload is extracted and send to the files adpater (example).

If we need to add another composite, we do not need to add an routing rule, we just add the composite, transform the message and send this event to the SOA 11g Server. There is no direct routing between the EventProvider and the EventHandler! It is decoupled!

An example of this code can be downloaded here.

So how does it works? The provider composites and the event-handler composite must have an identical event definition. These definitions must be the same;

• Even definition name
• Event name
• Event message

Then in the provider composites publish this event via the mediator, while the event-handler composite is subscribed to this event.

Note: If different composite are subscribed to the same event, all this composites will be triggered and an composite instance is created.