Re: Issue LC50 - MEPs

Hi Amy,

> 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.

I don't agree .. this is just a mess to say that using ReplyTo
means its a different MEP. The purpose of the WSDL MEPs is to
provide an application level concept of a request/response pattern.
How those messages actually get sent should not change the fact
that the pattern is request/response. 

> 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.

But I am NOT asking to send to a different node. I'm the same "node";
I just want you to put the reply over there instead of over here.
Thus "node" becomes a logical concept instead of physical. 

> 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). 

I think the point was that as far as the client is concerned what
matters is that (s)he sends the message and somehow gets a response.
Whether the respponse arrives by reading the reverse half of a stream 
socket, or by reading a POP mailbox, or by opening an HTTP server
port and reading the POST to it, or by a carrier pigeon delivering
it, or by a UDP packet etc. is IRRELEVANT details to the client.

I support that view too. Without that we have not gained anything
with WSDL MEPs.

> 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).

If "client" includes everything from the application code to the 
middleware then I agree. If "client" is app code then I strongly
disagree! I certainly don't want to have to change my app code
because my company switched from using HTTP to using UDP.

Sanjva.

Received on Friday, 19 November 2004 19:48:12 UTC