This week the BCS SPA group held a fascinating session titled “Modelling Choreography” by requirements analyst Ashley McNeile.

Ashley described some of the past efforts to model and implement choreographies, using types of process algebra such as  Robert Millner’s Calculus of Communicating Systems (CCS) and its derivative Pi-Calculus. However, Ashley used sequences of events and states (i.e. a state diagram) which he also compared to Michael Jackson’s formalised object lifecycles (e.g. JSD  / Jackson Diagrams). Various W3C efforts have described choreographies too - e.g. WS-CDL. Of course the latest modelling construct for choreography is BPMN2!

As an example of his practice, Ashley described an example - modelling bank account transactions via Protocol Modelling (using simple state diagrams):

• state model 1: defined the close and withdraw events on an active account
• state model 2: defined the freeze and release account events
• state model 3: this had no state transitions, but defined the state by the associated constraints (or business rules)
  • if balance < 0 then account state is overdrawn
  • one cannot close an account if it is overdrawn
• all 3 state models operate in parallel.

To analyse these state models they can be combined into a single state models (with all combinations of states, and all events), and then the unreachable states can be filtered out. The interesting thing here is (1) the analysis of state models for completeness and (2) the use of incomplete state diagrams as a business notation for textual (policy or constraint) business rules.

Other observations:

1. These types of business rule apply to states and data; they can be extracted and modified (by a developer, or state modeller) into event rules or guards in a state transition diagram. Is it interesting to specify these business rules up front before mapping to events and processes? Yes from a business perspective, as new events or states might affect or be affected by existing business rules.
2. Using a state to specify a business rule (in terms of the state and output) is an interesting notation that lends itself well to mapping to appropriate events (or indeed processes). Could it catch on in the business rule community?
3. The use of an explicit choreography language has not had  much success it seems. Google WS-CDL and most entries are dated 2009 or earlier. BPMN2’s choreography may yet prove useful but possibly the concepts are too difficult for business modellers yet imply a co-operative design process for developers that rarely occurs in practice (beyond “this is the interface”!).
4. At the end of the day, the sequence of events in a business system is just a complex event - which maybe can tell you if the choreography is valid or not.

I’ll add a link to the slides to help explain all the above when they become available…

Annex: a Distributed System Choreography Development Process:

This process describes a development process of state diagrams for choreography purposes:

1. Define participants and messages (/events) that interact between them
2. Define states with events as messages from and to, with only 1 sender per state
3. Project the states out to individual participants - i.e the parts of the state model for each participant - allowing ambiguous states but ensuring these have no sends
4. Merge the states for each participant
5. Enact - check each event at a time to prove feasibility of the interacting state models

One of the surprising (and for me, interesting) sessions at DEBS 2011 was the edBPM section - where event processing collides with business process management (or business processes, anyway). While much of the BPM world concentrates on workflow-oriented BPM (supported with automated services), there are several interesting areas (or extensions) such as “dynamic BPM” (any type of business process not explicitly pre-defined as an orchestrated process) or “case management” (handling cases with processes as well as plans and rules), through to “adaptive case management” (some superset of the two).

At DEBS, IBM’s Rick Hull presented on “Business Entities with Guard-Stage-Milestone Lifecycles: Managing Entity Interactions with Conditions and Events” (a good attempt at summarising the contents of the paper within the title!). This was directly related to the OMG Case Management standard submission mentioned last month… and amazingly well-aligned with TIBCO’s current deployments of the Advanced Fulfillment Framework (using CEP, BPM and decision management). The only main difference was that IBM had reworked the concept of state models (which is where guard-stage-milestone lifecycles - GSMLs? - come into play) to allow for things like more dynamic state transitions; in reality state models can be extended to handle such requirements but nonetheless UML could well benefit from some attention here.

On reflection, the IBM models presented at DEBS would make ideal extensions to BPMN. Most vendors are no doubt still digesting BPMN2; but do not be surprised if something like TIBCO AFF or IBM GSMLs get absorbed into a future BPMN (notation) standard!

This might seem an odd question, but there are 2 schools of thought here:

1. An event is a point in time.
   
2. An event is an activity that can take a period of time.

Taking the latter view, we can say things like:

• Earthquake MMM took place from date-time D1 to date-time D2
• Fraudulant act on account NNN took place from date-time D3 to date-time D4
• Flight QQ123 was delayed in the period date-time D3 to date-time D4, when it completed disembarkation time T1 late
• World War 2, an historical event, took place from 1 September 1939 to 2 September 1945.

The problem with this view is that activities, and therefore processes, can therefore be viewed as “events”, which in IT terms can lead to confusion and generalisation. And what about “historical events” like World War 2, which definitely have a duration. But in reality “world war” was a “state” the various nations affected found themselves entangled in - for sure it had a start event (invasion of Poland) and an end event (surrender of Japan), and many many events in between. And indeed many many “predictor events” (or even “causal events”) beforehand.

In event processing terms, we want to predict certain events - when will Earthquake MMM start, and with what strength? - as well as states - Flight QQ123 is now in a “delayed” state. In effect, in the real world, we are concerned not just with event patterns, but also state management and processing. Passengers might not care about the events that lead to their flight being delayed, but they may certainly care about being delayed!

The EPTS Glossary specifies events as points in time as “instantaneous events”. From the EPTS perspective, the 1929 Stock Market Crash was a complex event. At the time it was a “crashing state” for the Wall Street markets - within a period of instability, local rises interspersed with sharp falls. Top-to-bottom, the period covered Sept 1929 to July 1932, and an overall 89% decline in the Dow.

So perhaps History should be formalised, as a science, using event terminology?

I don’t normally have much to say on BPEL (as a language for orchestrated processes). A BPEL engine can be used to execute business processes and actions post-”complex event detection”, but at the end of the day its just a particular - albeit common and standards-based - technology for executing process orchestrations [*1].

On the other hand, state management of entities is particularly interesting for Complex Event Processing. In a nutshell, the state of some entity will often determine some event pattern detection, as well as the relevance of certain business decisions, operations / processes, and actions. CEP tools handle state, and some (like TIBCO BusinessEvents) actually allow developers to model state explicitly - usually for entity lifecycle management, including complex event pattern lifecycles…

It was therefore somewhat fascinating to find a new IBM initiative called BPEL4Data and an associated Business Entity Definition Language (BEDL) comprising of entities and state models (and indeed, almost MDM-like data management operations) [*2].

One trick I think the IBM team have missed is in tying themselves to (another reinvention of) BPEL. State models involve states and event-driven state transitions: to me this means that states are part of the behavior of entities, an active not a passive attribute. And conditional state transitions mean rules rather than processes. Ergo its no accident that TIBCO BusinessEvents state models are defined in an environment that combines them with events and declarative rules.

Of course BPEL - and orchestrated BPM - have their place and use cases - indeed TIBCO has many successful BPM customers, some of whom are combining entity models and states (in TIBCO BusinessEvents) to control workflow processes (in TIBCO BPM). There are indeed many patterns to combining event-based state changes with process orchestrations, and IBM’s focus on just one will be interesting to watch.

Notes:

[1] TIBCO’s BPM group of course has much more to say on BPM and BPEL …

[2] TIBCO followers will be bemused by the acronym overloading here:
- IBM BEs (Business Entities) are directly equivalent to TIBCO BE (BusinessEvents) concepts, with UML-based state models applicable to both.
- IBM BEs map via IBM BPEL4Data to BPEL business processes, whereas TIBCO BE concepts and states are directly executed in the TIBCO BE rule engine (with no BPEL intermediate step, if you like), with BPM processes as optional (downstream) activities.

IDC’s Stephen Hendrick gave the keynote on the 2nd day of BRForum, titled “BRMS at a Crossroads”. The gist of Stephen’s talk was the need for BRMSs to evolve to the next level. Interestingly this seemed to be the first conference mention of “cloud computing” - a welcome respite from the hype about remote deployment platforms - as “cloud” was one of the future trends that businesses needed to exploit, along with open source, visualization platforms, and, naturally, decision management…

Stephen started with an overview (based on IDC research) of the BRMS market: in 2008 this was worth $285M with a “10.5%” annual growth, with the 2 leading BRMS vendors taking 40% of that market. Of the 7 BRMS vendors he mentioned, TIBCO was rated as being joint 2nd due to its “strong legacy in rules and being well positioned to execute”…

He then introduced the “IDC Decision Framework”: measuring the “scope of decision” vs “degree of automation” vs “no of decisions” vs “level of collaboration” for any application area.

Onto the vision of a future Decision Management platform: this  needs better “data preparation” (which maybe means MDM)  and “decision refinement” (covering predictive analytics). But CEP events needed to drive the decisions, whose decisioning context was defined as handled by “state“. All these management constructs obviously mapped to a runtime platform for “active decisioning” / “always on” behavior…

Justifying the CEP connection, Stephen mentioned that in 2008 at least 20% of BRMS/decisioning deals had some kind of “real time” orientation which was expensive to handle in the “passive BRE” environments.

The key concept Stephen described was the move from the “process centric to information centric” approach. Sharp intake of breath from the BPM community present… however Stephen explained that fine-grain rule and event control and parallel processing were key, and useful, features of the CEP world.

Stephen ended with the comment that “cloud computing” will also be event-driven - so decision management platforms that are event-based will makes sense in the cloud deployment world. [And funnily enough, CEP certainly plays a role in TIBCO's Silver cloud offering].

From a TIBCO perspective, clearly the concept of state management and modeling, with event processing, decision management, MDM and analytics are all part of the “best practice” decision platform. Probably the “information centric” world will not replace the “process centric” world any time soon, but for those customers want to take this route, its good to know there are already vendor solutions…

Meanwhile, Sandy’s view of the talk can be found on her blog…