Differences between revisions 4 and 5
Revision 4 as of 2004-10-29 09:44:22
Size: 5012
Editor: 224
Revision 5 as of 2009-09-20 22:48:54
Size: 5016
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 105: Line 105:
http://ws.apache.org/~hemapani/images/DeployArci.png {{http://ws.apache.org/~hemapani/images/DeployArci.png}}


Hot Deployment

Hot deployment is consists of three basic scenarios

  • Hot Deployment

  • Hot un deployment

  • Hot update

Note: In the current implementation Hot update handle as hot un deployment followed by Hot Deployment. Hot update is similar to removing a service (or module) and adding a new service (or module).

In deployment it can deploy either or both modules and services. But there are two different directories for both modules and services those directories as follows;

  • WEB_INF/modules
  • WEB_INF/service

To have hot deployment it should have to deploy module or service as a axis archive file (.aar) otherwise it wont detect as a deployable file.

For module archive file that should follow the following directory hierarchy;


For the service archive file should be in the following directory hierarchy.


The rough format of module.xml file looks like as follows;

<module ref="xs:anyURI" | (name="xs:anyURI" class="...")>

And the service.xml file looks like as;

<service provider="xsd:string style="xsd:anyURI" contextPath=”xsd:string”>
  <parameter .../>*
  <typeMapping> ... </typeMapping>*
  <beanMapping> ... </beanMapping>* [re-visit for lang indep]
  <operation name=".." qname="..." style=".." use="..">
    <module ref="uri">
      <parameter ../>*
    <serviceref =”xsd:string”/>

Hot Deployment Architecture

The architecture of hot deployment consists of the following components;


This component itself is a thread and which perform a specific task forever in given time interval. In this case it is periodically inform to Listener to listen to the file system events. Here the file system is not the entire file system it is only the sub directories of WEB_INF that is modules and services.


As mentioned above Listener listen to file system events, it checks both the modules and services directors to list all the .aar files in those directories. And then add all those loaded files into the Repository. And then it informs DeploymentEngine to update the system


This stores information about already deployed modules and services. At the initialization process this loads information about all the modules and services in the module and service directories. And then deploy all those loaded modules and services.

And it can perform following operation to Repository;

  • Add new entry to Repository
  • Remove entry from Repository ,and
  • Modify entry in the Repository.

Those operations correspond to Hot Deployment, Hot unDeployment and Hot Update.

In the add operation it check whether the entry which is going to add already in the Repository if so it ignore the operation else it will add the entry to Repository and also it would add an entry to a list maintaining in DeploymentEngine (toDeploy list).

In the remove operation it directly remove the entry from the repository and will add an entry to a list maintaining in DeploymentEngine (toUnDeploy list)

In modify operation it will add entry to both the list in DeploymentEngine.


This component will perform the real deployment and un deployment. If there is some entry in the toUnDeploy list then first it un deploy those modules and services, thereafter it check the toDeploy list if there are entries (or entry) in that list it will give one by one to Schema Parser to parse and create either a service object or a module object (depending on whether the entry is service or module).

Schema Parser

This module is to parser the following three xml documents;

  • server.xml
  • service.xml
  • module.xml

And this is based on XML pull parser (xpp).


  1. Periodically inform to listen to the given (specified) directory
  2. Add entry to Repository
  3. Repository gives the document to parse
  4. Return the objects correspond to the document
  5. update the toDeploy and toUnDeploy list
  6. inform Listener to update system
  7. inform DeploymentEngine to do update (both deploy and undeploy)


In the case of un deployment and Hot update, DeploymentEngine will check whether the service which is going to undeploy or hot update is currently in use i.e. it will check there is a request for that service. If so it will delay the operation (undploy or update). That information has to get from the axis engine, since it is not fully implemented yet those checking have to be implemented.

FrontPage/Architecture/Deployment/Architecture (last edited 2009-09-20 22:48:54 by localhost)