Page tree
Skip to end of metadata
Go to start of metadata
Product Name
WebSphere Application Server
Publisher Page
Application Server Software Platforms
TKU 2020-11-1
In the Spotlight
In the Spotlight August 2009
More Information
Publisher Link

Product Description


Extended Discovery pattern which allows to build a J2EE inferred model of its Applications and Resources is available for this product.


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 Serve

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

r for AIX/Linux/Microsoft Windows/Solaris.

Software Pattern Summary

Product ComponentOS TypeVersioningPattern Depth
IBM Websphere Application ServerUnixCommand, Path and PackageInstance Based
IBM Websphere Application Server Node agentUnixPath
IBM Websphere Application Server Deployment Manager
IBM WebSphere Application Server ClusterUnixSoftwareInstance

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.


Software Instance Triggers

Websphere Application Server

Trigger NodeAttributeConditionArgument

Websphere Nodeagent

Trigger NodeAttributeConditionArgument


regex '(?i)-Dwas\.launcher\.server=\S+?:\S+?:nodeagent\s'

Websphere Deployment Manager

Trigger NodeAttributeConditionArgument


regex '(?i)-Dwas.launcher.server=\S+?:\S+?:dmgr\s'

IBM WebSphere Application Server Cluster

Trigger NodeAttributeConditionArgument
SoftwareInstancetype='IBM WebSphere Application Server'
cluster_idmatchesregex '.'

Software Instance type attributes created

The patterns in this module will set the following value for the type attribute on a SI:


 Pattern NameSI type
ApplicationServerIBM WebSphere Application Server
NodeagentIBM WebSphere Application Server Node agent
DeploymentManagerIBM WebSphere Application Server Deployment Manager

Other Node types created

The patterns will also create the following additional nodes:

 Pattern NameNodeNode typeDiscovery/ADDM Version
WebSphereClusterSoftwareClusterIBM WebSphere Application Server ClusterBMC Discovery 11.0 and after

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 748415854 for more details about the modeling of this product).

IBM Websphere Application Serverjava or java.exe followed by the WebSphere Application Server Class,
IBM Websphere Application Server Service (Windows only)wasservice.exe
IBM Websphere Admin Server (Unix/Linux only)java followed by the WebSphere Admin Server Class,
IBM Websphere Managed Server (Unix/Linux only)java followed by the WebSphere Managed Server Class,
IBM Websphere Nanny (Unix/Linux only)java followed by the WebSphere Nanny Class arguments,
IBM Websphere Deployment Manager (Unix/Linux only)java followed by the WebSphere Application Server Class,, followed by the string "dmgr"
IBM Websphere Nodeagent (Unix/Linux only)java followed by the WebSphere Application Server Class,, followed by the string "nodeagent"


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: <optional_privilege_escalation>ls %install_root%/properties/version | grep "\.product"In case the command result does not give us the file or the Discovery 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 748415854 section, below is a list of the filenames we check for.

AbbreviationProduct Filename
Embedded ExpressembeddedEXPRESS.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. If running script in normal mode fails, it is being re-runned in Privileged mode. The versionInfo script is present in the following location:-

  • UNIX: <product_install_root>/bin/
  • 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:


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.

SoftwareInstance Versioning

WebSphereCluster pattern extracts the version from the SoftwareInstance it had triggered off.


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.


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|] 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 product, the pattern triggers only on java commands (java or java.exe) with either '' line in the arguments or if arguments have '-Dwas.launcher.server' line at the beginning. Second attribute was added into the triggers list in TKU-Sep-2013 when IBM has introduced a fix as a work around for command-line truncation.


IBM has introduced a fix in WebSphere 6.0.2 onwards to work around command-line truncation. The reference is here

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.

The server name, node and cell name are obtained from the trigger process arguments using regular expressions as follows:

  • With '-Dwas.launcher.server' argument
    • Regular expression used: -Dwas\.launcher\.server=(\S+):(\S+):(\S+)

    • Resultant 3 regular expression groups are concatenated using '#:#' string

    • The newly formed string is then split into 3 parts:
      • cell name
      • node name
      • server name
  • Standard arguments location (at the end of the trigger process arguments)
    • Regular expression used: \s([^ /\s\\]+)\s+([^ /\s\\]+)\s+([^ /\s\\]+)$

    • Resultant 3 regular expression groups are concatenated using '#:#' string

    • The newly formed string is then split into 3 parts:
      • cell name
      • node name
      • server name
  • With -Dosgi.configuration.area argument
    Regular expression used:


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.

WebSphere Cluster

IBM WebSphere Application Server(WAS) Cluster can be set up using standard WAS tools. From Administraton Console it's possible to create/clone WAS servers and add them into the cluster. These servers should belong to the Nodes which are parts of the current WAS Cell. Empty WAS Cluster can also be created to add servers in it latter. Load balancing, session replication options can be set during the Cluster creation.

ApplicationServer pattern extracts cluster_name attribute from '<profile_dir>/config/cells/<cell_name>/nodes/<node_name>/servers/<server_name>/server.xml' file using '/process:Server[@name="%server_name%"]/@clusterName' xpath expression. It also extracts cluster_id from '<profile_dir>/config/cells/<cell_name>/clusters/<cluster_name>/cluster.xml' file with help of regex 'xmi\:id="(ServerCluster_[^"]+)"'

WebSphereCluster pattern in its turn triggers off WAS SoftwareInstance where cluster_id attribute is defined. It then models SoftwareCluster instance which key is comprised of type and cluster_id attributes. It then searches for all WAS instances with the same cluster_id and sets Containment relationship with them.

WebSphere Cluster model in BMC Discovery

The following model is obtained from BMC Discovery

WebSphere Cluster relationships visualization

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:

PlatformAlternative regular expression used for profile dir obtaining




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

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):

PlatformPath to 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.

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.


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

Information Sources

Open Issues