Is CEP a Service or a Process?
Posted by Paul Vincent
Followers of TIBCO will know that we divide the software world into 3 interoperating software stacks: BPM (iProcess and its associated components), SOA (covering ActiveMatrix service management, BusinessWorks orchestration, Adapters, and ESB / middleware like EMS and RV), and Business Optimization (pretty much everything else). So Business Optimization [*1] includes:
- visualization services, such as General Interface (AJAX) and PortalBuilder, for sophisticated user interfaces that enable businesses to interact better with their systems - optimizing the user experience
- business intelligence services, such as Spotfire, for analyzing and understanding data relationships in order to make better decisions (and, of course, identifying decisions to be automated in decision services, etc) - optimizing awareness via viewing data patterns
- complex event processing services (or agents), namely BusinessEvents, providing (distributed) event pattern identification, state modeling, business and decision rules, backed up by a high performance (distributed) cache - optimizing the responsiveness to business events
- master data management services, via Collaborative Information Manager, for controlling the critical data used in other services and processes - optimizing the management of master data.
One frequent (theoretical) question is: is CEP, as provided by tools like BusinessEvents, a process that is comparable to iProcess and BPM, or a service that really represents an EDA flavor in something like the Active Matrix stack? Lets look at the evidence for and against:
The case for SOA:
- BusinessEvents can deploy under ActiveMatrix BusinessWorks, either as a conventional EDA CEP component being fed events (asynchronously) under the control of BW, or as a decision service (common-or-garden rule engine) for complex (synchronous) declarative business rules.
- BusinessEvents provides an event processing service in composite applications - events are processed and returned as “high level information” events for other services to utilize as required, either synchronously or asynchronously (or, er, both).
- Event-driven business rules (can) provide the business logic for many services.
- Event processing is intrinsically a service to a variety of applications and processes in an IT system [maybe this is the same as 2, except the owner may be a business process rather than an IT service].
The case for BPM:
- Complex event processing is just a different, non-workflow, continuous type of event processing that is simply an extension (conceptually) of the simple BPMN-driven event processing in normal business processes.
- Business processes involve processing business events - although BPM is traditionally associated with a control flow that is “handling” some event, there is no reason why a business process cannot be doing continuous, complex, event processing (although this may be modeled differently e.g. via a state model and rules). [Maybe this is the same as 1]
- CEP processes could be “managed” just as other processes are: controlled releases, simulation of performance, multiple roles / actors involved in handling the event(s),
deployment to BPEL, … - Event processing is intrinsically a process carried out for a business, either generating events for other processes or consuming events generated from other processes (or both).
The conclusion? Perhaps the classification of CEP depends on the particular CEP application: it could be a business process OR an IT service OR both. More likely the latter, although if you view business processes as *just* those that carried out by (or capable of being carried out by) human workers, then clearly CEP won’t often apply; likewise, if you view SOA services as just synchronous services, then CEP won’t apply there either. For sure, BusinessEvents is used alongside both the TIBCO SOA and BPM stacks (and other vendors, of course), with no ill effect on either!
Notes:
[1] Of course, there is also “true optimization” as well as “approximate optimization”, such as using constraint logic techniques. These techniques / algorithms complement distributed CEP tools like BE, providing capabilities such as dynamic optimizer selection based on prevailing events and current business rules…
3 Comments
Other Links to this Post
-
Is CEP a Service or a Process? Reloaded « The Complex Event Processing Blog — May 30, 2008 @ 06:29
-
More on CEP: Process, Service or Reference Architecture? « The Complex Event Processing Blog — June 2, 2008 @ 00:44
RSS feed for comments on this post. TrackBack URI
By vincent, May 31, 2008 @ 00:39
Tim makes an interesting point (”CEP is a concept architecture”) in his reply. I would probably suggest the equivalent architectural pattern to SOA and BPM is EDA rather than CEP; anything (e.g. distributed processing, SOA etc) can have a reference architecture (i.e. architecture is orthogonal to the concepts of process or service); and that the reference tome The Power Of Events [Luckham, 2002] describes CEP as “a defined set of tools and techniques” rather than an architecture per se.