Extending the J2EE Deployment API For Disruption-free Service
Pages: 1, 2, 3, 4

Production Redeployment

The J2EE Application Deployment API outlines a basic redeployment strategy where an older version of the application will be replaced by the newer version. There is no mention about the state of HTTP sessions left in the container, so if you use this strategy and you redeploy an existing Web application that is in production, the existing HTTP sessions associated with this Web application will be destroyed. Also the application will be unavailable to the clients until it is reloaded by the container. This downtime may be minutes or hours depending on the size of the application being redeployed. In WebLogic Server 8.1, when you redeploy a Web application, the existing HTTP sessions associated with the application can be retained on the server by turning on a deployment descriptor attribute, save-sessions-enabled in weblogic.xml.

In WebLogic Server 9.1, to further address these challenges and to reduce the application downtime, a new deployment strategy called "production redeployment" or "side-by-side deployment " has been introduced. The old redeployment strategy of replacing the existing application is also available and named "on-place redeployment. "

The side-by-side redeployment feature in WebLogic Server 9.1 is a controlled process for deploying new versions of Web applications without needing to disrupt service. A new version of an application can be deployed alongside an existing version, and WebLogic Server will gradually migrate all the traffic to the new version. So when redeploying an existing application, the old version can be retired gracefully after all the existing sessions end. If required, a timeout can also be set to retire the old version of the application.

WebLogic Server 9.1 also includes the ability to roll back deployments. The server will automatically use the production redeployment strategy when the redeployed application version specifies a different version identifier than that of the currently deployed application. A developer can assign a version identifier to an application by specifying it in the manifest file of the application.

An Example of Production Redeployment

This section provides a brief, visual tour of production deployment. For more details, see the dev2dev article, Production-time Redeployment of Applications in WebLogic Server 9.0.

Developers can assign a version identifier to an application by specifying it in the manifest file of the application. Here is an example manifest.mf file with a version specified:

Manifest-Version: 1.0 
Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.) 
WebLogic-Application-Version: v1

The version identifier can also be assigned to an application by deployers during deployment or redeployment using the –appversion option of weblogic.Deployer tool:

java weblogic.Deployer -adminurl http://localhost:7001 
 -user system -password xx -deploy -name testds 
 -source C:/testds.war -targets AdminServer  
-appversion v1

Production redeployment can be performed either through the administration console or by using command-line tools such as weblogic.Deployer or WLST. Currently the administration console doesn't provide a mechanism to specify the application's version identifier—so the version identifier for an application has to be specified either on the manifest file or using the command-line option.

Administration Console Deployment

Now let's see how we can use the administration console to deploy a Web application. Later we'll see how we can redeploy the same application using the console. When using the administration console in WebLogic Server 9.1 you will start making changes by acquiring a lock over the configuration repository. The changes are left in a pending state and do not take affect until you activate them. This change management provides a predictable and secure way for distributing configuration changes in a domain.

So to start, you have to click the Lock & Edit button on the change center in the console to start deploying applications and finish by clicking the Activate Changes button on the change center. Start by clicking Lock & Edit:

Console Deployment - 1
Console deployment, step 1

To upgrade an existing application, select the application, and then click Update:

Console Deployment - 2
Console deployment, step 2

Select the path where the new version of the application exists:

Console Deployment - 3
Console deployment, step 3

Navigate to the location of the new version, and then select the new version of the application:

Console Deployment - 4
Console deployment, step 4

Specify how you want to retire the old version of the application, either gracefully or by timeout:

Console Deployment - 5
Console deployment, step 5

After you deploy the second version, activate the changes, and you will see two versions of the same application until the first one retires:

Console Deployment - 6
Console deployment, step 6

After the old version of the application retires, you will only see the new version as being active:

Console Deployment - 7
Console deployment, step 7

Using the command line

The weblogic.Deployer tool can also be used to redeploy the new version of an existing application. The old version of the application can be retired by specifying a –retiretimeout option for example:

Console Deployment - 8
Console deployment, step 8

Read Production-time Redeployment of Applications in WebLogic Server 9.1 for a thorough look at this tool.

Pages: 1, 2, 3, 4

Next Page »