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

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

From: Jean-Jacques Dubray <jeanjadu@Attachmate.com>
Date: Wed, 5 May 2004 06:55:32 -0700
Message-ID: <D15269CBED76D51185280008C73323FA02D40E6B@exch-bel6.attachmate.com>
To: "Steve Ross-Talbot" <steve@enigmatec.net>
Cc: <david.burdett@commerceone.com>, <Monica.Martin@Sun.COM>, <UCorda@SeeBeyond.com>, <public-ws-chor@w3.org>

Are you aware of this paper: 

http://www.doc.ic.ac.uk/%7Ehf1/phd/papers/compatibilityforchoreography-i
cws2004.pdf

Compatibility Verification for Web Service Choreography
Howard Foster, Sebastian Uchitel, Jeff Magee, Jeff Kramer
Imperial College London, 180 Queen's Gate, London SW7 2BZ, UK

Jean-Jacques

-----Original Message-----
From: Steve Ross-Talbot [mailto:steve@enigmatec.net] 
Sent: Wednesday, May 05, 2004 1:05 AM
To: Jean-Jacques Dubray
Cc: david.burdett@commerceone.com; Monica.Martin@Sun.COM;
UCorda@SeeBeyond.com; public-ws-chor@w3.org
Subject: Re: Abstract, portable and concrete choreographies ... a
proposed solution??


Woops,

This is a case of getting left and right mixed up. If you replay my 
email about this and swap conformance for compatibility then I think it 
matches Greg's slides.

Cheers

Steve T

On 5 May 2004, at 00:34, Jean-Jacques Dubray wrote:

>
> Strange, I don't read the picture the same way. I don't think it is
the
> best picture to resolve the discussion since I think greg meant by
> contract something bigger than WSDL (including behavior as well -I 
> think
> he does not believe in CDL). The correct picture should show a
ChorDef,
> an interface and an implementation.
>
> In a peer-to-peer scenario you need a ChorDef to decide on whether
WSDL
> contracts are compatible altogether. It just happens that in a binary
> case, the ChorDef is trivial with respect to the contract definition. 
> (I
> don't read that compatibility is between the contract and its
> implementation?)
>
> I read also that in addition to contract compatibility, an
> implementation must also be conformant to its contract for a
successful
> outcome of the choreography. Again in a peer-to-peer scenario you can
> only gauge the conformance of the implementation to the WSDL + ChorDef
> (to the WSDL only is not enough).
>
> With that said, we can only conclude that a WSDL definition may be
> compatible with a CDL and that an implementation conforms to it?
>
> It is clear to me that I could from a ChorDef generate compatible
> contracts (WSDL) and conformant implementation (assuming a given
> technology like BPEL).
>
> Am I missing something?
>
> JJ-
>
> -----Original Message-----
> From: Steve Ross-Talbot [mailto:steve@enigmatec.net]
> Sent: Tuesday, May 04, 2004 10:46 AM
> To: Jean-Jacques Dubray
> Cc: Monica.Martin@Sun.COM; UCorda@SeeBeyond.com;
> david.burdett@commerceone.com; public-ws-chor@w3.org
> Subject: Re: Abstract, portable and concrete choreographies ... a
> proposed solution??
>
> All:
>
> I think that one of the confusion is what we mean by compatibility and
> what we mean by conformance.
> I am drawn to the slides that Greg Meredith presented to the first F2F
> meeting
> (http://www.w3.org/2002/ws/chor/3/03/ChoreographyorContracts.ppt). I
> think these provide
> a good understanding of what is meant. Compatibility is between a
> service end point description (so WSDL)
> and it's implementation. Conformance is across end-points. The former
> is clearly outside of what we can
> do in WS-CDL but the latter is very much what we can do in WS-CDL.
>
> What we can do is is say that WSDL description is conformant to a
> WS-CDL description.
> What this provides is some level of confidence that, all things being
> equal, the end
> point will behave in a way that is conformant to the external
> observable behavior of the
> WS-CDL description.
>
> If you turn up the dial and so include some higher level enforcement
> through generation of behavioral
> stubs then the level of conformance and so the confidence will 
> increase.
>
> Cheers
>
> Steve T
>
> On 4 May 2004, at 16:53, Jean-Jacques Dubray wrote:
>
>>
>> I totally agree with David. CDL, as I understand it is about
> describing
>> peer-to-peer service interactions. It is expected that owners of
>> services engaging their services in a choreography will decide
whether
>> their service is compatible with the choreography or not. I don't
> think
>> that there is any mechanism that can guaranty that a WSDL will be
>> compatible with a choreography since WSDL does not express what is
>> happening behind the WSDL. However, you can quickly and easily that a
>> given WSDL is incompatible with a choreography from an I/O
> perspective.
>>
>> Choreography is to a peer-to-peer interaction what API is to
>> client/server.
>>
>> JJ-
>>
>> -----Original Message-----
>> From: david.burdett@commerceone.com
>> [mailto:david.burdett@commerceone.com]
>> Sent: Sunday, May 02, 2004 8:28 PM
>> To: UCorda@SeeBeyond.com; Monica.Martin@Sun.COM
>> Cc: public-ws-chor@w3.org
>> Subject: RE: Abstract, portable and concrete choreographies ... a
>> proposed solution??
>>
>>
>> Ugo
>>
>> This is odd. I see a small problem with a simple solution where I
> think
>> that others see a complex one.
>>
>> Firstly, I am **not** suggesting that WS-CDL defines how you can
>> automatically determine that two WSDL definitions are semantically
>> equivalent as I agree it is fraught with problems.
>>
>> What I am suggesting instead is that people determine that WSDL
>> definitions are semantically eqiuvalent. Here's an example ...
>>
>> I see a world where:
>> a) People agree, for want of a better word, a pattern for exchanging
>> messages, where the messages are identified at an abstract level,
i.e.
>> without reference to any WSDL definitions
>> b) Later, people map end points in those patterns to their own
>> previously existing WSDL definitions, or use the WS-CDL definition to
>> define skeleton WSDL definitions from which they can then create the
>> necessary code.
>> c) Once the systems are built and connected, the same people use the
>> WS-CDL definitions to automatically check that messages are being
>> exchanged in the correct sequence.
>>
>> Is there anything wrong with this scenario?
>>
>> David
>>
>>
>> -----Original Message-----
>> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
>> Sent: Sunday, May 02, 2004 10:14 AM
>> To: Monica J. Martin; Burdett, David
>> Cc: public-ws-chor@w3.org
>> Subject: RE: Abstract, portable and concrete choreographies ... a
>> proposed solution??
>>
>>
>>> How can you guarantee that the WSDL definitions at each end are
>> 'semantically' equivalent?
>>
>> Yes, the issue of semantic equivalence of Web services and their WSDL
>> interfaces has been raised a few times in the last couple of years in
>> various committees (WS-I Basic Profile, W3C WS Architecture and, I
>> think, WSDL WG). All the times the conclusion has been that such a
>> subject is out of scope and should be best left alone for now.
>>
>> Right now we don't have any precise way of defining the semantics of
a
>> Web service, let alone establishing that two Web services are
>> semantically equivalent.
>>
>> Ugo
>>
>>> -----Original Message-----
>>> From: public-ws-chor-request@w3.org
>>> [mailto:public-ws-chor-request@w3.org] On Behalf Of Monica J. Martin
>>> Sent: Sunday, May 02, 2004 8:02 AM
>>> To: david.burdett@commerceone.com
>>> Cc: public-ws-chor@w3.org
>>> Subject: Re: Abstract, portable and concrete choreographies
>>> ... a proposed solution??
>>>
>>>
>>>
>>>
>>>> mm1: 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**.
>>>>
>>> mm1: WS-CDL lacks the business semantical definitions required and I
>>> stand my ground that any attempts to include them will limit the
>>> language. Previously, I provided you a detailed list of business
>>> semantical constructs: business transactional patterns,
>>> signals/messages, partner roles that are not service-based, business
>>> dialog and contract obligation, to name only a few. As I have
>>> indicated
>>> before, WS-CDL could look to existing languages to provide
>>> this boundary
>>> (constraints, priority, preference and commitment basis).
>>>
>>>> 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>
>>>>
>>> mm1: They look to the existing language that provides that
>>> boundary for
>>> WS-CDL. This doesn't limit the WS-CDL language. It allows
>>> WS-CDL to do
>>> well what it is built to do while allowing it to look to existing
>>> languages (ebBP) to provide the business semantical boundary.
>>>
>>>>    * 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>
>>>>
>>> mm1: So now you are saying that WS-CDL will do business
>>> process pattern
>>> matching to understand if the choreographies are semantically
>>> the same
>>> although syntactically different. When was this role (and duty)
>>> established for WS-CDL? How can you guarantee that the WSDL
>>> definitions
>>> at each end are 'semantically' equivalent? This clearly has not been
>>> established as within the WS-CDL scope.
>>>
>>>>    * 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>
>>>>
>>>>
>>> mm1: When you make changes to the underlying attributes of
>>> the package,
>>> you change the context of the interactions that depend on it
>>> David. See
>>> comment above about what capability WS-CDL has to ensure semantic
>>> equivalency.  In addition, I point to Daniel Austin's
>>> comments about the
>>> limitations of WSDL.
>>>
>>>>    * 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. </DB>
>>>>
>>>>
>>> mm1: See previous comments regarding semantic 'equivalence'.
>>> On: '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':
>>> This group's scope necessitates its use and dependence on WSDL v2.0
>>> (which is forthcoming).  This clearly points out a concern I
>>> have voiced
>>> before that combining the choreography description and the
underlying
>>> interactions could create a limitation on the language because those
>>> concepts may not always complement one another. Don't get me
>>> wrong, I am
>>> not saying that we shouldn't define a choreography description, but
>>> suggest we recognize our scope boundaries and the
>>> capabilities that WSDL
>>> can support/understands. Your premise assumes that the
>>> underlying WSDL
>>> definitions will be capable of handling the variability of the
>>> choreography descriptions regardless if the latter may
>>> reference back to
>>> business semantics and contractual constraints outside of WS-CDL.
>>>
>>>>    * 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>
>>>>
>>>>
>>> mm1: I stand my ground that changing the values of the choreography
>>> definition based on the premise that WS-CDL understands semantic
>>> equivalence is fraught with risk (and ill advised).
>>>
>>>
Received on Wednesday, 5 May 2004 09:58:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:57 GMT