Re: mid-course correction on abstract model for module processing

Hi Mark,
Great job!  I have some questions and comments.

Module or Handler?:
In Stuarts Williams's abstract processing documents, module and handler
are explicity distinguished.  A module is a collection of blocks, and
a handler is a component which processes module(s).  I may just memorize
the terminology wrongly.

Actor:
In SOAP, an actor targets an "application" in my opinion because there is
no
handler concept.  Once we introduce the handler concept, should we
introduce
two kinds of actor attribute, i.e. applicationActor and handlerActor?
I am not sure how handlers and applications are properly targeted with
a single Actor attribute.

Removal of Blocks:
We had a long discussion on this in Apache Axis project.  In the
discussion,
I always a digital signature usecase.  Assume that there is a message that
includes SOAP digital signature header according to W3C SOAP Security
spec, and it is sent from a one company to another company.  The receiver
company wants verify the signature, and "log" the singed message only
when valid.  There are some ways of system configuration within the
receiver side, i.e. (1) a single SOAP application, (2) a Gateway (SOAP
intermediary)
and an ulitmate destination, and so on.  In this scenario, the sender does
not
care (even should no know) whether the signature header is logged.
I am not sure if giving "non-targeted" is responsibility of the sender.

Regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668


From: Mark Jones <jones@research.att.com>@w3.org on 2001/03/16 05:26

Please respond to Mark Jones <jones@research.att.com>

Sent by:  xml-dist-app-request@w3.org


To:   jones@research.att.com, moreau@crf.canon.fr
cc:   Lynne.Thompson@unisys.com, SISAACSON@novell.com,
      frystyk@microsoft.com, John Ibbotson/UK/IBM@IBMGB, ksankar@cisco.com,
      marc.hadley@uk.sun.com, marting@develop.com,
      nick.smilonich@unisys.com, ohurley@iona.com, skw@hplb.hpl.hp.com,
      xml-dist-app@w3.org, ylafon@w3.org
Subject:  Re: mid-course correction on abstract model for module processing



Thanks for the comments.  As I mentioned in the AM meeting, I will be
updating this to reflect the glossary, but here are some quick responses.

     Date: Thu, 15 Mar 2001 17:44:34 +0100
     From: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
     To: "Mark A. Jones" <jones@research.att.com>
     Cc: Henrik Frystyk Nielsen <frystyk@microsoft.com>,
             Stuart Williams <skw@hplb.hpl.hp.com>,
             John Ibbotson <john_ibbotson@uk.ibm.com>,
             Krishna Sankar <ksankar@cisco.com>,
             Lynne Thompson <Lynne.Thompson@unisys.com>,
             Marc Hadley <marc.hadley@uk.sun.com>,
             Martin Gudgin <marting@develop.com>,
             Nick Smilonich <nick.smilonich@unisys.com>,
             Oisin Hurley <ohurley@iona.com>, Scott Isaacson
<SISAACSON@novell.com>,
             Yves Lafon <ylafon@w3.org>, xml-dist-app@w3.org
     Subject: Re: mid-course correction on abstract model for module
processing

     Mark,

     Thanks for the rewriting and the hard work, although I must admit I
     preferred the original version. :(

     "Mark A. Jones" wrote:

     >   1. An XML Protocol Message consists of zero or more header blocks
     >      and one body block. [...]
     >
     There has been some discussion in the past as to whether we should
     keep the (somewhat artificial) distinction between headers and body.
     Are you suggesting that we should keep both, instead of just having
     blocks?

This will become zero or more blocks in a header and zero or more
blocks in a body -- blocks are various referred to as "entries" or
"parts" in SOAP.  The main distinction as I see it is where the
responsibility lies for generating responses.  Some handler in some
module at the destination must take on that responsibility, and having
a body makes a convenient place to designate that responsibility.

     Also, how would I be able to send two RPCs to an XMLP Receiver via a
     single XMLP Message if a Message can only carry one body
     block?

I don't think having multiple body blocks is a problem, but it seems
like a single module must be given responsibility for processing them
and determining a result.  In the case of header blocks, they can all
be individually targeted.

     >   1. Each header has an optional associated id (identifier), an
     >      optional actor and an optional mustUnderstand flag.  The body
     >      has an optional associated id (identifier) and an optional
     >      actor.  The body must be understood.  The id is an ID that
     >      identifies the block for the purposes of reference by other
     >      blocks.  The actor is a URI used by the XML Protocol Processor
     >      for determining which module to apply to the block. [...]
     >
     Noah has suggested (cf issue 41) that we use two different URIs, one
     for physically identifying the host, one for the identifying the
     service. Wouldn't this have an impact on the actor attribute?

I think the transport level needs to have a way of physically
identifying the host, since it has to eventually get the bits
to some computational engine.  The actor URI's on the other hand
are really naming either default or particular functionality
at the site.  They are really URN's IMHO.

     >   1. There are reserved actor URI's with special significance:
     >        http://.../none       // matches no module (i.e., an
     >      untargeted header)
     >        http://.../next       // matches a default module at the next
     >      processor
     >        http://.../final      // matches a default module at the
     >      final processor
     >        http://.../body       // matches the module selected at the
     >      final processor (can be used as a target for headers)
     >      [...]
     >
     Don't we need some lower level of granularity in these URIs, so we can
     address, for example, a particular handler?

Here's how I think about the dispatching rules.

(1) Some actors are like "locations":

  <m:foo xmlns:m="some-URI"  XMLP-ENV:actor="some-place-URI"> ... </m:foo>

  Here you think of the actor as a spce where the processor lives.
  SOAP has a predefined URI for the "next" place, for example.
  It could also be a URL (but probably not) or another means of describing
a place.
  In SOAP, the application/processor makes the handler dispatch
  presumably based on the m:foo tag.  In XMLP, we seem to be taking the
  view that modules know the rules, so you would think of
  "some-place-URI" as a default module for the place that knew how to
  select a handler and do the dispatch.


(2) Actors that are "modules":

  <m:foo xmlns:m="some-URI"  XMLP-ENV:actor="some-module-URI"> ... </m:foo>

  This seems to be the natural case to me.  The module
  ("some-module-URI") knows about the block types (such as m:foo)
  in its sphere of influence and it determines what handler to
  dispatch for m:foo, whether to treat it as RPC, etc.
  In the general, non-RPC case, a single handler
  may work on many different types of blocks.

     Also, shouldn't the URIs be HTTP agnostic, if we claim we are
     transport independent?

Generally, yes, but see above.

     >   1. When a header is selected for processing by a module at an
     >      intermediary, the header is removed from the envelope.  [...]
     >
     I am concerned by us automatically removing blocks as soon as they are
     consummed. I think there are cases where you do want to keep consummed
     blocks from one intermediary to the next, and I would be reluctant to
     us having to use the push(pop()) kludge, instead of solving the issue
     properly. If we really want this functionality, shouldn't we at least
     make it optional?

This is the purpose of "none".  Multiple targeted blocks could link
to a non-targeted block.  Each targeted block gets removed as it
finds a module capable of processing it, but the non-targeted blocks
would not be removed.  If the sender wanted to target several
different intermediaries/modules with the same info, he would include
separate targeted blocks linking to the common block.  Each targeted
block will disappear one-by-one, but the untargeted block would survive.

     >      The processing of a header may result in a fault or a
     >      successful evaluation.  A fault terminates processing and
     >      causes a return message containing the fault to be generated if
     >      a return path is available. [...]
     >
     Does a fault terminate all processing, including forwarding to the
     next hop; or does it only terminate processing at the current node,
     with forwarding still happening? The text probably requires some
     amount of clarification.

I currently see the simplest model as distinguishing between (1) a real
fault (no point in going on), and (2) not that serious, continue.  In
case (2), a block can be inserted into the message to reflect the
issue that arose and the response that eventually gets generated can
incorporate it if desired.


     I hope this helps,

     Jean-Jacques.

Thanks...

Mark Jones

Received on Friday, 16 March 2001 23:42:23 UTC