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

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 Friday, 12 October 2001 07:05:15 UTC