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.
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!
- The WebSphere Contrarian: Options for Accelerating Application Deployment with WebSphere Application Server
- The WebSphere Contrarian: High availability (again) versus continuous availability
- Changing or adding application files
- Ways to update enterprise application files
- Maintain continuous availability while updating WebSphere Application Server enterprise applications
- IBM developerWorks WebSphere