href="http://www.centrebenesh.fr/index.html"> class="alignright"

src="http://www.centrebenesh.fr/images/notation.gif" alt=""

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

href="http://www.bcs.org/content/conEvent/6652"

target="_blank">session titled "Modelling

Choreography" by requirements analyst title="Book: Protocol contracts with application to choreographed

multiparty collaborations by Ashley McNeile"

href="http://www.springerlink.com/content/5u59650u2873h387/"

target="_blank">Ashley McNeile.

Ashley described some of the past efforts to model and

implement choreographies, using types of process algebra such as

href="http://en.wikipedia.org/wiki/Calculus_of_communicating_systems"

target="_blank">Robert Millner's Calculus of

Communicating Systems (CCS) and its derivative title="Wikipedia reference"

href="http://en.wikipedia.org/wiki/Pi-calculus"

target="_blank">Pi-Calculus. However, Ashley used

sequences of events and states (i.e. a

target="_blank">state diagram) which he also

compared to Michael Jackson's formalised object

lifecycles (e.g.

href="http://en.wikipedia.org/wiki/Jackson_system_development"

target="_blank">JSD / Jackson Diagrams). Various W3C

efforts have described choreographies too - e.g.

href="http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/"

target="_blank">WS-CDL. Of course the latest

modelling construct for choreography is

target="_blank">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

href="http://www.addtoany.com/share_save?&linkurl=http%3A%2F%2Ftibcoblogs.com%2Fcep%2F2012%2F02%2F02%2Fmodelling-choreography-with-events-states-and-business-rules%2F&linkname=Modelling%20Choreography%20%28with%20events%2C%20states%20and%20business%20rules%29"> src="http://tibcoblogs.com/cep/wp-content/plugins/add-to-any/share_save_120_16.png"

width="120" height="16" alt="Share/Save/Bookmark" />

No related posts.

src="http://feeds.feedburner.com/~r/ComplexEventProcessing/~4/kUmGqiz0HWg"

height="1" width="1" />