Re: Issue LC50 - MEPs

Hmm,

(oh, and cc's snipped again, *sigh*)

On Fri, 19 Nov 2004 20:18:32 +0600
Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:
> > 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. 

I think that we're arguing on different levels.  If TIBCO and IBM
execute an agreement such that TIBCO initiates a particular (agreed
beforehand) operation, setting the replyto address to somewhere at IBM,
it's certainly a single operation, and it's arguably request/response,
but it's unquestionably not a single node that's involved.

My contention is that when the response MAY be sent to a different node
than the requesting node, then a different MEP than the one we currently
have is required, because the current MEP identifies the requesting node
and the target of the response as identical.

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

But then we're not talking about the same thing, are we?  I'm talking
about situations in which the information MAY go to a different node. 
You're talking, I think, about a situation in which the address may be
different, but the ultimate processor is somehow supposed to be the
same.  I don't think that, with a replyto mechanism, you can guarantee
that the response is delivered to the same node, however defined.  So
it's significant to have the ability to distinguish between "the
response is always returned to the same node" request/response and "the
response could go to some other (known-in-advance, but possibly not the
same as the requesting) node".  These *are* different MEPs.  IMO.  It's
useful information to place into the WSDL.

This implies, then, that there might be a best practice for use of
WS-Addressing: in request-response constrained to same-node (our current
MEP), the requestor *ought* to insure that the reply-to address is
somehow associated with itself.

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

My objection to this stuff is not that it's possible to do code
generation.  It's to the constraint of WSDL to be *no more* than a code
generation language.  Code generation is not enough.

> 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 agree in principle, but so far as I know, there is no way of
specifying multi-transport operations in WSDL as it currently stands. 
Are you suggesting that WS-Addressing or WS-MD or some other mechanism
is already able to define such operations?

Can we agree that this is only one of the use cases for replyto? 
Another, very important use case is something like internet mail, or
jms, in which every message must carry correlation and destination and
replyto information, because there is no built-in return path, as there
is in http.  For these protocols, it is certainly useful to be able to
distinguish, in the wsdl, between request/response (return to sender)
and request/response (third-party notify).

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

WSDL MEPs currently say nothing about multi-protocol exchanges, and to
the best of my knowledge and belief, WSDL 2.0 as it currently stands
cannot describe such an exchange.  Am I missing something?

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

Sorry, we're talking code generation again?  I'm not certain I know
where you're drawing the boundaries, you see.

If the UDP exchange is defined to be "always return to sender," then
there's no change to "application" code (well, depends on just exactly
what you're doing, and how you're doing it, but no necessary change, it
seems to me).  If the reason for switching to UDP is so that the
response can be sent to that-department-over-there, then yes, I'd say
the WSDL changes (to third-party r/r), since it's a different node.

I'm not certain I want to define what a node is.  It's enough, to me, to
note that even the most broadly-defined "node" can't always be the
recipient of the response message for a request, unless you use the
meaningless definition "not the service" (well, you can't even do that,
since the service could be talking to itself, rather like i'm probe to
do).

Are there cases in which a replyto directs a message to a *different*
node than the requestor?  For any definition of node you like, mind, so
long as it's actually a definition and not a universal.  If so, it seems
to me that *that* is a different MEP, and that permitting *that* ought
to require a different MEP, one that explicitly does not state identity
of requesting node and response target node.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 19 November 2004 20:45:35 UTC