BEA Websphere Application Server

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.

BEA 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
  • 10.1

Software Pattern Summary


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

h2. Platforms Supported by the Pattern

The pattern identifies BEA Weblogic Application Server on Unix. BEA Weblogic Application Server is only identified on the Windows platform at the Simple Identifier level.

Identification

Software Instance Triggers

DDD Node OS Type Attribute Condition Argument
DiscoveredProcess Windows cmd matches regex ‘\bjava\.exe$’
args regex ‘weblogic\.Server’
Unix cmd matches regex’\bjava$’
args regex’weblogic\.Server$’

Example:

C:\bea\jdk142_05\bin\java.exe
-client -Xms32m -Xmx200m -XX:MaxPermSize=128m -Dlog4j.config=log4j.properties -Dcom.bea.medrec.xml.incoming=incoming -Dphys.app.wsdl.url=http://localhost:7001/ws_medrec/MedRecWebServices?WSDL -Dweblogic.Name=MedRecServer -Dweblogic.ProductionModeEnabled= -Djava.security.policy=“C:\bea\weblogic81\server\lib\weblogic.policy” 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

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 args matches
BEA WebLogic Application Server regex’\bweblogic\.Server$’
BEA WebLogic Nodemanager regex’\bweblogic\.NodeManager$’
regex’\bweblogic\.nodemanager\.NodeManager$’

Versioning

Version information for the product is currently collected using one of three 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

Windows Platforms

The pattern determines the value of two variables called ‘‘wls_home’‘ and ‘‘bea_home’‘ by parsing the arguments through a Regular Expression.

‘’‘Regular Expression employed to determine ‘‘wls_home’‘:’‘’ -Dplatform.home=(.*)

‘’‘Regular Expression employed to determine ‘‘bea_home’‘:’‘’ (.*)\\

As in many cases Foundation 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.

To get the BEA_HOME:
“grep \“BEA_HOME=\” /common/bin/commEnv.sh” – installation directory obtained from value of ‘-Dplatform.home’ in the process arguments

Before this file can be parsed, the value of $BEA_HOME has to be discovered in order to obtain the installation folder. There are several ways to obtain this variable. Foundation tries them in the following order, and uses the first method that works.

  1. The process arguments may contain –Dplatform.home. That is not the value of BEA_HOME, but it contains the path to the installation of WebLogic Application Server. This path is extended by the following directory ‘common/bin’, and a file called commEnv.sh in that location is parsed by Foundation to obtain the value of BEA_HOME (i.e. the path).
  2. The process arguments may contain -Dbea.home. The value of this is then taken as the path to registry.xml file.
  3. If the java process running Weblogic Server has a full path, Foundation tries to find registry.xml file in a directory relative to ‘/bea/’ in the path to the java process.
  4. Foundation looks for registry.xml in some common locations (’/opt/bea’, ‘/usr/local/bea’, ‘/opt/bea/weblogic’, ‘/root/bea’)

There is a possibility that more than one version of WebLogic is installed under the same $BEA_HOME. We therefore 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 is looked up in registry.xml.

Due to their multi-step nature and reliance of results obtained in one step to proceed to the next, these methods could not be used in Foundation 6.x.

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

Foundation 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

Alternative Versioning Approach

Future Considerations

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 (-Dweblogic.Name)

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.

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 Foundation model.

The way Foundation enumerates different instances is by looking for and storing the “-Dweblogic.Name” process argument. The value of this argument is extracted using the following regex: ‘(?i)Dweblogic.Name=(\S+)’, it 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.

The SI key created is a combination of the application server name (value of ‘weblogic.Name’ argument), type (BEA WebLogic Application Server), the version and the host key (as created by the invocation of the software pattern).

If the name of the WebLogic application server is not known, a ‘grouped’ Software Instance is generated with the key group being a combination of full process path (command and arguments) and version.

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.
Foundation 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 the pattern is able to locate BEA_HOME and access bea.license file.

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

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

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

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 Foundation 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’‘ installtion.

  1. The ‘‘resitry.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’‘.

Differences to 6.x approach

Foundation now has a much more advanced way of versioning BEA Weblogic Application Server, in that it is not limited to Path versioning and Package versioning, but now has an advanced Active versioning approach that we described in the versioning section of this document.
In addition to this, the TKU 2008 January release of the pattern also features:

  • Detection of BEA WebLogic Portal installation
  • Detection of BEA Aqualogic Service Bus installation
  • Determining WebLogic Application Server edition
  • License information

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 Foundation record data from Unix hosts (Solaris, Linux) as well as with actual installations (8.1, 9.2, 10.0) running on Solaris and Linux.

Information Sources

Open Issues N/A