Tim Bass
Mon, 02 Jun 2008 08:43:56 +0000
In reply to Paul Vincent’s*post
Is CEP a Service or a Process?*I posted
Is CEP a Service or a Process? Reloaded.* This post is a follow-up to my dialog with Paul and the CEP community, as a whole.
Some of the more remarkable critical comments on the book “The Power of Events” was that the book did not (for the most part)*discuss architecture.*
As we all know, there are many definitions of “architecture;” however, one definition*that is easy to discuss, in this context, is that an IT systems*”architecture” represents the components of*an IT*system*and the relationships between the various*components in the architecture.*
An architecture can be “technical” or “functional” or “operational” or*”data” centric.* For example, an architecture can be based on an orchestration of*service-components, like an SOA.* In another example, an architecture can be represented by the semantics of the data.* In yet another example, an architecture can be represented by the functionality of the components.
Because David’s book on CEP did not address architecture, folks have been free to use any “tool” or “technique” they like, and call it “CEP”.** My focus has been on overall CEP functionality and reference architectures that depict this functionality for solving CEP classes of problems.
This was one of the first topics (issues)*with CEP*we identified a few years ago; and*is why we, including*me at*my*good ole’ days at TIBCO until now, created a functional reference architecture for CEP (also in this blog and the TIBCO CEP blog).
In that functional reference architecture, we discussed*and illustrated*how CEP should operate as a cooperative (distributed) functional reference architecture to solve most “real” CEP classes of problems.
Therefore, *CEP should not be, generally speaking, considered*as a “process” or a “service”,* per se,**because*CEP, as a*functional reference architecture, depicts the methodologies (functionaility) required to solve complex detection-oriented problems.* This abstract permits CEP to have meaning in a broad context of event processing applications.
Naturally, a functional reference architecture can be viewed as a “service” if all the components in the architecture cooperate to solve a problem and are encapsulated as a service.* In addition, a functional reference architecture can be viewed as a “process” when solving problems in a specific domain.* So, a “process,” in this case, is an instance of the functional reference architecture; and if the instance is packaged as a solution, this solution can be encapsulated as a service.
So, it is misleading, at least in my opinion,*to reduce CEP to a “process” or a “service” unless we are discussing a particular solution to a domain problem within a (functional) reference architecture (functional context).
This confusion also*manifests itself in the
lively debate between Mark Palmer and the blogosphere regarding the maturity of CEP.** Mark and others have created an instance of event processing in capital markets and call it “CEP,” when in fact, what they are doing is COTS algo trading and using one or more functional components of CEP to realize their solution.
The is an important distinction, in my opinion.
Source...
06-02-2008
