Product Description

BEA WebLogic Server is an enterprise-class J2EE Application server. BEA Weblogic Server is part of the BEA Weblogic platform and supports Oracle, IBM DB2, Microsoft SQL Server, MySQL and other JDBC-compliant databases.

A domain is the basic administration unit for WebLogic Server. It consists of one or more WebLogic Server instances, and logically related resources and services that are managed, collectively, as one unit.

The Weblogic Application Server is shipped in all the bundles listed below; each bundle is defined by licensing or extra features.

WebLogic Platform

Enables full support for WebLogic Server Premium (including WebLogic Workshop), WebLogic Portal, and WebLogic Integration functionality.

WebLogic Server Premium Edition

Enables full support for WebLogic Server functionality including the core Java 2 Enterprise Edition (J2EE) features, and WebLogic Workshop. WebLogic Server Premium Edition provides premium clustering, caching, and messaging.

WebLogic Workshop

Provides a complete development framework for easily building web services applications that automatically leverage the power, reliability, and scalability of WebLogic Server.

WebLogic Portal

Enables full support for WebLogic Portal functionality, which provides a framework for building enterprise portals leveraging campaign, commerce, and personalization services. Includes WebLogic Server Premium.

Further information with regards the identification of Weblogic Portal can be found later in this document.

WebLogic Express Basic Edition

WebLogic Express offers many services and APIs available with WebLogic Server, including WebLogic JDBC features, JavaServer Pages (JSP), servlets, Remote Method Invocation (RMI), and Web server functionality. WebLogic Express differs from WebLogic Server in that WebLogic Express does not provide Enterprise JavaBeans (EJB), Java Message Services (JMS), J2EE CA, WebLogic Workshop, or the two-phase commit protocol for transactions.

WebLogic Express Premium Edition

Enables basic WebLogic Express functionality as described above. Includes premium clustering support.

Aqualogic Service Bus

Weblogic application server is installed as part of a Aqualogic Service Bus deployment, Aqualogic makes use of the Weblogic platform to provide its functionality.

Further information with regards the identification of AquaLogic Service Bus can be found later in this document.

Known Versions

• 5.1
• 6.1
• 7.0
• 8.0
• 8.1
• 9.0
• 9.2
• 10.0
• 10gR1
• 10gR2
• 10gR3
• 11gR1
• 12c

Note: BEA was acquired by Oracle in 2008 and the first release of the product using Oracle naming scheme is 10gR1

Software Pattern Summary

Product Component	OS Type	Versioning	Pattern Depth
Application Server	Unix	Command (Active), Path, Package	Instance-based or Grouped (data dependent)
	Windows

Platforms Supported by the Pattern

The pattern supports both the Windows and UNIX platforms

Identification

Software Instance Triggers

Trigger Node	OS Type	Attribute	Condition	Argument
DiscoveredProcess	Windows	cmd	matches	\bjava\.exe$
		args		regex 'weblogic\.Server'
	Windows (run as service)	cmd	matches	(?i)\bbeasvc(?:X64)?\.exe$
	Unix	cmd	matches	regex'\bjava$'
		args		regex'weblogic\.Server$'

Software Instance type attributes created

The patterns in this module will set the following attributes:

Pattern Name	SI type
ApplicationServer	BEA WebLogic Application Server
ServerWindows	BEA WebLogic Application Server

Simple Identification Mappings

The following components are identified using simple identity mappings. Note that the component is identified by arguments and not by process name.

Name	cmd matches	args matches
BEA WebLogic Application Server		regex'\bweblogic\.Server$'
BEA WebLogic Nodemanager		regex'\bweblogic\.NodeManager$'
		regex'\bweblogic\.nodemanager\.NodeManager$'
BEA WebLogic Application Server	java.exe	regex 'weblogic\.Server'
	javaw.exe	regex 'weblogic\.Server'
BEA WebLogic Windows Service	regex '(?i)\bbeasvc(?:X64)?\.exe$'

Obtaining key variables

Obtaining Install Root

Install root is obtained from the trigger process arguments on the UNIX platform or Windows platform (when not running as a Windows service) using the following regular expression:

• (?i)-Dplatform\.home=(\S+)

When the WebLogic Application Server is running as a Windows service, the pattern first determines the process arguments by:

1. Mapping the trigger process to the service name under which it is running
2. Obtaining the WebLogic Application Server arguments using the following registry query: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service_name>\\Parameters\\CmdLine

The result is then parsed using the following regular expression:

• (?i)-Dplatform\.home=(\S+)

Obtaining bea_home

Windows Platforms

If the pattern has triggered off a JAVA process the bea_home and wls_home variables are obtained by parsing the trigger process arguments with the following regular expressions:

• wls_home: -Dplatform\.home=(.*?)\s
• bea_home: -Dplatform\.home=(.*)\\

If the pattern has triggered off the beasvc.exe process (the BEA Windows service), the bea_home and wls_home variables are also obtained using the same regular expressions but the process arguments are obtained using the approach mentioned in the 'Obtaining Install Root' section.

As in many cases ADDM will scan a Windows shortened path, the pattern determines the corresponding full path by executing an Active Command.
Active Command Executed: cmd /c dir /x bea_home

After obtaining the full bea_home path, the pattern parses a file within that path, called registry.xml. Version is extracted from that file by parsing it for an installation of WebLogic Server which matches the Installation Directory extracted from the Trigger arguments.

This method will usually return a depth of three levels.

Unix Platforms

Active versioning is performed by looking for and parsing a file called registry.xml which contains version information. It is stored in a directory defined in the variable BEA_HOME.

The BEA_HOME variable is obtained by one of the following methods:

• Running grep "BEA_HOME=" <install_root>/common/bin/commEnv.sh and parsing the output
• Parsing the trigger process arguments with regular expression (?i)-Dbea\.home=(\S+)
• Parsing the trigger process arguments with regular expression (?i)-Djava\.security\.policy==?(.*)/server/lib/weblogic\.policy, then checking a registry.xml file exists in the extracted directory
• Parsing the installation root with regular expression ^(.)/*, then checking a registry.xml file exists in the extracted directory
• Parsing the trigger process command with regular expression (?:^|\s|:|=)(/[^ :]*?/bea)/
• Checking standard locations (e.g. /opt/bea, /usr/local/bea) for a registry.xml file - the standard locations are listed and can be updated in the pattern configuration section via the pattern management UI in Atrium Discovery

Note: The registry.xml file is viewed using an unprivileged account. It is possible to view them as a privileged user on Atrium Discovery 8.2 and later. To do this you must alter the PRIV_CAT variable is the platform scripts

Versioning

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

The methods are tried in an order of precedence based on likely success and/or accuracy of the information that can be gathered. Once a result is obtained, the methods lower in precedence are not attempted. In order of precedence the methods are:

Active Versioning

The pattern parses the file <bea_home>/registry.xml with the following xpath:

• /bea-product-information/host/product[@name='WebLogic Platform']/release/component[@name='WebLogic Server']/@version

There is a possibility that more than one version of WebLogic is installed under the same $BEA_HOME. We therefore firstly try to find WebLogic Application Server with install dir which the pattern obtained earlier (if it was able to do this) and get the version from that node. After this the pattern try to ensure that the installation directory parsed from the registry.xml can be matched with part of the server command-line. If this succeeds, the version (if it wasn't found in previous attempt) is looked up in registry.xml.

Path Versioning

Windows Platforms

The pattern matches the Full Installation Path against two Regular Expressions, stopping whenever one of them returns a Version.

Regular Expressions employed:

• \bweblogic(\d)(\d)
• \bwlserver_(\d+\.\d+)

This method will usually return two levels of Version Depth.

Unix Platforms

ADDM extracts version information from the full command-line (command and arguments) of the WebLogic java process, and does so even if BEA Weblogic Application Server is installed in a non-default location.

The versions this method currently works for are as follows: 5.1, 6.1, 7.0, 8.0, 8.1, 9.0 and 9.2.

Package Versioning

This method works exclusively on Unix Platoforms. Furthermore, it is only attempted if both active versioning and path regex methods fail.

The package names in the package manager have a number of regexes (i.e. "wls451", "wls452", "WLS51", "wls510", "wls600", "wls610") applied to them and the version information extracted from any that match. If two or more packages match, a Package Preference Algorithm is applied which seeks to discover the package with the lowest preference; the version of the "most trusted" package is returned.

This method has been found to occasionally work but only in some environments and with old versions of WebLogic Application Server

File Versioning

If the port information wasn't obtained using previous methods and config.xml config file was found, the version is parsed out from its content using the following XPath query:

• /domain/domain-version

This method is actual for WebLogic versions starting from 9 (due to the format of the configuration file).

Application Model Produced by Software Pattern

Product Architecture

It is possible to run multiple instances of Weblogic on a single host. Instances are typically identified through the process argument list as each server is named in the command-line arguments or the process arguments obtained from the Windows Service via registry query and extracted using the following regular expression:

• -Dweblogic\.Name=(\S+) - UNIX platforms
• -Dweblogic\.Name="?(\S+)"? - Windows platforms

Software Pattern Model

The trigger process used by this pattern in the creation of BEA Weblogic Application Server Software Instances (SI) is the Java VM process with 'weblogic.Server' in its argument list or one of the Windows services, beasvc.exe or beasvcx64.exe.

SI Depth

By default the pattern produces a Deep (Instance Based) Software Instance for BEA WebLogic Application Server. Each WebLogic Application Server instance that can be uniquely identified will generate a Software Instance in a ADDM model.
The WebLogic Application server instance name is used as part of the key to generate a Software Instance and is also stored as the 'server_name' attribute on the SI node.

If value of BEA_HOME was found it is used for creation of the SI key (path is changed using an MD5 hash), in conjunction with the domain name (if found), as well as the application server instance name. If those parameters were not found, 'grouped' Software Instance is generated with the key group being a combination of BEA_HOME with either application server name or version found.

Protocol and Port Information

The pattern attempts to add domain, cluster, listen address, listen port, ssl listen port, channels, default protocol and default secure protocol information to the Software Instance.

To obtain this information the pattern tries to read a config.xml file in the config directory. To locate this file the pattern uses the following approaches (tried in order shown) of determining the path to directory which possibly contains it:

• parsing the command line of parent process (on Windows and UNIX platforms) using the following regular expressions:
  **(/[^ ]*)/bin - UNIX platforms
  **(?i)"?(\w:[\\|/](?:[\w\\/])*?)(?:[\\/]bin)?[\\/][^\\/]*\.(?:cmd|bat)"? - Windows platform
• for UNIX platform it tries (if it's permitted in the pattern's configuration section) to use elevated privileges in order to use one of the following active commands (dependent on the type of OS, adding 'pargs' and/or 'ps' to your sudo configuration file as required) for obtaining "PWD" environment variable which usually holds the path to domain directory:

Operating System	Active Command Requiring Elevated Privileges (where %parent.pid% is the PID of the parent process)
Solaris	pargs -e %parent.pid%| grep -v "OLDPWD"| grep "PWD"
Linux	ps xew | grep "\s*%parent.pid%"
AIX	ps axew | grep "\s*%parent.pid%"

• if domain name is specified in command-line arguments the pattern tries to determine its possible location based on default domain path and by adding to the default the user domain directory paths (relative to "BEA_HOME" directory) from pattern's configuration section.
• The domain name may also be obtained from the registy when WebLogic Application Server is running as a Windows Service using the following registry query: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service_name>\Parameters\ExecDir

Note: If you are looking for a way of how to extend the depth of results returned by the pattern on UNIX platform you could enable usage of elevated privileges (in Pattern Configuration section) which should allow the pattern to use them for obtaining "config.xml" which stores most important information related to ports, domain, cluster and JMX connectivity.

Note: If even using elevated privileges didn't help to obtain a path to domain directory, or you are discovering WebLogic Application Server on Windows platform, you can allow the pattern to use a user configurable list of possible absolute domain directories by enabling this option in the pattern Configuration section in the Atrium Discovery UI where also you can insert needed values to such list for each platform. Beware that this option can be the reason of incorrect modelling in case when there will be multiple WebLogic servers from different domains without obtained domain paths on the same host.

Note: The config.xml file is viewed using an unprivileged account. It is possible to view them as a privileged user on Atrium Discovery 8.2 and later. To do this you must alter the PRIV_CAT variable is the platform scripts

Domain is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/name
• /Domain/@Name

Cluster is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/cluster
• /Domain/Server[@Name="%appservername%"]/@Cluster

Listen address is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/listen-address
• /Domain/Server[@Name="%appservername%"]/@ListenAddress

Default protocol is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/default-protocol
• /Domain/Server[@Name="%appservername%"]/@DefaultProtocol

If unknown, this attribute defaults to 't3'.

Default secure protocol is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/default-secure-protocol
• /Domain/Server[@Name="%appservername%"]/@DefaultSecureProtocol

If unknown, this attribute defaults to 't3s'.

Listen port is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/listen-port
• /Domain/Server[@Name="%appservername%"]/@ListenPort

If unknown, this attribute defaults to '7001' but can be user-defined via the default_listen_port option in the configuration section.

SSL listen port is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/ssl/listen-port
• /Domain/Server[@Name="%appservername%"]/SSL/@ListenPort

If unknown, this attribute defaults to '7002' but can be user-defined via the default_ssl_listen_port option in the configuration section.

The channel names are ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/network-access-point/name
• /Domain/Server[@Name="%appservername%"]/NetworkAccessPoint/@Name

Having obtained a list of channel names, additional information for each channel is obtained via a number of further xpath calls:

The protocol used by the channel is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/network-access-point[name="%channel_name%"]/protocol
• /Domain/Server[@Name="%appservername%"]/NetworkAccessPoint[@Name="%channel_name%"]/@Protocol

If unknown, this attribute defaults to 't3'.

The address the channel is listening on is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/network-access-point[name="%channel_name%"]/listen-address
• /Domain/Server[@Name="%appservername%"]/NetworkAccessPoint[@Name="%channel_name%"]/@ListenAddress

The port the channel is listening on is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/network-access-point[name="%channel_name%"]/listen-port
• /Domain/Server[@Name="%appservername%"]/NetworkAccessPoint[@Name="%channel_name%"]/@ListenPort

JMX attributes

Pattern aims to determine whether the discovered Application Server is an Administration server in order to populate JMX port information which can then be used for extended discovery of WebLogic.

This is performed by analyzing config.xml file from config directory obtained in Protocol and Port Information. The algorithm is as follows - the server is Admin Server when:

• its only one in its domain
• if its name is specified in <admin-server-name> node of config.xml
• it is the first one among other servers within the server list in config.xml and if version of WebLogic Application Server is 8 or older.

In case the pattern confirms that this instance is Admin Server for domain, it populates the jmx_enabled (with Boolean "true" value) and jmx_port (the same as "listen_port") attributes.

Weblogic Extended J2EE Discovery

JMX attributes populated (in particular: jmx_enabled and jmx_port) are used for Weblogic Extended discovery. As from Atrium Discovery 8.3 the extended J2EE discovery functionality is strengthened by an additional approach which uses the WebLogic configuration file - config.xml and by analyzing it models J2EE Applications, Domains, JDBC and Mail Resources. This config-file-based method is fully described here.

Relationship with Oracle Jolt

The pattern checks for the Oracle Jolt Connection Pool information present in the config.xml file. The following Xpath query is used for extracting the information about the Jolt Connection Pool:

/Domain/JoltConnectionPool/@PrimaryAddresses

For all the hosts mentioned in the XML, the pattern will search for the "Oracle Jolt Server" Software Instance present on the host and if found create a communication relationship between that SI and the WebLogic SI.

Product Editions and License Information

As mentioned above, WebLogic Application Server is shipped in a number of different editions. Many components of WebLogic Application Server are licensable. Editions in essence govern the functionality that has been enabled through licensing. Components may be licensed for different periods of time. If license expires on certain components, WebLogic Application server edition changes and this typically degrades some of its functionality.
ADDM attempts to determine the product edition by parsing the license file of the WebLogic installation.
The license file is called 'license.bea' and it is located in the same directory as registry.xml (i.e. BEA_HOME).

Note: The requirement for determination of WebLogic editions and gathering of license information is that the pattern is able to locate BEA_HOME and access bea.license file.

Note: The license files are viewed using an unprivileged account. It is possible to view them as a privileged user on Atrium Discovery 8.2 and later. To do this you must alter the PRIV_CAT variable is the platform scripts

The license file is parsed using the following approach:

1. The pattern ensures that it is parsing the section of the license file that pertains to the installation of WebLogic Application Server that is running at the pattern triggered on.
2. The pattern then looks for existence of key components in the license file. Presence or absence of these key components determines the edition of the product.
3. The 'expiration' attribute of each of these components is compared with the date stamp from the scanned host to determine whether the component is still licensed. If not, the edition is updated prior to the setting of 'edition' attribute on WebLogic Application Server SI.
4. In addition to this, the 'WebLogic' component entry is parsed in detail to determine:

• The license type (stored as 'license_type' on the SI)
• The number of CPUs the license is for (stored as 'cpus_licensed' on the SI)
• The licensee (stored as 'licensee' on the SI)
• The number of unique IP addresses that can connect to the server (stored as 'allowed_unique_connections')
• License expiry date (stored as license_expiry_date) - This is the expiry date for the 'WebLogic' component - once the license expires for this component the WebLogic Application Server is not licensed at all

To get the date from the host we run a command that is dependant on the host operating system, this is required for working out whether license expired:

Unix date command: date '+%Y-%m-%d'

Windows date command: date /T

Note: The date returned by Unix is consistent across platforms and locales, the Windows command returns a date that is specific to the language and locale. We have to perform additional checks on the output returned by Windows to ensure we check the date in the correct format.

The three possible formats that we have identified are US style (mm-dd-yyyy) with day name at the beginning, EU style (dd-mm-yyyy) and other (yyyy-mm-dd).

After reviewing all possible locales on a standard Windows XP system we identified that by looking for each of these styles we would cover ~97% of all possibilities.

The following Regular expressions extract the specific date formats:

US date regex: \w{3}\s+(\d+)[/\.-](\d+)[/\.-](\d+)

EU date regex: (\d{4})[/\.-](\d{2})[/\.-](\d{2})

Other date regex: (\d+)[/\.-](\d+)[/\.-](\d+)

ADDM currently identifies the following editions:

• Premium
• Advantage
• Workgroup
• Express Premium
• Express Base

These product editions are common between WebLogic Application Server versions 8.1, 9.0, 9.2, 10.0, 10.1, 10.2.

Product editions such as Server Process (WebLogic 8.1, 9.0, 9.2), Integration and WebLogic Platform (WebLogic 8.1) are currently identified as Premium edition which they are supersets of.

WebLogic Platform edition (called SDK in WebLogic 9 and 10) can be however deduced from the 'license_type' attribute which will be set to 'SDK'.

Note: As of WebLogic Application Server 10.3 (i.e. 10g Release 3) the product licensing is no longer controlled by the 'license.bea' file and Oracle have released the product for download without any restrictions for non-production use. The pattern will therefore not be able to gather license information for versions 10.3 and above.

Additional Products on the WebLogic Framework

WebLogic Portal Installation Detection

WebLogic Portal is installed on top of WebLogic Application Server (Premium Edition) and provides a framework for building enterprise portals.
As it is not a different product per-se but a framework layer on top of WebLogic Application Server, the current ADDM functionality allows us to detect its installation but not whether the Portal is actually running.
Portal installation is detected through parsing of registry.xml file for a particular WebLogic Application Server installation.

Note: The requirement for detection of "WebLogic Portal" installation is that the pattern is able to locate "BEA_HOME" and access "registry.xml" file.

There are therefore three possible outcomes when attempting to detect WebLogic Portal installation:

1. registry.xml file parsed, WebLogic Portal installation detected - portal_installed attribute created on the WebLogic SI and set to true.
2. registry.xml file parsed, WebLogic Portal installation not detected - portal_installed attribute created on the WebLogic SI and set to false.
3. BEA_HOME could not be determined and registry.xml file not obtained - the pattern does not create the portal_installed attribute on the WebLogic SI.

AquaLogic Service Bus Installation Detection

In a similar manner to the WebLogic Portal detection, the pattern tries to determine whether AquaLogic is also installed on the platform. It does so by parsing the registry.xml file, residing in the bea_home directory. The pattern will therefore be able to parse the xml file only when it can identify the bea_home directory.

There are therefore three possible outcomes in the identifying of an AquaLogic installation.

1. The registry.xml file is parsed, and AquaLogic is detected. An attribute called aqualogic is added to the SI and set to true.
2. The registry.xml file is parsed, and AquaLogic isn't detected. An attribute called aqualogic is added to the SI and set to false.
3. The registry.xml file isn't parsed and no further attempt at identifying AquaLogic is carried out. An attribute called aqualogic isn't created.

Finally, the pattern checks for the AquaLogic license in the license.bea file. In the event that the license expired, the pattern sets the aqualogic attribute to false.

Workshop Installation Detection

In a similar manner to the WebLogic Portal detection, the pattern tries to determine whether Workshop is also installed on the platform. It does so by parsing the registry.xml file, residing in the bea_home directory. The pattern will therefore be able to parse the xml file only when it can identify the bea_home directory.

There are therefore three possible outcomes in the identifying of a Workshop installation.

1. The registry.xml file is parsed, and Workshop is detected. An attribute called workshop_installed is added to the SI and set to true.
2. The registry.xml file is parsed, and Workshop isn't detected. An attribute called workshop_installed is added to the SI and set to false.
3. The registry.xml file isn't parsed. An attribute called workshop_installed isn't created.

Subject Matter Expertise

Initial information on detection of WebLogic Portal installations and determining WebLogic editions was provided by Andy Key (JPMC).

Testing

We tested the pattern for BEA Weblogic Application Server using ADDM record data from Unix hosts (Solaris, Linux) as well as with actual installations (8.1, 9.2, 10.0, 10gR3, 11gR1, 12c) running on Solaris, Linux and Windows.

Information Sources

• WebLogic Server 8.1 License Packages
• WebLogic Server 9.0 License Packages
• WebLogic Server 9.0 License Packages
• WebLogic Server 10.0 License Packages

Open Issues

N/A

TOP

---

Created by: Nikola Vukovljak 10 January 2008
Updated by: Nikola Vukovljak 23 Jan 2012