RE: choreography & orchestration must be defined in a context

Assaf

You said ... "there needs to be demand for a standardized mechanism to
exchange such abstract process definitions".

I think there is because of the use case I gave earlier, which I restate
here with slight variations ... there are two choreographies:
- Choreography 1 which consists of a complex choreography that allows for
placing, changing and canceling an order where the schemas being used for
the message definitions were from RosettaNet, and, 
- Choreography 2, which was *absolutely* identical except that all the
message definitions were taken from UBL

If I understand the problem correctly, then to define these two
choreographies at Level 1 would require that the Choreographies be defined
twice one for each version of the messages that was being sent.

Now lets add to this use case, the requirement, which we come accross
frequently, where one business wants to support both choreographies with a
single business process that supports either RosettaNet or UBL. This ought
to be really quite easy for the business to do as all it needs to do is map
the content of the messages - the sequence in which they are exchanged is
the same.

However, if there are two separate choreography definitions that define how
the business should respond, then he is taking a risk if he implements one
process as:
1. He either assumes they are the same, as far as the sequence and
conditions in which the messages are exchanged. But there might be some
subtle differences since there are two definitions, or
2. He needs some way of mechanically verifying that they are the same.
However since the definitions are separate and might use different terms for
the same things, this could be hard, if not impossible to do.

On the other hand, if the two Choreography definitions were both derived
from a single definition that defined the sequence of exchanging messages,
then the business could be confident in implementing a single business
process to handle it.

So if you accept the need for having a common definition for a choreography
that allows just the message formats to change, then you are then left with
a choice of how you represent that "common definition". If you use UML or
something similar, then you need to do a translation or mapping. On the
other hand, if you can define the Choreography in an appropriately abstract
way but using basically the same representation for abstract as well as
concrete choreographies, then you should be able to just replace the
abstract definition of the message content, e.g. an Order, by the Concrete
instance, e.g. either a RosettaNet Order or a UBL Order.

You also said ... "I would include the effort required to write the
specification, review it, build an implementation, support the
implementation, test for interoperability, etc. The benefit has to be
significant for it to be considered 'reasonable'."

I agree, but we haven't looked at potential ways of doing this from a
"specification" perspective yet so the jury's still out!

Best wishes

David
PS and for all the Americans here - I hope you had a good Thanksgiving ;)

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Friday, November 28, 2003 8:21 PM
To: Burdett, David
Cc: 'Monica J. Martin'; Ugo Corda; Jean-Jacques Dubray; Steve
Ross-Talbot; public-ws-chor@w3.org
Subject: Re: choreography & orchestration must be defined in a context



My opinion is that "level 0" type of abstraction fails both test #2 and #3.

For "level 0" to pass test #2, there needs to be demand for a 
standardized mechanism to exchange such abstract process definitions. I 
do not see any demand for that, the only requirements I have at this 
level of abstraction are fully met by existing visual notations (BPMN, 
UML, etc).

Under #3 I would include the effort required to write the specification, 
review it, build an implementation, support the implementation, test for 
interoperability, etc. The benefit has to be significant for it to be 
considered "reasonable".

Like Monica, I would like to keep the scope at the level of Web 
services, and what I need to deliver is strictly a solution at the level 
of Web services.

arkin

Burdett, David wrote:

> Monica
>
> I understand your concerns about scope creep. However I suggest that 
> if we review scope changes carefully then we should be OK. 
> Specifically I think we should only extend scope if all the following 
> are true:
>
> 1. The extended scope must be capable of being very clearly defined
> 2. The benefit of extending the scope must be significant
> 3. The work required to handle the extended scope must be reasonable.
>
> I think that the "level 0" type of abstract definition meets all of 
> these.
>
> David
>
> -----Original Message-----
> From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
> Sent: Wednesday, November 26, 2003 9:27 AM
> To: Ugo Corda
> Cc: Burdett, David; Jean-Jacques Dubray; Steve Ross-Talbot;
> public-ws-chor@w3.org
> Subject: Re: choreography & orchestration must be defined in a context
>
>
> Ugo Corda wrote:
>
> >Monica,
> >So are you are saying that level 0 should be out of scope? I bet 
> David might be able to derive the opposite conclusion ;-).
>
> >I suspect we should be much more explicit than that.
> >
> mm1: First is a semantic definition within the scope of WS-Choreography,
> particularly those described by David in Level 0? These seem to fall
> into the business category.  If we continue to expand the scope where
> does our boundary stop?
>