- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Mon, 15 Oct 2001 10:24:32 -0400
- To: Jean-Jacques Moreau <moreau@crf.canon.fr>
- CC: Doug Davis <dug@us.ibm.com>, Mark Nottingham <mnot@akamai.com>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>, Noah Mendelsohn <Noah_Mendelsohn@lotus.com>
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