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
