A post on the CEP blog, http://tibcoblogs.com/cep/2008/09/02/the-value-of-state/ , covered the value of state modeling in CEP. The post is reproduced below:
... sounds like a political comment about Big Government [*1], but in fact we mean to delve a little into UML (and TIBCO BusinessEvents‘) State Models and their value to Complex Event Processing.
Firstly, some CEP pundits might think that for low-latency applications, you won't have time for (or want to model) some inheritantly "long-lived" notion as "state". However, "complex events" are derived from other events and may usefully be modelled with a "state" - in TIBCO BusinessEvents any concept (c.f. UML class) can have a state, and concepts are used to represent "complex event" objects.
State models differ from conventional Activity Diagrams (or Business Process flows in BPMN [*2]) in that:
- the nodes in the state diagram represent an attribute (i.e. state) of the object being modeled: this is akin to an object property called "state" whose value is the name of the state node in the diagram;
vs: in an activity or process diagram, the nodes represent some task containing behavior or activity - the transition paths between states represent possible changes in stat, and are (usually) defined as state transition rules (conditions for the state change to take place);
vs: in an activity or process diagram, the links between tasks represent some task-specified movement to a new task
So what are the uses for "state" in CEP?
- Managing the lifecycle of entities.
This is the obvious role: concepts have a lifecycle that is important to the business service being automated, and this information is used to direct behavior (as well as being itself a Key Performance Indicator). State represents that lifecycle for "situation awareness".
Examples could be: - a network security system might define "system state" as one of {offline, no threats detected, threats detected, compromised}.
- an anti-money laundering system might define "transaction state" as one of {received, compliance-checked, completed}.
- Representing a control flow.
This is where the state of an entity represents a stage in its "processing cycle". This means that state can be used effectively in lieu of "ruleflow" mechanisms used in popular BREs [*3]. Examples could be: - a network security system might define a sequence of decision steps, executed by decision tables, for a sequence that includes {scoreThreat, determineSecurityAction, appraiseRegulatoryCompliance}
- an anti-money laundering system might define a sequence of decision steps for a sequence that includes {appraiseIdentity, priceActions, appraiseRegulatoryCompliance}
- Case management. [*4]
When we are monitoring important "cases" for businesses, like orders, customer applications, renewals, etc, then state provides a convenient identifier for the "track and trace" of the case.
So State Models can play an important role in modeling CEP (and its related business processes). They can also be used very flexibly (be inherited, run concurrently, have timeouts, and so forth). Very useful for the UML modeler as well as the business process modeler and CEP modeler!
Notes:
[1] ...which is about as political as we get on this blog in the run up to the 2008 US Election!
[2] BPMN (as used in TIBCO iProcess for BPM and workflow) and its equivalents for SOA (as in TIBCO ActiveMatrix BusinessWorks) are orchestration diagrams that make configuring processes and services very straightforward. As such they are really Business Analyst diagrams or developer aids, operating for example at the business-level end of the Model Driven Architecture. State Models can define their behaviors during state transitions, such as state entry or exit.
[3] Typical ruleflow constructs are loops, branches, etc - in other words, most ruleflows are equivalent to process diagrams (a.k.a. BPMN). Except few if any use BPMN. Not only can these constructs be replicated in state models, but the state transitions themselves are rules, and multiple such "flows" can be active (for different concepts) at the same time...
[4] This is really a subtype of Type 1, Entity Lifecycles, but is interesting enough to stand on its own...
