Modelling Choreography (with events, states and business rules)
First Published Friday, 3rd February 2012 02:30 pm from TIBCO Software : Paul Vincent
The opinions expressed by this blogger and those providing comments are theirs alone, this does not reflect the opinion of Automated Trader or any employee thereof. Automated Trader is not responsible for the accuracy of any of the information supplied by this article.
width="417" height="578" />This week the title="BCS SPA home page" href="http://bcs-spa.org/index.php"
target="_blank">BCS SPA group held a fascinating
Choreography" by requirements analyst title="Book: Protocol contracts with application to choreographed
multiparty collaborations by Ashley McNeile"
Ashley described some of the past efforts to model and
implement choreographies, using types of process algebra such as
Communicating Systems (CCS) and its derivative title="Wikipedia reference"
target="_blank">Pi-Calculus. However, Ashley used
target="_blank">state diagram) which he also
compared to Michael Jackson's formalised object
target="_blank">JSD / Jackson Diagrams). Various W3C
target="_blank">WS-CDL. Of course the latest
example of his practice, Ashley described an example - modelling
bank account transactions via Protocol Modelling (using simple
- state model 1:
defined the close and withdraw events on an active
- 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
close an account if it is overdrawn
- if balance < 0 then account state is
- all 3 state models operate in
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.
- 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
This process describes a development
process of state diagrams for choreography
participants and messages (/events) that interact between
- 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
width="120" height="16" alt="Share/Save/Bookmark" />
No related posts.
height="1" width="1" />