Re: [Axis Arch] Pluggable Registry (was: Sanjiva's walkthrough at F2F)

[Jacek Kopecky <ja...@idoox.com>]

 Hello. I've just read the whole discussion in the threads
re: Sanjiva's walkthrough at F2F and I see one main issue here.
 Please do slap me if this has been solved in an other thread, I
haven't read all the mail I've got in my queue.

 The issue lies in configuration. The issue is: Who loads and parses
the configuration file?
 a) The servlet's (transport layer's) config file contains the whole
initial configuration, the servlet (TL) parses it into DOM, gets from
there the name of the class to instantiate and to send requests to,
then calls init on that instance, passing throught the relevant part
of the DOM tree.
 b) The servlet's (TL's) config file only contains the name of the
class to instantiate, that class (the Engine) then does the config
loading and parsing (from a different place). There's no need for
init()ing the instance, so this class can be a PayloadHandler
actually, it's passed the messages created upon a request.
 c) The servlet's (TL's) config does not contain anything relevant,
the servlet (TL class) instantiates org.apache.axis.Engine (no need
for init() again), rest is as in b).

 I prefer the scenario b. Although it does split the config in two
parts, I think this is necessary if we want both to be
transport-layer-independent and started from servlet (the only usable
way using servlets as the TL). In cases we don't use the servlet TL,
it's the Engine that's started up first I guess, not the Transport
Layer. 

 Sticking to my scenario b, we don't require the Engine (Router,
Registry) if we use servlets (or other TL where the TL class is
started before the engine), in the other cases the Engine will be
needed, so then we won't be able to do direct TL->Handler, it will be
TL->Engine->Handler in the simplest case.

                            Jacek Kopecky
                               Idoox



On Fri, 22 Dec 2000, Ryo Neyama wrote:

 > Steve,
 > 
 > I don't think the registry is mandatory for the core SOAP engine, even
 > if it's implemented in Apache SOAP v2.  Of course, it will be nice to
 > have.
 > 
 > To me, the word "mandatory" seems to be a little ambiguous.  We should
 > define the word first.  In my definition, "a functionality is
 > mandatory for the SOAP engine" means that the functionality is
 > definitely requisite for the minimal set of SOAP engine and the engine
 > does not conforms to the SOAP spec without the functionality.
 > 
 > Generally speaking, an application that conforms to the SOAP spec can
 > be implemented without a registry.  Therefore the registry is not
 > mandatory to me.
 > 
 > We have to carefully consider the layering of the engine when we
 > discuss about the architecture, and clearly separate the core engine
 > and the other components like a registry, deployment tools, RPC
 > libraries, and so on.
 > 
 > Regards,
 >     Ryo Neyama @ IBM Research, Tokyo Research Laboratory
 >     Internet Technology
 >     neyama@trl.ibm.co.jp
 > 
 > From: "Steve Graham" <sg...@us.ibm.com>
 > Subject: Re: Sanjiva's walkthrough at F2F (was: Requirements - 2000/12/11)
 > Date: Fri, 22 Dec 2000 00:57:54 -0500
 > 
 > I see a registry as mandatory.  It is essentially an extension of the
 > ServiceManager concept already core in SOAP v2.0
 > 
 > ++++++++
 > Steve Graham
 > sggraham@us.ibm.com
 > (919)254-0615 (T/L 444)
 > <<Pithecanthropus Erectus>>
 > Emerging Internet Technologies
 > ++++++++
 > 
 > 
 > "Yuhichi Nakamura" <NA...@jp.ibm.com> on 12/21/2000 09:42:24 PM
 > 
 > Please respond to soap-dev@xml.apache.org
 > 
 > To:   soap-dev@xml.apache.org
 > cc:
 > Subject:  Re: Sanjiva's walkthrough at F2F (was: Requirements - 2000/12/11)
 > 
 > 
 > 
 > 
 > comment inline <yn></yn>
 > 
 > Yuhichi Nakamura
 > IBM Research, Tokyo Research Laboratory
 > Tel: +81-46-215-4668
 > FAX: +81-46-215-7413
 > 
 > 
 > From: "Steve Graham" <sg...@us.ibm.com> on 2000/12/21 21:43
 > 
 > Please respond to soap-dev@xml.apache.org
 > 
 > To:   soap-dev@xml.apache.org
 > cc:
 > Subject:  Re: Sanjiva's walkthrough at F2F (was: Requirements - 2000/12/11)
 > 
 > 
 > 
 > Yuhichi:
 > 
 > I am curious, you are proposing that registry has the chainable API, same
 > as handler/chain/chainContainer.
 > 
 > So the registry receives the invoke() message send, and its behavior on
 > invoke is to examine the contents of the (one or two (ISSUE1)) Messages,
 > determine the service name/operation being invoked, lookup the chainable
 > associated with that service/operation key and delegate the invocation to
 > the chainable returned by the lookup.  Is this what you were proposing?
 > <yn>Exactly.  I just replaced the term "engine" by "Registry."  You seem
 > to think it works, but feel strange.  Right?
 > </yn>
 > 
 > I believe at the F2F we discussed the notion of a Router.  A Router is a
 > chainable, it collaborates with the Registry to do the lookup and then
 > delegates to the result of the lookup.  I am more comfortable with this
 > division of tasks, keep the registry simple, add a Router chainable to do
 > the chaining behavior, collaborating with the registry.
 > 
 > <yn>Within Registry, Router can be invoked.  It's an implementation issue.
 > We can develop a registry I mentioned in this way.
 > Maybe, the dicussion point here is whether a registry is mandatory or not.
 > It is a requirement issue.  I am claiming that we should be able to
 > develop tiny applications without registry.</yn>
 > 
 > sgg
 > ++++++++
 > Steve Graham
 > sggraham@us.ibm.com
 > (919)254-0615 (T/L 444)
 > <<Pithecanthropus Erectus>>
 > Emerging Internet Technologies
 > ++++++++
 > 
 > 
 > "Yuhichi Nakamura" <NA...@jp.ibm.com> on 12/20/2000 11:30:00 PM
 > 
 > Please respond to soap-dev@xml.apache.org
 > 
 > To:   soap-dev@xml.apache.org
 > cc:
 > Subject:  Re: Sanjiva's walkthrough at F2F (was: Requirements - 2000/12/11)
 > 
 > 
 > 
 > 
 > Steve,
 > The following portion looks like a key to clarify the difference:
 > 
 > <sgg2>How can you go from TransportListener to dispatcher?  You need to
 > have some mapping to know which target web service (and therefore which
 > pluggable provider/dispatcher) needs to be invoked.  So I think the
 > Registry needs to be in the call chain somewhere.</sgg2>
 > 
 > First, I may ask: How can you go from TransportListener to Engine/Resigtry?
 > (This is not a important question :)
 > 
 > In my case, TransportListner has a reference to the next entity
 > (Handler or Consumer).  I assume that Registry and Dispatcher
 > has a same API, so TrsanpostListner has a reference to either
 > entities.  The idea here is that I want to develop tiny
 > applications as tiny as possible.  In my simplest example,
 > you only need listner and dispatcher, but do not need
 > big stuff such as engin and registry.  Even when incluing
 > ChainContainer, you may not need Registry either.  Based on our
 > pluggable architecture, such flexibility is possible.
 > Do you agree that Registry can be viewed as Handler/Consumer?
 > 
 > For lifetime management, yes, you can do within ChainContainers.  In this
 > case,
 > you can update chains and handlers, but you cannot update ChainContainers
 > (?).
 > Is there any pros and cons here?
 > 
 > Regards,
 > 
 > Yuhichi Nakamura
 > IBM Research, Tokyo Research Laboratory
 > Tel: +81-46-215-4668
 > FAX: +81-46-215-7413
 > 
 > 
 > From: "Steve Graham" <sg...@us.ibm.com> on 2000/12/21 04:35
 > 
 > Please respond to soap-dev@xml.apache.org
 > 
 > To:   soap-dev@xml.apache.org
 > cc:
 > Subject:  Re: Sanjiva's walkthrough at F2F (was: Requirements - 2000/12/11)
 > 
 > 
 > 
 > Yuhichi, sorry for the late reply.
 > <sgg2></sgg2>
 > 
 > ++++++++
 > Steve Graham
 > sggraham@us.ibm.com
 > (919)254-0615 (T/L 444)
 > <<Pithecanthropus Erectus>>
 > Emerging Internet Technologies
 > ++++++++
 > 
 > 
 > "Yuhichi Nakamura" <NA...@jp.ibm.com> on 12/19/2000 10:03:36 AM
 > 
 > Please respond to soap-dev@xml.apache.org
 > 
 > To:   soap-dev@xml.apache.org
 > cc:
 > Subject:  Re: Sanjiva's walkthrough at F2F (was: Requirements - 2000/12/11)
 > 
 > 
 > 
 > 
 > Comments inline <yn></yn>
 > 
 > Yuhichi Nakamura
 > IBM Research, Tokyo Research Laboratory
 > Tel: +81-46-215-4668
 > FAX: +81-46-215-7413
 > 
 > 
 > From: "Steve Graham" <sg...@us.ibm.com> on 2000/12/19 22:06
 > 
 > Please respond to soap-dev@xml.apache.org
 > 
 > To:   soap-dev@xml.apache.org
 > cc:
 > Subject:  Re: Sanjiva's walkthrough at F2F (was: Requirements - 2000/12/11)
 > 
 > 
 > 
 > Yuhichi:
 > <sgg></sgg>
 > 
 > Yuhichi wrote:
 > 
 > >Steve and James,
 > >It seems difficult for me to follow the discussion, but ...
 > >In F2F, Sanjiva drew a behavior of the engine as follows:
 > >  TransportListner--(invoke)-->Engine--(invoke)-->ChainContainer -->
 > >(Sorry, I am not sure if I remember it correctly.)
 > <sgg>at the highest level view, it looks pretty much like what we worked up
 > during the session </sgg>
 > 
 > >According to me, Engine should be called Repository (or Contianer pool)
 > >which manages multiple ChainContainers to forward incoming request
 > >one of them.
 > <sgg>In OO speak, I believe an engine HASA chainContainerRegistry (and a
 > handlerRegistry) but I don't believe an Engine ISA registry.  </sgg>
 > <yn>(If I am right) He mentioned that "engine" chose a ChainContainer
 > with an incoming request.  Therefore, I restated "Registry(Repository)"
 > instead of "engine."  Do you have "Engine" class/interface in your
 > mind?</yn>
 > <sgg2>The thought was that the engine uses some indication in the incoming
 > message (eg namespace on the soap envelope) to identify what "kind" of
 > message this is.  This information is used as a lookup in to a
 > deployedServicesRegistry to retrieve the chainable (usually chainContainer,
 > but could be chain, or could be a single handler).  The chainable is sent
 > invoke() passing in a message object (one or two depending on outcome of
 > ISSUE1).  So, yes there should be an Engine class that describes the
 > relationship between deployedServicesRegistry and other environment
 > things.</sgg2>
 > 
 > >Is the conclusion you had along this idea?  Otherwise, I am happy if you
 > >(esp. Steve) map your idea to the engine behavior we drew.
 > 
 > >Yes, even ChainContainers are pluggable, so you may invoke a
 > >payload processor without ChainContainer if you do not need any
 > >header processing.
 > <sgg>It may be as you say, no chainContainer, or perhaps a chainContainer
 > that is "empty".  Functionally the same, but the "empty" chainContainer
 > avoids an exceptional situation in the architecture.  Probably
 > implementation detail.  There will most likely always be a chain container,
 > first, the global one (derived from global WSDD).  Second, the dispatcher
 > (pluggable provider to) that invokes the target web service is a handler.
 > At least that is the current thinking and we need to understand Yuhichi's
 > ISSUE better.</sgg>
 > <yn>I considered a simple (the simplest) case, i.e. Transport Listner
 > just invokes the dispatcher directly.  In this case, we do not need
 > even a chainContainer.</yn>.
 > <sgg2>Yes, in this case you do not need chainContainer.  The key is that
 > the deployedServicesRegistry holds onto chainables, chainContainers, chains
 > or handlers.  Depending on the deployment of the service, the lookup will
 > return one of these, normally chainContainer, sometimes, as in your case,
 > just a dispatcher (handler)</sgg2>
 > 
 > >  Furthermore, to me, Repository (Engine in the
 > >above figure) is also pluggable.  Therefore, if you do not need
 > >lifetime management etc., you just invoke ChainContainer or
 > >payload processor directly.
 > >Thoughts?
 > <sgg>I had not imagined the registry (repository) itself would be
 > pluggable.  I had imagined that the registry is a simple lookup table,
 > potentially with some sort of pluggability at the persistence layer.
 > Perhaps the class which implements the registry interface is configurable
 > in the engine.  I had imagined that alot of the lifecycle management would
 > happen at the chainContainer level (ie something more specific to the
 > target web service itself, and therefore could understand the target web
 > service's lifecycle scope as deployed).  The chainContainer could do
 > lifecycle management by how it implements the invoke() method (ie on invoke
 > (), it delegates invoke() to one of a pool of chains, or delegates invoke()
 > to the chain associated with the session (based on some session
 > identification derived from the Message object).</sgg>
 > 
 > <yn>I had imagined that chainContainers are simple entities, each of
 > which contains three chains (input/output/fault).
 > <sgg2>I agree mostly.  I agree chainContainers are simple, however they
 > could embody complexity such as pooling etc.
 > Technically, the chain container could contain a "normal" (combined input
 > output chain), or an input/output chain pair with a dispatcher as "pivot
 > point".  Also, there could be several fault chains.</sgg2>
 >   On the other hand,
 > the registry looks up chainContainer table, and invokes appropriate one
 > per request as in Sanjiva walk-through.  Furthermore, it does lifetime
 > management.  The idea here is that ChainContainers, Dispatcher and
 > Registry have a same interace ("Handler" in your term, "Consumer" in
 > my term).  I may draw the following figure:
 >    TransportListner-->Registry-->ChainContainer -->Dispatcher
 > As I mentioned before, the simplest case is as follows:
 >    TransportListner-->Dispatcher
 > <sgg2>How can you go from TransportListener to dispatcher?  You need to
 > have some mapping to know which target web service (and therefore which
 > pluggable provider/dispatcher) needs to be invoked.  So I think the
 > Registry needs to be in the call chain somewhere.</sgg2>
 > 
 > This seems simple enough (to me).
 > </yn>
 > <sgg2>Do you think chainContainer does lifecycle management?  Can you
 > describe a little more please?</sgg2>
 > 
 > 
 > <sgg>As clarification, when you use the term "payload processor", are you
 > referring to the object we have been calling dispatcher, pluggable
 > provider, pivot point, etc.?</sgg>
 > <yn>Basically yes, but slightly different.  It indicates a module which
 > process body entries, therefore it should be a ultimate
 > destination module of a message path.  Dispatcher is equvalent to payload
 > processer only if it is in the ultimate destination application.
 > Pluggable provider is a payload processor, but it is specialized for RPC.
 > Pivot point is similar to dispatcher.  We may have to have a terminology
 > document.</yn>
 > <sgg2>I am proposing a Glossary appendix in the arch. doc.</sgg2>
 > 
 > <<attached emails in discussion chain snipped>>
 >