Solstice Enterprise Manager 4.1 Developing C++ Applications Doc Set ContentsPreviousNextIndex

Chapter 1

Introduction to the Solstice EM C++ Development Environment

The Solstice Enterprise Manager (Solstice EM) C++ development environment enables you to extend the functionality of Solstice EM by developing custom applications to meet your particular network management needs.

This chapter introduces the Solstice EM C++ development environment.

1.1 What You Can Develop in the Solstice EM C++ Development Environment

Solstice EM is a network and element management platform that simplifies the management of large and complex networks. Solstice EM is suitable for many management tasks, for example:

Use the Solstice EM development environment to develop client applications to perform specific network management tasks when there is a need to:

1.2 Solstice EM Network Management Model

Network management in the Solstice EM environment follows the International Organization for Standardization (ISO) network management model. This model is based around manager and agent applications that exchange network management information. The ISO network management model is object oriented. According to this model, a network resource that you want to manage is represented as a managed object. A managed object is a software abstraction of a managed resource. For more information, refer to Section 2.1 ISO Management Model.

1.3 Solstice EM Programming Model

To develop robust applications that are easy to maintain, adopt a component-based programming model. Applications developed according to such a model are built from a number of separate components. Building applications from separate components simplifies the development and maintenance of applications, particularly if the application is large and complicated, or if the network to be managed is subject to change. Application development is simplified because changes to one component do not require the entire application to be modified.

Building an application from a number of different components enables you to isolate each component to deal with its own data. Isolating each component minimizes the effects on your application of changes to the network that your application will manage. If your application has to manipulate new data types (for example, because a new device type has been added to the network) you need to modify only the components that handle the new data types. The rest of your application is unaffected.

1.3.1 Solstice EM Application Program Interface (API) Component

The Solstice EM API component handles interactions between your application and the Solstice EM platform. Changes to your network can affect the Solstice EM API component. To minimize the effects of such changes, keep the Solstice EM API component independent of your network management data whenever possible. In particular, try to enable your code for this component to handle data in any format.

To enable you to write code that can handle data in any format, the Solstice EM development environment requires you to take account only of the operations permitted on managed objects. You do not need to take account of the attributes of managed objects, nor the data types of these attributes. The Solstice EM development environment enables you to query managed object definitions to obtain information about attributes of managed objects. For more information, refer to Section 5.10 Retrieving Data From the Metadata Repository.

Another means of keeping this component independent of your network management data is to decode your data and pass the decoded data to an application-specific class that stores important attributes. Chapter 9 explains how to decode complex data types.

1.3.2 Data Component

The data component provides a programmatic representation of your network management data. The data component is only necessary when the amount of network management data is large. If your application has to maintain only a subset of the data, you can enhance the performance of your application by writing C++ classes to represent the data. By keeping this representation in separate C++ classes, you minimize the effect of changes to your network management data on your application.

1.3.3 Graphical User Interface (GUI) Component

The GUI component handles interaction between your application and its users. The GUI component contains:

Isolate the code for this component from application specific code to minimize the effects on your application of changes to the GUI.

Computer-aided software engineering (CASE) tools such as SPARCworksTM VisualTM GUI builder simplify the generation of code for this component. If you use such a tool to generate code for the GUI component, isolate the generated code from code you write.

Isolating generated code simplifies maintenance and future development of your application. For example, if the look and feel of the GUI change, all you need to do is make changes in the CASE tool, generate new code and implement new functionality in the GUI component.

1.4 Overview of the Application Development Process

The application development process in the Solstice EM development environment is similar to the process that is followed on any serious software engineering project. Such a process typically consists of the following phases:

1.4.1 Requirements Analysis and High-Level Design

The requirements analysis phase identifies the functional requirements of your application. The requirements analysis phase consists of:

The high-level design phase adds to the requirements specification by identifying nonfunctional requirements. The high-level design phase consists of:

Information on how to write an object model by using GDMO is given in Chapter 2.

Special considerations in the requirements analysis and high-level design phases for an application developed by using Solstice EM include:

1.4.1.1 Device Type Properties

If you are writing an application to manage a new class of device that has been added to your network, consider which aspects of the device need to be managed. Considering the aspects of the device that need to be managed involves identifying the parameters of the device that you want to control and monitor. The parameters you identify affect the object model you write for the device.

After you have identified the aspects of the device that you want to manage, consider how your application will manage the device. Considerations for how your application will manage a device include:

Polling a Device

If a device needs to be polled, decide whether it can use existing poll rates or new poll rates. If a polling operation detects an error, consider what action should be taken. When considering the action to take in response to an error, decide whether:

Handling Unsolicited Messages From a Device

If a device sends notifications, traps, or other unsolicited messages, consider how your application will handle such messages.

If the messages are of a type that the Solstice EM platform already recognizes, decide if the messages need to be handled differently from how the Solstice EM platform is currently configured to handle messages of that type.

If the messages are of a type unrecognized by the Solstice EM platform, decide if the messages need to be handled or can be ignored. If the messages need to be handled, decide whether they can be handled in a similar way to messages of a type that the Solstice EM platform currently recognizes, or whether they need special handling.

Setting Configuration Parameters of a Device

When you add a new class of device to a network decide how the configuration parameters of the device will be set. If a configuration parameter is set to a default value for all instances of a device, consider specifying that value in the object model of the device. If a configuration parameter is set to a different value for each instance of a device, consider enabling users of your application to set the parameter.

Monitoring the Performance of a Device

To monitor the performance of a device you need to know what is the normal performance of the device. To enable a device to report performance problems, identify the attributes or behaviors that you can use to indicate normal and abnormal performance. These attributes or behaviors are defined in the managed object class that represents the class of the device. Also determine if existing performance defaults can be used.

Handling Error Conditions for a Device

To handle error conditions for a device, identify the normal and error states of the device. After you have identified these states, assign a severity to each state. Assigning severities is a policy decision.

To enable a device to report an error condition, identify the attributes or behaviors that you can use to indicate normal and error states. These attributes or behaviors are defined in the managed object class that represents the class of the device.

To facilitate error recovery, decide to whom error conditions should be reported and how they should be reported. For example, decide whether an indication of the alarm in the Viewer tool by changing the color of an icon is sufficient. Also determine whether any standardized process or commands exist to correct error conditions associated with a device. If such processes do not exist already, consider if you need to implement them in your application.

1.4.1.2 Network Properties

The properties of the network your application will manage affect the design of your application. Considerations arising from network properties include:

Importance of the Device to the Functioning of Your Network

If you are managing a device, the importance of the device to your network affects how you choose to manage the device. A device that is part of your network backbone, or is a dedicated file server or application server, is likely to play a key role in your network.

If a device plays a key role in your network, consider whether you need to monitor it more closely than less important devices. For example, if the device is polled, consider whether the polling rate should be higher than for other less important devices.

If the device is a server, consider how frequently is it accessed. Consider also the effect on your network of a server failure.

Performance Requirements of Your Network Backbone

The smooth operation of a network requires that the network backbone performs adequately. When you design a network management application, determine what level of performance is required for the backbone of the network, what level of performance should be considered marginal, and what level of performance should generate alarms.

1.4.1.3 User Interaction

The needs of users who will interact with your application affect the design of your application. Taking account of the needs of users involves:

Identifying Information That is Presented to Users of Your Application

To manage a network, users of your application need to be informed of the state of network resources. Analyze the functional requirements of your application to identify information that needs to be presented to users of your application.

When you have identified information that needs to be presented, analyze the network that your application will manage to find out where the information will come from. Find out, for example, if the information will be provided by a device or by another application, such as the Nerve Center or event forwarding discriminators (EFDs).

Determine if you need to gather, summarize, or process information in a manner that is not possible by using Solstice EM subcomponents such as Nerve Center requests, EFDs, or log objects. Where possible, use Solstice EM subcomponents to obtain the information you want to present to users of your application. Using Solstice EM subcomponents saves the costs of having to develop entire applications from scratch.

Deciding How Information is Presented to Users of Your Application

To determine how best to present information to users of your application, analyze how that information will be used. Determine whether the information needs to be presented in a specialized manner that is not possible by using existing Solstice EM tools, such as the Viewer or the Alarm Manager. Specialized presentation of information includes special presentation windows, GUI-based device front ends, or terminal output.

Even if you require specialized presentation of information, consider if it also makes sense to display some information in standard Solstice EM tools such as the Viewer, the Log Manager, or the Alarm Manager, or in another Solstice EM client application you have developed.

Determining How Users Should Start Applications You Develop

Applications you develop will typically be used in conjunction with other Solstice EM components to provide a complete network management solution. To enhance the usability of your network management solution, determine which is the most convenient means for users to start your applications. Depending on the purpose of an application, you can enable users to start the application from:

Identify the information that your application needs when it is started, for example context information or initialization information. When you have identified this information, determine where it comes from and whether it differs from the information your application normally uses or displays.

Preventing Users From Introducing Errors

Design the user interface of your application to prevent users from introducing errors. Where possible, prevent users from carrying out sequences of operations that will introduce error conditions into your network.

Control access to critical data to ensure that such data is modified only by operators who are qualified to do so. For more information, refer to Section 1.4.1.5 Access Control for Solstice EM Applications.

1.4.1.4 Management Information Sharing

If your application needs to share management information, considerations for your application include:

Access to Information From Multiple Users

How multiple users access information affects the design of your application. If your application is intended to be used by more than one user at a time, you need to enable your application to support multiple concurrent users.

You also need to determine if several applications need to access to management information simultaneously. If the information that needs to be shared exists in the Solstice EM MIS, all you need to do is develop an application to access the information.

Information Sharing and Storage Requirements

If your application will gather or summarize information, determine whether this information needs to be stored permanently or temporarily. If the information needs to be stored temporarily, determine if it needs to be stored only as long as your application is running, or as long as a server that serves your application is running.

Identify the sources of the information your application will gather or summarize. For example, the information may reside in the MIS, EFDs, or the Nerve Center.

If other applications require information gathered or summarized by your application, determine how best to share this information.

Note – Applications normally share information by using the MIS. To enable applications to share information directly (that is, without using the MIS), use the application-to-application API. For an overview of the Solstice EM C++ APIs, see Section 1.4.2.1 API Choice.

Distribution of Information in Unsolicited Messages

If several copies of your application will be running simultaneously, determine if all copies need to receive notifications, traps, or other unsolicited information.

Access Control for Shared Information

If information is shared between several copies of your application, determine if the information used by one copy of the application needs to be kept secure from other copies of the same application. Similarly, if information is shared between applications, determine if the information used by an application needs to be kept secure from other applications.

Note – Solstice EM does not currently support this type of data partitioning for security purposes.

1.4.1.5 Access Control for Solstice EM Applications

If you want to enforce access control for your application, you need to decide which of the following levels of access control you require:

For more information about designing access control for your applications, refer to Chapter 12.

Application-Level Access Control

Implement application-level access control if you want your entire application to be inaccessible to some users of the network management solution that your application is a part of. For example, if your application is used for the administration of your network management solution, make the application accessible only to system administrators and inaccessible to network operators.

If you implement application-level access control, make sure that your application gives proper feedback to a user that is denied access to your application.

Application-Feature-Level Access Control

Implement application-feature-level access control if you want some users to be able to access some, but not all, the features of your application. For example, if your application enables users to monitor, add, modify, and delete network resources, implement application-feature-level access control to allow some users to monitor network resources, but not to add, modify, or delete network resources.

If you implement application-feature-level access control, make sure that your application gives proper feedback if a user is denied access to a feature. Where possible, make sure that your application prevents users from performing operations they do not have permission to perform. In a graphical application, make commands for performing such operations inactive and grayed out.

If you implement application-feature-level access control, make the list of application features available to your system administrator so that the system administrator can grant users access rights to perform various operations.

Managed-Object-Level Access Control

Implement managed-object-level access control if you want some managed objects to be inaccessible to some users of your network management solution.

Managed-object-level access control denies users access to managed objects regardless of which application they use to try to access the managed objects. If you use application-feature-level access control to deny access to these managed objects, you do not prevent users from accessing the managed objects by using other features of other applications.

If you implement managed-object-level access control, make sure that your application gives proper feedback if a user is denied access to a managed object. In addition, make sure that your application can handle any exceptions or errors thrown if a user is denied access to a managed object.

Event Notification Access Control

Implement event notification access control if you want to ensure that a user's event logs contain only event notifications emitted by managed objects to which the user has access. By default, all events that the Solstice EM platform receives are written to a user's event logs, including event notifications from managed objects that the user is normally denied access to.

MPA Access Control

Implement MPA access control if you want some managed objects that are accessed through an MPA to be inaccessible to some users of your application.

If you implement MPA access control, make sure that your application gives proper feedback if a user is denied access to a managed object accessed through an MPA.

1.4.1.6 Multiple Management Information Server (MIS) Management

If more than one Solstice EM MIS will be used to hold your network management information, you need to consider how multiple MISs will be managed. Managing multiple MISs involves:

Determining the Subordinate Objects of the Root of the MIT

In the Solstice EM environment, managed objects that represent your network resources are arranged in a hierarchy known as the management information tree (MIT). For more information on the MIT, refer to Section 2.2.6 Identifying Containment Relationships.

If more than one EM MIS will be used to hold your network management information, determine which managed objects will be located under the root of the MIT. For each managed object that will located under the root of the MIT, you need to determine its fully distinguished name (FDN). For more information on FDNs, refer to Section 2.2.6.2 Names of Managed Object Instances.

Deciding if the FDN Table Requires Manual Updating

Each managed object that resides outside the local MIS has an entry in the FDN table. The FDN table maps the FDN of a remote managed object to the location of the entity in which the managed object resides. The location of the remote entity is given by its presentation selector.

If more than one EM MIS will be used to hold your network management information, you need to determine if the FDNs of remote managed objects need to be manually updated into the FDN table.

Assigning Managed Objects to an MIS

If more than one EM MIS will be used to hold your network management information, you need to assign each managed object to an MIS.

Deciding Which Information is Exchanged Between MISs

If more than one EM MIS will be used to hold your network management information, you need to decide on the types of information that will be automatically passed from one MIS to another.

When information is shared between MISs, you need to decide how MISs will be arranged hierarchically. The possible arrangements are as follows:

1.4.2 Low-Level Design

The low-level design phase follows the high-level design phase. The low-level design phase defines how your application will meet the requirements identified in the requirements analysis and high-level design phases. The low-level design phase consists of:

Special considerations in the low-level design phase for an application developed by using Solstice EM include:

1.4.2.1 API Choice

The Solstice EM C++ development environment provides a number of APIs, each of which has a specific purpose. You are free to use any combination of the APIs in a single application. The choice of APIs to use in an application depends on a combination of factors, such as:

The architecture of the C++ APIs supplied with Solstice EM is shown in FIGURE 1-1.


FIGURE 1-1   Architecture of the Solstice EM C++ APIs
Low-Level Portable Management Interface (PMI)

The low-level Portable Management Interface (PMI) provides a low-level abstraction of management services. The management services provided by the low-level PMI are equivalent to the services defined in ITU-T X.710/ISO-9595 Common Management Information Services (CMISE). The interface provided by the low-level PMI is distributed and independent of any transport-layer protocols.

Use the low-level PMI for applications that require high performance. Using the low-level PMI requires you to write more code than using the high-level PMI.

High-Level PMI

The high-level PMI is the primary API for management applications. This API provides a high-level abstraction of the managed resources in a network. This abstraction provides a means for manipulating objects that is independent of the class description, supported protocol, or location of the managed objects. The generic nature of the high-level PMI eases the development of network management applications.

Use the high-level PMI to keep coding simple for applications that do not require optimum performance.

The high-level PMI is built on the low-level PMI.

Object Services API

The object services API enables object behavior functions you develop to access information and services provided by the MIS. The decision to use these services depends on the behavior defined for an object. To develop object behavior functions, use the Solstice EM object development tools (ODT).

The object services API is built on the low-level PMI.

Topology API

The topology API provides access for management applications to topology services provided by Solstice EM. This API enables you to manipulate topology nodes, which are displayed in the Network Views tool. For information on the Network Views tool, refer to Managing Your Network.

The topology API hides the topology implementation, enabling you to port topology-based applications easily to future releases of Solstice EM as the high-level PMI evolves.

The topology API is built on the high-level PMI.

Nerve Center Interface

The Nerve Center interface enables provides an API to the Nerve Center. The Nerve Center interface enables you to create request templates, launch requests against objects in the MIS, and retrieve information about objects. For information on the Nerve Center, refer to the Customizing Guide.

The Nerve Center interface is built on the high-level PMI.

Application-to-Application API

The application-to-application API enables applications to share information directly (that is, without using the MIS). Applications normally share information by using the MIS. The application-to-application API is built on the high-level PMI.

Viewer API

The viewer API enables you to integrate applications with the Network Views tool. This API enables applications to communicate with and modify the Network Views tool. For example, an application can get the current view, set the contents of the Network Views footer, or change the Network Views zooming or magnification.

The viewer API also enables applications to register with the Network Views tool to receive events generated by the tool. When an application registers with the Network Views tool to receive events, the application also registers callbacks that are executed when events are received from the Network Views tool.

For information on the Network Views tool, refer to Managing Your Network.

The viewer API is built on the application-to-application API.

Access Control Engine API

The access control engine API enables you to control user access to objects supported via user-developed MPAs and auxiliary servers. In this way, the access control engine API enables user-created MPAs and auxiliary servers to impose access control on the objects they manage.

For more information about designing access control for your applications, refer to Chapter 12.

The access control engine API is built on the low-level PMI.

Access Control API

The access control API enables you to control user access to your application, features within your application, and managed objects manipulated by your application. This API provides classes and member functions that enable you to assign access control rules to groups of users. These classes and member functions also enable you to define access control rules.

For more information about designing access control for your applications, refer to Chapter 12.

Grapher API

The grapher API enables your application to send data to the Grapher tool. If the Grapher tool is not running, the grapher API starts it automatically. The grapher API supports:

For information on the Grapher tool, refer to Managing Your Network.

1.4.2.2 Object Location

In the Solstice EM environment, managed objects that represent your network resources are stored as objects. Objects are either local or remote.

1.4.2.3 Provision of Behavior Code for Objects

All objects need behavior code. Behavior code enables an object to respond to management requests.

The MIS provides behavior code only for local objects. The MIS does not provide behavior code for remote objects. You must ensure that the entity within which a remote object resides provides behavior code for the object.

The behavior code that the MIS provides enables an object in the MIS to exhibit default behavior. If you want a local object to exhibit custom behavior, you can develop custom behavior code by either of the following means:

Using ODT

Using ODT simplifies the development of custom behavior code by generating much of the code for you. However, an object the behavior of which is developed by using ODT must reside in the MIS. Use ODT with care because errors in the behavior code of such an object may cause the MIS to fail.

For information on using ODT, refer to Chapter 10.

Writing an MPA

An MPA performs protocol translation required for communication between the Solstice EM platform and an external entity, such as an agent. Writing an MPA requires you to write more code than using ODT. However, an object the behavior of which is implemented by an MPA can reside on a separate server from the MIS, thereby enhancing the performance and reliability of your management solution.

For information on how to write an MPA, refer to Chapter 11.

1.4.2.4 Managed Object Identification

By default, a managed object in the Solstice EM environment is identified by its FDN as explained in Section 2.2.6.2 Names of Managed Object Instances. In an MIT with many levels of containment, FDNs become long and complicated. The FDNs of managed objects that are many levels below the root of the MIT are particularly long and complicated. To simplify the task of selecting managed objects you can assign nicknames to managed objects and select managed objects by specifying their nicknames.

For more information on setting up nicknames, see Section 5.3.2 Selecting a Managed Object by Specifying its Nickname.

1.4.3 Implementation

The implementation phase follows the low-level design phase. During the implementation phase, code that implements the design of your application is written, and the executable files of your application are generated.

In the Solstice EM C++ development environment, the implementation phase consists of:

1.4.3.1 Enabling Applications to Access Managed Objects

To manage a network, the applications you develop must have access to current data about managed resources. In the Solstice EM environment, managed resources are represented as managed objects. Your applications must be able to access managed objects to obtain the data they require.

For information on how to enable applications to access managed objects, refer to Chapter 3.

1.4.3.2 Handling Errors

Users need to know when an attempted network management operation has failed. By providing accurate information on why the operation failed, your applications can ease a user's work by indicating the corrective action required when problems occur.

For information on how to handle errors, refer to Chapter 4.

1.4.3.3 Performing Operations on Managed Objects

An application manages a network by monitoring and controlling managed resources in the network. In the Solstice EM environment, managed resources are represented as managed objects. An application monitors and controls managed resources by performing operations on managed objects.

For information on how to perform operations on managed objects, refer to Chapter 5.

1.4.3.4 Performing Management Operations on Object Collections

An object collection is a group of managed objects that your application can treat as a single entity. An object collection simplifies bulk operations by enabling you to select multiple managed objects to be the subject of a management operation. Any management operation that your application performs on an object collection is performed on every managed object in the object collection.

For information on how to perform management operations on object collections, refer to Chapter 6.

1.4.3.5 Handling Events

Any network management application that monitors and controls managed resources on a network needs to process information it receives from those managed resources. Such information is contained in event notifications. An event notification is an unsolicited message sent from a managed object that represents a managed resource. Event notifications contain error information and other types of status information.

For information on how to handle events, refer to Chapter 7.

1.4.3.6 Performing Asynchronous Management Operations

A management operation can take a significant length of time to finish, particularly if the operation exchanges a large quantity of data between your application and the network resources it is managing. If your application is blocked while waiting for an operation to finish, the application may appear unresponsive to a user, or may fail to respond quickly enough to important events on your network. Performing asynchronous management operations enables an application to continue with other processing without waiting for the operations to finish.

For information on how to perform asynchronous management operations, refer to Chapter 8.

1.4.3.7 Encoding and Decoding Complex ASN.1 Values

In the Solstice EM environment, attribute values in management requests, responses and event notifications are represented in a machine-independent format for transmission over a network. The format used is defined in ITU-T X.208/ISO-8824 Specification of Abstract Syntax Notation One (ASN.1). This standard defines several complex data types and enables you to define your own custom data types. When an application sends a request to set an attribute value represented by a complex data type, the application must encode this value for transmission over a network. When an application receives an attribute value represented by a complex data type (for example in a response or an event notification) the application must decode this value to extract the information the value contains.

For information on how to encode and decode complex ASN.1 values, refer to Chapter 9.

1.4.3.8 Controlling Access to Applications and Data

Controlling access to applications and data prohibits unwanted access to critical applications and network components. Without access control, any user of your network management solution can read or modify all your network management and configuration data. The risks of this approach can be devastating when users without the proper authority or expertise modify your network management data or the configuration data of your network management solution. By controlling user access, users are allowed to access only those applications and data they need based on their network management responsibilities and other relevant criteria.

For information on how to control access to applications and data, refer to Chapter 12.

1.4.3.9 Optimizing Performance

The high-level PMI provides many features that simplify the coding of an application. However, if you need fast response from an application, or if an application is controlling and monitoring a large number of managed objects, you need to tune the application to obtain optimum performance.

For information on how to optimize the performance of your applications, refer to Chapter 13.

1.4.3.10 Compiling and Linking Applications

Applications you develop by using the Solstice EM C++ APIs require specific flags to be set at compilation time. You also need to link your applications with the Solstice EM C++ libraries.

For guidelines on compiling and linking applications developed by using the Solstice EM C++ APIs, refer to Chapter 14.

1.4.4 Unit Testing and Debugging

The unit testing and debugging phase follows the implementation phase. The unit testing and debugging phase assures the quality of the application by ensuring that the application meets its stated requirements.

The Solstice EM C++ development environment provides tools to help you test and debug your applications. For information on how use these tools, refer to Chapter 15. This chapter also provides guidelines on how to avoid and correct errors specific to applications developed by using the Solstice EM C++ APIs.

1.4.5 Integration

The integration phase follows the unit testing and debugging phase. The integration phase integrates your custom applications with the Solstice EM platform to create a complete network management solution.

For information on how to integrate applications with the Solstice EM platform, refer to Chapter 16.

1.4.6 System Testing

The system testing phase follows the integration phase. The system testing phase assures the quality of your complete network management solution.

Sun Microsystems, Inc.
Copyright information. All rights reserved.
 		Doc Set  |   Contents   |   Previous   |   Next   |   Index