NMS OAM is an integral part of Natural Access. Natural Access is a development environment providing standard programming interfaces for hardware-independent functions. You must have Natural Access installed on each host system to build applications using the NMS OAM service.
For detailed information about Natural Access, see the Natural Access Developer's Reference Manual.
Natural Access is based on a client/server model. This model allows client applications and servers to share resources and distribute processing tasks over a network. Clients and servers can reside on the same chassis or on separate chassis. Client applications can access resources available on multiple Natural Access chassis.
NMS OAM operates within this model. Regardless of whether an application is accessing NMS OAM on a local or remote system, the relationship between the application and NMS OAM is always client and server.
NMS OAM is built into the Natural Access Server (ctdaemon). Thus, ctdaemon must be running on a system in order for NMS OAM to be operational.
NMS OAM is implemented as a Natural Access service. A service is a group of logically related functions. The NMS OAM service provides functions to manage and maintain NMS resources. Other services address other aspects of an application. For example, the Switching service controls circuit switching; the NaturalFax service provides fax functionality.
A context organizes services and accompanying resources around a single processing unit. To access NMS OAM service functionality on a given host system, a client application creates a context on that system and opens the NMS OAM service on the context, along with any other services it requires. For more information, refer to Initializing NMS OAM client applications.
Note: A context can access the services and resources only on the host system on which it was created.
An event queue is the communication path from a service to an application. A service generates events indicating certain conditions or state changes. An application retrieves the events from the event queue.
When creating a context, you specify an event queue. All events from the services on the context are sent to the event queue attached to the context.
You can specify the same event queue for more than one context, even if the contexts were created on different host systems.