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:
- 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.
- 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?
- 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”!).
- 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:
- Define participants and messages (/events) that interact between them
- Define states with events as messages from and to, with only 1 sender per state
- 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
- Merge the states for each participant
- Enact – check each event at a time to prove feasibility of the interacting state models
