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


    It seems we have a choice: use WSDL 1.1 as it was intended, or embrace the misinterpretations that have been made about it. It would be irresponsible, IMHO, if we as a standard endorsed and perhaps even encouraged poorly implemented web services. There is plenty of scope for implementations, tools, and third-party product vendors to find ways to make existing abominations (aka non-compliant services) work within a compliant infrastructure.

    I don't see how accomodating non-standard services within the BPEL standard serves the standards process; it sounds like a good product feature to me.


Ugo Corda wrote:
My basic point is that WSDL 1.1, by allowing abstract messages other than those specified in a portType to be bound to the wire, makes the concept of a portType useless.
The concept of an abstract interface should be such that it guides the process of binding. In other words, it tells what can be bound to a concrete interface and what cannot. But WSDL 1.1 allows abstract messages outside the portType to be bound as well. So my definition of abstract interface is as good as the one based on portType, because the one based on portType is in practice not used by WSDL 1.1 when it comes to bindings. For instance, parts coming from the portType can be bound to SOAP headers on the wire the same way that "extra" abstract messages can. So what is the point in saying that the abstract interface is limited to the portType?
In a way, my definition of abstract interface is a demonstration of how absurdly defined some parts of WSDL 1.1 are. I am completely in agreement with your idea of using WS-I BP to solve many WSDL 1.1 problems (in fact I was one of the champions for that). Unfortunately BP 1.0 does not solve all of WSDL 1.1 problems, and in particular does not say anything about the use of "extra" abstract messages.
The issue I have been trying to address with issue 77 is, in any case, a legacy one and we would be facing it even if BP 1.0 had said something very explicit in this area, because of our previous conclusion that BPEL should support legacy applications even in those cases when they are deprecated by BP 1.0.
-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Monday, December 01, 2003 10:08 AM
To: Ugo Corda
Cc: Sanjiva Weerawarana; wsbpel@lists.oasis-open.org
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]