Ron,
> If
I may rephrase your definition of abstract endpoint, to verify that I understand
it properly:
>
A WSDL instance defines a set of messages, composed from a set of parts.
> A port type defines a set operations. A
binding composes operations from messages and parts,
> such that all the operations for a
particular port type are defined.
> An abstract endpoint is thus the binding
(less the encoding and protocol
details).
Sorry, that is not what I meant. For me an abstract endpoint
is the union of a particular portType plus all the abstract messages defined
outside a portType (end of definition of an abstract
endpoint).
The second part of my original definition is just a
description of what it means to bind such an abstract endpoint. What it means is
you map a subset of the abstract messages (their parts, actually) and a subset
of the parts appearing in the
portType.
> The most authoritative interpretation we have is that of
the WS-I, in BP 1.0a:
I am glad you mention that. As you can see, that is a SHOULD
and not a MUST (see the phrase "although not disallowed"). Throughout all this
discussion, my position has been that I understand the rational for a SHOULD and
I can subscribe to that. What I do not accept is that we turn it into a
MUST.
Ugo
-----Original Message-----
From: Ron Ten-Hove
[mailto:]
Sent: Wednesday, November 26, 2003
7:21 AM
To: Ugo Corda
Cc:
Subject: Re: [wsbpel] Issue - 77 - Under
specified operation
definitions
Ugo,
If I may
rephrase your definition of abstract endpoint, to verify that I understand it
properly: A WSDL instance defines a set of messages, composed from a set of
parts. A port type defines a set operations. A binding composes operations
from messages and parts, such that all the operations for a particular port
type are defined. An abstract endpoint is thus the binding (less the encoding
and protocol details).
Is this a fair restatement of
your definition?
More comments
in-line:
-Ron
Ugo Corda wrote:
Ron,
> What,
exactly is the relationship between an operation defined in a port type, and
that operation as bound
> to a
particular protocol? Is this why you are concerned about relying on
port types for our message descriptions?
I am not sure I
understand your question. What I was saying is that there is no substantial
difference between a binding for a portType and a binding for an abstract
message not belonging to a port type. In either case, the associated parts
might or might not be used by the binding. So, you might find variables in
current BPEL activities that, for some bindings, have parts not mapped
to the wire (so are uninitialized), despite the fact that they belong to
what you consider the "true" abstract
interface.
Perhaps this is covered by my
restatement above.
> "A binding
defines message format and protocol details for operations and messages
defined by a particular portType."
> This
clearly separates the layers. I don't see any mention of "extra"
abstract messages becoming part of the abstract endpoint type.
The fact that a
reference to "extra" abstract messages binding is missing is just an example
of how poorly "extra" abstract messages are described in the spec. (That's,
after all, the source of all these discussions). Or are you saying that
this binding rule does not apply to "extra" abstract messages? Then where is
that binding rule specified? And if those "extra" abstract
messages have no binding defined, how would you be able to map them to
a soap:header, the same way you do for a part defined in a
portType?
> Can you
provide us with a definition of an abstract endpoint using WSDL terminology?
Here it is. "An abstract endpoint is defined by a particular
portType plus all the abstract messages not belonging to any
portType. A particular binding will specify which parts in those
"extra" abstract messages will belong the concrete endpoint (the same
way that the binding will specify which parts in the portType will
belong to the concrete endpoint)".
You certainly can say that this interpretation is
arbitrary, but yours is too for the simple reason that the WSDL 1.1 spec
*does not* define what an abstract endpoint is. Any such definition can only
be derived by interpretation of certain parts of the spec. Since the spec
itself is unfortunately unclear, different interpretations can be derived
from it.
The most authoritative
interpretation we have is that of the WS-I, in BP 1.0a:
5.3.3 Unbound portType Element Contents
WSDL 1.1 is not explicit about whether it is permissible for a
wsdl:binding to leave the binding for portions of the content
defined by a wsdl:portType unspecified.
R2209 A
wsdl:binding in a DESCRIPTION SHOULD bind every
wsdl:part of a wsdl:message in the
wsdl:portType to which it refers to one of
soapbind:body, soapbind:header,
soapbind:fault or soapbind:headerfault.
A portType defines an abstract contract with a named set of operations
and associated abstract messages. Although not disallowed, it is expected
that every part of the abstract input, output and fault messages specified
in a portType is bound to soapbind:body or
soapbind:header (and so forth) as appropriate when using the
SOAP binding as defined in WSDL 1.1 Section 3.
Although this recommendation refers specifically
to SOAP bindings, it is applicable to any binding. In particular, the notion
of "abstract contract" is key.
-Ron
