I resisted the temptation to title this blog “Choosing between CEP, SOA and BPM“, even though those acronyms effectively describe where these products are targeted. And it is not such a silly question: I recently listened in on a conversation regarding “when to choose” TIBCO BusinessEvents (the distributed event processing platform – hereafter BE), in lieu of TIBCO ActiveMatrix BusinessWorks (the service integration tool – hereafter BW), or TIBCO iProcess (the BPM tool – hereafter … iProcess). Clearly all 3 of these tools can process “events” of one type or another, and exist to automate business processes…
Here is 1 attempt at a comparison:
| CEP tool: BusinessEvents |
SOA tool: BusinessWorks |
BPM tool: iProcess |
|
|---|---|---|---|
| Main behavior model | Production Rule | Orchestration | BPMN Orchestration |
| Event types | Any message | Any message | Workflow-oriented |
| Engine | Rule (+ state, query and decision) engine | Transformation and flow engine, BPE | Workflow engine |
| Default State Management | Stateful | Stateless Transactions | Stateful |
| Roles | High-Performance Complex Event Processing | Application Integration / Orchestration | Workflow Management and Control, Forms Processing |
| Notes | Continuous Event Processing; Decision Management | Integration via many pre-built adapters | For a BPM view of the entire stack, see BPM+ |
For automated processes and event-based services, one typically uses BW for services integration (or service-oriented systems) and BE for “more complex” scenarios. Typically BW provides links to multiple existing systems via pre-built adapters, whereas BE provides the stateful “complex event” view of the world. Both BE and BW can act as containers for application components, including each other, at runtime. Both can manipulate XML. Often they are used together when we use:
- BE as the container, delegating to BW for interfaces to existing systems / extracting data as required for event processing
- BW as the container, delegating to BE as an embedded rule engine for complex decisions in service integration applications
The main characteristic to be aware of in these tools is that BE is primarily rule-based (using an embedded rule engine), whereas BW and iProcess are orchestration / flow engines. In BE we can use a state diagram to indicate a sequence of states which may define what process / rules apply, but this is really just another way of specifying a particular type of rules (i.e. state transition rules).
The main advantages to specifying behavior as declarative rules are:
- Handling complex, event-driven behavior and choreography
- Iterative development, rule-by-rule
The main advantages of flow diagrams and BPMN-type models are:
- Ease of understanding (especially for simpler process routes)
- Process paths are pre-determined and therefore deemed guaranteeable.
In combination these tools provide many of the IT capabilities required in an organization. For example, a business automation task uses BW to consolidate information from multiple existing sources, with human business processes for tasks such as process exceptions managed by iProcess. BE is used to consolidate (complex) events from systems to provide business information, or feed into or drive both BW and iProcess, and also monitors end-to-end system and case performance.
[On a side note, the tool or technology is of course only part of the solution – the application of that tool or technology by appropriate specialists is also key.]
