Re: Issue LC50 - MEPs

On Thu, 2004-11-18 at 12:34, Amelia A Lewis wrote:
> It is my understanding of the current status quo, which is based on the
> combination of WSDL 1.1 and WS-Addressing, that features/extension
> specs/policies can override the semantic of a MEP.  I don't like this,
> mind, but I believe that this is the status quo.

Yes, *required* extensions can override the semantics of WSDL 2.0,
because WSDL 2.0 delegates the semantics of a required extension to the
spec that defines that extension:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#mandatoryext
[[
A mandatory extension is an extension that MAY change the meaning of the
element to which it is attached, such that the meaning of that element
is no longer governed by this specification. Instead, the meaning of an
element containing a mandatory extension is governed by the meaning of
that extension. Thus, the definition of the element's meaning is
delegated to the specification that defines the extension.
]]
A later note further explains:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#extensibility-semantics
[[
Authors of extensibility elements should avoid altering the existing
semantics in ways that are likely to confuse users.
]]

> A cleaner semantic would require that, if the response in an in-out is
> sent to an alternate address, or even to an address specified by a
> feature/policy/extension spec, a different MEP (David's horribly
> confusingly-named p2c (sorry, David)) be used.

Hey, at least it has an unambiguous URI!  ;-)

> The implication is that a binding to, for instance, internet email for
> the current in-out *requires* that the reply-to header always be set to
> the address of the originating node.  In order to have the flexibility
> to send to a different node, one would want to have a more general
> in-out MEP, one which specifically permits redirection of the response.

That depends on the meaning of "node".  I was previously assuming (as
you appear to be) that a response sent to an alternate address would be
modeled as going to a different *node*.  But Sanjiva's view is that if
the in-out MEP is specified, then the alternate address is merely a
different physical delivery point for the same logical node.  For
example, suppose the incoming message arrives via FTP and the outgoing
message is delivered by email.  Clearly they need to be different
physical addresses, but it can still be the same logical node.

During the F2F, I argued that it's important to be able to model the
interaction either way: as multiple physical locations owned by the same
node; or as different nodes.  But if they're modeled as different nodes,
that's when GlenD's argument comes into play.  

> I *strongly* disagree with Glen's assertion that the client doesn't
> care, that the client views this as "two one-way" (probably meant to be
> "in-only" plus "out-only", but it isn't true, in my opinion, anyway). 
> The client *ought* to be able to know, in advance, whether it's expected
> to supply an address for a response, and ought to be able to vary its
> requests such that it can receive responses itself, or direct them
> elsewhere.  All of this information is of interest to the requesting
> node (as well as to the target node for the response, which presumably
> also has access to the WSDL).

The assertion isn't that the client doesn't care.  The client may care
about many things that are outside the scope of WSDL.  The point is
merely that client1 doesn't receive the reply when the reply is sent
instead to client2.  Therefore, from the point of view of modeling the
interaction in WSDL, there is only a single one-way message from the
client1 to the service, or a single message from the service to
client2.  More concretely, client1 doesn't generate stubs and skeletons
for client2.  The fact that client1 needs to send along an address of
client2 is outside the scope of WSDL, along with any other
application-specific info that may be needed.

-- 

David Booth
W3C Fellow / Hewlett-Packard

Received on Thursday, 18 November 2004 21:27:50 UTC