3.7 Communications in Operations Center

Operations Center uses a range of ports. The specific ports used depends on the overall architecture that is implemented (whether Operations Center is inside/outside firewalls, whether adapters must communicate across firewalls to management systems, and so on), as well as the data source.

During every initialization, Operations Center starts at a specified number (2000 by default) and looks for consecutive range of unused ports equal to the number it needs, up to a specified value (3000 by default). The potential exists for the server to use different ports each time the server starts.

If you need the ports to be specific to meet firewall or other security restrictions, you can change the server configuration to set specific ports. For information, see Configuring Ports in the Operations Center 5.6 Server Configuration Guide.

The Operations Center server receives data from a management system or other Operations Center tool, such as BDI, Experience Manager, Event Manager, or SNMP Integrator, via an adapter. In addition to integrating the data for reporting and monitoring, the Operations Center server has functionality that replicates the functions of the management system.

Each adapter is an API that is written for a specific product and a specific version of that product. For a list of management systems for which Operations Center provides an adapter, see Section 4.0, Supported Versions and Hardware Requirements.

Each adapter has different requirements from a firewall configuration standpoint. Operations Center provides a secure relay connection for integrating with some third-party management systems. The relay connection provides secure cross-host communication by acting as an intermediary, accepting and delivering messages between the Operations Center server and the third-party management system.

IBM Micromuse Netcool and BMC Software Patrol Enterprise Manager (PEM) are currently supported. For more information on these integrations and on configuration of secure relay connections, see the Operations Center 5.6 Adapter and Integration Guide.

The Operations Center console uses two ports. Both initial connections are through the HTTP (or HTTPS) port.

The Operations Center server cannot know in advance the location of a Operations Center console (or another server) that wants to communicate with it. For this reason, Operations Center consoles (and other Operations Center servers) issue a standard request to a target server when they want to communicate with it. This request travels over either the unsecured or secured Web port, and takes the form of a special URL. The originating Operations Center console (or server) parses the data returned by this request to determine which port number to use for further communication with the target.

If the Operations Center console contacted the target server using secure HTTP, the port value returned is the bidirectional IIOP port for secure data. If the Operations Center console contacted the target server using unsecured HTTP, then the port value returned is the bidirectional IIOP port for standard HTTP.

The same mechanism used to return port values also specifies the IP address of the server. However, in the presence of a Network Address Translation (NAT) device, the IP address published by the server is the IP address of the server from the private side of the NAT device, not the public side. This IP address does not allow the client to successfully pass from the user’s desktop through the NAT device to reach the server. You must make a configuration change to the Operations Center server to account for this behavior. For more information, see the Operations Center 5.6 Server Configuration Guide.

Operations Center allows for data from one Operations Center server to be used by another Operations Center server. The connection is similar to how the Operations Center console connects to a Operations Center server. You can connect multiple Operations Center servers for a cascading effect, but each connection slows performance.

Operations Center servers running the same version can always be connected with each other. However, check the Release Notes to verify if Operations Center servers running different versions can communicate over an InterConnection Adapter (ICA), and what versions are supported.

The connection is made using the ICA, which allows data that resides in one Operations Center server (such as Server A) to be visible to and used by another Operations Center server (such as Server B). The servers can be divided by a firewall.

To configure the ICA, you must specify the host name and HTTP port of the Operations Center server to which you want to connect. To secure the connection, you can use HTTPS and restrict access by IP address. For more information, see the Operations Center 5.6 Server Configuration Guide.

Data from Server A appears in Server B as local elements, which can be used to build service models. The state (such as current condition) is propagated to elements in service models. You can also create local service level agreements (SLAs) on these elements. Any SLAs that apply to the element on Server A appear as remote SLAs on Server B. For more information on service models and SLAs; see the Operations Center 5.6 Service Modeling Guide and Operations Center 5.6 Service Level Agreement Guide, respectively.

The Operations Center server also communicates with other servers, such as the Web server and Image server, and databases.

When configuring the Operations Center server, you must specify the database for the Configuration Storage data source and the settings (such as Java runtime and trace levels) for connection to the databases. You must also specify the port for connection to SQL Views (if that product is used).

Database connections most likely use a specific port, but the communications is usually through a JDBC protocol. Depending on the JDBC driver, it might be pure JDBC or a vendor-specific protocol, such as SQL*Net or DBLib, and so on.

You must also define the ports for communication with the Web server and Image server. Communication with the Web server can use either HTTP or HTTPS.

RMI communications can be used between the Operations Center server and Web server used for the dashboard. RMI is the Remote Method Invocation, which is a Java application programming interface used for communication using HTTPS.

The dashboard’s Web server also supports the use of a truststore a (defined as a repository for keys that are trusted by the Operations Center server or the dashboard server) and a keystore (defined as a repository for certificates that the Operations Center server or dashboard server uses to identify itself). Any certificate that is in the truststore, or signed by a certificate in the truststore, is trusted by the server. Operations Center validates the certificate dates.

The certificate used to secure HTTP communications on the Operations Center server or dashboard server must also be used to secure RMI communications on that server. If your environment requires different certificates for RMI communications, contact Support for assistance.