Most organizations at this point in time have made up their minds about SOA, such as when and if they will eventually invest in it, and if so, what tools and vendors are the best fit for the job. Yet as the ever evolving technology sector should have it, many vendors in the SOA landscape are now churning a new concept out to existing SOA customers, that of event-driven architecture (EDA), a seemingly new term which has at best blurred lines with the more widely used SOA acronym. So up next we will take a look at what constitutes EDA and its relevance to the SOA market.
Let's start by exploring what is perhaps the most common thing that comes to mind when saying "event" in an enterprise software context -- to many it will bring up thoughts of either messaging middleware, asynchronous communication, publish/subscribe topics, JMS, MSMQ or whatever other technology can used to establish event notification. Nothing new there of course, so now let's switch gears to the Web services standards that cover similar scenarios, here you will likely come up with Web Services Eventing (WS-Eventing) by the W3C or Web Services Notification by OASIS, at first glance the use of these standards will likely spark the thought of the EDA/SOA marriage. After all, it's service-based architecture with event processing tossed into the mix, but this would in fact be wishful thinking.
An EDA is a much broader concept -- much like SOA itself is an approach -- one that has in fact been exploited for many years. If in times past you've heard of complex event processing (CEP) vendors, then you were in fact within the confines of an EDA, though you may not have realized it by this three letter acronym. Still for those not familiar with the concept, the premise behind CEP and EDA is to execute business logic upon the presence of certain system events, which can in fact originate from a wide range of mediums, including the aforementioned publish/subscribe middleware scenarios to more elaborate setups like event detection via RFID scanners or even something as mundane as an event occurring in a database.
In this sense, CEP vendors have carved out niche markets across several industries, especially in the financial and manufacturing sectors where event sensitive logic is vital, such as stock order triggers or fulfillment operations. But in confronting such problem areas, many a CEP vendor has had to develop ad-hoc approaches for extracting meaningful events from enterprise systems, creating a plethora of proprietary engines, adapters, query languages and, of course, their respective management, monitoring and editing tools.
All of this has led to a certain dichotomy between early SOA proponents, CEP vendors and the actual validity of EDA as some sort of SOA 2.0. From a CEP standpoint, one would be hard pressed to admit the technical justification of SOA or anything related to services in order to make CEP a reality, given that CEP has succeeded without much SOA influence as early as 2000 in production type environments.
But let's recap what makes CEP unique to the enterprise. The sell point to most CEP solutions is that they offer real time event processing, something which is in stark contrast to the static nature of most middleware event processing systems, which generally entail lag times, either related to retrieving archived events or simply determining courses of action for extremely elaborate event sequences. So with that said, now take a bird's eye view at the foundations being set by SOA: loosely coupled interfaces/services based on standards, accessible across enterprise tiers and platform agnostic sources. Case in point, simplified access to the majority of an organization's data with the potential to access events in much the same manner.
Though the need for CEP is still vital to only a handful of industries, it hasn't taken much for SOA vendors to figure out there is a business opportunity in leveraging the same infrastructure being laid out for SOA to fulfill CEP requirements, something which has led to terms like: Event-Driven SOA, EDA as SOA 2.0, including numerous engine and product announcements around this same paradigm. As far as the old guard in the CEP market is concerned -- the non-SOA camp if you will -- there is a certain reluctance in combining SOA, EDA and CEP in the same sentence, especially since most have done fine even before the great SOA frenzy.
The reality is that SOA has a much to gain from CEP, as does CEP from SOA. In its current state, most every SOA product line lacks the real time event processing capabilities present in niche CEP engines, on the other hand, most CEP engines possess fragmented techniques -- read vendor lock-in -- for executing real time event processing all of which could greatly benefit from already exposed SOA designs. Whether the term SOA 2.0 or EDA will be chastised by the media as "buzz" has yet to pan out, but what will definitely come to fruition sooner than later, is a reciprocal understanding between the prevalent SOA vendors and the offerings of niche CEP vendors, no matter what it's called.
About the Author
Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics.
