Re: Relating SOAP and XMLP Terminology and Message Processing

Mark Jones wrote:

>         The recent discussion on "Modules vs. Handlers" has articulated one fundamental
>         difference between the two: Modules are abstract, conceptual, specification
>         entities, whereas Handlers are concrete, tangible, runnable pieces of software
>         -much like Java Servlets, in a sense. Hence, I think XMLP ought to be targetting
>         Handlers -whether by type, name, property, physical location, or else-, rather
>         than Modules.
>
> I agree that there is a distinction between the terms.  Maybe I am
> thinking at a different granularity.  I think of a module as something
> like an object class -- something that encapsulates a collection of
> behaviors, expected inputs and outputs (e.g., block formats), etc.  I
> think of an individual handler as something like a method call.
> Indeed for RPC, it will be a method or procedure call.  I see an XMLP
> processor as a server which gets customized with a set of modules
> (classes).

I think we may use the same words to mean different things; so let me try to highlight the
differences/similarities:

  1. You have a two stage dispatching process (Block->Module->Handler), whereas I have one only
     (Block->Handler).
  2. Your Module is a cross between my notion of Application (a thing built out of a set of Handlers) and that
     of Handler (a concrete piece of software dealing with Blocks).
  3. Your Handler is at a lower level of granularity than "my" Handler.

> "Targetting" is a process of dereferencing names/descriptions to
> individual entities.  The real question is what component(s) know how
> to do the dereferencing.  Is it delegated to a module or handled
> entirely in the processor, for example?  If it is handled in the
> processor, how did the processor get configured with this
> application-specific mapping?  Or is the mapping very
> conventionalized?
>
> My earlier reply to Mark Nottingham gave a concrete example.
>
> Let block B = <m:foo xmlns:m="some-ns-URI"  XMLP-ENV:actor="some-actor-URI">
>                 ...
>               </m:foo>
>
> Let element tag T = m:foo
> Let       actor A = some-actor-URI
>
> Using the object-oriented view above, my favored solution was to think
> of the actor A as a reference to a module, and to let the processor
> delegate the responsibility to the module for targetting the correct
> handler (method).  It is still a handler that gets targeted.  The
> sender accomplishes the targeting by a combination of the tag T and
> the module A in the block.  The question is who knows about those
> internal methods (handlers) of the module -- how public or private are
> they?

I personnally see handlers implementing just one single, public, well-known method:
    public void handle(Blocks input, Blocks output)

In that model, there is no real need for the extra indirection you suggest.

> In the case of RPC, I will grant you that the tag T translates pretty
> directly into the handler name.  In that case, there isn't much
> translation for the module to do and the handler name is very public.
> For general XML markup, however, there need not be any direct
> relationship between the tag T and the handler that you want invoked.
> You could have the same handler H invoked on a wide set of elements
> with completely different tags.  In fact, I don't see why the tags
> couldn't even be drawn from different namespaces.  The processor would
> just ask the module (class) what the handler was for this element
> and then apply it (there would be some standard API for the processor
> to ask the module to return a reference to a handler).  In shorthand:
>
>         H = A(T)   // the module dereferences the tag to a handler (reference)
>         H(B)       // the handler is applied to the block (and possibly
>                    // other blocks destined for the same handler)
>
> For the tags that A (the module) knows are to be treated as RPC, there
> is a particularly regular mapping that, for example, turns tag T=m:foo
> into handler (method name) H=m:foo.

Doing dispatching by directly mapping from tag-name to method-name sounds attractive; but I am wondering
whether this does not make sense mostly for the RPC Module/Handler.

> To take a much different kind of non-RPC example, however, suppose
> that there is a module Archiver, with one handler, "store-XML".  It
> takes ANY block B with any tag T and stores it.  In this case
> Archiver(T) always returns the same handler, store-XML.
>
> B = <m:foo xmlns:m="some-ns-URI"  XMLP-ENV:actor=".../Archiver">
>      ...
>     </m:foo>
> [...]

Why not address the Handler directly?
    B = <m:foo xmlns:m="some-ns-URI"  XMLP-ENV:actor=".../Archiver/store-XML">

Jean-Jacques.

Received on Tuesday, 20 March 2001 06:45:24 UTC