axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe" <>
Subject [Axis2] Purpose Deployment changes
Date Thu, 07 Apr 2005 03:00:35 GMT
Hi all;

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 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.


How deployment work in new architecture (after face to face summit).

  a.. Firstly it loads server.xml and using that creates EngineConfiguration (EC) object which
is more like EngineRegistry in old architecture. 
  b.. Then if there are any module to be deploy then load them one by one 
    a.. 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.  
    b.. 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.
    c.. 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..
    d.. Next add that module to the EC.
    e.. Apply the same procedure for all the module.
  c.. Next check to see whether there are any module references in srever.xml if so
    a.. Gets the corresponding module (s) form EC and gets handlers of those modules.
    b.. And add those handlers to the Post-dispatch phase , (those handlers are not going
to be ordered at the deployment time)
  d.. Next if there are any service have been deployed (drop in to /service directory) then
load them one by one
    a.. Read it service.xml and using service name retrieve the corresponding "Service Context"
and while processing the xml file fill the Service context. 
    b.. Next check to see whether there are any module references if so gets handlers corresponds
to those. 
    c.. Next using above handler come from
      1..  modules (module references)
      2.. service specific handlers (defined in service.xml) 
      3.. 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)

    a.. Next using above service context invokes init method of the service implementation
    b..  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




View raw message