OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 77 - Under specified operation definitions


Please see my responses below.

Ugo

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Saturday, November 29, 2003 4:45 PM
> To: Ugo Corda; Ron Ten-Hove
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 77 - Under specified operation 
> definitions
> 
> 
> "Ugo Corda" <UCorda@SeeBeyond.com> writes:
> > In your example, there are two abstract interfaces (according to my
> definition):
> >
> > ai1 = {pt1, m5}
> >
> > ai2 = {pt2, m1, m2, m3, m4}
> >
> > A particular binding for ai1 is free to bind m5 parts to the
> > wire message. (It is also free to select any subset of m1-m4 parts).
> > Similarly, a binding for ai2 is free to bind any of the parts from
> > messages m1-m4 to the wire message. (It is also free to bind any
> > subset of m5 parts).
> >
> > I don't see what the problem is with that.
> 
> The first problem is that its completely void of semantics. Your
> argument would have that any <message> definitions which just
> happen to get included to a WSDL automatically become part of
> every interface in the document (or any other document later on
> that includes this one). Just imagine the impact on re-usability
> of WSDL documents with that view.

The actual impact on re-usability can only be assessed by examining what the abstract interface allows you to do at binding time (without that type of assessment, we are just having an academic discussion). From that point of view, there is no difference between my definition and yours: whatever abstract messages can be bound to a concrete interface using my definition can also be bound using yours.

> 
> The other problem is that its defined by a figment of your
> imgination, and not by anything in the spec. 

My definition is a figment of imagination as much as yours. WSDL 1.1 simply does not in any way define what an abstract interface is (just search the document for "abstract interface"). 

> Where does it say
> in the spec that m5 belongs to ai1 and that m1 also doesn't
> occur there additionally? (I mean m1 is used in an operation
> abstract and then again as a free variable in another operation.)

Not sure what you are saying. What I meant by "ai1 = {pt1, m5}" is that the abstract interface ai1 includes m1-m4, coming from pt1, plus m5. (And a binding can just take that interface and associate the whole set m1-m5 with the message on the wire).

> After accusing me of interpreting WSDL 1.1 you're coming up with
> entirely new semantics for it.

In order to come up with a definition of "abstract interface", which is simply not given in the spec, you need to interpret the spec as much as I do.

> 
> Furthermore, WSDL 2.0 will have no such mechanism. The way to add
> stuff in bindings will be via policies (features and properties)
> and those may not even be expressed inline in the same WSDL
> document as the binding.

The discussion we are having is about WSDL 1.1. It's clear that WSDL 2.0 will require non trivial changes to the BPEL spec (for example WSDL 2.0 will not have messages, so many areas of BPEL will be affected by that). 

In any case, I sure hope that WSDL 2.0 will be a better spec than WSDL 1.1. Just think of the amount of time WS-I had to spend on that spec in order to fix all the underspecified and erroneous areas (and there are still very poorly defined areas left - support for intermediaries being a primary example).

> 
> Sanjiva.
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]