3 scopes not 2

Dear Colleagues,

 
Just would like to make again in a message one of the points that I made
at the inaugural W3C WS-Choreography group meeting, which I think was
accepted.
 
One discussion at the meeting centred on the scope of the work of this
group and was phrased in terms of two possible scopes, one 'internal'
and the other 'external'.
 
I suggest that there are actually three different scopes we should
consider, rather than just two.  They are illustrated in the the
attached (lightweight!) diagram.
 
Scope 1 - might be called 'global' or some such
Is the whole picture.  Specifies the roles in the overall business
process (buyer, distributor and supplier in this example)  and  the
message sequences between each leg relative to other legs.   It is
relatively course grained.
It seems to me that this kind of model is useful at design time - and
only at design time.  It allows one to design the overall process that
achieves a particular  business goal (/set of requirements).  It allows
one to decide which roles are required and what information needs to be
exchanged between the roles.
 
Scope 2 - bilateral
Focuses in on a single bilateral relationship, such as buyer to
distributor in the attached example and specifies the allowed message
sequences, message meanings and the externally observable effects (such
as some piece of information must be persisted at a specified point in
time onwards).  It is not concerned with the internal operation of
either role.  Thus in this case the buyer would just deal with the
distributor and would not be concerned with the suppliers that the
distributor uses - or even that there are suppliers rather than stuff
being sourced internally.   Obviously this does not mean that there are
not other roles involved, just that they are not of concern to the
bilateral relationship being focused on.
This kind of model is essential for specifying interoperability between
two roles. 
 
Scope 3 - internal
This scope is concerned with the relationship between input and output
'ports' at a particular role and some of the details of processing.  So
in the example if we take the distributor then the internal scope is
represented by the pink oval and concerns the messages received from and
sent to the buyer and the various suppliers.  It can include as much
detail of the processing of messages and internal actions and events as
is desired for a particular application of the language. 
This kind of model could actually be in the form of a language that is
directly executable, or it could be in a form that provides
configuration information to an execution engine.
 
My intent is to clarify the possible scopes of any specification coming
out of this WS-Choreography group, rather than to express an opinion on
which we should adopt / focus on at this stage.  Though I would agree
with at least some others that it can be argued that Scope 2 is the most
important as this is what needs to be shared and agreed between two role
players.
 

Best Regards,

Tony                           


 <http://www.choreology.com/> 

Tony Fletcher

Technical Advisor 
Choreology Ltd.
13, Austin Friars, London EC2N 2JX UK


Phone:  

+44 (0) 20 7670 1787


Mobile: 

+44 (0) 7801 948 219


Fax:    

+44 (0) 20 7670 1785


Web:

 <http://www.choreology.com/> www.choreology.com


Cohesions 1.0(tm)


Business transaction management software for application coordination



Work: tony.fletcher@choreology.com 


Home: amfletcher@iee.org