|
Ron,
The
fact remains that the example I mentioned under issue 77 is a completely
standard-compliant service (even though it is probably not one we would use as a
recommended usage pattern). In fact the existence of such a case is
explicitly called out in sec. 3.7 of the WSDL spec. I agree with you that is
should not have been allowed to start with, but unfortunately it's out there now
and we simply cannot say that it's non-standard.
In my view it's just
a matter of whether we want to support legacy applications or not. Again, my
understanding is that this TC decided we want to support legacy cases even
when they are deprecated by later specs like WS-I
BP.
Ugo
Ugo,
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.
Cheers,
-Ron
Ugo Corda wrote:
Ron,
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.
Ugo
Ugo,
My
responses are, like yours, in-line:
-Ron
Ugo Corda
wrote:
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.
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?
Regards,
-Ron
|