W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

Re: SOAP intermediary - issue 70 (cont'd)

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Mon, 15 Oct 2001 09:29:49 +0200
Message-ID: <3BCA906D.332563E3@crf.canon.fr>
To: Doug Davis <dug@us.ibm.com>
CC: Jean-Jacques Moreau <moreau@crf.canon.fr>, Mark Nottingham <mnot@akamai.com>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>, Noah Mendelsohn <Noah_Mendelsohn@lotus.com>
So is this your scenario?

  1. A receives a SOAP message M
  2. A delegates processing to B
  3. B processes M, and generates a modified message M'
  4. B passes M' back to A
  5. A forwards M'

Jean-Jacques.

Doug Davis wrote:

> No, A->B->A->C isn't the scenario I'm talking about.
> I'm talking about the case where the actual forwarding
> is done by something outside of the SOAP nodes
> themselves (see my original scenario down below).
> The SOAP node just does processing and leaves
> any forwarding or routing to some external piece of
> code.  It's just a different way of viewing how SOAP
> nodes are invoked.
> -Dug
>
> Jean-Jacques Moreau <jjmoreau@acm.org>@w3.org on 10/12/2001 03:46:16 AM
>
> Sent by:  xml-dist-app-request@w3.org
>
> To:   Doug Davis/Raleigh/IBM@IBMUS
> cc:   Mark Nottingham <mnot@akamai.com>, "xml-dist-app@w3.org"
>       <xml-dist-app@w3.org>, Noah Mendelsohn <Noah_Mendelsohn@lotus.com>
> Subject:  SOAP intermediary - issue 70 (cont'd)
>
> [Switching to dist-app.]
>
> Then I think the term you are looking for is a SOAP node, not a SOAP
> processor.
>
> As for your second point, you seem to suggest the following path:
>     A -> B -> A -> C
> where A, B and C are SOAP intermediaries.
>
> We are arguing about B's role. Personally, I think B is both a receiver and
> a
> sender, ie. it does forward the (possibly modified) message back to A.
>
> Jean-Jacques.
>
> Doug Davis wrote:
>
> > They might, or might not, be on the same host - I don't
> > think it matters.  The spec doesn't say (rightly so) that
> > nodes or processors must, or must not, be on the same host.
> >
> > The text you proposed doesn't address my original concern
> > (about implying that it MUST be the intermediary that does
> > the forwarding), how about:
> >   A SOAP intermediary is a SOAP receiver but is not the
> >   ultimate destination of the SOAP message.  It is target-
> >   able from within a SOAP message, and MUST adhere to the
> >   SOAP processing model.  When completed with its processing,
> >   the SOAP message will be forwarded further along the SOAP
> >   message path to the next SOAP node.
> >
> > -Dug
> >
> > Jean-Jacques Moreau <jjmoreau@acm.org> on 10/10/2001 07:56:52 AM
> >
> > To:   Doug Davis/Raleigh/IBM@IBMUS
> > cc:   Mark Nottingham <mnot@akamai.com>, w3c-xml-protocol-wg@w3.org, Noah
> >       Mendelsohn <Noah_Mendelsohn@lotus.com>
> > Subject:  Re: Extra agenda item (short) for Oct 3 XMLP telcon -- issue 70
> >
> > Are the "controller" and "SOAP nodes" in your example below colocated on
> > the same host? If so, I
> > think your "SOAP nodes" are really "SOAP processors" colocated on the
> same
> > "SOAP node", and not
> > "SOAP nodes" themselves.
> >
> > This being said, I am beginning to think an intermediary may not do any
> > forwarding, for example if
> > it fails to find the next node or if there is an instruction (block) that
> > tells it not to forward
> > the message (if some condition holds, e.g.); but I guess this is the
> > exceptional case, not the
> > usual one?
> >
> > Trying to take previous input from you, Mark and Noah into accountw, what
> > about:
> >
> >      A SOAP intermediary is both a SOAP receiver and a SOAP sender,
> > target-able from within a
> >      SOAP message. It may process any block from the SOAP message (and
> not
> > only blocks
> >      targeted at itself) and may add new blocks to the message. It may
> > transmit the message
> >      further along the SOAP message path.'
> >
> > Here is a variation for the last sentence:
> >
> >      'It usually transmits the message further along the SOAP message
> path,
> > although if may
> >      not do so, for example if it fails to find the next node or one of
> the
> > message's block
> >      instructs it not to do so.'
> >
> > Jean-Jacques.
> >
> > Doug Davis wrote:
> >
> > > I think you're right - I think "SOAP sender" should probably be
> > > removed.  For why a SOAP intermediary does not necessarily
> > > do forwarding...seemy note at the bottom of this mail for my
> > > reasoning behind it.
> > > -Dug
> > > [...]
> > > > > > [issue]
> > > > > > Section 1.4.2: SOAP intermediary (et al)
> > > > > >   A SOAP intermediary is both a SOAP receiver and a SOAP
> > > > > >   sender, target-able from within a SOAP message. It processes
> > > > > >   a defined set of blocks in a SOAP message along a SOAP
> > > > > >   message path. It acts in order to forward the SOAP message
> > > > > >   towards the ultimate SOAP receiver.
> > > > > > This  last sentence seems to imply that intermediaries do
> > > > > > forwarding when in fact they might not do that at all. Do these
> > > > > > terms imply a certain implementation choice?  We typically think
> > > > > > of the processing model where messages are PUSHed to a SOAP node
> > > > > > and then that node will then PUSH it on to the next node.  I see
> > > > > > a mode of operation that might not fit all of the definitions as
> > > > > > stated above, for example:
> > > > > >   Each SOAP Node is invoked with the SOAP message thru a simple
> > > > > >   procedure call.  In this mode an intermediary doesn't forward
> > > > > >   on the message, it just returns (notice it might return "void"
> > > > > >   or it might return a SOAPEnvelope object depending on whether
> > > > > >   it is supposed to modify the message) it would then be up to
> > > > > >   the controller that is doing the call's to then determine which
> > > > > >   is the next SOAP node to "call".
Received on Monday, 15 October 2001 03:30:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT