event dispatcher
Today, I had the most perculiar experience. I talked to some academics about ESB technology and despite their reputation, these guys (and galls:-) had a pretty pragmatic and practical approach. I have mentioned this article about business events before. http://docs.jboss.com/jbpm/IEEE-BusinessEventDispatcher.pdf But today, they came and explained it in more depth. Here's my summary.
In short, they have shown the motivation for a business event dispatcher component on the ESB. It has learned me how a simple piece of infrastructure was able to give structured approach to integration development.
A business event dispatcher is a component that could be associated with an ESB just like a BPEL engine. It has a vocabulary of events that can take place. Then components can subscribe to be notified of these events. The dispatcher will be responsible for notifying the interested components. Notification can be done in different schemes: E.g. dispatcher notifies component A, which in its turn notifies component B, ... Or another scheme can be that the event dispatcher itself contacts all the registered components. These schemes can be predefined patterns or custom pieces of logic. The nice thing about this approach is that it provides a very natural separation between the lower level notification and the overall orchestration of the business events.
The event dispatcher can also manage the contextual data related to business events.
I also liked the development model that was given as background information with this component.
Integration development process
1) First, the business event vocabulary is established
2) Second, the business event orchestration is worked out
3) Third, the notification schemes are worked out
* The way that BPEL is perceived/used today, it combines business event orchestration with event notification, resulting in complex processes. Separating these concerns results into better scoping capabilities. The event dispatching approach is most appropriate if you have many systems that need to be kept in sync. That is when you will prevent cluttered BPEL processes by separating the overall business event logic from the way that components are notified of business events.
* Keeps the focus on the integration. Mixing a business process modelling aspects with integration might result in a blurry context. I like very much like how the start from business events keeps the focus to the integration scope.
Also the focus on the business events give a very nice basis for integration of data. The business events could be enriched with data items that comes from XML documents, database tables, java objects, ... So the underlying framework could take the sources and destination into account. A business event could be graphically shown against a W3C Schema, DB Table, java bean, ... You know those tools where you draw lines between left and right. All these different type systems could be remembered to take into account any mismatches or conversions that need to take place. Also this gives good traceability in case you want to change your central companywide business event data schema.
I think that a runtime component that manages the companywide repository of business events with their associated data is very useful.
Were there any other discussions or lines of thinking in that direction ?
Would you guys think it is interesting to pursue such a component/development cycle on top of the ESB ?
