Mobicents Deployment Architecture

Author: Jean-Noel GADREAU (jngadreau@dev.java.net)

The JBoss deployment architecture

JBoss uses the org.jboss.deployment.MainDeployer to deploy the various elements (EAR, JAR, SAR, ...). For each kind of deployed target, a specific deployer is defined. This deployer is a subclass of org.jboss.deployment.SubDeployerSupport.

The MainDeployer and SubDeployerSupport classes use the org.jboss.deployment.DeploymentInfo class to store information about the deployment. It contains information such as:

TODO: may add more details here if needed

The current mobicents deployment architecture

DeployableMBeanImpl and DeploymentManager

Every mobicents deployment starts by the DeploymentMBeanImpl. It is called (using JMX) by the client to deploy a DeployableUnit (using the "install" method). This will cause a DeploymentManager to be created and used to deploy the DeployableUnit (DU). This will copy the DU file locally, and then use a DeployableUnitDeployer to perform the actual deployment.

DeployableUnitDeployer

The 'deploy' static method creates a DeployableUnitDeployer, initializes it, and then 'deployUnitContent'.

The 'deployUnitContent' is where the actual deployment starts. First, the "deployable-unit.xml" file is parsed. For each JAR file indicated in the deployement descriptor, an instance of AbstractComponentDeployer. The actual instance created depends on the type of component being deployed.

The different types of AbstractComponentDeployer are:

The deployment of the various elements is done in several steps. First, all the EventTypeComponentDeployer are called, and then the others are called. Finally, ServiceDeployers are created for all the <service> tags.

Each sub-deployer is first initialized (initDeployer) and then deployAndInstall is called.

Sub-deployers (AbstractComponentDeployer subclasses)

The 'initDeployer' method is in charge of parsing the XML descriptor to create. The parsing is performed by a specific parser (XXXXDeploymentDescriptorParser) and will create a list of XXXXDescriptorImpl instances.

The 'deployAndInstall' method is in charge to extract the JAR contents into the classpath. It then takes all the XXXXDescriptorImpl instances and casts them as DeployedComponent. Each is then checked (DeployedComponent.checkComponent()) and then installed using the SleeContainer's install(DeploymentComponent) method.

SleeContainer deployment role

TODO: explain this
	- install(DeployedComponent) method
	- all the DeployableUnit-related methods

The proposed architecture

DeploymentMBeanImpl

This class is the implementation of the DeploymentMBean, which is accessed via JMX to install a new DeployableUnit (DU). It delegates all the DeployableUnit related methods to the DeployableUnitManager class.

DeployableUnitManager

The DeployableUnitManager handles everything that relates to DeployableUnits. It keeps tracks of all the DeployableUnits. It implements the following methods of the DeploymentMBean:

It also provides the following API:

Note: Part of this API was implemented by SleeContainer before. It is centralized in the DeployableUnitManager, which makes the SleeContainer simplier.

To install the DU, the DeployableUnitManager uses the standard JBoss mechanism by calling the MainDeployer 'deploy' method.

JNG: For the uninstall, need to define exactly how it is going to be implemented. Start with MainDeployer.undeploy

MainDeployer, DeployableUnitDeployer and other deployers

The MainDeployer is used as is. The only thing is that new SubDeployers are registered to handle all the SLEE deployment features. All those SubDeployers inherit from AbstractSleeDeployer.

Those deployers are installed in JBoss via the jboss-service.xml file in the jboss-slee.sar. TODO: detail more here

AbstractSleeDeployer

This class (subclass of SubDeployerSupport) provides common features to all the deployers:

DeploymentInfo content for Mobicents

The org.jboss.deployment.DeploymentInfo is central to JBoss's deployment architecture as it holds all the information about a deployment. Here is a table rassembling information about each field of DeploymentInfo and how it is used in the particular case of Mobicents. When the field is used exactly the same way as in JBoss, the indication "Standard JBoss" is used.

Field Name Description
url URL used for the deployment. This is basically the one provided when deploying. (Standard JBoss)
localUrl URL of the local copy of the deployed target. (Standard JBoss)
watch This contains the URL that will be watched to know if the target has changed and should be redeployed. QUESTION: What is the behavior we want here ? I suppose that at best, only the DeployableUnit.jar should be watched (when expanded directory, watching the META-INF/deployable-unit.xml). However, this may not be a good idea so your input is welcome. For other types of deployers, I think it would be better not to allow redeployment (no watch)
shortName Short name of the file containing the deployed target. (Standard JBoss)
lastDeployed TODO: give a little explaination (self explainatory) (Standard JBoss)
lastModified TODO: give a little explaination (self explainatory) (Standard JBoss)
status String indicating the current status of the deployment. This can contain some text description. (Standard JBoss)
state Field indicating the current state of the deployment. (Standard JBoss)
deployer Deployer that is associated with this deployment. Depending on the type of the component deployed, this will vary. (Standard JBoss)
ucl UnifiedClassLoader. TODO: get a better understanding of the UCL for the various components
localCl URLClassLoader that is used for metadata loading (the XML files). It is (always ???) based on di.localUrl and is setup by the JBoss standard mechanisms. This is the ClassLoader that needs to be used when parsing the XML files to generate the XXXXDescriptorImpl instances.
classpath TODO: explain how it works and how it will be used
mbeans TODO: explain how it works and how it will be used
subdeployments This contains the subdeployments associated with this deployment. This is only used by the DeployableUnitDeployer to contain the DeploymentInfo for all the components in the DU.
For all the other deployers, this will not contain anything as there are no subdeployments.
parent DeploymentInfo of the parent deployment. This is null for the DeployableUnitDeployer (because it is the root deployer). For the other deployers, this is the DeploymentInfo associated with the DeployableUnitDeployer.
webContext This is null (no Web context for any SLEE deployment)
manifest TODO: will probably be needed in order to be able to reference JARs as 'Class-Path:' in the Manifest (see 3.1.9, page 27)
document DOM Document of the XML file of the deployment. QUESTION: should it be the "official" XML file (standard) or the Mobicents one ? (just like ejb-jar.xml and jboss.xml)
documentUrl TODO: See how this is used
metaData This is where JBoss stores all the metadata that was parsed from the XML descriptors. The deployers will put here the XXXXDescriptorImpl instances produced by the XXXXDeploymentDescriptorParser.

TODO: see if should be directly the XXXXDescriptorImpl instances or if it should be in a List (if there are several)

context TODO: See how this is used
isXML Indicates whether the deployed target is an XML file. (Standard JBoss)
isScript Indicates whether the deployed target is a script (.bsh file). (Standard JBoss)
isDirectory Indicates whether the deployed target is a directory. (Standard JBoss)
deployedObject TODO: See how this is used
repositoryConfig This is the configuration to define the classes repository used with the UnifiedClassLoader. TODO: See how this is used
server MBeanServer used for JMX operations. (Standard JBoss)

Concrete Classes Generation

Concrete class generation is done using Javassist API. The implementation relies on a ClassPool instance to provide representations of classes (CtClass objects).

In order for this generation code to work properly, it is important that the lifecycle of the ClassPool object is related to the lifecycle of a DeployableUnit. When the DU is uninstalled and reinstalled, a new ClassPool should be used in order to have the new version of the classes available.

TODO: see where to store the ClassPool object (how about in the 'context' field of the DeploymentInfo ?)