4.1 Defining Management Middleware

There are two main reasons for the definition of pre-defined, commonly usable and delegatable functionality for realizing management services in distributed heterogeneous environments i.e. management middleware:

• Functionality needed by several management applications should only be defined and implemented once. It can then be used collectively by all sorts of management applications. This can be done in object-oriented environments by inheriting the desired functionality from appropriate services. Examples of this kind of functionality are services for creating, deleting and grouping managed objects or the application of management policies.
• As mentioned in section 2, scalability issues require the delegation of specific management functions to the managed systems. Appropriate examples are threshold monitoring, event filtering and forwarding or the scheduling of periodic management tasks.

The adequate means of implementing management middleware in object-oriented environments is by defining the functionality in terms of services and making them accessible to all the components of a management system. The Interface Repository and the DII in conjunction with CORBA 2.0 interoperability provide a well-suited infrastructure for these purposes as the interfaces of newly introduced managed objects are implicitly propagated throughout the ORB environment.

Figure 2 illustrates how management services can be shared between managing and managed systems. As these services are implemented as objects, any managing or managed system is able to derive the needed functionality from these services.

  

Figure 2: Sharing Management Services between Managing System and Managed Systems

There are two ways of introducing management services in CORBA:

• The first possibility is to implement new services "from scratch" and introduce them as new CORBAfacilities. This approach has been chosen by the X/Open Systems Mananagement Task Group. A first set of management facilities has been submitted to the OMG and is described in detail in [16]. It encompasses the following services: Policy-driven Base, Instance Management, Policy Management and Managed Sets.
• The second way consists in reusing management functionality defined in the traditional management architectures and making it accessible to CORBA-objects. This approach is described in subsection 4.2.

It is important to consider that the boundary between CORBAservices and CORBAfacilities is not static but is able to change over time. The consequence is that services for systems management are not necessarily bound to the CORBAfacilities but can also be defined as CORBAservices or even be provided as part of the ORB runtime system.

The following example describes functionality defined as a CORBAservice: As in traditional client/server architectures, accounting plays an important role for CORBA-based applications. The main difference is that these applications consist of a multitude of fine-grained software components; current accounting mechanisms like node-locked or application-bound, floating licenses are therefore not appropriate for performing accounting functions in distributed environments. This problem has been recognized by the OMG and is addressed by the Licensing service.

An example of management functionality being part of the ORB and therefore not being defined in terms of services is given below: In CORBA-based systems, objects are identified by an object reference; this reference hides the objects' properties like its location. While this may look unsuitable for systems management because it is important to determine where to look in case of failures, this restriction is compensated by the methods of the Interface Repository in cooperation with the ORB Interface. Given an object class, some ORB implementations are able to determine the location of currently instantiated objects; this is comparable to a management auto-discovery service.

The conclusion to be drawn is that in CORBA environments, management functionality is not specified in terms of a dedicated model (as it is the case with the OSI/TMN architecture), but occurs at different levels of the OMG framework.