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.