One trend to watch in 2008 will be to see how SOA shapes up in the real world. With the din dying down, now guess enterprises will review their SOA strategies and skim the froth to look for where it really makes sense. Too much has been said on what exactly is SOA, why is it ir is-not ESB, is BPM same as SOA or is it part of SOA, simple p2p web services or a more sophisticated services infrastructure, message based or http based, do we need hardware web-services protocol handlers/policy enforcement/XML accelerators, or just sofwtareshould do. And lot more.
One interesting development is that with SOA getting more accepted in enterprise solutions design now, and ESB slowly gaining in traction as a preferred services infrastructure, slowly there is a message based enterprise integration happening. This bring forth the hiterto esoteric Event Stream processing (ESP) and Complex Event Processing (CEP) into the fore now. In the SOA context. Enabling more widespread use of CEP for business solutions.
This trend is encapsulated in the emerging Event driven architecture (EDA) in the SOA context. Sometimes referred to as ED-SOA. In Complex Event Processing and SOA: a ‘beautiful thing’?, Joe McKendrick talks about the possibility of SOA, EDA and CEP converging in 2008. Really, not an improbably possibility at all!
Now, even as there is widespread concurrence that SOA brings in the possibility of EDA being used for more mainstream biz usecases, there is a lot of debate on exactly how EDA will blend in with SOA. Ranging from EDA being the 'new SOA', to EDA 'succeeding' SOA, to EDA 'extending' SOA, to undiluted skepticism of any relationship at all!
As I see it, with message based ESBs gettinginto the mainstream, there is already a clear acceptance of discreet-messages based services infrastructure. Now teh SOA infratsructure is more a core (and generic use) system than the so far typical CEP usecases. With messages in the core infra, the notionof using the very loose-coupled nature of messages is already in place. This is a fundamental buildingblock for EDA- as 'events' are much like the messages in a message based infrastructure (like ESB). Albeit, the events in an EDA may be much much higher in number than the typical service requests in an SOA usecase. Like say, consider the events being a stock market price change or even worse, say an RFID scan. However, these can easily be integrated with messagingbackbones (already in use in many CEP engines, like say Progress software's Apama). Some of these are also ,a href="http://www.progress.com/psm/sonic/event-driven-soa/index.ssp">integrated with SOA infra like Sonic ESB.
Yet another emerging synergy between CEP and SOA is the usage in BAMs. So far, SOA was considered tehprimary backbone for BAM. Now CEP engines also are positioned for the same. So, a question of time before they get more tightly integrated.
The simplest integration of CEP into SOA infrastructure will be to aquire a CEP engine and have it setup as a service in the SOA infrastructure. The events are sent in the infrastructure (conceivably as XML files?), and the CEP engine processes them and identifies the complex events, and when a CE handling defined, will invoke the required event hanler. IN effect the CEP's internal processing, CE detection and CE handling is completely hidden from the SOA infrastructure. The SOA infra ONLY understands the simple-events that were 'sent' to the CEP service.
Now, given that the events can be very many and this will result in a much smaller number of actual Complex-Events, the CE engine is probably better placed "inside" the services bus, as an intermediary service.
In all, surely a space to watch. Am personally more inetrested in seeing how the events and messages get blended into one. And have the CEp processing and CE detection inside the bus as an ESB intermediary service rather than as a separate CEp engine that just triggers an SOA/ESB service or process as th4e CE handler (after detecting a CE's occurrence).
