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

Hi,

	SOAP defines Actor as the recipient of a message and in that sense (for the
current discussion) the Application is the recipient. And the handlers are
extensions of an Application i.e. a handler by itself is an idle mechanism ;
only an application makes it alive and interesting. So your assertion that
Application = Actor is correct and application of course "contains"
handlers. (Remember, in an actual implementation they (handler and
application) could even be in different namespaces and communicating via
messaging, COM,CORBA,RMI et al. But logically Application "contains"
handlers for communication)

	On a related note, I assume the handler is the physical manifestation (=
XML protocol Processor), which processes XMLP messages which are modules
which in turn are made up of blocks. The distinction between a module and a
handler is not clear to me yet.

cheers

|-----Original Message-----
|From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
|Behalf Of Yuhichi Nakamura
|Sent: Friday, March 16, 2001 5:19 PM
|To: Mark Jones
|Cc: xml-dist-app@w3.org
|Subject: 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 Saturday, 17 March 2001 02:53:57 UTC