Event-driven architecture

, , ,
1

I was researching the origin and definition of event-driven architecture (EDA) and came across an article titled The age of events from the InformationAge web site.

According to the article, EDA is yet another TLA from our friends at Gartner, introduced in 2003. Overall, the article struck me as odd. Indeed, the entire notion that EDA is new seems odd to me.

“In recent years, several major developments have made event processing both a viable technology and a strategically important approach in IT…the underlying infrastructure is now available to deliver asynchronous event information – perhaps using some kind of enterprise service bus – in large volumes, in near real time.”

In recent years? One could argue that this stuff has been around for at least a decade. Vitria, TIBCO, ActiveWorks and others introduced the enabling technologies over 10 years ago.

To be fair, complex event processing (CEP) is relatively newer. But still, EDA isn’t just about CEP. Simple event processing falls under the EDA banner too, and that’s been around for a long time.

“Analysts say there is much more work to be done – not least in opening up applications so that they communicate event information better; and in building resilient, scalable systems.”

This statement is reminiscent of statements I remember seeing back in the late 90s. Vivek Ranadive captured this notion in his book “The Power of Now”–back in 1999.

“But as more and more information is communicated in real time, the EDA, even if it doesn’t eventually fly under that flag, will inevitably be widely adopted.”

EDA is at least the 2nd flag, possibly the 3rd. This leads me to wonder, do any of the adoption predictions come true? For example, did the prediction of the adoption of EAI come true? It seems that a prediction of “in 5 years XYZ technology will be mainstream” will ever come true because XYZ won’t be the hot buzzword in 5 years. Rather, it will be reborn under a new name, which will achieve mainstream adoption in yet another 5 years.

How would you characterize EDA? New? Old? Are you following EDA principles in various projects? For integration? For application development? Are you following EDA and SOA principles in your projects or just SOA?

2

I think the term “EDA” was coined to highlight a shortcoming of 1st generation web services which were mostly synchronous request-reply interactions between service provider and service consumer. Those “services” had very little ability to implement publish-subscribe, broadcast of notifications and other functionality that is characteristic of event-driven architecture.

Of course this functionality is extremely useful in many integration and software development scenarios so even though web services over SOAP were all the rage, not having a place for event-driven was a big limitation.

Standards bodies (no doubt at the prompting of traditional EAI vendors) quickly began work on things like WS-Eventing, WS-Resource Framework and WS-Notification and their underlying components. While these are much further along than before, I have still not see wide-spread adoption among my clients.

As recently as 6 months ago, the webMethods Broker team was still trying to decide if implementing WS-Eventing and WS-Notification made sense given the low industry adoption rates.

Having just built a web services-based notification capability to inform service consumers about business events of interest, I can say that doing so was very feasible without use of a WS-* standard, but I’m sure we reinvented the wheel in some areas. That said, I found the WS-* specs in this area to be pretty “heavy” and more complicated than what the project requirements called for. Still, there would have been value in adopting the vocabulary set provided by these WS-* standards.

Event-driven functionality is a very useful tool for an enterprise to use where appropriate. SOA itself neither precludes nor requires EDA in and of itself, but my assertion is that enterprise-wide SOA must have event-driven components or it is not complete just as SOA must have a well-implemented integration backbone.

Baby-step SOA projects were often limited to web services layers slapped onto packaged or custom business applications and lacked many things such as governance, policy enforcement, security / identity management and event-driven capabilities. If EDA was coined to highlight this limitation then it was useful, but it is hardly a “new thing”.

Mark