RE: 3 scopes not 2

Tony:

If I may and following the presentation I gave, I would like to also
suggest that the internal scope might be divided into two different
scopes:

Scope 3a executable Business Process (or Web Service Composition)
	This scope specifies how the B2B interface of one party binding
to its internal service components (e.g. Order 	Entry, Billing, Shipping
modules)

Scope 3b Orchestration (Service Component).
	This scope is relative to the behavior of a service component
within a long running executable business process. 	This is
typically the level that I associate with orchestration which takes a
centric point of view (i.e. I am 	the Order Entry component and
this is the long-running logic (and code :-) I execute )

I think it is important to have level 3a at the same level of level 1 or
2 because nothing really distinguishes where the company boundary,
furthermore, the company boundary may be moved at anytime (e.g. billing
can be outsourced – why would the overall message exchange change?).

Jean-Jacques Dubray____________________
Chief Architect
Eigner  Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451
781-472-6317
jjd@eigner.com
www.eigner.com 

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Fletcher, Tony
Sent: Tuesday, March 18, 2003 12:45 PM
To: public-ws-chor@w3.org
Subject: 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 	

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:
www.choreology.com
Cohesions 1.0™
Business transaction management software for application coordination
Work: tony.fletcher@choreology.com 
Home: amfletcher@iee.org
 

Received on Tuesday, 18 March 2003 16:33:57 UTC