The vast majority of Oracle Network Management System static and dynamic model data is stored in an Oracle Relational Database Management System (RDBMS). All updates to a single NMS RDBMS instance are managed through at least one pair of Oracle RDBMS username/schema. This Oracle RDBMS access user name is used by NMS C++ services, WebLogic JDBC connections, the Oracle SQL Plus utility along with Perl and Python scripts to update/maintain the NMS instance. Actual NMS end users are generally authenticated outside of the Oracle RDBMS (via LDAP accessible Directory Services). For security purposes - it is recommended that access to the production NMS RDBMS be managed appropriately.

For a typical installation NMS updates the RDBMS using the following access mechanisms:

The NMS C++ Service daemons manage the vast majority of updates to the NMS RDBMS schema. NMS services perform RDBMS updates via calls to the various NMS *DBService daemon processes. The *DBService daemon processes use the Oracle Call Interface (OCI) to update/query the Oracle RDBMS. The Oracle Call Interface is an Application Programming Interface (API) that uses the Oracle Net8 (SQL*Net V2) protocol to communicate to the Oracle RDBMS "listener" process. The Oracle listener runs on the same node as the Oracle RDBMS and allows remote network nodes to access the Oracle RDBMS.

Oracle NMS services are a set of C++ daemon processes that manage the majority of the processing and coordination required to manage the operational NMS Electrical Network model. These NMS C++ service processes coordinate with each other using the ISIS message bus.

ISIS runs on the node where NMS services run. By default, ISIS runs on the loopback (localhost) network. In this mode ISIS is only used to coordinate messages between NMS service processes and no ISIS ports are accessible from any external nodes. NMS ISIS messages are not encrypted. ISIS uses the configuration file pointed to by the $ISIS_PARAMETERS environment variable. In general, $ISIS_PARAMETERS should not be changed unless specifically instructed by Oracle NMS support.

The NMS SwService (Switching Service) uses Simple Object Access Protocol (SOAP) over HTTPS to send synchronous request messages to WebLogic that require a distinct response. These messages are authenticated and can also be encrypted via SSL. Oracle Wallet functionality is used to hold authentication credentials for the NMS services that send these SOAP messages to WebLogic. In order to use a secure connection, SwService needs to connect to the SSL port of the WebLogic server and provide an SSL certificate file, which is used to confirm identity of the WebLogic server. See Creating the Certificate for SwService for information on creating an appropriate certificate file to use with the commands below.

Oracle WebLogic provides NMS with a Java Enterprise Edition (EE) Application Server and general purpose integration platform. Oracle NMS utilizes a collection of Enterprise Java Beans (EJBs) that execute within WebLogic to:

A given WebLogic Managed Server communicates via a Java Database Connectivity (JDBC) pool to the Oracle listener process on the Oracle RDBMS host. WebLogic must be configured to use the JDBC Thin Drivers (not the OCI based JDBC drivers) for connection to a non-RAC RDBMS and Active GridLink drivers for a RAC RDBMS. WebLogic manages Oracle RDBMS user name and password credentials inside WebLogic. The user and password credentials must be specified when you configure the JDBC Data Source for given WebLogic Managed Server instance.

WebLogic can be configured to open up both a standard and secure port to support in-bound communication for each WebLogic Managed Server. The specific ports are configured within WebLogic. The WebLogic standard port supports HTTP, SOAP, EJB RMI calls and anything else that uses JNDI. In general WebLogic supports:

For a more secure implementation WebLogic should be placed behind an additional internal firewall (in addition to the corporate firewall - see Figure 1). In this case the only port that would need to be opened to NMS end users is the SSL (secure) port, and optionally the standard port. Specifically, the database and the NMS services including the corba gateway and publisher do not need to be directly accessible to the NMS Java client.

Note it is highly recommended that NMS Java clients be configured to run on the latest supported Java Runtime Environment (JRE). To help ensure the latest JRE versions is being used older JREs should also normally be uninstalled. In a similar fashion it is also generally recommended that the latest Java Development Kit (JDK) - which includes a JRE - be installed on the WebLogic host. Note WebLogic must also be properly configured to ensure the WebLogic JVM is actually using the latest JDK.

CORBA is used to allow back end NMS C++ services to support front end NMS clients. The NMS corbagateway (service process) speaks ISIS on the NMS service side and CORBA IIOP on the WebLogic side. The NMS corbagateway uses "The Ace Orb" (TAO) ORB and WebLogic uses the WebLogic ORB to coordinate communication via the TAO Naming Service (tao_cosnaming) process.

The port and host that WebLogic uses to find the tao_cosnaming process are defined in the NMS RDBMS, in the nms_parameters_view table column where nms_parameters_view.attrib='WEB_corbaInitRef'.

For example:

The port and host that the NMS corbagateway process uses to find the tao_cosnaming (ORB) process is defined in the project specific NMS system.dat configuration file. A typical entry for a given corbagateway process might start something like the following:

If more than one WebLogic Managed Server is in play (for whatever reason), each must be configured to communicate to NMS Services via a specific "pair" of corbagateway processes. One corbagateway process handles WebLogic (client) initiated requests and another "corbagateway -publisher" process that sends NMS Service "published updates" to that WebLogic Managed Server. On the WebLogic Admin Server - on the "Server Start" tab for the Managed Server in question - ensure the "‑DintersysName=InterSys_xxx_n" value matches a set of corbagateway processes with a matching "‑implname InterSys_xxx_n" value - where "n" is typically the only value differentiating different WebLogic Managed Servers.

The port used to communicate to the naming service can be modified but must be coordinated. CORBA message traffic between NMS C++ services and WebLogic is not encrypted.

The HTTP server, lighttpd, is a lightweight third party HTTP server shipped with Oracle NMS. It is used by Oracle NMS to serve NMS map files to WebLogic. The lighttpd daemon is auto-configured and started using the nms-lighttpd script:

The lighttpd HTTP server is configured and monitored by SMService by default in the template system.dat files.

The HTTP server is generally configured to serve a single directory of unencrypted NMS model map files to specific IP addresses (where the WebLogic instances that support this NMS instance run). The HTTP server is typically not configured to serve encrypted NMS map files to WebLogic, however HTTPS is supported if desired. More information on configuration options for the nms-lighttpd script can also be found under [project]_parameters.sql in the Oracle Utilities Network Management System Installation Guide.

The lighttpd HTTP server is also used to serve up log files to the Oracle Utilities Network Management System Application Management Pack (AMP) for Oracle Enterprise Manager (OEM). The server logs can be downloaded from the NMS AMP plug-in and/or viewed without having to log into the server where the NMS services are running.

The nms-lighttpd-oem script is used to start this auto-configured instance of lighttpd.

This nms-lighttpd-oem instance has the same monitoring and configurable options as what was described for the nms-lighttpd instance.

Oracle NMS generally uses LDAP accessible enterprise Directory Services to authenticate NMS end users. This is accomplished by routing authentication requests from NMS Java clients through WebLogic - which must in turn be configured to connect to the appropriate LDAP accessible Directory Service. In practice (especially production) LDAPS (LDAP over TLS) should be used to encrypt LDAP traffic. See the Oracle Utilities Network Management System Installation Guide for details on configuring LDAP within WebLogic.

Oracle NMS uses Java (Swing) clients to allow NMS end users access to the operational NMS Electrical Network data model. Once initiated these clients are in near-constant communication with WebLogic in an effort to remain synchronized with the real-time operational model.

The NMS Java clients generally use two forms of digital signing certificates:

For both of these certificates, Oracle recommends using a certificate generated by a trusted Certificate Authority (CA). However for testing purposes, self-signed certificates are supported. Please see Security Certificates in Oracle Utilities Network Management System for details on using security certificates.