You have distributed applications (from different vendors running on variety of platforms) integrated with middleware infrastructure. Applications interact with each other in a traditional/synchronous way by sending messages over the Enterprise Service Bus (ESB)/Broker to get the job done.

Infrastructure Problem

The synchronous infrastructure is causing delays leading to unproductive wait times and dissatisfaction from the users. There is a need for applications to propagate information (state changes and interesting events) to other interested applications asynchronously without knowing the details about their identity.

Driving Forces

The following are driving forces behind the Enterprise Event Bus (EEB).

• Applications (Publish-subscribe) can be dynamically added/removed from the EEB
• Applications should be able to publish various Events
• Applications should be able to consume various Events for which it is interested, and should not receive other events
• EEB should support the following:
  • Store and Forward
  • Throttling
  • Translation
  • Filtering
  • Push and Pull
  • Various Protocols
  • Governance and Monitoring

Middleware Solution

Enhance the existing middleware infrastructure to allow registering/deregistering of publisher/subscriber. Devise a mechanism to send the event (notification) to intended listeners with the help of topics. One of the two WS-* specifications (WS-Notification: Spearheaded by IBM, WS-Eventing: Spearheaded by Microsoft) may be considered while implementing the approach. In this expample we will use JBoss Fuse Services to implement this approach.

Architecture

Design is pretty simple as we have a set of components (services and processes) to provide functionality, exposed over various bindings, data store (relational and column oriented) of the configuration and eventing data, and a mechanism (in this case Apache Camel) to route/translate events.

Level 0

Level 1

Level 2

Here is the ER diagram to start with. With this setup, store and forward can be implemented easily.

Why JBoss Fuse Service Works

• Exposing any end point (SOAP, REST, JMS, AMQP, etc.) is just a matter of few clicks
• Monitoring and Governance support
• Built in support to integrate with BPMN, Drools and Camel
• Can be deployed to OSGi as well as the server
• Java EE support
• I wanted to try something different :)

Enterprise Event Bus Example

A mini EEB using JBoss Fuse Service works for demonstration purposes can be cloned from GitHub. Instructions to get it up and running is provided in the README.md file.
 
Here is the switchyard diagram for the Notification feature. It hardly took me any time to implement this feature and can be extended further to provide other features easily. 

Resulting Context

When considering this approach, the following benefits and liabilities should be evaluated. 

Benefits

•    Supports the business demands for better service
•    Highly decoupled applications with a more flexible and agile structure
•    Highly secured

Liabilities

•    Increased maintenance
•    Decreased performance

Conclusion

An Enterprise Event Bus can help enterprise build highly decoupled, flexible, secured and event driven applications.

References

•    Enterprise Event Bus with Fuse Service Works
•    IBM's Article on WS-Notification
•    Thomas Erl on Notification and Eventing
•    Oracle on Event Driven SOA
•    JBoss on WS-Notification
•    Javaworld's Article on Event Driven SOA
•    Pub-Sub with WSO2
•    Event-Driven Architecture: How SOA Enables the Real-Time Enterprise
•    Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing, 4th Volume
•    Microsoft's Integration Pattern Blog
•    Pattern-Oriented Software Architecture For Dummies
•    Do More with SOA Integration: Best of Packt
•    WS-Notification implementation using CXF and ActiveMQ