Architecture

Starting with Netcool Configuration Manager version 6.2, the API communicates with the Netcool Configuration Manager - Base server using an XML over HTTP/S serialization mechanism that has similar behavior to a Java RMI interface, but avoids J2EE vendor-specific library dependencies.

API functionality that does not require direct access to network resources merely accesses or manipulates data in the underlying database. Functionality that requires access to network resources (including requesting current data from a network resource, and changing the configuration on a network resource) results in data being placed in the database that will result in the Worker Servers using that data to interact with the network resources. With one exception, the presentation server does not interact directly with network resources as the result of API method calls. (The only notable exception to this approach is the use "direct commands", in which case the Presentation server executes commands against network resources. See the caveats listed later in this document regarding using this approach).

Figure 1. API architecture
The API architecture figure shows how the API fits into the Netcool Configuration Manager architecture.
Interfaces in the com.intelliden.icos.idc package represent data stored in the underlying database including data regarding network resources, configurations associated with network resources, UOWs, and other Netcool Configuration Manager resources. These interfaces are implemented by classes used in the presentation server and worker server code. The interface representation of the data may or may not be representative of how the is actually stored in the database in any particular Netcool Configuration Manager version.
  • Attributes and methods in the implementing classes are exposed only as they are deemed to useful and safe to use from the API.
  • The API is generally structured to allow API users to create powerful solutions that may require in-depth manipulation of Netcool Configuration Manager resource data. In some cases many of the underlying "setter" methods are exposed that allow users to attempt to set inaccurate data on resources, such as "last modified time" or "last modified by" attributes. These "setter" methods should be used with caution to avoid introducing inaccurate data into the Netcool Configuration Manager system. In many cases, the Worker Servers may overwrite such user-supplied data as they process work.