Sunday, September 28, 2008

On the scope of event processing as a discipline again


Back home... short work week due to the Jewish New Year holiday (tomorrow is the holiday eve).
One of the topics that were not discussed in the EPTS meeting is - "what is CEP?", an indeed EPTS is looking at "Event Processing" as a discipline, where "Complex Event Processing" - no matter how it is defined, is a subset of a larger whole. One of the discussion points is to define the scope of the "event processing" discipline (some people prefer to call it "event-based systems" but we are talking about the same thing), I have already written in this Blog about event processing as a discipline before, talking about some interesting subsets.

As one interesting source, let's look at the scope of DEBS 2009:

Event-based systems are rapidly gaining importance in many application domains ranging from real time monitoring systems in production, logistics and networking to complex event processing in finance and security. The event based paradigm has gathered momentum as witnessed by current efforts in areas including publish/subscribe systems, event-driven architectures, complex event processing, business process management and modelling, Grid computing, Web services notifications, information dissemination, event stream processing, and message-oriented middleware. The various communities dealing with event based systems have made progress in different aspects of the problem. The DEBS conference attempts to bring together researchers and practitioners active in the various sub communities to share their views and reach a common understanding.
The scope of the conference covers all topics relevant to event-based computing ranging from those discussed in related disciplines (e.g., coordination, software engineering, peer-to-peer systems, Grid computing, and streaming databases), over domain-specific topics of event-based computing (e.g., workflow management systems, mobile computing, pervasive and ubiquitous computing, sensor networks, user interfaces, component integration, Web services, and embedded systems), to enterprise related topics (e.g., complex event detection, enterprise application integration, real time enterprises, and Web services notifications).
While this is not a definition that I have phrased, it shows that the discipline is diverse, and has touch points with some other disciplines (software engineering, databases, sensor networks, embedded systems etc...). It is also interesting to note that the applications presented in the EPTS use cases group were also diversified: we have seen applications from - Finance and Defense (not surprising), but also from - Media and Entertainment, Chemical and Petroleum, Telco and emergency management.
The event processing discipline crosses several aspects - modeling, architectures, languages, engineering aspects, performance and optimization, user interfaces, intelligent components, and domain-specific additions - again, all of these in the context of creating specific platforms and tools for building event processing applications. In the next few postings I'll return to some micro-level issues I have faced in the last few weeks.
Happy New Year.

1 comment:

harvey said...

Opher,

Thanks for bringing us back to our "roots" :-)

-- I will offer that EP is a discipline which is focused on event relationships between participants. Some of those participants (as in CEP) may be able to recognize "situations" which may further stimulate event relationships.

As such, EP is less concerned with building "systems" or "services", and more concerned with the proper relationships between participating systems, services, and people.

In fact, we may consider an EP effort as possibly delivering a coherent "capability" which is delivered to the enterprise, as opposed to delivered to any participating organization.

Thus part of the "EP discipline" is the art of coordinating multiple activities (RFPs and contracts for US federal gov't). This requires the ability to specify EP relationships between participants without being solution specific. This "EP architecture" can then be used as a coordinative element between contracts.

-- Regarding EPTS, I regret not being able to attend. I look forward to the next conference!

Take care