JavaEE SE and JBI Runtime Service Assembly Management Contract

The JavaEE SE registers a JavaEEDeployer MBean on the DAS when it is started for target=server. As per our contract , before we deploy, undeploy, stop, start, shutDown a service assembly, we need to invoke the operation on this MBean first ( for each and every service unit targeted to the JavaEE SE ) and provide: service assembly name, service unit name and target name as parameters. We do this in our facade DeploymentService before any life cycle or deployment operations. For service unit/service assembly deploy and undeploy the JavaEEDeployer MBean deploy/undeploy operations perform the actual deploy of the service unit i.e. the application is deployed/undeployed to the actual target via the DAS.

In the current runtime facade DeploymentService managing service units targeted to the sun-javaee-engine is a two step process

1. The management operation is invoked on the JavaEEDeployer MBean first. For deploy/undeploy, this MBean does the real deployment. The component ServiceUnitManager operations for deploy/undeploy are a no-op. Even before the facade proceeds to perform the actual operation on the instance ( Step 2 below ) the management operation is invoked on the JavaEEDEployer MBean for each service unit targeted to the JavaEE SE.
2. The management operation is invoked on the DeploymentService on the target instance ( instances in the cluster case )

It is not possible to collapse the JavaEE service assembly management into a single step since :

• Step 1 needs to be performed so the DAS is aware of the applications being deployed to a target. Instances cannot inform DAS of applications being deployed to a target.
• Step 2 is required by the JBI runtime so that an instance is updated with the service assembly deployment status. If we skip step 2 for deploy we will not be able to perform any lifecycle operations on the assembly and cannot undeploy the service assembly since the instance will not have a record of the service assembly.

Issues to be addressed

If the operation is deploy/undeploy and Step 2 above fails then Step 1 needs to be rolled back otherwise the JBI runtime is left in a bad state. For example consider the case where a service assembly with two service units, both targeted to the JavaEE SE is deployed and step 1 succeeds and step 2 fails, we are left with two service units actually deployed to the JavaEE SE, but the JBI runtime has no record of the service assembly since the facade DeploymentService depends on Step 2, for determining success in the service assembly deploy.

Since recovery from failed service assembly life cycle operations is possible we only need to handle the deploy/undeploy scenarios.

Failure Use Cases for deploy/undeploy and recovery solutions

• Case 1 : Service assembly with two service units both targeted to the JavaEE SE, one service unit succeeds and other fails in Step 1. The JBI runtime rolls back ( i.e. undeploys the deployed service assembly ) and deploy operation fails fast. This is the current implementation.

• Case 2 : Service assembly with two service units both targeted to the JavaEE SE, step 1 succeeds for both service units and step two fails. Solution : The service units deployed in Step 1 need to be undeployed. undeploy is invoked on the JavaEE Deployer MBean and both service units are undeployed.

• Case 3 : Same scenario as case 2, but service assembly has a third service unit targeted to HTTP BC which succeeds. With the rollback of the two JavaEE SE we have a partially deployed service assembly.

• Case 4 : Service assembly with two service units both targeted to the JavaEE SE, step 1 succeeds for both service units and step two fails only for the second service unit. Only the failed service unit is undeployed from the JavaEE Deployer MBean, so we have a partially deployed service unit.

• Case 5 : Service assembly with two service units targeted to JavaEE SE is successfully deployed to both the JavaEE Deployer MBean and the target instance(s). When undeploying this assembly, the service units are successfully undeployed from the JavaEE Deployer MBean, but fail undeploy from the instance. Solution : One cannot really rollback the undeploy from the JavaEE SE. The client gets back an exception indicating the undeploy failed. The user can attempt another undeploy or use a forced undeploy to undeploy the JavaEE SE, the JavaEE Deployer MBean undeploy operation should be a no-op ( and not throw an exception ) if the service unit is not deployed to the engine.

• Case 6 : Similar to case 5, the only difference being one service unit is successfully undeployed from the instance. The same solution as in 5, applies.

Use cases in * red need to be fixed in Sierra.

When target=cluster

For service assembly deploy step two is considered a failure if the service units fail deploy on all instances in the cluster. Even if one service unit targeted to the JavaEE SE is deployed successfully to a single instance, step 2 is a success for that service unit. For service assembly undeploy step two is considered a success if the service unit is undeployed from all instances in the cluster. If a service unit targeted to the JavaEE SE is not undeployed from even a single instance, the service unit fails undeploy.

This page (revision-5) was last changed on 20-Nov-07 01:38 AM, -0800 by JBIWIKI.
This page was created on 20-Sep-07 00:19 AM, -0700 by JBIWIKI.

More info...