Why ESBs are Made for Event-Driven Architecture

Recently I posted an article on how EDA extends SOA and why it is important. I am very pleased this article is gaining popularity in the SOA/EDA community. The posting is also available as a downloadable PDF, which I frequently extend with additional content.

But what I like most is that Dave Chappell of Progress Software (the inventor of the ESB) contributed a two-part article to eBizQ where he explains the most important role of an ESB to implement the ideas I defined in my article. Thank you Dave... Maybe these pictures can help you evangelizing the concept; feel free to use them as you wish.

Some interesting quotes from Dave's article:

• "...the real sweet spot where an ESB has shown its power and flexibility is in process-oriented, event driven architectures."




• "...the key to success is to have an architecture that allows for each application to be decoupled from the rest of the SOA by using the ESB as a form of mediation."




• "...the event-driven interaction style is a major advantage of keeping applications decoupled from one another."




• "...the applications themselves often need to be written or adapted to this event driven style of interaction."




• "The course of action taken when a complex pattern of events is identified may vary, but can range from alerting a business user in a Business Activity Monitoring (BAM) dashboard or to invoke a service or a business process via the ESB."




• "Event-driven architectures are beginning to emerge as the best approach toward implementing a SOA where applications are truly decoupled from each other. Large scale SOA projects using an ESB are broadening the reach of application integration in ways that were never before possible.




• "...these technologies can all generally be used both standalone and pluggable into anything using Web services interfaces..."

SOA and LEGO, do you dare to compare?

SOA is about flexibility, which means the ability to be changed after being built.

Many people compare SOA building blocks (services) with LEGO blocks when evangelizing the concept to the nitwits. See Google, or this blog of Joe McKendrick. Or this one of Jason Bloomberg.

Well, let's try out the analogy. First start building a nice fortress with LEGO blocks. Then after you finished it, just change one little LEGO block somewhere in the middle of the wall. You won't be very happy, I suppose. Not to mention creating a new window or a door. And, o my dear, make the cellar a few feet deeper.

LEGO constructs are easy to be built, but a nightmare to be changed and so have nothing to do with flexibility.

Business people never seem to understand the IT-folks; I know why... do you?