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


    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:


Ugo Corda wrote:
> 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.


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