W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2004

RE: Abstract, portable and concrete choreographies ... a proposed solution??

From: <david.burdett@commerceone.com>
Date: Tue, 27 Apr 2004 08:00:54 -0700
Message-ID: <975D1A379F57F34995874608D9FE8C910FE2B4@C1SCAMSG05.commerceone.com>
To: <Monica.Martin@Sun.COM>
Cc: <public-ws-chor@w3.org>


Thanks for your comments. See my thoughts in-line below.


-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
Sent: Monday, April 26, 2004 11:01 PM
To: Burdett, David
Cc: public-ws-chor@w3.org
Subject: Re: Abstract, portable and concrete choreographies ... a
proposed solution??

David, I am concerned you are adding complexity here.  Comments:

    * Adding specialization of PackageBinding. This assumes that the
      business semantics are a part of the WS-CDL (and in import). They
      are not.
<DB>I know we have discussed this before, but I don't understand your point. How could a responsible designer define an "interaction", i.e. the exchange of information usually in the form of a message, in a WS-CDL definition without explaining what that interaction **means**, i.e without explaining its **semantics**. If the semantics are missing from the WS-CDL definition, then how would an organization that wanted to use that definition as part of their implementation know that they were using it correctly?</DB>

    * Note 5: What impacts are realized if you change the original WSDL
      definitions on the fly? How do you insure conformance when you
      begin to change the underlying semantics that are expected? Aren't
      these actually different WSDL definitions rather than an
      augmentation of an existing one?
<DB>Firstly, I don't think that WSDL definitions would or should be changed on the fly - it's too risky. Secondly, the main assumption is that you can **only** do an alternative package binding if the underlying semantics are the same - if they are not then package binding won't work. Thirdly the approach assumes that the semantics of the WSDL definitions at each end are "equivalent". For example I would say that a UBL Order definition and a RosettaNet Order definition are semantically "equivalent", they just have diferent XML representations. The same goes for WSDL defintions, for example the actual names used for a port, message, document, operation etc are irrelevant as long as the behavior of the service "behind" the definition is the same. A good test for equivalence is if you can easily map between one definition and another. </DB>

    * It appears that you are adding more semantics that already occur
      in existing open standards. What is the provocation to create anew
      that could be used in existing technologies? Isn't a mapping a
      easier path?
<DB>I don't think I am adding more semantics. All the package binding idea provides is a method of either changing the values of elements/attributes in an existing package definition or adding in the values in the original package definition that were missing. The package binding does not introduce **any** new concepts or structures to the package element as currently defined in the latest spec. Can you give an example of where you think I am adding in more semantics as that was not the intention?</DB>

    * What is the benefit of a fully abstract choreography? This relates
      to previous question about recreating the wheel of other technologies.
<DB>The short answer is reuse and lower maintenance costs. A more detailed answer follows:
1. Before two (or more) independent businesses can start exchanging messages as part of some shared business process, e.g. a buyer and a seller buying goods, they have to agree on two things: i) the WSDL interfaces they will expose that will accecpt messages, and ii) the sequence in which they exchange messages, i.e. the choreography definition.
2. Many of those business' WSDL definitions will be different but semantically "equivalent" as described earlier
3. A "concrete" choreography definition is, by definition, "tied" to specific WSDL definitions. This means that if the WSDL definitions change for some reason, then the choreography definition **must** change even if the sequence of exchanging messages has not.
4. If you have an "abstract" choreography that is independent of the WSDL then you can change the WSDL definitions independently of the choreography definition therefore reducing the maintenance effort and enabling the choreography to be reused.
5. Finally, **if** standards groups create "standard" abstract choreography definitions, then businesses can just agree to use them and then they only have to focus on how they align their WSDL definitions.

    * You are adding yet another layer of abstraction in your
      definitions - this is complexity may not be prudent and may
      actually serve as an impediment to adoption by industry (abstract,
      concrete-based on abstract, concrete with fillings, portable with
      partial, etc and more....)
<DB>I don't see how I am adding another layer of abstraction. As I said earlier, the basic mechanism of a package binding is one of replacing values in a choreography definition by alternatives that are semantically equivalent. Where is the complexity in this approach? I don't see it. Can you provide an example? I do agree though, that if complexity exists, then it should be avoided.</DB>

Received on Tuesday, 27 April 2004 11:03:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:24 UTC