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

I'm thinking more along the lines of the case where
everything is internal to one machine.  So, within
a single program a SOAP message is generated and
then a series of procedure calls are made - where
each procedure is in essence a SOAP Node.
In this case each Node doesn't forward on the message
to the next Node, rather the message is forwarded by
some controller (e.g. the code looping over each
SOAP Node procedure call).
I've heard people talk about using SOAP in lots of,
shall we say 'interesting', ways - not all of which
will require the message to actually leave a machine.
-Dug


"Jean-Jacques Moreau" <moreau@crf.canon.fr> on 10/15/2001 03:29:49 AM

To:   Doug Davis/Raleigh/IBM@IBMUS
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>
Subject:  Re: SOAP intermediary - issue 70 (cont'd)



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 09:09:40 UTC