(ii) separate out the coordinator logic from the actual "coordinator" (as
per the HP submission), enabling the "initiator" (or should it be "terminator"
in this case?) to control the business logic used to complete the business
activity during its "flow". As was mentioned during the meeting there may be
reasons why the actual coordination logic may need to change over time.
Furthermore, if you think about what a coordinator actually does in terms of
logic, message distribution, and response collation, the first and latter are
configurable whereas actually sending the messages is probably not. What we
suggested in our submission was separating the logic and response collation
from the entity that sends messages: the coordinator is actually pretty dumb,
allowing a single implementation of this to work with pretty much any model
simply by slotting in different coordination/control logic.
Comments, suggestions?
I
think I agree the possibility of the division of labour, but does this imply
all the branches (participants ?) are equal ?
For
a classic transaction, they are - each resource/subordinate has a veto
and they all get the same final signal. The only exception is where something
votes read-only, when (for most protocols) it is usually ignored
thereafter.
For
a cohesion, our use-cases have tended to include things which are distinct -
some parts (atomic groups) within the cohesion may be vital to the overall
purpose, others may be optional (any 2 from 5), others may have a
preferred/backup relationship (cancel the second unless the first refuses).
That means the coordinator must distinguish each of these to the control logic
and send appropriate messages back to each.
Peter
ps. to model
group: I'm going to be off email from tomorrow until Thursday - if I don't
reply, I'm not ignoring people.
------------------------------------------------
Peter
Furniss
Choreology Ltd
email:
peter.furniss@choreology.com
phone: +44 20 7670 1679
direct: +44
20 7670 1783
13 Austin Friars, London EC2N 2JX