- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Mon, 15 Oct 2001 09:29:49 +0200
- To: Doug Davis <dug@us.ibm.com>
- 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>
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 03:30:10 UTC