The WebSphere Contrarian: The best way to install applications in WebSphere Application Server is...

It should come as no surprise that there are several options available for installing and updating applications in IBM® WebSphere® Application Server. What version of WebSphere Application Server you are running, which environment you are installing into, and how cautious you need to be will determine which option you choose. Here is some guidance to help you out. This content is part of the IBM WebSphere Developer Technical Journal.


Tom Alcott, Senior Technical Staff Member, IBM

Tom Alcott is Senior Technical Staff Member (STSM) for IBM in the United States. He has been a member of the Worldwide WebSphere Technical Sales Support team since its inception in 1998. In this role, he spends most of his time trying to stay one page ahead of customers in the manual. Before he started working with WebSphere, he was a systems engineer for IBM's Transarc Lab supporting TXSeries. His background includes over 20 years of application design and development on both mainframe-based and distributed systems. He has written and presented extensively on a number of WebSphere run time issues.

18 May 2011

Also available in Chinese

In each column, The WebSphere® Contrarian answers questions, provides guidance, and otherwise discusses fundamental topics related to the use of WebSphere products, often dispensing field-proven advice that contradicts prevailing wisdom.

It depends

In a past column, I discussed several procedures that could be employed to accelerate application binary distribution and deployment and, in turn, update and install applications. What I didn’t discuss is likely a more fundamental consideration, which is choosing the appropriate installation option.

Those of you who have heard me speak in person or read articles of mine can likely guess how I’m going to start in response to a question about choosing between application installation options: it depends. This is because each of the application installation options in IBM® WebSphere® Application Server has advantages as well as disadvantages depending on whether the target environment is for development, test, or production. As a result, an option that is suitable for one environment might not be the best option for another environment.

In WebSphere Application Server V6.x and V7, you can choose from these options:

  • Manual installation using the administrative console.
  • Automation using wsadmin or JSR-88 Java™ programs.
  • WebSphere Rapid Deployment.

In WebSphere Application Server V8, you will have two additional options:

  • Monitored directory.
  • Properties files.

Installation via the admin console likely needs little further explanation; basically the admin console graphical interface is used to specify the application file, the installation target (application server, cluster), and application binding information, with an application or application server restart occurring at the end of the process. Since this is a manual process, it’s probably most appropriate for development and prototyping environments for the initial installation of a new application.

Automated deployment, either using wsadmin or Java programs, where you specify the same information and follow the same process as described above for the admin console, is my preferred option for systems integration, production-like test (for example, quality assurance testing), and for production environments because automation provides the rigor and repeatable processes necessary for effective enterprise administration. As I’ve stated before, "point and click in the WebSphere Application Server admin console is not a repeatable process” and as a result, the admin console really isn't an effective interface for production configuration changes, especially for applications where there’s a stringent service level requirement. In fact, when I encounter customers using the admin console for production administration, there is universal recognition of the need to employ scripts rather than use the admin console.

WebSphere Rapid Deployment and monitored directory are two similar options that are best reserved for development environments. WebSphere Rapid Deployment can be used to install and update Java 1.3 EE and Java 1.4 applications, while monitored directory can be employed for Java EE 5 and Java EE 6 applications. Both of these options enable placement of application artifacts into a directory that is monitored with automatic application installation or update occurring once new or updated artifacts are detected, with hot deployment or dynamic reloading typically employed to avoid an application server restart. Properties files are a variation of monitored directory, where property files are used instead of application artifacts.

(There are some implementation differences between WebSphere Rapid Deployment and monitored Directory; there’s an Eclipse plug-in-based daemon process for WebSphere Rapid Deployment while monitored directory relies on already running administrative processes.)

By avoiding an application or application server restart, WebSphere Rapid Deployment and monitored directory are options that are targeted for developers who are concerned with rapidly testing code under development where updates are limited to a single JSP or class file. However, avoiding an application server restart introduces the possibility of class conflicts between classes on one classloader that was not recycled with classes on the classloader for the new artifacts. In a development environment, the impact of a conflict or problem is localized to a developer or development team, while in production, any issue likely impacts a much larger population of production application users. Additionally, in production -- or more precisely, in a clustered environment -- a series of application requests for a given client might be served from different application servers, with varying versions of the application and an inconsistent application view. (This can occur even with affinity a delay in application restart could be interpreted by the HTTP server plug-in as an outage, with the request being retried on another server.)

While not a substitute for stopping and restarting an application server, fine grained deployment is an option to consider for production if a single or very few files are being updated.

You could certainly limit production use of hot deployment and dynamic reloading to the supported scenarios in order to minimize the risk of a problem, but there’s a risk nonetheless, and that risk is greater than with compete application server stop and restart. Avoiding risk should be of paramount importance for any process dealing with production configuration or application changes. Moreover, if a problem does occur in production, stopping and starting the application server are likely to be required as part of the problem resolution process. As a result, my recommendation would be to make server restart part of any production process in order to avoid problems in the first place, as opposed to dealing with them as they occur (while you’re trying to meet production service levels). Further information on staggering application deployment and application server restarts to avoid service interruptions is available in this excellent article.

The best option?

What’s best is going to depend on the target environment, and while there’s no one-size-fits-all solution, I’d recommend that any updates or changes employing WebSphere Rapid Deployment, monitored directory, properties files, and the admin console be reserved for development. For production, the only option that provides a repeatable process is an automated mechanism such as scripting that employs complete application updates in conjunction with stopping and starting the application server.

In some cases, production use of fine-grained deployment via automation might be suitable for production if your configuration management process is mature, but keep in mind that any configuration management mismatches will result in a problem determination exercise, and I can think of many other ways I’d prefer to get my exercise!



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=The WebSphere Contrarian: The best way to install applications in WebSphere Application Server is...