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

If I understand it well, runtime bi-simulation is a kind of black-box
approach, in the sense that I derive my understanding of a system's
behavior by external observation. If that is the case, it seems to me
that establishing semantic equivalence by those means would still remain
an elusive goal. 

As a trivial counterexample, one of the two systems might have been
designed so that it behaves differently starting next month. If I base
my conclusions on runtime bi-simulation done this month, I might very
well have reached the wrong conclusion.

Ugo 

> -----Original Message-----
> From: Steve Ross-Talbot [mailto:steve@enigmatec.net] 
> Sent: Sunday, May 02, 2004 10:59 AM
> To: Ugo Corda
> Cc: david.burdett@commerceone.com; Monica J. Martin; 
> public-ws-chor@w3.org
> Subject: Re: Abstract, portable and concrete choreographies 
> ... a proposed solution??
> 
> 
> Equivalence is a tricky subject. The best treatment I have 
> seen is that 
> two systems are bi-similar. What this means is that wrt their 
> observable behaviour they cannot be distinguished. There are two ways 
> to do bi-simulation. The static method is to apply reductions to the 
> process algebraic definitions of the two systems to see if 
> they remain 
> the same through the reduction. If they do then they are said 
> to be the 
> same. Problem with the approach is you end up with state explosion as 
> you are effectively looking at their labelled state transitions. Some 
> techniques for managing state explosion have been applied in 
> different 
> contexts and so it might be possible to do something akin to 
> bi-simulation. The only other way I can think of is continual runtime 
> monitoring which leads to runtime bi-simulation and does much 
> the same 
> thing.
> 
> Cheers
> 
> Steve T
> 
> On 2 May 2004, at 18:14, Ugo Corda wrote:
> 
> >
> >> 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 20:59:40 UTC