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

Amy, it sounds like we're agreeing. The action item from the
F2F was to come up with a definition of "node" to enable
replyTo to work as long as the sending/receiving "enpoints"
are linked by "blood, marriage, oath, fire, orientation, 
gender, species, planet, language, or anything else."

Cool.

Sanjiva.

----- Original Message ----- 
From: "Amelia A Lewis" <alewis@tibco.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: <www-ws-desc@w3.org>
Sent: Saturday, November 20, 2004 2:55 AM
Subject: Re: Summary, 9-11 Nov 2004 WS Description WG FTF: two objections


> On Fri, 19 Nov 2004 19:56:13 +0600
> Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:
> > So, does this mean that the current in-out pattern can ONLY be
> > used with a bi-directional underlying transport? In particular,
> 
> I don't see why.  But it suggests that the replyto address ought to
> identify the same "node" as the requestor.
> 
> When the replyto address is permitted/expected to identify a different
> "node," then it's a different MEP.
> 
> > 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?
> 
> In this case, I would say that the correct use of the MEP is only when
> the replyto address is the "same node" (FSVO the term) as the "From"
> address.  Possibly a "logical" node, but presumably, if the address
> belongs to someone else running different software and hostile to my
> interests, they're not quite entirely the same node.  That is, "best
> practice" holds that for protocols that mandate replyto addressing and
> inband correlation, the current in-out MEP should have the same
> semantics that we've given it (which are based on HTTP's semantics).  If
> you wanna send the response to *some other node*, then the MEP ought to
> be a *different MEP* that permits that (as a best practice, mind,
> because once you've got the replyto address, there's no policing that
> this is what's actually happening).
> 
> > > 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
> 
> I'm not at all certain why the obsession with network connections, here.
> 
> > 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."
> 
> *shrug*  I don't believe that you can represent that as in-out in WSDL
> 2.0 as it now stands.  I agree it's an important use case, but it
> requires some sort of extension to enable it anyway.
> 
> > 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
> 
> It currently does, because WSDL 1.1 has a very limited vocabulary of
> MEPs.
> 
> > 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."
> 
> Unless they *aren't* a "node," and aren't linked administratively,
> corporatively, by blood, marriage, oath, fire, orientation, gender,
> species, planet, language, or anything else.  Which is the point. 
> Replyto can point at something which is definitely and emphatically
> *not* the same node.  We ought to provide a means of saying "this is the
> MEP you use then.  When you use the in-out pattern [that is, the current
> one], your replyto SHOULD identify the same node."
> 
> Amy!
> -- 
> Amelia A. Lewis
> Senior Architect
> TIBCO/Extensibility, Inc.
> alewis@tibco.com

Received on Saturday, 20 November 2004 13:48:26 UTC