Product Description

IBM WebSphere Application Server (WAS), a software application server, is the flagship product within IBM's WebSphere brand. WAS is built using open standards such as J2EE, XML, and Web Services. It works with a number of Web servers including Apache HTTP Server, Netscape Enterprise Server, Microsoft Internet Information Services (IIS), IBM HTTP Server for i5/OS, IBM HTTP Server for z/OS, and IBM HTTP Server for AIX/Linux/Microsoft Windows/Solaris.

The main features found in IBM Websphere Application Server are:

• JAX-RPC Support - JAX-RPC 1.1 allows the reuse of legacy Java assets as web Services.

• Websphere Integration - As it is part of the core Websphere range of products, Websphere Application server integrates seamlessly into a Websphere environment.

• Administration Tools and Documentation - Websphere Application Server comes shipped with a set of integrated Administration Tools and documentation and samples to help you get started with the minimum of fuss.

The Operating Systems that are currently supported by Websphere Application Server are Windows 2000 and above (though older versions may work on NT 4), Linux and Unix distributions.

Known Versions

• 1
• 1.1
• 2
• 3
• 3.5
• 4.0
• 5.0
• 5.1
• 6.0.0.1
• 6.1
• 7.0
• 8.0

Software Pattern Summary

Product Component	OS Type	Versioning	Pattern Depth
IBM Websphere Application Server	Unix	Command, Path and Package	Instance Based
	Windows
IBM Websphere Application Server Node Agent	Unix	Path
IBM Websphere Application Server Deployment Manager

Platforms Supported by Software Pattern

The ApplicationServer pattern has been created in a manner that allows it to support Windows, Linux and Unix platforms from the same module; a Software Instance is created for each unique server, node and cell combination running on a host.

The Nodeagent and DeploymentManager patterns only identify instances of IBM WebSphere Application Server components on the Unix platform.

Identification

Software Instance Triggers

Websphere Application Server

Trigger Node	Attribute	Condition	Argument
DiscoveredProcess	cmd	matches	regex'(?i)\bjava(?:\.exe)?$'
	args		regex'com\.ibm\.ws\.runtime\.WsServer.*[^(dmgr|nodeagent)]$'

Websphere Nodeagent

Trigger Node	Attribute	Condition	Argument
DiscoveredProcess	cmd	matches	regex'(?i)\bjava(?:\.exe)?$'
	args		regex'com\.ibm\.ws\.runtime\.WsServer.*\s\bnodeagent$'

Websphere Deployment Manager

Trigger Node	Attribute	Condition	Argument
DiscoveredProcess	cmd	matches	regex'(?i)\bjava(?:\.exe)?$'
	args		regex'com\.ibm\.ws\.runtime\.WsServer.*\s\bdmgr$'

Simple Identification Mappings

The following processes are identified through the use of Simple Identifiers and are modeled within a full Software Instance for Websphere Application Server using the primary and associate relationships (See Application Model Produced by Software Pattern for more details about the modeling of this product).

Name	Command
IBM Websphere Application Server	java or java.exe followed by the WebSphere Application Server Class, com.ibm.ws.runtime.WsServer
IBM Websphere Application Server Service (Windows only)	wasservice.exe
IBM Websphere Admin Server (Unix/Linux only)	java followed by the WebSphere Admin Server Class, com.ibm.ejs.sm.server.AdminServer
IBM Websphere Managed Server (Unix/Linux only)	java followed by the WebSphere Managed Server Class, com.ibm.ejs.sm.server.ManagedServer
IBM Websphere Nanny (Unix/Linux only)	java followed by the WebSphere Nanny Class arguments, com.ibm.ejs.sm.util.process.Nanny
IBM Websphere Deployment Manager (Unix/Linux only)	java followed by the WebSphere Application Server Class, com.ibm.ws.runtime.WsServer, followed by the string "dmgr"
IBM Websphere Nodeagent (Unix/Linux only)	java followed by the WebSphere Application Server Class, com.ibm.ws.runtime.WsServer, followed by the string "nodeagent"

Versioning

Version information for this product is currently collected using one of four possible methods.

Active Versioning

For this active versioning technique, an XML file is identified in one of the directories found in the installation directory; the XML file contains information on the version and build of the specific instance of a specific installation.

The file is present in the same location on Windows and Unix and the base directory is identified using the same process, the only difference between the two is the command used to check if the file exists.

Unix, Linux and Windows

The installation directory for Websphere Application Server is identified using the "-Dwas.install.root" argument, by extracting the relevant path we are able to identify where on the file system the process is running from.

Using knowledge that has been provided by a SME we then check for the existence of a product file in the "properties/version" subdirectory.

This product file has a different name depending on the edition of Websphere Application Server that is installed. First we try to find the file using the following command:-

Windows: cmd /c dir "%install_root%\\properties\\version\\*.product"
UNIX/Linux: ls %install_root%/properties/version | grep "\.product"

In case the command result does not give us the file or the ADDM user does not have sufficient privilege to run this command, we perform a check for each of the known filenames, a full list of the editions can be found in the Editions section, below is a list of the filenames we check for.

Abbreviation	Product Filename
ND	ND.product
Base	Base.product
Embedded Express	embeddedEXPRESS.product
Express	Express.product
WAS	WAS.product
PLG	PLG.product

Each of the filenames is checked to see if it exists, when a file has been found it is opened and the following XPath expression is ran:

XPath Query:	/product/version/text()

Note: this is the XPath query found in the pattern, it would also be valid to use /product/version (without the explicit call of the text() node).

Should the XPath method fail, the pattern attempts the Regular Expression method, applied to the same file.

Regular Expression employed to retrieve Versioning: <version>(\d+(?:\.\d+)*)</version>

We have found that this approach provides a version number up to four levels of depth, i.e. x.x.x.x.

Active Command Versioning

If the pattern fails to get the version from the above mentioned method, then it tries to run the versionInfo script for obtaining the version and edition. The versionInfo script is present in the following location:-

• UNIX: <product_install_root>/bin/versionInfo.sh
• Windows: <product_install_root>\\bin
  versionInfo.bat

If the command executes successfully and a result is obtained, then the version is extracted using the following regular expression:-

• Version\s*(\d+(?:\.\d+)*)

The edition is extracted using the following regular expression:-

• ID\s*(\w+)

Path Versioning

If the Active Versioning Command does not return any version information then we check the installation path to see if we can extract version information.

Path Regex:	(?i)(?:websphere|apps/WAS|websphere/appserver/ver|WebAS|websphere/appserver|/was)-?/?(\[0-9\](?:\[-._\]\d+)*)

An additional processing technique is then used on the resulting value to normalise the version so that it is separated using periods rather than - or _.

Depending on the deployment of the product we have found that this approach provides a version number between one and four levels of depth, i.e. x through to x.x.x.x.

Package Versioning

If the Active Versioning Command does not return any version information then we check the installed packages to see if we can extract version information from one of them.

Package Regexes:

• WASserver
• IBM WebSphere Application Server
• WSBAA\d+

If a single package is returned then the version number is taken from it and assigned to the Software Instance.

Disadvantages

The main risk of package versioning is that if more than one version of Websphere Application Server is installed then the version information may not be mapped to the correct instance that has been identified.

Editions

As mentioned in the versioning section, Websphere Application Server can come in a number of different editions, each edition offers different features and/or deployment methods, all editions offer the core Application Server software.

The editions available for the current release, 6.x, are:

• Community Edition
• Express Edition
• Standard Edition
• Network Deployment Edition

A full list of the features and differences between editions can be found in the [Appserver Comparison Document|ftp://ftp.software.ibm.com/software/webserver/appserv/was/Appserver_Comparison.pdf] on the IBM website.

To identify the version of the Websphere Application Server we have to have access to the product file mentioned in the Versioning section, if we have access to the file then we use another XPath query to extract the edition information from it.

XPath Query:	/product/id/text()

Note: this is the XPath query found in the pattern, it would also be valid to use /product/id (without the explicit call of the text() node).

Should the XPath method fail, the pattern attempts the Regular Expression method, applied to the same file.

Regular Expression employed to retrieve Edition: <id>(.+)</id>

Application Model Produced by Software Pattern

Product Architecture

Websphere Application Sever is essentially a Java application, you can have any number of WebSphere Application Server instances running on a single machine, you can even have multiple instances running on separate machines that are part of the same Cell or multiple instances on the same machine that are part of different Cells.

The structure of the WebSphere Application Server Pool is as follows...

1 Cell -has-> m Nodes

An instance of the Application Server needs to have a Node and Cell specified, a Cell must contain at least one node and all nodes must be part of one, and only one, cell.

The Node and Cell are a logical grouping of related Websphere Application Server instances. This allows related Applications to be hosted within the same logical group despite being physically hosted on different machines or even in different physical locations.

Multiple instances of WAS can be run from a single installation on the same machine, as specified they must be part of a unique Cell/Node key, in this manner a machine could have two Node 1's running but they would need to be part of different logical Cells.

The Cell/Node that an instance belongs to can be identified from the command line arguments. In addition to this, the command line also contains the Logical Server Name for the Application Server Instance.

With regards the other related processes, the Node Agent and Deployment manager are also part of a Node/Cell - they are services that deal with a specific part of a Application Server Pool, for example the Deployment Manager process manages communication between various Websphere Application Server instances in the same Node/Cell.

Software Pattern Model

The trigger for the ApplicationServer pattern is the core Websphere Application Server process, the pattern triggers only where the process cmd matches a java executable (java or java.exe) followed by one of the known Websphere Application Server arguments (com.ibm.ws.runtime.WsServer).

Due to the nature of the product a check is then made in the body to remove all Websphere Application Server instances that are actually children of the main process.

SI Depth

The pattern produces a Deep (Instance Based) SI for Websphere Application Server where we have been able to gather the required information.

The information that is used for the key in the SI creation is based upon the Server, Node, Cell name and the actual installation path of the software.

Network Deployment Edition

When dealing with a WebSphere Network Deployment product, the pattern takes a few additional steps, in order to correctly represent Cells, Nodes and Servers. The Servers belonging to the same Node are linked as Clients to the relevant Node Agent, determined by matching cell_name and node_name attributes. Finally, all Nodes belonging to the same Cell are linked as Clients to the relevant Deployment Manager, determined by matching cell_name.

All these relationship end up building a correct model for the Network Deployment infrastructure. The relationship can be mapped across multiple hosts.

Inference Relationships

Associate relationships are created between the primary Software Instance and all its Child processes.

Communication Relationships

A communication relationship is created between the Node Agent and Application Server Software Instances, the Node Agent is treated as the Server and the Application Server(s) are the clients.

The relationship is only created from the Node Agent and only when we are confident that we have a valid Node and Cell name for the Node Agent, a search is then performed for all other SoftwareInstances within the Datastore that have the same Node and Cell defined.

If a Software Instance is found then the relationship is created.

Due to the manner in which discovery scans are performed it may some times result in the relationships not being created on the first scan, if the Node Agent SI is created before the Application Server SI then there is nothing for the Node Agent to create the relationship to when the SI is triggered, in these instances you will require an additional scan which will result in the relationship being created.

JMX attributes

The patterns attempt to obtain JMX connection port of each WebSphere Application Server or Network Deployment instance. This JMX port is called "SOAP Connector Address" in WebSphere terminology and stored in XML configuration file "serverindex.xml". The basic requirement for JMX information is existence of Server name in case of Application Server and Cell and Node names values for both - Application Server and Network Deployment instances. Below is the way for compilation the path to "serverindex.xml" file.

Firstly the pattern tries to get the profile directory path (in which the current cell is located) from the arguments of triggered process by comparing it against the next regular expression:

• -Duser\.install\.root=(.+?)(?:"?)\s+"?-

If this approach failes the patterns try to compare arguments against another regular expression:

Platform	Alternative regular expression used for profile dir obtaining
Windows	(%install_root%\\profiles\\.+?)\\
UNIX	(%install_root%/profiles/.+?)/\\

where %install_root% is installation root of WebSphere instance which is found while doing Versioning.

Then the patterns try to obtain "serverindex.xml" file looking for it by next location (only if profile directory path, Cell and Node names are found):

Platform	Path to serverindex.xml
Windows	%profile_dir%\\config\\cells\\%cell_name%\\nodes\\%node_name%\\serverindex.xml
UNIX	%profile_dir%/config/cells/%cell_name%/nodes/%node_name%/serverindex.xml

where used variables are:

%profile_dir%	WebSphere instance profile directory path
%cell_name%	WebSphere Cell name
%node_name%	WebSphere Node name

Finally the port is found after successful XML file obtaining by using the next XPath query against XML file contents (only if server name if known):

• //serverEntries[@serverName="%server_name%"]/specialEndpoints[@endPointName="SOAP_CONNECTOR_ADDRESS"]/endPoint/@port

where %server_name% is server name of Application Server instance or "dmgr" in case of Network Deployment instance.

(This query will result in number correspondent to port of "SOAP_CONNECTOR_ADDRESS" specialEndpoints node related to current WebSphere instance).

In successful case the patterns populate jmx_enabled attribute (with Boolean "true" value) and jmx_port (with value found by XPath query).

Extended J2EE Discovery

From ADDM 8.3 onwards, extended J2EE discovery of WebSphere Application Server components is also available. This config-file-based method is fully described here.

Differences to 6.x approach

The versioning of Windows instances of Websphere Application Server has been improved. Owing to Foundation 7.0 functionality we are now able to perform an active version command on Windows hosts, improving the depth and scope of versioning for this product.

We are now also able to extract and store the edition information for this product.

Subject Matter Expertise

SME input has already been received and incorporated into this pattern, relating to the Active Version Command and Edition identification process.

Further input would be appreciated if they could identify a manner with which we could version the product using other means - such as a configuration file or a process that is not dependent on identifying the installation directory.

Testing

This pattern was tested against live installations running on Linux, Solaris and Windows operating systems.

Information Sources

Open Issues

TOP

---

Created by: Chris Blake 08 July 2010
Reviewed by: Neha Kabra Updated by: Vineet Deshpande 20 Jan 2012