Event Delivery Network (EDN) - A practical example

What I hope to do in this article is to demonstrate how easy EDN is to use and where I believe its advantages lie.

Let's begin by describing a trivial (and highly contrived) Business Process (BP) for a particular message. We will make the BP requirements slightly more complex later in order to demonstrate the flexibility that EDN offers.

Our message needs to be defined in terms of its structure and we do this in the traditional way with an XML Schema Definition that you can find here

Our  BP will validate the message with respect to its Country element. If the Country is "US" the message will be processed in one way. If Country is "UK" it will be processed differently. If it is neither of these values, then it will be processed as invalid.

This is trivial in the extreme. However, as an experienced developer, you will know that simple things often grow and become more complex over time. So, rather than writing something that is going to be immutable, we'll build in flexibility, modularity and extensibility.

Consider this SOA Composite design that fits the business requirements as stated above:-

Without going "under the covers" of the BPEL and Mediator processes, those readers unfamiliar with EDN will notice a distinct lack of "connections" between bpValidatePerson, Mediator and bpInvalidPerson. That is because EDN facilitates decoupling in a very straightforward way. What you will notice is that some components indicate in their graphical representations in the JDeveloper Composite Editor that they Publish or Subscribe to certain events.

This pattern allows us to describe the functionality of a Mediator or BPEL process in very simple terms. Let's take bpValidatePerson for example. Its job is to validate the message and it will either publish a ValidPerson event or an InvalidPerson event depending on the business rules that it implements. And that is all it does - a fundamental aspect of modular development. What's important here is that this BPEL process has no "knowledge" of how valid and invalid messages are handled because it does not need to know. In fact, it is possible to publish events that are not subscribed to by any component. Such events will simply be discarded at runtime (particularly useful during early development).

In the Composite that we have so far we see two event subscribers. The Mediator will receive and process a ValidPerson event and bpInvalidPerson will receive and process an InvalidPerson event. Coding of the Mediator is simplified because it can assume that the message it receives is valid - i.e. it doesn't need to "hand off" anything that doesn't fit its routing rules to, for example, a DLQ.

Now we need to extend the Composite. We'd prefer not to break it and we'd like it to remain modular. But someone's asked for a change. Or, at least, an addition. What's needed now is to audit all messages received whether they are valid or invalid. A traditional approach might be to modify bpValidatePerson and introduce, for example, a Database Adaptor through which we dump the message to a table. And that's fine except that it breaks the paradigm. We've said that this BPEL process has just one job - validation. And we'd rather not interfere with the simplicity of our original design. So what can we do? Here's the answer:-

We simply add a new BPEL process that subscribes to both ValidPerson and InvalidPerson events!

Thus we have been able to introduce additional functionality to our Composite without modifying any of its constituent parts and we have further ensured fully decoupled / modular design methodology remains in tact.


Nice explanation..

Posted by guest on January 12, 2012 at 07:02 PM PST #

Hi Andy,

We have a typical requirement in our implementation. We are currently upgrading all our SOA 10g Projectes in to SOA 11g. In our ESB projects we had a AQ/MQ adapter --> a Routing Service --> and a SOAP Service. when we migrated this project,all the above three component have become a part of a single composite. But unlike 10g where we were able to enable/disable a single component (like AQ/MQ adapter in our case), SOA 11g allows us to stop / retire the whole composite which results in the failure of in-flight transactions (we have tried both stop and retire functionality).

As a work around, I have introduced the EDN approach with one composite having the AQ/MQ adapter and a Mediator for publishing the event. and another Composite for subscribing the same event. Though this approach resolved our requirement but, if the subscribing Composite is down for some reason, we dont see the Business Events waiting in the EDN_EVENT_QUEUE table. After reading the documentation I found that EDN does not support the durable subscriptions. Because of this we are hesitant to go with this approach.

Please suggest if you have any alternative / change in configurations of the AQ to make it durable. We wanted the EDN AQ should retain the message till the subscribers are available and picked up.

Your suggestion would really help us proceed further in our upgrade.

Thanks in advance,
Prakash Singh.

Posted by Prakash Singh on May 03, 2012 at 10:29 PM PDT #

Hi Prakash,

You might want to go through the link below.
and Select a level of delivery consistency for the event.


Select a level of delivery consistency for the event.

· one and only one

Events are delivered to the subscriber in its own global (that is, JTA) transaction. Any changes made by the subscriber within that transaction are committed after the event processing is complete. If the subscriber fails, the transaction is rolled back. Failed events are retried a configured number of times.

· guaranteed

Events are delivered to the subscriber asynchronously without a global transaction. The subscriber can choose to create its own local transaction for processing, but it is committed independently of the rest of the event processing. The event is guaranteed to be handed to the subscriber, but because there is no global transaction, there is a possibility that a system failure can cause an event to be delivered more than once. If the subscriber throws an exception (or fails in any way), the exception is logged, but the event is not resent.

· immediate

Events are delivered to the subscriber in the same global transaction and same thread as the publisher. The publish call does not return until all immediate subscribers have completed processing. If any subscribers throw an exception, no additional subscribers are invoked and an exception is thrown to the publisher. The transaction is rolled back in case of any error during immediate processing.

Posted by Nitin Aggarwal on May 24, 2012 at 04:54 AM PDT #

Hi Nitin,

Thanks a lot for your response. I was under the impression that my request will be unheard. But you proved me wrong.

As the management was hesitant to go with this approach, we had opened an SR with Oracle to fine-tune the retire functionality.

But I will still explore EDN and comeback to you very soon.

Thanks a lot again,
Prakash Singh.

Posted by Prakash Singh on January 29, 2013 at 09:46 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

This is the blog for the Oracle FMW Architects team fondly known as the A-Team. The A-Team is the central, technical, outbound team as part of the FMW Development organization working with Oracle's largest and most important customers. We support Oracle Sales, Consulting and Support when deep technical and architectural help is needed from Oracle Development.
Primarily this blog is tailored for SOA issues (BPEL, OSB, BPM, Adapters, CEP, B2B, JCAP)that are encountered by our team. Expect real solutions to customer problems, encountered during customer engagements.
We will highlight best practices, workarounds, architectural discussions, and discuss topics that are relevant in the SOA technical space today.


« July 2016