Hi, Let me add some more to this ;)
On Apr 7, 2005 10:07 AM, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: > > hi all, > > I am sorry the previous mail was with wrong subject so I am mailing it again > with correct subject. > > > > > 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 ( > www.apache.org/~deepal/axis2f2f/axiscontext.jpg ) > 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 that > 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 for > each service, i.e they act as global handlers. The main rationality behind > 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. > > > > How deployment work in new architecture (after face to face summit). > > Firstly it loads server.xml and using that creates EngineConfiguration (EC) > object which is more like EngineRegistry in old architecture. > Then if there are any module to be deploy then load them one by one > > 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 up, > EC gives an empty Module Context else it gives the previously saved (when > server shutdown) Module context corresponding to the module. > 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. For example, the security module ot WSA module may add some handlers to pre-dispatch phase. > 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 new > 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. > 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 gets > 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) > > > Next using above service context invokes init method of the service > implementation class. > Finally it will be added the created service to the EC. > > > > � At the run time for each message arrive, it invokes > engage(serviceChain , EngineContext) method of each and every module , then > 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 about > 1% their module developer can use either Phase rule or any other mechanism > to change the handler chain. 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. Regards, Eran Chinthaka > > > > > > > > Thanks > > Deepal -- -------------------------------------------------------- Eran Chinthaka
