Re: Summary, 9-11 Nov 2004 WS Description WG FTF: two objections

Hi Amy,

> Reading the minutes, I'm slightly disturbed by the overall hyperfocus on
> client/server models of networking.  Here, as in other places, there is
> a strongly-held assumption evident in the discussion that "service" ==
> "server" and the partner of the service is always a client.

Not at all, at least not for me.

> The definition of "node" in part two is intentionally vague (David Booth
> experienced interesting problems in the task force, trying to achieve a
> precise definition, because too tight a definition might mean, for
> instance, that a node which is a service cannot make use of its own
> interface as a client ... granted, a corner case, but ruling it out by
> definition seems to go a few steps too far).
> 
> For this issue: different names of nodes (A, B, C) imply that identity
> MAY be different, but do not require it.  A node of a given name has
> identity.  This is the only assertion about node identity that the
> message exchange patterns make.

We understood that.
 
> Therefore, for instance, in section 2.2.3, the use of a single node,
> named N, interacting with the service, absolutely precludes the
> participation of some other node (N1, O, M, whatever).  In the current
> request-response MEP, the request message comes from one particular
> named node, and both faults and responses MUST go back to that
> particular named node, because there is no other node mentioned in the
> MEP, and there is no flexibility permitted.

So, does this mean that the current in-out pattern can ONLY be
used with a bi-directional underlying transport? In particular,
if I'm doing SOAP/SMTP instead of SOAP/HTTP, then clearly I have
to use RFC822 ReplyTo (or the usual From: hackery) to figure out
where to reply to .. is that correct or incorrect use of the 
in-out MEP in your view?

> The "generalized" pattern of in-out would have a request from some node
> N1, a response to some node N2.  Whether N1 and N2 are the same node
> would be left unspecified.  They MAY be, but are NOT REQUIRED to be.

Even the SOAP request-response MEP does not require that the
response be delivered via the same network connection with the
bits going the other way. IMO we have to reflect reality that
its very natural for a node to originate a message via one
"connection" and receive a response via another "connection."
 
> According to the rules of features/extension, WS-Addressing/WS-MD or the
> equivalent is able to override the meaning of these MEPs in particular
> bindings, effectively highjacking the messages (rather than describing
> the MEPs accurately).  This is ugly, but it's the status quo at present.

I don't want the use of WS-Addressing to be "hijacking" anything.
If there's a problem with the status quo let's fix it .. IMO
use of ReplyTo is going to be pervasive and its silly for our
simplest in/out pattern to not support that properly without
having to introduce force!

> MEPs containing two messages all share these issues.  Wherever the "node
> N" interacting with the service is mentioned more than once in a MEP,
> there is potentially a parallel MEP, in which there is a node N1 and a
> node N2 (more likely with input-first MEPs than output-first; it is more
> common to redirect a response than to nominate an alternate respondent).

IMO this is unnecessary; we should just define "node" logically and
be done with it ... then messages can be sent and received at different
host/port combos (or whatever such beasts) which in combination is the
"node."

Sanjiva.

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