Re: choreography & orchestration must be defined in a context

If the choreographies are almost identical and only differ in the 
over-the-wire message format, then it sounds to me like a problem that 
can be solved with the message binding.

There are issues with specific types of abstractions (message formats in 
this case), which are not specific to choreography. Obviously, the 
solution I would prefer is one that's not specific to choreography 
eitherr, so I can leverage it in other places as well. Protocol 
bindings, encoding rules, extensible XML schemas, etc. I believe we 
discussed all of that.

Given that those solutions are required in the general space of WS, not 
just choreography, and can be leveraged in the space of choreography, I 
don't see the need to reinvent them, or do them differently for 
choreographies. So starting the the premise of a) list of problems, and 
b) list of existing solutions, and narrowing it down to those from 
column a) that don't appear in column b), I end up with the exact same 
conclusion.


You are presenting a lot of good arguments in justification of a 
mechanism that allows abstract messages and more concerete presentations 
to exist. And my experience is that those arguments are valid and an 
issue that needs to be addressed. Everytime we have this discussion it 
goes back to the original point of listing the requirement, but there's 
no disagreement on the requirement.

My experience leads me to conclude that there are already existing 
solutions for the problem and we should build the language around those 
solutions, not supplant them. Hence, my conclusion is different than 
yours. For as long as we continue to disagree on the available solutions 
to the message abstraction problem, we are going to disagree on whether 
"level 0" choreography is an interesting solution or not.

If there is another solution I can use to the problem, and I prefer the 
other solution, then I'm not going to use "level 0" choreography, which 
means I do not see any value in its existence which can justify any 
effort to specify and implement it.

Personally, until I am convienced that the abstract issues you are 
talking about will not be solved outside the choreography specification 
itself, I am going to remain firm in my opinion.

arkin


Burdett, David wrote:

> 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?
> >
>

Received on Tuesday, 2 December 2003 00:01:30 UTC