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

Ugo,

Yes you are completely correct about runtime bi-simulation. I think if 
I were to be more exact
there is no such thing as runtime bi-simulation since bi-simulation 
tends to be used in a static
type checking sense.

Cheers

Steve T

On 3 May 2004, at 01:59, Ugo Corda wrote:

>
> 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 Monday, 3 May 2004 11:05:47 UTC