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 Sunday, 2 May 2004 13:15:09 UTC