|
| |  | |
Principal Sponsors:
 | Embedded Telecommunications Management Network (TMN) Solutions |
7. Developing the Agent Software
The agent model is the foundation for the agent application. The code for the agent software is based on this GDMO model. To create the software code for the agent application, it is necessary to create C++ (or whatever language is chosen) classes to somehow represent the GDMO managed object attributes, actions, and notifications in the model. The GDMO that makes up the model references other files called documents. These documents contain the GDMO standards that the model references. These documents also must be incorporated in the code.
This would be a difficult and time-consuming task to do by hand, but fortunately tools are available to automate part of this process. Some tools can build an application based on the GDMO model automatically linking GDMO documents, the model, and other information and creating a header file and a C++ makefile—everything that is needed for the agent application. It is necessary only to tell the tool where all of the pieces are located.
There are agent features that must be included in the software that are difficult to code by hand. The following are features of the agent application:
- The agent application must be able to encode and decode the CMIP protocol data units (PDUs) sent to it. CMIP defines how to do secure electronic transactions (SETs), government emergency telecommunications service (GETS), etc.
- The manager must know the directory structure of the agent. Alternatively, the manager must be able to "discover" the agent's directory structure, which means that the manager asks the agent what the directory structure is. This is provided in the containment tree.
- The agent application must support allomorphism, an MO class that can look like a different MO class to different managers. To understand this concept more fully, think of a tape recorder/compact disc (CD) player as an MO. If the agent application supports allomorphism, this small stereo can be seen as a tape player to one manager, a CD player to another manager, and both to yet another manager. This way the agent can interact with a wider range of managers. There does not have to be a separate attribute or instance for each manager, which saves bandwidth.
- The application must support single mode fibers (SMFs). SMFs are functions that provide more complex behavior than the normal manager-to-agent commands like GET, SET, etc. Behavior may include event forwarding and attribute modeling. In other words, the agent can perform operations without being told by the manager. For example, the agent can send a signal only when something goes wrong.
- The application must be able to coordinate message processing so that the agent can perform more than one operation at a time or receive more than one message at a time. This interprocess communications (IPC) must be handled because often the resource is not on the same processor as the agent.
- The Q-interface is the interface between the communications protocol and the manager and agent. In the case of embedded TMN agent, the Q-interface is the OSI stack. The agent application must be integrated with this Q-interface.
- The manager must have scoping and filtering capabilities so that it can perform operations or find out information about entire sections of the containment tree. The manager can operate on whole sections of the containment tree. Scoping allows for the identification of a set of managed objects to run the test on, while filtering allows for the display of results within a specified range. This functionality must be built into the agent application.
- The application must be written for or ported to the selected RTOS. Many different RTOSs are available from different vendors, each offering unique functionality. Therefore, the agent must be specific to the target RTOS.
- Finally, it is necessary to integrate MOs with real resources. This can be done in C++ by hand, but some tool kits available can ease that process by providing C++ hooks or stub functions so that all that is needed is to write the C++ code that associates these hooks with the real resources on the network. When doing the C++ coding by hand, it is necessary to create all of the code that associates the agent application with the real resources on the network.
TMN++ API
This application programming interface (API) was developed by the Network Management Forum (NMF) to help ease the agent development process. The API allows the application to move from one Q3 interface to another without difficulty. This is useful for developers who must be able to use the same agent applications over different types of Q3 interfaces or over Q3 interfaces from different vendors.
The TMN/C++ API is made up of three APIs: the GDMO/C++ API, the common management information services (CMIS)/C++ API, and the ASN.1/C++ API. The GDMO/TMN++ API allows mapping between GDMO object classes and C++ classes. It provides services to instantiate objects and services to maintain the management information tree (MIT). High-level protocol services are provided by the CMIS/C++ API, which is an interface to common management informations services element (CMISE) and association control service element (ACSE). The ASN.1/C++ API lets the developer move data between application-specific data types and ASN.1 data types. It performs operations on ASN.1 data types and can encode and decode data for transmission between systems. Using this API will speed development if one is coding by hand.
|
