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


    My responses are, like yours, in-line:


Ugo Corda wrote:
Please see my responses below.


-----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 

"Ugo Corda" <UCorda@SeeBeyond.com> writes:
In your example, there are two abstract interfaces (according to my
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.
This is terribly unstructured, for what is manifestly a layered approach to defining services. Each message added, deleted, or modified in a WSDL file then causes every abstract interface to change.

Of what use are port types in under this definition of abstract interfaces? Do they serve simply as a list of operation names? Why associate messages with the operations?

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"). 
    Let's keep on topic here. The question is: how does BPEL use WSDL-described services in such a way that it is a) not binding specific, and b) capable of using different bindings? We are being utilitarian here. What is the appropriate abstract interface that BPEL should use from WSDL-described services?

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).
So each abstract interface is simply the set of all abstract messages?

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.
There is a difference between using existing elements of the language, and creating new compositions of those elements. When Sanjiva asserts that the abstract interface is the port type (Sanjiva, correct me if I'm misrepresenting your argument), this in no way affects the semantics of the language; it is defining an alias. Your definition extends and modifies WSDL semantics, which is problematic.

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).
    Alas, we are using WSDL 1.1, warts and all. Thankfully the WS-I has done the work of clarifying many things in WSDL 1.1. Why not use their work, where appropriate, to help avoid bogging down in the "WSDL 1.1 is broken" mire?


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