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

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.

I don't agree with this at all.  one o or more  Block is an
instantiation of a module.
I thought ( and hope ) that we do not distinguish between them in the AM
document.

Stuart?

Yuhichi Nakamura wrote:
> 
> 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 Monday, 19 March 2001 07:13:58 UTC