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 03:46:29 UTC