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

Jean-Jaques,

"and different from the..." seems a bit odd. How 'bout:

  A SOAP intermediary is a SOAP receiver, target-able from with a SOAP
      message, that is neither the intial SOAP sender nor the ultimate
      receiver of that message. It processes a SOAP message according to the SOAP
      processing model. A consequence of processing is that the SOAP message
      is forwarded further along the SOAP message path to the next SOAP node.

Cheers,

Chris

Jean-Jacques Moreau wrote:

> I see what you mean. Here's a variation on a definition you proposed earlier:
> 
>      A SOAP intermediary is a SOAP receiver, target-able from with a SOAP
>      message, and different from the intial sender or the ultimate
>      receiver. It processes a SOAP message according to the SOAP
>      processing model. Upon processing, the SOAP message is forwarded
>      further along the SOAP message path to the next SOAP node.
> 
> What do you think?
> 
> Jean-Jacques.
> 
> 
> Doug Davis wrote:
> 
> 
>>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".
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> Subject:
>>>>>>>>
>>>>>>>> Re: Extra agenda item (short) for Oct 3 XMLP telcon -- issue 70
>>>>>>>> From:
>>>>>>>>
>>>>>>>> "Doug Davis" <dug@us.ibm.com>
>>>>>>>> Date:
>>>>>>>>
>>>>>>>> Wed, 10 Oct 2001 08:35:15 -0400
>>>>>>>> To:
>>>>>>>>
>>>>>>>> Jean-Jacques Moreau <jjmoreau@acm.org>
>>>>>>>>
>>>>>>>>
>>>>>>>>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".
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Part 1.2
>>>>>>>>
>>>>>>>> Content-Type:
>>>>>>>>
>>>>>>>> message/rfc822
>>>>>>>> Content-Encoding:
>>>>>>>>
>>>>>>>> 7bit
>>>>>>>>
>>>>>>>>

Received on Monday, 15 October 2001 10:28:00 UTC