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

David,
Sorry, I was still thinking in terms of the recent pushback intended to
reestablish the previous three levels.

Regarding your specific latest proposal, I would have to think more
about it. My instinctive reaction is that if we want to take that
approach, we should make sure that users are not going to use it to
shoot themselves in the foot. That implies that we should rigorously
define what is permitted in terms of text filling-in/replacement, and we
should make sure that tools could be built that could enforce those
requirements. In other words, it would not be a good idea, in my mind,
to simply tell the user "just put any changes that you think will work
with the existing choreography, and good luck".

But I am not sure at this point that such rigorous definitions and such
verification tools can be easily created, because of the complexity
involved in identifying, for instance, "semantic equivalence". Maybe
people that have strong theoretical background in this area can provide
some inputs regarding the current state of the art.

Ugo

> -----Original Message-----
> From: david.burdett@commerceone.com 
> [mailto:david.burdett@commerceone.com] 
> Sent: Tuesday, May 04, 2004 7:20 PM
> To: Ugo Corda; Monica.Martin@Sun.COM
> Cc: public-ws-chor@w3.org
> Subject: RE: Abstract, portable and concrete choreographies 
> ... a proposed solution??
> 
> 
> Ugo
>  
> Please take another look at the approach I suggested in my 
> email [1] as I am **not** suggesting another layer of 
> abstraction. The essence of what I suggested was: 1. Take the 
> existing CDL spec and identify the parts of a CDL definition 
> that were "concrete" i.e. specific to a particular 
> implementation and make those elements/attributes optional. 
> This would mean that that a valid choreography **could** be 
> defined that it was essentially "abstract". 2. Define an 
> additional construct called "Package Binding" that would a) 
> reference an existing choreography "package" definition, and 
> b) contain data that "filled in" all the optional stuff that 
> was missing from the original choreography definition.
>  
> This is really no more than a mechanism "text replacement" 
> yet it would, I think, allow a choreography to be defined at 
> an abstract level, a concrete level or any level inbetween.
>  
> Thoughts?
>  
> David
>  
> [1] 
> http://lists.w3.org/Archives/Public/public-ws-chor/2004Apr/0050.html
> 
> ________________________________
> 
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Tue 5/4/2004 5:47 PM
> To: Burdett, David; Monica.Martin@Sun.COM
> Cc: public-ws-chor@w3.org
> Subject: RE: Abstract, portable and concrete choreographies 
> ... a proposed solution??
> 
> 
> 
> David,
> Ok, I see what you mean.
> 
> I think my major rationale for resisting the introduction of 
> an additional abstraction layer on top of WSDL is complexity. 
> You need to define a new interface language, its syntax and 
> semantics, when you could instead just piggyback on all the 
> work already done for WSDL (and I am not talking about a 
> trivial amount of work - just think about the huge effort in 
> the Web services community to make WSDL right, starting with 
> WSDL 1.1, fixing it in WS-I Basic Profile, and evolving it 
> through the WSDL 2.0 WG, a multi-year effort by itself).
> 
> I believe WS-CDL will face easier acceptance if it reduces 
> its size to the minimum (at least on first version) and 
> relies on widely accepted and understood concepts like WSDL. 
> The risk of trying to make WS-CDL do too much is that it 
> could easily end up being ignored by the Web services community.
> 
> Ugo
> 
> 
> > -----Original Message-----
> > From: david.burdett@commerceone.com 
> > [mailto:david.burdett@commerceone.com]
> > Sent: Sunday, May 02, 2004 8:28 PM
> > To: Ugo Corda; 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 15:40:21 UTC