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

Sounds good to me!  8-)
-Dug


"Jean-Jacques Moreau" <moreau@crf.canon.fr> on 10/15/2001 09:45:04 AM

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>,
      Jean-Jacques Moreau <moreau@crf.canon.fr>
Subject:  Re: SOAP intermediary - issue 70 (cont'd)



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".

Return-Path: <w3c-xml-protocol-wg-request@w3.org>
Received: from lancelot.crf.canon.fr ([194.2.158.66]) by
mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP
id GKZOWG00.9G8; Wed, 10 Oct 2001 14:19:28 +0200
Received: (from smap@localhost)    by lancelot.crf.canon.fr (8.11.4/8.11.4)
id f9ACWOM03514;    Wed, 10 Oct 2001 14:32:24 +0200 (MET DST)
X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to
<w3c-xml-protocol-wg-request@w3.org> using -f
Received: from smtp1av.net.oleane.net( 194.2.20.32) by lancelot via smap
(V2.0beta)     id xma003510; Wed, 10 Oct 01 14:32:12 +0200
Received: from VirusWall by smtp1av.net.oleane.net with ESMTP id
f9ACa1Zl022722;     Wed, 10 Oct 2001 14:36:02 +0200
Received: from www19.w3.org (www19.w3.org [18.29.0.19])      by
smtp1av.net.oleane.net (8.12.0/8.12.0/8.12-FT) with ESMTP id
f9ACZv8c022694;     Wed, 10 Oct 2001 14:35:57 +0200
Received: (from daemon@localhost)  by www19.w3.org (8.9.0/8.9.0) id
IAA21546; Wed, 10 Oct 2001 08:35:54 -0400 (EDT)
Resent-Date: Wed, 10 Oct 2001 08:35:54 -0400 (EDT)
Resent-Message-Id: <200110101235.IAA21546@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])     by www19.w3.org
(8.9.0/8.9.0) with ESMTP id IAA21512     for
<w3c-xml-protocol-wg@www19.w3.org>; Wed, 10 Oct 2001 08:35:49 -0400 (EDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])   by
tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA23773    for
<w3c-xml-protocol-wg@w3.org>; Wed, 10 Oct 2001 08:35:49 -0400
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com
[9.37.3.209])  by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA130548;
Wed, 10 Oct 2001 07:32:53 -0500
Received: from d04nm204.raleigh.ibm.com (d04nm204.raleigh.ibm.com
[9.67.228.13]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with
ESMTP id f9ACZHM227986;  Wed, 10 Oct 2001 08:35:17 -0400
Importance: Normal
To: Jean-Jacques Moreau <jjmoreau@acm.org>
Cc: Mark Nottingham <mnot@akamai.com>, w3c-xml-protocol-wg@w3.org,   Noah
Mendelsohn <Noah_Mendelsohn@lotus.com>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF8FB3A0AE.F3FB048E-ON85256AE1.0044B060@raleigh.ibm.com >
From: "Doug Davis" <dug@us.ibm.com>
Date: Wed, 10 Oct 2001 08:35:15 -0400
X-MIMETrack: Serialize by Router on D04NM204/04/M/IBM(Release 5.0.8 |June
18, 2001) at 10/10/2001 08:35:16 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: Extra agenda item (short) for Oct 3 XMLP telcon -- issue 70
Resent-From: w3c-xml-protocol-wg@w3.org
X-Mailing-List: <w3c-xml-protocol-wg@w3.org> archive/latest/2555
X-Loop: w3c-xml-protocol-wg@w3.org
Sender: w3c-xml-protocol-wg-request@w3.org
Resent-Sender: w3c-xml-protocol-wg-request@w3.org
Precedence: list
List-Id: <w3c-xml-protocol-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <
mailto:w3c-xml-protocol-wg-request@w3.org?subject=unsubscribe>

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 09:48:23 UTC