In the last part of this three part series, we're going to look at some advanced topics and further considerations for running WebSphere effectively under UNIX, including monitoring, security and resilience.

Monitoring WAS
The immediate status of all WAS servers can be obtained using the command:

#serverStatus.sh -all

WAS processes can be listed using the command (Solaris):

$pgrep -f -l 'WebSphere.*java'

Current WebSphere process IDs are also written to files in the application server log directories (e.g., MyAppServer.pid).

The most effective way to monitor WebSphere and its applications is to request one or more known stable URLs directly from the application server. For example, either curl or the check_http plugin in the Nagios monitoring package can do this. You can optionally verify the contents of the response to be sure that the application is working correctly.

It's also useful to monitor the load (uptime) and memory usage on each system, since faulty application server processes often consume all the CPU time and/or virtual memory.

General Tips for Running WAS

• Run backupConfig.sh at regular intervals via cron on each installed WAS host. Ideally, copy each backup archive file to a remote system. Note that these files can be quite large, since they also contain a copy of every installed application.
• Review the section on WAS Security below and check the issues raised against your local security policy.
• Install the Tivoli Performance Viewer and Log Analyzer components from WebSphere on a desktop system, such as your PC (you may need the Windows version of the software for this).
• If you're developing shell scripts to manage WebSphere, it's worth sourcing the WAS setup script at the start since it provides a number of useful environment settings. For example, deployed application files can be found under ${WAS_HOME}/installedApps/${WAS_CELL}/ .
• WebSphere should be properly tuned for good performance under intensive loads. See the bibliography for suitable references.

WAS Scripting
Besides the administration console, WAS operations can be scripted using Java implementations of TCL and Python called JACL and Jython. These scripts are run using the wsadmin utility (wsadmin.sh). Scripts configure and control WAS via various method calls on different Java Management eXtension (JMX) objects known as Managed Beans (MBeans).

Unfortunately, there's no comprehensive documentation available on all the possible MBeans (their number and types vary depending on the WAS topology and installation). The syntax and use of MBeans is rather verbose and unfriendly. The best - in fact, the only - way to learn how to perform tasks via scripting is by example. (While wsadmin has a help facility, its contents are rather terse.) There are a number of sample scripts in the Infocenter, the Redbooks, and other online articles from IBM.

It's also difficult to debug faulty scripts except by running wsadmin interactively and entering the individual commands, since script error messages don't include line numbers. Despite these difficulties, scripting is very useful if you wish to configure and control a number of separate, identical WAS cells, or do the same operations repeatedly on a consistent basis. Scripting also offers a path towards automated WebSphere deployments and recovery procedures.

It may be easier to tackle the tasks that are simplest to script, better documented, and more frequently done first (for example, installing EAR files), and gradually develop more complex scripts as you gain experience.

Working with the wsadmin interface is easier if you have command line editing and history facilities. Although the program doesn't support this itself, the Open Source rlwrap utility can be used to add these features.

WebSphere Application Server Network Deployment
The base edition of WebSphere only supports a single node in a cell. WebSphere Application Server Network Deployment (WAS ND) is used to support and manage several nodes in a distributed cell. WAS ND is a separate product that can be installed either alongside the base edition or on a dedicated system. It provides a component called the WebSphere Deployment Manager (DMgr), which is a specialised application server process. The DMgr has a Web-based administration console very similar to the base edition, but with extra features for managing a cell containing more than one node. Distributed cells provide workload balancing, scalability, and resilience improvements via the use of clusters (groups of application servers running the same application). For example, user sessions can be migrated from a failed application server to another one in the cluster using the session persistence feature.

Existing node base installations are federated or added into a DMgr cell. During this process, their own adminconsole application is removed and they are henceforth configured from the DMgr. To accomplish this, a separate, dedicated server called the Node Agent is created on the remote node. New application servers can be created or cloned from existing ones on any node in the cell. However, there's no facility for making identical changes to several application servers simultaneously.