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

Testing Applications in Administration Mode

New application versions must be tested before opening them to external clients. You can do this in WebLogic Server by starting the application in Administration mode, which restricts access to the application to a configured Administration channel so that you can perform final testing without opening the application to external client connections or disrupting connected clients.

Admin Mode
Admin mode

Besides using the administration console, you can also start an application in administration mode from the command line:

java weblogic.Deployer -adminurl http://localhost:7001 
   -user weblogic -password weblogic -start  
                        
-adminmode
   -name /applications/CreditApplication
                      

An Administration channel can be created in a domain by enabling the Administration Port property of the domain. The default administration port is 9002. The Administration channel is a secured channel that will accept only SSL connections, and once the administration port is enabled in a domain, all the administration traffic must go through that secured port.

Let's see how you can use this to test a potential deployment. For example, if a Web application ( timeoff.war) with a context root /timeoff is deployed to a server in a domain with administration port 9002, then the application can be accessed by the following URL: https://serverhostname:9002/timeoff/. The administration console will indicate the state as "Admin," as shown in the following figure:

Testing Applications in Admin Mode
Testing applications in Admin mode

If you are happy with the testing, then the Web application can be started. Only after the application is started can external clients access it through the regular listen ports configured for the targeted servers. An application can also be started through other tools like weblogic.Deployer or WLST.

This feature, used along with production redeployment, can be used to isolate the new version of the application. While the old version of the application is still available for external clients without disruptions, the newer version of the application can be tested and subsequently deployed.

Module-level Deployment and Redeployment for Enterprise Applications

The J2EE Application Deployment API outlines the following types of application archives as deployable objects:

  • EAR
  • JAR (standalone module or EJB archive)
  • WAR
  • RAR

An EAR file is also outlined as a J2EE application object. The Deployment API outlines the association of a deployable object or a J2EE application object and a server or group of servers. But there is no mention about how to distribute the modules packaged with an enterprise application to different targets (servers or groups of server). With WebLogic Server you can target/associate individual modules packaged with an enterprise application to different server targets, or to deploy only a subset of available modules in an enterprise application. This provides flexible packaging options, allowing you to bundle a group of related modules together in an enterprise application, but deploy only selected modules to individual servers or clusters in a domain.

This module-level targeting provides fine-grained control in deploying modules in an enterprise application. Module-level targeting can be performed using any standard WebLogic deployment tools such as the administration console, WLST, or weblogic.Deployer. This can simplify packaging and distribution of applications by packaging multiple modules in a single, distributable EAR, but targeting only the modules you need to the respective servers in a domain.

Here is a simple module-level deployment example:

java weblogic.Deployer -adminurl http://localhost:7001 
  -user weblogic -password weblogic -name mywebapp 
  -targets welcomewebapp@server1 -stage 
  -deploy c:\files\myApp.ear

This command will deploy only the Web application module ( mywebapp) packaged as part of the enterprise application ( myApp.ear) and will target it to the server called server1 using the staging mode stage. See the deployment documentation for further details.

Summary

Live application upgrade is a major factor in achieving a disruption-free service. This article discussed the need for a deployment API, and extensions to the standard J2EE Application Deployment API found in WebLogic Server 9.1. These extensions, together with the other features in WebLogic Server 9.1, such as clustering, live server upgrades, the diagnostic framework, automatic server migration, the customizable administration console, and powerful scripting tools, allow you to achieve a high level of disruption-free service.

References

Additional Reading

Product Documentation

Balamurali Kothandaraman is a Senior Delivery Technologist for Education Services at BEA Systems Inc. He has over 8 years of experience in Java and J2EE technologies and is a BEA Certified Server Specialist, Administrator, and Instructor.

Takyiu Liu Takyiu Liu is with the education service of BEA, and has been training customers on J2EE topics with WebLogic Server for several years.