Page tree
    Skip to end of metadata
    Go to start of metadata
    Discover with BMC Discovery
    download

    This product can be discovered by any edition of BMC Discovery. Download our free Community Edition to try it out, or [see what else it can discover] !

    What is this?
    This is a product information page, containing details of the information that BMC Discovery gathers about a product and how it is obtained.
    Product Name
    WebSphere Application Server
    Publisher Page
    IBM
    Category
    Application Server Software Platforms
    Release
    TKU 2019-07-1
    In the Spotlight
    In the Spotlight August 2009
    Change History
    IBM WebSphere Application Server - Change History
    Reports & Attributes
    IBM WebSphere Application Server - Reports & Attributes
    Publisher Link
    IBM

    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 Server for AIX/Linux/Microsoft Windows/Solaris.

    Known Versions

    • 1.0
    • 1.1
    • 2.0
    • 3.0
    • 3.5
    • 4.0
    • 5.0
    • 5.1
    • 6.0
    • 6.1
    • 7.0
    • 8.0
    • 8.5

    Software Pattern Summary

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

    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 NodeAttributeConditionArgument
    DiscoveredProcesscmdmatchesregex'(?i)\bjava(?:\.exe)?$'
    argsregex'com\.ibm\.ws\.runtime\.WsServer'
    or
    (?i)^-Dwas\.launcher\.server

    Websphere Nodeagent

    Trigger NodeAttributeConditionArgument
    DiscoveredProcesscmdmatchesregex'(?i)\bjava(?:\.exe)?$'
    args

    regex'com\.ibm\.ws\.runtime\.WsServer.*\s\bnodeagent$'

    Websphere Deployment Manager

    Trigger NodeAttributeConditionArgument
    DiscoveredProcesscmdmatchesregex'(?i)\bjava(?:\.exe)?$'
    args

    regex'com\.ibm\.ws\.runtime\.WsServer.*\s\bdmgr$'

    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 IBM WebSphere Application Server#Application Model Produced by Software Pattern for more details about the modeling of this product).

    NameCommand
    IBM Websphere Application Serverjava 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: <optional_privilege_escalation>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 IBM WebSphere Application Server#Editions section, below is a list of the filenames we check for.


    AbbreviationProduct Filename
    NDND.product
    BaseBase.product
    Embedded ExpressembeddedEXPRESS.product
    ExpressExpress.product
    WASWAS.product
    PLGPLG.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)(?:webspherev|apps/WAS|websphere/appserver/ver|WebAS|websphere|/was|websphere/appserver)-?/?([3-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.

    SoftwareInstance Versioning

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

    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 product, the pattern triggers only on java commands (java or java.exe) with either 'com.ibm.ws.runtime.WsServer' 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.

    Note

    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:
             servers[\\/](\S+)[\\/]configuration

     

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

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

    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


    Created by: Chris Blake 08 July 2010
    Updated by: Alex Kashkevich 29 Feb 2016