axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe" <>
Subject Re: [Axis2]Proposed Deployment changes
Date Thu, 07 Apr 2005 08:27:02 GMT
see my comments below;

> Hi all:
> Comments below.
> Eran Chinthaka wrote:
>> On Apr 7, 2005 10:07 AM, Deepal Jayasinghe <> wrote:
>>>At the axis2 face to face we did number of changes to axis2 architecture,
>>>had to get rid of EngineRegistry and introduce new set of contexts (
>>> )
>>>considering all those I will have to do some changes to the deployment
>>>module too. This mail describes purpose changes to that, so please read 
>>>carefully and feels free to give your comments and any suggestions.
>>>Pre-dispatch phase:
>>>This is a system inbuilt phase and which is not going to specify in the
>>>server.xml as available phase , and all the handlers in this phase run 
>>>each service, i.e they act as global handlers.  The main rationality 
>>>introducing phase like this is to provide a way to add global handlers by
>>>modules if they want.
>> If I add something more to this : We wanted somethings to happen
>> before any of the dispatch handlers run. For example, security, WSA,
>> erc., The name is just another name for a phase, but unlike other
>> phases this will be burnt in to the engine. All the other phases are
>> mentioned in the server.xml, or somewhere else, but we thought its
>> better even not to mention pre-dispatch phase in server.xml as if we
>> do that, one can go and delete that entry. So we will just put a
>> comment in the server.xml about this phase, but not an entry.
>> This pre-dispatch phase can be considered as another global scoped
>> phase, but these should before any of the dispatch handlers.
> Um - guys?  I don't recall talking about a "pre-dispatch" phase at all! 
> (?)  Where did this come from?
> IIRC, we just said that since you need to know the operation before 
> engaging operation-specific handlers/modules (which might actually include 
> security, etc), it's important to do this level of dispatch as early as 
> possible.  So if an HTTP handler figures out the operation based on the 
> action parameter of the MIME type, then great!  That just means the 
> operation specific (and by definition the service-specific also) handlers 
> can be merged onto the ExecutionChain by the OperationDesc (or whatever 
> we're calling the WOM Operation thing) really early on.
> We also discussed the idea that our "baked-in" phases might actually all 
> be immutable - there would probably only be a handful of these, such as 
> "decryption", "reliability", etc., but we'd fix the relative order of 
> those phases and make them always available even if nothing is in them, 
> regardless of configuration.  I don't think we settled on that as a path 
> forward, but it came up in the same discussion.
>>>Using its module.xml find the module name and then retrieve corresponding
>>>"Module Context" form EC. If this is the first time server gets started 
>>>EC gives an empty Module Context else it gives the previously saved (when
>>>server shutdown) Module context corresponding to the module.
> But it's up to the Module, not the engine, to figure out how to get the 
> context, right?  I.e. the Module would be the one doing any recovery from 
> DB or disk and filling in the ModuleContext in the appropriate place.


agreed , I have no objection regrading who is going to do the recovery 
process, but I think if it is going to do by module he can do it the way he 

>>>While processing the module.xml if there are any handlers with the phase
>>>property as "Pre-dispatch" phase then those handlers will be added to the
>>>Pre-dispatch phase by DeploymentEngine.
> Again, this doesn't match my recollection.  I thought that we just had all 
> the regular phases, like reliability, security, etc... and the Modules 
> just got to deploy anywhere they wanted within those (or define their own, 
> which I believe we did decide to move forward with).
> Oh, wait - maybe you were thinking of a "pre-dispatch ExecutionChain"? In 
> other words, there is a "global" set of Handlers which is going to run by 
> default.


Yup , that is what we are talking about , which is going to be run for all 
the services.

You know this chain before dispatch happens (it's the
> handlers+modules in the engine.xml), and that set acts as a template for 
> each individual MessageContext's "real" ExecutionChain.  So that set would 
> likely include, for instance, the WSA handler and the WSS handler - but 
> they'd still be deployed in whatever phases they wanted on the chain... 
> i.e. no actual phase called "Pre-dispatch" (unless you wanted to custom 
> build one, that is :)).
> Does this match others' understanding?
>> For example, the security module ot WSA module may add some handlers
>> to pre-dispatch phase.
> (see above)
>>>Then using the above Module context and EC, it calls the init() method of
>>>module implementation class , from that we give more flexibly for module
>>>developers to change the order of handlers in Pre-dispatch phase , add 
>>>handlers to that chain, if the module need to deploy a new service to do 
>>>that and etc..
>> this init() will only be called once and for all, during the life time
>> of the engine. Basically this will called during engine startup or the
>> corresponding module deployment ONLY.
>> If one needs to do some other stuff per message basis within the
>> module, use the engage(...) method.
> I'm wondering if Modules might need to do things like send messages 
> *after* all the other Modules are started, so that global policies get 
> correctly followed even during recovery.  If so, we might need some kind 
> of work-queue that Modules could add themselves to during startup to get 
> pinged again after everyone's ready (i.e. register for the "engine is up!" 
> event...).
>>>Next add that module to the EC. Apply the same procedure for all the 
>>>module. Next check to see whether there are any module references in 
>>>srever.xml if
>>>so Gets the corresponding module (s) form EC and gets handlers of those
>>>modules. And add those handlers to the Post-dispatch phase , (those 
>>>handlers are not
>>>going to be ordered at the deployment time) Next if there are any service 
>>>have been deployed (drop in to /service
>>>directory) then load them one by one Read it service.xml and using 
>>>service name retrieve the corresponding
>>>"Service Context" and while processing the xml file fill the Service
>>>context. Next check to see whether there are any module references if so 
>>>handlers corresponds to those. Next using above handler come from
>>> modules (module references) service specific handlers (defined in 
>>> service.xml) all the handlers in the Post-dispatch phase
>>>    Creates three kind of flows (or three kind of execution chains) 
>>> called
>>>1.      In-Flow
>>>2.      Out-Flow
>>>3.      Fault-Flow
>>>(Let's call those flows as serviceChain and those are also called pre
>>>compute handler chains)
> This was pretty confusing to read... :)
> Didn't we talk about needing in/out/infault/outfault chains (potentially 
> at each level global/service/operation)?  You might want to do something 
> very different for outgoing faults than for incoming ones....

Agreed, I remember that we discuss about in-fault-flow and out-fault-flow , 
so in the deployment time all the four kind of chains will be crated.

>>>Next using above service context invokes init method of the service
>>>implementation class. Finally it will be added the created service to the 
>>>ยท        At the run time for each message arrive, it invokes
>>>engage(serviceChain , EngineContext) method of each and every module , 
>>>the depending on the WS-police module will decide what to do to the
>>>serviceChain , 99% of the time it will do nothing. But if we consider 
>>>1% their module developer can use either Phase rule or any other 
>>>to change the handler chain.
> I thought we decided it was engage(chain, context) where context is simply 
> the generic Context interface, so that Modules can be reused easily at all 
> levels (it might be OperationContext, ServiceContext, EngineContext....)?

> Also, I don't think engage() is getting called as often as you think it 
> does.  That method gets called when a given Module learns that it should 
> be applied to a given chain.  So for the 
> [engine/service/operation]-specific Modules (ones that are referenced in 
> service.xml, say), that happens at init time, once.  If Modules are 
> *available* in the engine but not actually *engaged*, it's possible to 
> engage them at runtime via some Handler which is processing something like 
> policy metadata in an EPR.
> But engage() shouldn't always be called on every module for every 
> message - should it?  (it's late here, so maybe I'm misremembering, but I 
> didn't think we went there)
>> Its like this. When engine asks for an execution chain for a service,
>> or for an operation, the engine configuration will do the phase
>> resolving as usual for all the handlers, irrespective of whether they
>> are in a module or not. But even after that, the engine will call
>> engage method of each every module connected to the current message.
> >
>> Most of the time, we guess this engage method will do nothing. But if
>> one needs to do some handler manipulation even after phase resolving,
>> here is the time.
> Hm.  See above.  (?)
> --G


View raw message