Re: choreography & orchestration must be defined in a context

Burdett, David wrote:

> Now if there is already some way of specifying things abstractly that 
> has been defined then I would be happy to use it if it makes sense.
>
We've discussed this before re: using WSDL *abstract *message 
definitions and protocol *bindings,* using XSDL extensible types and 
using semantics to describe those abstract messages (see RDF and WSDL). 
WSDL 1.2 is even further along in simplifying how this is done and 
providing more flexibility at the same time.

So, were do we go from here?

Assaf

> Hope this helps.
>
> David
>
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Monday, December 01, 2003 6:40 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
>
>
> 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 22:54:20 UTC