JIDM Facilities

Overview

The adopted approach consists in defining a basic set of CORBA Facilities, referred as JIDM Facilities, that will work for every Systems Management Reference Model.

JIDM Facilities can be extended or put together with additional complementary facilities to build up the set of CORBA Facilities that will be finally used to implement each of the specific Systems Management Reference Models. Thus, for example, when defining OSI Systems Management Facilities, specific OSI Management Facilities will be defined (facilities that allow to translate between OSI names and CosNaming::Names, handling operations with scoping and filtering, etc) in addition to those defined within JIDM Facilities (facilities defined to get references to single managed objects given their names, etc).

The JIDM Module

From the Manager application persepective the following interfaces are used:

• The ProxyAgent interface

• The ProxyAgentController interface

• The ProxyAgentFinder interface

• The EventPort interface

• The EventPortFactory interface

From the Agent application perspective the following additional interfaces are used:

• The DomainPort interface

• The DomainPortFactory interface

• The EventPortFinder interface

This section describes these interfaces and their operations in detail.

JIDM Managed Objects

However, every management environment must define some kind of managed object, that is the entity being managed in the respective environment. For example, in OSI systems man-agement, there is the concept of a managed object directly; in SNMP management, there is no concept of a managed object, but a concept of entries within the SNMP MIB, that is equiva-lent to a managed object.

The definition of these managed objects, in all management environments, must support the design principles outlined in Design Principles.

In particular, in support of the transparency principle, the following semantics are required of any managed object interface:

• If a CORBA object reference is used to request a managed object to perform an operation and the managed object does not exist, an OBJECT_NOT_EXIST exception should result.

• If a CORBA object reference is used to request a managed object to perform an operation and the request causes an OBJECT_NOT_EXIST exception, the managed object was actually deleted. (This property helps users avoid unnecessary failures while attempting to re-create an object that already exists.)

• If a CORBA object reference is used to request a managed object to perform an operation and the managed object exists, the operation shall not result in an OBJECT_NOT_EXIST exception.

The JIDM::ProxyAgent Interface

Invoking operations exposed by the JIDM::ProxyAgent object, CORBA manager objects are able to obtain references to:

• An initial CosLifeCycle::FactoryFinder object in the managed object domain being accessed

• An initial CosNaming::NamingContext object in the managed object domain being accessed

Invoking the find_factories operation exposed by the initial CosLifeCycle::FactoryFinder object, CORBA manager objects may find factories that enable creation of new members of the managed object domain.

Invoking the resolve operation exposed by the initial CosNaming::NamingContext object, CORBA manager objects may obtain CORBA object references to existing members of the managed object domain.

The get_domain_factory_finder Operation

The get_domain_factory_finder() operation enables to obtain a reference to this initial CosLifeCycle::FactoryFinder object in the domain being accessed through a given JIDM::ProxyAgent object.

As shown in CosLifeCycle::FactoryFinder Interface Definition, the find_factories operation supported by CosLifeCycle::FactoryFinders returns a sequence of factories which match some given key. The space of keys is established by convention in particular environments as explicitly declared in reference CORBA (chapter 6, page 14). Conventions adopted for JIDM facilities (that is, common to every Systems Management Reference Model) are described in JIDM Conventions for Factory Finder Keys. Additional conventions may exist for each specific Systems Management Reference Model being considered.

Several alternatives can be followed for assigning values to the keys that will be passed to the find_factories() operation.

• Only the name of the object interface is specified.
  Here, it is implicitly assumed that there is a factory interface associated to the managed object interface. CORBA managers know the name and operations associated to this factory in advance so that they can properly narrow and use the reference returned by the find_factories() operation.

• Only the name of the object factory interface is specified.
  Here, references returned by the find_factories() operation can be narrowed to the IDL interface whose name has been specified. The CORBA manager object who invoked the operation knows the signature and semantics of operations supported by the designated object factory interface. This option will be the one used to obtain references to generic factories exporting the CosLifeCycle::GenericFactory interface or any of the generic factory interfaces defined in reference SYSMANfacilities.

• Both the name of the object and factory interfaces are specified.
  This will be useful in environments where there are more than just one factory object interface associated to each managed object interface. Thus, the CORBA manager object specifies what is the interface that will be exported by the object to be created and, among the possible types of factories that can create objects exporting such interface, which is the actual interface of the factory that it wants to use for creating the new object.

In any case, the result of passing several key values should be interpret as the logical AND of the conditions associated to each of the keys.

In respect to creation of managed objects, it is worth noticing that JIDM facilities provide a generic framework that requires to be specialized for each specific Systems Management Reference Model. Such specialization implies precise definition of:

• The whole space of keys that are valid for finding factories

• The space for keys and criteria that can be passed as arguments to the create_object() operation exposed by CosLifeCycle::GenericFactory objects.

• Other types of interfaces that are better suited to the specific Systems Management Reference Model that is being considered (the OSIMgmt::ManagedObjectFactory interface or interfaces generated from namebinding GDMO templates in the OSI Systems Management Reference Model, for example)

The get_domain_naming_context Operation

The get_domain_naming_context() operation enables obtaining of a reference to the initial CosNaming::NamingContext object in the domain being accessed through a given JIDM::ProxyAgent object.

The design imparts no semantics or interpretation of the names themselves. Because the structure of names must be common to all Systems Management Reference Models, the structure of names defined in the standard CosNaming Service specification (see reference CORBA) has been adopted. The actual semantics or interpretation of names is up to the specific Systems Management Reference Model being used. CORBA facilities defined for a given reference model will typically include definition of library interfaces enabling construction of names in CORBA Naming Service form (CosNaming::Names).

Exceptions Raised by the Resolve Operation describes the exceptions raised by the resolve operation. Note that this description complies with the description given for the standard CosNaming service in referenced document CORBAservices.

Only the resolve() operation is guaranteed to be available in any management environment.

CORBA manager objects may not have access to the rest of operations (bind, unbind, etc.) exposed by the initial CosNaming::NamingContext object or any of its subordinate CosNaming::NamingContext objects. If a CORBA manager object invokes an operation it cannot access, a NO_PERMISSION exception is raised.

The access_criteria Attribute

This attribute is represented as a Criteria, and its contents are dependant on the specific System Management Reference model being used.

The destroy Operation

Destruction of a JIDM::ProxyAgent object can take place in one of the following modes:

• gracefully, meaning that resources associated to the session are going to be disposed in a graceful manner. If this is not possible, a CannotDestroy exception is raised.

• non_gracefully, meaning that resources associated to the session are going to be disposed in an abrupt manner. No user exception is expected in this case.

Graceful destruction of JIDM::ProxyAgent objects should always be requested in the first place. If graceful destruction were not possible, a client may request non_graceful destruction in order to destroy the object.

Invokers of the destroy operation may pass a criteria that will be analyzed to determine whether the destruction request can be accepted or not.

If any of the destruction criteria are not understood, the InvalidCriteria exception is raised. If the destruction request is not accepted, the CannotMeetCriteria exception is raised. The criteria describing reasons for the rejection is provided with the exception.

If destruction is accepted, the destroy operation returns a Criteria value which typically describes the terms and conditions under which destruction has been accepted. This criteria is initialized with values provided by controller objects in the manager and managed object domains. See The JIDM::ProxyAgentController interface for more details.

Once a JIDM::ProxyAgent object is destroyed, references to it are not further valid. Therefore, invoking an operation on a JIDM::ProxyAgent object that has been destroyed causes the standard OBJECT_NOT_EXIST exception to be raised. In addition, invoking operations using references to existing managed objects, factories, factory finders and naming contexts that were obtained through the destroyed JIDM::ProxyAgent object causes the standard NO_PERMISSION exception to be raised.

The JIDM::ProxyAgentController interface

A JIDM::ProxyAgentController object may be associated with a JIDM::ProxyAgent object during the invocation of access_domain() operation in the JIDM::ProxyAgentFinder, where it is passed in the criteria parameter. In this case, the JIDM::ProxyAgentController plays the role "associated at the manager side". Following the exact matching rule of key and criteria, a maximum of one JIDM::ProxyAgentController object may be associated with a given JIDM::ProxyAgent object at the manager side.

One or more JIDM::ProxyAgentController objects may be associated with a JIDM:ProxyAgent, at the managed object domain. This can be done if a JIDM::DomainPort object is initialized with a list of JIDM::ProxyAgentController objects (see The JIDM::DomainPort interface).

A destroy() operation invoked in a JIDM::ProxyAgent object will invoke operation(s), depending on the destruction mode, in all JIDM::ProxyAgentController objects associated with such JIDM::ProxyAgent.

The destruction_is_allowed Operation

The criteria passed as argument to the destroy operation is passed to the JIDM::ProxyAgentController objects as a parameter of the destruction_is_allowed() operation.

If destruction is allowed, the destruction_is_allowed() call returns a Criteria potentially specifying the terms and conditions under which destruction is allowed. If the Criteria is empty, destruction is allowed unconditionally.

If destruction is prohibited, the CannotMeetCriteria exception should be raised. This exception carries the reason why permission to destroy was not granted.

When an exception is raised by any JIDM::ProxyAgentController object in response to this call, this exception is automatically propagated as the result of the destroy call that triggered this process.

If all JIDM::ProxyAgentController objects associated to the JIDM::ProxyAgent being destroyed allow the destruction, then the JIDM::ProxyAgent object is effectively destroyed. The Criteria returned by the destroy call is the result of combining all Criteria returned by all involved JIDM::ProxyAgentController objects. P When combining several criteria into one, the shared components are copied (once) into the combined criteria, and those that are present in one but not other are also copied into the combined criteria. That is, the combination is a union of criteria components. The actual number and type of values in the criteria will typically depend on the reference model being considered>

The destroyed operation

This call carries the Criteria passed to the destroy() call in case of ungraceful destruction, or the combined results of the corresponding destruction_is_allowed() calls, as described above.

If there are more than one JIDM::ProxyAgentController object associated to a JIDM::ProxyAgent, they will all be notified.

JIDM::ProxyAgentFinder Interface

A JIDM::ProxyAgent object represents a session established with a managed object domain. Each session is unequivocally characterized by:

• A key which typically identifies the specific Systems Management Environment being considered (for example, OSI environment, SNMP environment). This key enables to adequately interpret the criteria value passed as second argument to the operation

  and

• a criteria value which contains, among other things, the title associated to the domain being accessed (an AEtitle in OSI environments, an IP-address or hostname in SNMP environments).

This means that invoking the access_domain() operation with two different <key , criteria> pairs will result in creation of two different JIDM::ProxyAgent objects.

The access_domain Operation

• No JIDM::ProxyAgent object exists with the same key and criteria values passed in the invocation. In this case, a new JIDM::ProxyAgent object is created with the key and criteria values associated to it. Finally, a reference to the new JIDM::ProxyAgent object is returned.

• A JIDM::ProxyAgent object exists with the same key and criteria values passed in the invocation. In this case, a reference to the already existing JIDM::ProxyAgent object is returned.

It is worth noticing that there can be multiple sessions established with a managed object domain. This means that any managed object may be accessed through multiple JIDM::ProxyAgents.

Conventions adopted for keys in JIDM are described in JIDM Conventions for Proxy Agent Finding Keys. Standard key values include OSI Management and Internet Management, denoting the OSI and SNMP-based Systems Management Environments.

The criteria passed as second argument to the access_domain() operation will contain information needed to setup the requested session. Only the title assigned to the domain being accessed has been identified as required for all Systems Management Reference Models. Wildcard titles are supported in some specific management environments, enabling designation of the whole space (domain) of managed objects.

If the manager requires to excersise control upon destruction of the ProxyAgent, a reference to a JIDM::ProxyAgentController object must be also specified in the Criteria (see The JIDM::ProxyAgentController interface).

JIDM Conventions for Proxy Agent Finding Criteria summarizes the name and meaning of criteria that may be passed as input argument to the access_domain operation exposed by JIDM::ProxyAgent objects.

The actual number and type of values in the criteria will typically depend on the reference model being considered.

A reference to a root JIDM::ProxyAgentFinder object at the manager may be obtained by means of invoking the resolve_initial_references() operation exposed through the standard CORBA::ORB interface. The standard CORBA::ObjectId assigned to the root JIDM::ProxyAgentFinder object would be JIDM::ProxyAgentFinder.

Example code for Accessing a Managed Object Domain is an example fragment of code in a CORBA Manager program:

Other possibilities include (but are not limited to) registration of the root JIDM::ProxyAgentFinder object in the local initial CosNaming::NamingContext or a local Trader.

The JIDM::DomainPort interface

All JIDM::DomainPort objects associated to a managed object domain (that is, associated to titles used to refer to that managed object domain) hold references to initial CosNaming::NamingContext and CosLifeCycle::FactoryFinder objects in the domain.

In pure CORBA environments, when a manager object invokes the access_domain() operation on a ProxyAgentFinder object, the request will finally arrive to the JIDM::DomainPort object associated to the title passed as one of the parameters in the criteria.

Two scenarios may occur:

• A JIDM::ProxyAgent object exists that exactly matches the key and criteria values passed as arguments to the access_domain() operation. In this case, the JIDM::DomainPort object finds a reference to the JIDM::ProxyAgent object and returns it to the invoker.

• There is no JIDM::ProxyAgent object matching the key and criteria values passed as arguments to the access_domain() operation. In this case, the JIDM::DomainPort object creates a new JIDM::ProxyAgent object and returns the reference to the invoker. References to the initial CosNaming::NamingContext and CosLifeCycle::FactoryFinder objects in the domain will be passed to the new JIDM::ProxyAgent object by the JIDM::DomainPort object.

During its lifetime, a JIDM::DomainPort object will keep the references to all JIDM::ProxyAgent object it creates. This is necessary in order to resolve the first scenario.

The JIDM::DomainPortFactory Interface

The key passed as first parameter to this call follows the same conventions that were specified in JIDM Conventions for Proxy Agent Finding Keys. The criteria passed as second argument to the create_domain_port() operation will contain information needed to create the JIDM::DomainPort object. Only the title assigned to the domain being accessed has been identified as required for all Systems Management Reference Models. Other criteria values may be considered as default values for all the JIDM::ProxyAgent objects that are created by a given domain port.

If the managed domain requires to excersise control upon destruction of the JIDM::ProxyAgent objects, a reference to one or more JIDM::ProxyAgentController objects must be also specified in the Criteria.

The JIDM::EventPort Interface

A JIDM::EventPort object models the port through which events are going to be received by a given manager application. This port is created according to a certain criteria which, among other things, contains the title that identifies the manager domain (see The JIDM::EventPortFactory Interface). Any agent/managed object that wants to send events to a manager must set up a connection with the CosEventChannelAdmin::SupplierAdmin object associated to the JIDM::EventPort object with the appropriate title.

A JIDM::EventPort therefore provides and handles access to a specific CosEventChannelAdmin::SupplierAdmin object in a channel (the SupplierAdmin object associated to the EventPort). The same CosEventChannelAdmin::SupplierAdmin object may be assotiated with different JIDM::EventPorts, and therefore may be accessed through several JIDM::EventPorts.

Also note that more any number of agents/managed objects may establish sessions with the same CosEventChannelAdmin::SupplierAdmin associated to a given JIDM::EventPort.

JIDM::EventPorts may be destroyed by means of invoking the destroy operation they expose.

The JIDM::EventPortFactory Interface

Any manager wanting to receive events should obtain an object reference to a CosEventChannelAdmin::SupplierAdmin of the channel that is to be used to receive the events, and create a JIDM::EventPort object with the desired Criteria. The JIDM::EventPort object receives a key, identifying the Systems Management Reference model to be used (with the same values specified in JIDM Conventions for Proxy Agent Finding Keys), a criteria containing at least the title of the manager, and a reference to the CosEventChannelAdmin::SupplierAdmin object. Only the title of the manager application has been identified as required by all System Management Reference models. The criteria may contain other fields associated to the specific management environment being used.

Note that the manager may create a new channel (or admin) or use an object reference to an existing one.

A manager needs to create an EventPort just once, independently of the agents that are or will be interested in receiving events. This enables a manager to receive event reports from one or more agents through a specific title.

In addition, several manager objects could share the same SupplierAdmin, or EventChannel (NotificationChannel) object, and connect themselves as consumers interested in receiving just some kind of events.

If the creation is successful, a reference to the newly created JIDM::EventPort object is returned.

In case of problems, the appropriate exception is raised:

• InvalidKey in case the Key is not recognized

• InvalidCriteria if any of the components of the Criteria is not understood

• CannotMeetCriteria if the conditions for creating the EventPort cannot be met

• AlreadyExists in case there is already an existing Event Port registered with matching Key/Criteria

JIDM::EventPortFinder Objects

Connection to the CosEventChannelAdmin::SupplierAdmin object associated to a given JIDM::EventPort is gained by means of invoking the operation find_event_port() exposed by a JIDM::EventPortFinder object in the agent. As a result of that invokation, a reference to the CosEventChannelAdmin::SupplierAdmin object that matches the corresponding Key and Criteria is returned. Managed objects may establish specific connections to this CosEventChannelAdmin::SupplierAdmin object by using operations exposed by the SupplierAdmin interface.

It is worth noting that the JIDM::EventPortFinder object returns a reference to the CosEventChannelAdmin::SupplierAdmin objects associated to the JIDM::EventPort object, and not a reference to the JIDM::EventPort itself.

Essentially, invoking the find_event_port() operation exposed by a JIDM::EventPortFinder object implies that the following steps are followed (see Finding References to JIDM::EventPort Objects):

1. The JIDM::EventPortFinder object finds a reference to the JIDM::EventPort object associated to a given key and criteria

2. The JIDM::EventPortFinder finds the CosEventChannelAdmin::SupplierAdmin object associated to this JIDM::EventPort, and a reference to this object is returned to the CORBA managed object that invoked the find_event_port() operation.

In case the request fails, the appropriate exception is raised:

• InvalidKey in case the Key is not recognized

• InvalidCriteria if any of the components of the Criteria is not understood

• CannotMeetCriteria if the conditions for finding the EventPort cannot be met

• NoEventPort in case there is no Event Port registered with the appropriate Key/Criteria

Different strategies to resolve how CORBA managed objects finally report events can be implemented:

1. CORBA managed objects directly register themselves as PushSuppliers or PullSuppliers through the SupplierAdmin associated to the JIDM::EventPort

2. CORBA managed objects register themselves as PushSuppliers or PullSuppliers in a single object which acts as some kind of EventChannel (or NotificationChannel) which in turn is registered as a PushSupplier or PullSupplier as described above. This is particularly useful when there are more than one JIDM::EventPort objects and the CORBA managed objects do not need to be aware of the specific port to which events must be sent.

Programming Model

It presents different scenarios where the use of this specification is clarified. This should be considered as a high level tutorial on some potential uses of the JIDM model. Also, some potential implementation options are discussed.

Programming semantics

This concept of transparency is specifically supported by the fulfillment of the semantic rules presented in JIDM Managed Objects.

Creating Managed Objects

1. Obtain a reference to a JIDM::ProxyAgent object that enables access to the domain where the managed object is going to be created.

2. Obtain a reference to the initial CosLifeCycle::FactoryFinder in the domain.

3. Invoke the find_factories() operation exposed by the initial CosLifeCycle::FactoryFinder object to find a factory for the new managed object.

4. Select a factory among the several factory objects that may meet the keys for finding factories passed to the find_factories() operation.

5. Invoke an appropriate operation, exposed by the selected factory, to create the managed object.

The CORBA manager will narrow references returned by the find_factories() operation in order to get visibility of the specific interface exported by each factory. Two scenarios are possible:

• There is a specific factory interface associated to each managed object interface

• Factories export a well-known generic interface like the CosLifeCycle::GenericFactory interface (see CosLifeCycle::GenericFactory Interface Definition)

CORBA Managers should know which of these two scenarios is implied when the name of factory object interface is not passed as key to the find_factories() operation.

Typically, a name for the managed object is passed as argument to the create operation. This name would unequivocally identify the managed object within the domain where it will be created. The identifier of the principal interface exported by the managed object should also be passed to the create operation in case that it was not passed as a key to the find_factories() operation.

As already mentioned in section The JIDM::ProxyAgent Interface, valid key values for finding factories depend on the specific Systems Management Reference Model being considered. However, the overall philosophy is common to all models.

Example Code for Creating a Managed Object shows the code used to create a managed printer. This fragment of code would be the same for all reference models (for example, it would be the same for OSI management or SNMP-based management). Only the way in which the reference to the JIDM::ProxyAgent object is obtained, and the keys used to find factories or semantics of arguments passed to the create_object() operation may vary.

As shown in the example, CORBA managers will create managed objects (a managed printer in the example) in the same way they create CORBA objects in the local ORB domain - that is, by means of using standard CosLifeCycle services. Whether this actually happens or not depends on how the corresponding managed object domain is being accessed:

• Through one or several interconnected ORBs (that is, directly through CORBA)

• Through a JIDM gateway (a CORBA/CMIP gateway, for example).

Invoking Operations Directly Through CORBA illustrates how CORBA manager objects will create a new managed object in a pure CORBA environment.

Here, the JIDM::ProxyAgent created as a result of establishing a session with a CORBA managed object domain would typically hold references to the root CosNaming::NamingContext object and CosLifeCycle::FactoryFinder object in the domain. The following steps are followed:

1. The CORBA manager invokes the get_domain_factory_finder() operation exposed by the JIDM::ProxyAgent object. As a result, a reference to the initial CosLifeCycle::FactoryFinder in the domain being accessed is returned.

2. The CORBA manager object invokes the find_factories() operation exposed by the initial CosLifeCycle::FactoryFinder object. As a result, a reference to a managed object factory is obtained and returned to the CORBA manager object that requested it.

3. The CORBA manager object invokes a suitable operation on the managed object factory using the CORBA object reference previously obtained. Typically, the CORBA manager will narrow this reference to a wellknown managed object factory interface (the CosLifeCycle::GenericFactory interface, for example).

4. The managed object factory creates the CORBA managed object and perform any other required action such as registering a reference to the managed object with a name in the local CosNaming::NamingContext and/or notifying that a new managed object has been created to other objects at the managed object domain. These kinds of side effect actions may vary depending on the Systems Management Reference Model being considered.

5. Finally, if everything is all right, the managed object factory returns a reference to the CORBA manager object. Otherwise, it returns an exception.

Invoking Operations on Managed Objects

1. Obtain a reference to a JIDM::ProxyAgent object that enables access to some domain of which the managed object is member.

2. Obtain a reference to the initial CosNaming::NamingContext in the domain, by means of invoking the get_domain_naming_context() operation exposed by the JIDM::ProxyAgent object.

3. Construct the name that unequivocally identifies the managed object within the domain.

4. Invoke the resolve operation exposed by the initial CosNaming::NamingContext object in the domain, thus obtaining a CORBA object reference pointing to the managed object.

5. Invoke the operation on the managed object.

Of course, steps 1 through 4 are only strictly required the first time a managed object is accessed. Actually, the CORBA manager object that obtains a reference to a managed object can register the reference in some local object service so that other CORBA manager object can find the reference and do not need to interact with JIDM::ProxyAgent or CosNaming::NamingContext objects.

Once a reference is obtained for a managed object, it is valid as long as the managed object exist and the associated managed object domain is accessible. A valid object reference can be used as many times as required. Two alternatives exist for invoking an operation on a managed object once a CORBA object reference is obtained for the object:

• Use the Dynamic Invocation Interface (DII)

• Use IDL stubs generated from definition, in OMG IDL, of interfaces exported by the managed object.

In the first case, the CORBA object reference obtained as a result of resolving the name of the managed object can be used directly. In the second case, the CORBA object reference must be narrowed to a specific interface exported by the managed object.

Example Code for Invoking an Operation on a Managed Object shows the code used to invoke the reset operation exposed by a managed printer (that is, objects exporting the Printing::ManagedPrinter interface) using IDL stubs generated in C++.

It must be pointed out that this fragment of code would be the same for all Systems Management Reference Models (for example, it would be the same for OSI management or SNMP-based management). Only the way in which the reference to the JIDM::ProxyAgent object is obtained or the way in which the name of the managed object is constructed may vary. Thus, CORBA managers will have the illusion that managed objects (a managed printer in the example) are implemented as CORBA objects directly accessible via CORBA. Whether this actually happens or not depends on how the corresponding managed object domain is being accessed:

• Through one or several interconnected ORBs (that is, directly through CORBA)

• Through a JIDM gateway (a CORBA/CMIP gateway, for example).

Invoking Operations Directly Through CORBA illustrates how CORBA manager objects invoke operations on a managed object in a pure CORBA environment.

As already explained, the JIDM::ProxyAgent created as a result of establishing a session with a CORBA managed object domain would typically hold references to the initial CosNaming::NamingContext object and CosLifeCycle::FactoryFinder objects in the domain. Thus, the following steps will be followed:

1. The CORBA manager object invokes the get_domain_naming_context() operation exposed by the JIDM::ProxyAgent object, in order to obtain a reference to the initial CosNaming::NamingContext object.

2. The CORBA manager object invokes the resolve() operation exposed by the initial CosNaming::NamingContext object, passing the name of the managed object upon which it wants to operate. As a result of this, a CORBA object reference to the managed object is obtained and returned to the CORBA manager object that requested it.

3. The CORBA manager object invokes an operation on the managed object using the CORBA object reference previously obtained. IDL stubs or the standard DII can be used for doing this. If IDL stubs are used, the CORBA manager object must narrow the reference to a specific OMG IDL interface.

Reception of Events at CORBA Managers

• CORBA manager objects responsible of performing management functions directly register themselves as PushConsumers or PullConsumers at every local JIDM::EventPort.

• CORBA manager objects responsible of performing management functions register themselves as PushConsumers or PullConsumers in a single EventChannel. The event channel registers itself as a PushConsumer or PullConsumer in every local JIDM::EventPort. This is particularly useful when there are more than one JIDM::EventPort objects and the CORBA manager objects dont need to distinguish through which specific port events were received.

It is worth noticing that several advantages are derived from defining JIDM::EventPort objects as having CosEventChannelAdmin::SupplierAdmin objects. Among them, we should mention the following:

• Any EventChannel implementation supplied by any software provider can be used for receiving events from an agent.

• Managers wanting to filter events can register a NotificationChannel instead of an EventChannel in order to filter events. A manager who does not want to filter events can use a simple EventChannel. this can be achieved transparently for gateway/managed domains.

• The same EventChannel can be shared by several managers and a manager can reuse the EventChannel whenever he wants, independently of it is being used by other managers.

• Given the new NotificationChannel structure, multiple Admins per channel are possible (even frequent); by registering the Admin rather than the Channel itself, the user has better configuration possibilities.

• Ability to globally filter on reception.

• Easier grouping capabilities into a single channel, but keeping separate Admins per title (with potentially different filters).

• Potentially support delegation facilities (an agent/manager application could get a SupplierAdmin from a higher level manager and register it with another title, effectively saving a forwarding step).

• An EventChannel can be created in the gateway proccess (there is a EventChannelFactory facility being provided for doing so) or it can be created in any other distributed proccess and be registered in the gateway; that is: EventChannel can be distributed and the load of managing the final CORBA events can be balanced.

• CORBA manager objects consume events generated by remote managed objects in the same way they receive other events (events generated by other CORBA manager objects at the same CORBA Manager, for example)

• CORBA manager objects residing in different CORBA Managers can use JIDM::EventPorts to exchange events between them since they are ordinary event channels

• multiple scenarios for handling incoming events are possible at CORBA managers: one or several JIDM::EventPort objects can be installed, reception of events can be handled by means of applying different cascading techniques, push and pull styles of event communication can be combined, etc.

Handling Event Reports with Event Channels (Push Model) represents one possible scenario, where CORBA manager objects performing management functions are registered as consumers at an event channel which, in turn, has been registered as a PushConsumer at two local JIDM::EventPort objects. The basic algorithm being used is defined as follows:

1. During the start up phase of the CORBA Manager Application, a CosEventChannelAdmin::EventChannel object is registered as a CosEventComm::PushConsumer in every local JIDM::EventPort. CORBA manager objects actually performing the management functions are registered as consumers in this channel.

2. An JIDM::EventPort object receives data associated to an event.

3. The JIDM::EventPort invokes the push operation exposed by all objects that have been registered as CosEventComm::PushConsumers. This includes the CosEventChannelAdmin::EventChannel object. Data in the event is passed in the invocation as type any.

4. When the CosEventChannelAdmin::EventChannel object receives an event, it invokes the push operation exposed by all CORBA manager objects that were registered as CosEventComm::PushConsumers in the channel.

5. The CosEventChannelAdmin::EventChannel object keeps every event it receives until all CORBA manager objects that were registered as CosEventComm::PullConsumers invoke the pull operation on the channel or a timeout expires.

Handling Event Reports with Event Channels (Push Model) represents another possible scenario, where CORBA manager objects performing management functions are registered as consumers at one event channel that, in turn, has been registered as a PullConsumer at two local JIDM::EventPort objects. The basic algorithm being followed is:

1. During the start up phase of the CORBA Manager Application, the CosEventChannelAdmin::EventChannel objects is registered as a CosEventComm::PullConsumers in every local JIDM::EventPort.

2. A JIDM::EventPort object receives data associated to an event report.

3. The JIDM::EventPort object holds the event so that all objects registered as CosEventComm::PullConsumers can consume the event. They will do it by means of invoking the pull operation exposed by the JIDM::EventPort object.

4. When the CosEventChannelAdmin::EventChannel pulls the event, it invokes the push operation exposed by all CORBA manager objects that has been registered as CosEventComm::PushConsumers in the channel.

5. The CosEventChannelAdmin::EventChannel object also keeps every event it pulls, until all CORBA manager objects that have been registered as CosEventComm::PullConsumers invoke the pull operation on it or a timeout has expires.

Federation of JIDM::ProxyAgentFinders & JIDM::DomainPorts

The specific service used to federate JIDM::DomainPort objects in a pure CORBA environment is transparent to CORBA manager clients and, therefore, is out of the scope of this specification. Use of Traders or intermediate JIDM::ProxyAgentFinder objects connected in a graph are some examples of valid solutions. Furthermore, different federation services can be supported and combined in order to implement a complete solution.

Note that in this respect, the root JIDM::ProxyAgentFinder object that is accessible to CORBA managers simply represent a simple bootstraping mechanism that encapsulate access to whatever Federation Service is finally used. By means of standardizing this interface, portability of CORBA manager clients is guaranteed. On the other hand, the JIDM::ProxyAgentFinder interface allows easier implementation of gateways between CORBA managers and managed object domains that are only accessible through standard management protocols (CMIP, SNMP, etc).

In a pure CORBA environment, a complete solution may be implemented based on a graph of inter-connected JIDM::ProxyAgentFinder objects. In such solution, there would be at least two styles of JIDM::ProxyAgentFinder objects:

• JIDM::DomainPort objects which actually work as factories of JIDM::ProxyAgent objects

• Intermediary JIDM::ProxyAgentFinder objects which pass requests on to either JIDM::DomainPorts or other intermediary JIDM::ProxyAgentFinder objects

By configuring intermediary JIDM::ProxyAgentFinder objects and JIDM::DomainPort objects into a graph, the service for finding JIDM::ProxyAgent objects can be built so that it administers access to a large number of managed object domains.

Whenever a manager object invokes the access_domain() operation, the request would traverse the graph until it reaches a JIDM::DomainPort object which can satisfy the request (one which resides in the managed object domain being accessed). As the request traverses the graph, each intermediary (non-terminal) JIDM::ProxyAgentFinder object would decide which link the request would be traversed next. Decisions will be based upon information about each available link, any policies in force at that node and value of parameters in the request.

Clearly, configuration of JIDM::ProxyAgentFinder graphs and definition of policies to traverse these graphs requires definition of Federating interfaces (see Appendix 6C of reference CORBAservices for definition of interfaces to federate CosLifeCycle::GenericFactory objects). Again, different federation policies can be supported and combined in order to implement a complete solution. One possible alternative may consist in that intermediate JIDM::ProxyAgentFinder objects export an interface that enables to bind a reference to an JIDM::ProxyAgentFinder object together with a specific filter that can be applicable to key and criteria values passed to the access_domain() operation. This would allow to register one JIDM::ProxyAgentFinder object that are able to find references to JIDM::ProxyAgent associated to some range of title values.

Implementing Federation with Graphs of ProxyAgentFinders illustrates how federation of JIDM::DomainPorts would work if a graph of intermediate JIDM::ProxyAgentFinder objects is implemented. The following steps would be followed:

1. A manager object invokes the access_domain() operation exposed by the root JIDM::Proxy-AgentFinder object. The manager object typically obtained a reference to this JIDM::Proxy-AgentFinder object using local initialization services.

2. The JIDM::ProxyAgentFinder object that first receives the access_domain request will typically act as an intermediary JIDM::ProxyAgentFinder object. Based on information available to that object, it will decide to pass requests on to other JIDM::ProxyAgentFinder objects.

3. The request will traverse the graph until it reaches a JIDM::DomainPort object which resides at the managed object domain being accessed. That object will create or return an already existing reference to a JIDM::ProxyAgent object which matches the key and criteria value passed in the request.

4. As a result of this process, a valid reference to a JIDM::ProxyAgent object would be passed to the manager object which requested to establish a session. Using this reference, the manager object is able to operate upon members of the managed object domain or create new members of the managed object domain.

1. A manager object would invoke the access_domain() operation exposed by the root JIDM::ProxyAgentFinder object. The manager object would typically obtain a reference to the root JIDM::ProxyAgentFinder object using local initialization services.

2. The root JIDM::ProxyAgentFinder object would convert the request into an invocation of the lookup operation exposed by a Trader object. This Trader object may be federated with other Trader objects.

3. The request would traverse the graph of Traders until some of them finds a JIDM::DomainPort object which resides at the managed object domain being accessed. A reference to this JIDM::DomainPort object is passed to the root JIDM::ProxyAgentFinder object which initiated the process.

4. The root JIDM::ProxyAgentFinder object would invoke access_domain() on the JIDM::DomainPort object. As a result, a reference to a JIDM::ProxyAgent object is returned.

5. The returned reference would finally be passed to the manager object which requested to establish a session. Using this reference, the manager object is able to operate upon members of the managed object domain or create new members of the managed object domain.

Federation of JIDM::EventPortFinders & JIDM::EventPorts

The specific service used to federate JIDM::EventPort objects in a pure CORBA environment is transparent to CORBA manager clients and, therefore, is out of the scope of this specification. Use of Traders or intermediate JIDM::EventPortFinder objects connected in a graph are some examples of valid solutions. Furthermore, different federation services can be supported and combined in order to implement a complete solution.

Note that in this respect, the root JIDM::EventPortFinder object that is accessible to CORBA managed objects simply represent a simple bootstraping mechanism that encapsulate access to whatever Federation Service is finally used. By means of standardizing this interface, portability of CORBA managed object implementations is guaranteed. On the other hand, the JIDM::EventPortFinder interface allows easier implementation of gateways between CORBA managers and managed object domains that are only accessible through standard management protocols (CMIP, SNMP, etc).

In a pure CORBA environment, a complete solution may be implemented based on a graph of inter-connected JIDM::EventPortFinder objects. By means of configuring intermediary JIDM::EventPortFinder objects into a graph, the service for finding JIDM::EventPort objects can be built so that it administers access to a large number of managed object domains.

Whenever a managed object invokes the find_event_port() operation, the request would traverse the graph until it reaches the target JIDM::EventPort object. As the request traverses the graph, each intermediary JIDM::EventPortFinder object would decide which link the request would be traversed next. Decisions will be based upon information about each available link, any policies in force at that node and value of parameters in the request.

Clearly, configuration of JIDM::EventPortFinder graphs and definition of policies to traverse these graphs requires definition of Federating interfaces (see Appendix 6C of reference CORBAservices for definition of interfaces to federate CosLifeCycle::GenericFactory objects). However definition of such interfaces is out of the scope of this specification since they are transparent to the clients (managed objects). Different federation policies can be supported and combined in order to implement a complete solution.

One possible alternative may consist in that intermediate JIDM::EventPortFinder objects export an interface that enables to bind a reference to an JIDM::EventPortFinder object together with a specific filter that can be applicable to key and criteria values passed to the find_event_port() operation. This would allow, as an example, to register one JIDM::EventPortFinder object as being able of finding references to JIDM::EventPort objects associated to titles that fall within some specific range of title values.

Finding JIDM::EventPort Objects illustrates how federation of JIDM::EventPorts would work if a graph of intermediate JIDM::EventPortFinder objects is implemented. The following steps would be followed:

1. A managed object would invoke the find_event_port() operation exposed by a JIDM::EventPort-Finder object. The managed object typically would obtain a reference to this JIDM::EventPortFinder object using local initialization services.

2. The JIDM::EventPortFinder object that first receives the access_domain request would typically act as an intermediary JIDM::EventPortFinder object. Based on information available to that object, it would decide to pass requests on to another JIDM::EventPortFinder objects.

3. The request would traverse the graph until it reaches the target JIDM::EventPort object. The last JIDM::EventPortFinder object in the graph would obtain a reference to the CosEventChannelAdmin::SupplierAdmin object in the channel and would return that reference.

4. As a result of this process, a valid reference to a CosEventChannelAdmin::SupplierAdmin object would be passed to the managed object which issued the request. Using this reference, the managed object is able to register as a push or pull supplier.

JIDM Gateways

Manager-side Gateways

Overview

A JIDM gateway runs in one CORBA server. However, one or several JIDM gateways can co-exist in the same CORBA server. Programs of the CORBA server have access to both ORB services and services encapsulating access to managementspecific protocols provided by JIDM gateways at the server. Besides, there can be several CORBA servers containing JIDM gateways in the same CORBA Manager Application.

Any JIDM gateway typically has several CORBA objects associated with it (see Structure of JIDM Manager-side Gateways:

• A JIDM::ProxyAgentFinder object for establishing connections to managed object domains being accessed through the gateway

• One or several JIDM::EventPort objects for receiving notification of events from members of managed object domains being accessed through the gateway

The JIDM::ProxyAgentFinder object is created during startup of the CORBA server where the JIDM gateway is going to run. JIDM::EventPort objects at the gateway may be created during or after startup of that server. This typically requires the existence of an EventPortFactory object at the gateway.

Several JIDM gateways can exist in a CORBA manager and one JIDM::ProxyAgentFinder object is typically associated with each of them. All of them would be registered in a root JIDM::ProxyAgentFinder object at the CORBA manager (see also Structure of JIDM Manager-side Gateways). CORBA managers can obtain a reference to this local root JIDM::ProxyAgentFinder object by using standard CORBA Initialization Services.

As a result of establishing a connection through a JIDM gateway, a JIDM::ProxyAgent object is created at the gateway. JIDM::ProxyAgent objects created this way are responsible for:

• Creating a CosLifeCycle::FactoryFinder object that in turn enables creation of CORBA factories that handle creation of managed objects at the domain

• Creating a CosNaming::NamingContext object that in turn enables creation of CORBA proxy managed objects for each member of the domain

Access to Managed Object Domains

1. The CORBA manager invokes the access_domain() operation exported by the JIDM::ProxyAgentFinder object located at the gateway. Information that unequivocally identifies the managed object domain to be accessed is passed in the invocation.

2. As a result of invoking the access_domain() operation, a CORBA JIDM::ProxyAgent object is created at the gateway. The new JIDM::ProxyAgent object is bound to a management protocol communication endpoint (a service access point in OSI environments). If a specific domain title was specified in the criteria passed as argument to the access_domain() operation, then a connection is established with the managed object domain. In such a case, the JIDM::ProxyAgent is responsible to manage resources associated with the connection.

3. A reference to the JIDM::ProxyAgent object is returned to the CORBA manager that requested access to the managed object domain being considered.

Creation of Managed Objects

1. The CORBA manager invokes the get_domain_factory_finder() operation exported by the JIDM::ProxyAgent object.

2. The CORBA manager invokes the find_factories() operation exported by the returned CosLifeCycle::FactoryFinder object, passing a valid key value.

3. The CosLifeCycle::FactoryFinder object finds references for appropriate managed object factories at the JIDM gateway. If there is no managed object factory matching the key, the CosLifeCycle::FactoryFinder object creates one. References to managed object factories are returned to the CORBA manager.

4. The CORBA manager invokes an operation on the managed object factory using the CORBA object reference it obtained. Typically, the CORBA manager narrows this object reference to a specific managed object factory interface supported by the factory (the CosLifeCycle::GenericFactory interface, for example).

5. The CORBA request is received by the JIDM gateway and is translated into an appropriate management create request PDU. This create request PDU is sent through the management protocol communication endpoint held by the JIDM::ProxyAgent.

6. When the response to the request PDU is received, the invoked operation returns with the appropriate result values.

7. If the create operation must return an object reference then a CORBA proxy managed object is also created at the gateway.

Invocation of Operations on Managed Objects

1. The CORBA manager invokes the get_domain_naming_context() operation exported by the JIDM::ProxyAgent object.

2. A CORBA manager invokes the resolve operation exported by the returned CosNaming::NamingContext object, passing the name of the managed object upon which it wants to operate.

3. The CosNaming::NamingContext object finds a reference to the CORBA object acting as the proxy of the managed object and returns it to the CORBA manager that requested it. The CORBA proxy managed object resides in the JIDM gateway. The CosNaming::NamingContext object is responsible for creating the CORBA proxy managed object if it did not exist at the gateway, the first time an existing managed object is accessed.

4. The CORBA manager invokes an operation on the managed object using the CORBA object reference to the corresponding proxy. IDL stubs or the standard DII can be used to perform this action. Whenever IDL stubs are used, the CORBA manager must narrow the reference, obtained from the CosNaming::NamingContext, to a specific OMG IDL interface (the Printing::ManagedPrinter interface, for example).

5. The CORBA request is received by the JIDM gateway and is translated into an appropriate management request PDU. This request PDU is sent through the management protocol communication endpoint held by the JIDM::ProxyAgent.

6. When the response to the request PDU is received, the invoked operation returns with the appropriate result values.

Event Reception

As mentioned in Reception of Events at CORBA Managers, different strategies to resolve how CORBA manager objects finally consume events can be implemented. Just to give an example, CORBA manager objects can register themselves directly to JIDM::EventPorts or via some additional event channel.

The following steps are followed when a CORBA manager receives an event through a JIDM::EventPort located at a gateway (see Event Reporting at JIDM Manager-side Gateways):

1. During the start up phase of the CORBA Manager Application, one or more application objects register themselves either as CosEventComm::PushConsumers or CosEventComm::PullConsumers in each of the existing JIDM::EventPorts.

2. A PDU containing a notification of an event from a managed object is received by the JIDM gateway through some management connection endpoint. This management connection endpoint is bound to a specific title and has a JIDM::EventPort object associated with it which finally receives the event data carried in the PDU.

3. The appropriate response (if applicable) is sent by the JIDM gateway back to the application that reported the event, confirming that the event was received at the Manager Application.

4. The JIDM::EventPort invokes the push operation exported by all CosEventComm::PushConsumers objects connected to it. Data of the event is passed in the invocation as an any.

5. The JIDM::EventPort maintains the event until all CosEventComm::PullConsumers objects connected to the port pull the event. Data of the event is obtained by consumers as an any.

6. CosEventChannelAdmin::EventChannel objects can be connected as consumers to the event port. In such a case, manager objects performing management functions can be connected to the channel instead of directly to the event ports.

Agent-side Gateways

Overview

A JIDM gateway runs in one CORBA server. However, one or several JIDM gateways can co-exist in the same CORBA server. Programs in this server have access to both ORB services and services encapsulating access to management-specific protocols provided by JIDM gateways at the server. Besides, there can be several CORBA servers containing JIDM gateways in the same CORBA Agent Application.

Any JIDM gateway at a CORBA Agent Application has several objects associated with it (see Structure of JIDM Agent-side Gateways):

• A JIDM::EventPortFinder CORBA object that enables CORBA managed objects at the agent application to establish connections to JIDM::EventPort objects at remote Manager Applications that are accessible through the gateway.

• A JIDM::DomainPort object that serves requests issued from remote Manager Applications that want to get access to managed objects at the local managed object domain.

These objects are created during startup of the CORBA server where the JIDM gateway is located.

Several JIDM gateways can exist in a CORBA Agent and a JIDM::EventPortFinder object typically is associated with each of them. All of them would be registered in a root JIDM::EventPortFinder object at the CORBA Agent (see also Structure of JIDM Agent-side Gateways).

An initial CosLifeCycle::FactoryFinder object and CosNaming::NamingContext object exist at any CORBA managed object domain. Whether these two interfaces are exported by the same CORBA object or different CORBA objects is an implementation issue. References to these CORBA objects can be obtained from a JIDM gateway by using the standard Initialization Services and are passed to the JIDM::DomainPort object at creation time.

Handling Access to Managed Objects

Every JIDM::DomainPort object has a title associated with it. This title is used by remote Manager Applications to identify the managed object domain associated with the JIDM::DomainPort object.

When a new association request is received by the JIDM::DomainPort object that is in a gateway, the JIDM::DomainPort object creates a new JIDM::ProxyAgent object. This object handles CMIS requests received through the newly established association.

A JIDM::DomainPort object in a JIDM gateway holds references to initial CosNaming::NamingContext and CosLifeCycle::FactoryFinder objects located at the managed object domain where the JIDM gateway is located. The JIDM::DomainPort object passes copies of these references to each JIDM::ProxyAgent object it creates.

Creation of Managed Objects

1. A JIDM::ProxyAgent object receives a management create PDU indication through the management connection endpoint it holds.

2. The JIDM::ProxyAgent object finds an appropriate factory by invoking the find_factories() operation provided by a CosLifeCycle::FactoryFinder object.

3. The JIDM::ProxyAgent object narrows the obtained Factory object reference to a new object reference associated with a specific factory interface. Next, it invokes the operation for creating managed objects exported by the factory being referenced.

4. The Factory object creates a new CORBA managed object, instance of the managed object type specified in the management create PDU indication.

5. The Factory object may bind a name (the one passed as the Managed object instance field in the management create PDU indication, but in IDL form) to the new CORBA managed object.

6. The Factory object may inform other CORBA managed objects, in the same managed object domain, that the new managed object has been created.

7. When the operation invoked by the JIDM::ProxyAgent object returns (or when an exception is raised), the JIDM::ProxyAgent object constructs and sends an appropriate create PDU response to the remote Manager Application.

Invocation of Operations on Managed Objects

1. A JIDM::ProxyAgent object receives a management PDU indication, referred to a single managed object, through the management connection endpoint it holds. A name that unequivocally identifies the managed object is typically passed in the indication.

2. The JIDM::ProxyAgent object finds a CORBA object reference to the target managed object by invoking the resolve operation exported by a local NamingContext object. The name of the target managed object is passed in the invocation, once it is translated to IDL form.

3. The JIDM::ProxyAgent object invokes the appropriate operation on the managed object. In a Dynamic JIDM gateway, this may be accomplished by using the Dynamic Invocation API provided by the local ORB.

4. When the management operation invoked by the JIDM::ProxyAgent object returns (or when an exception is raised), the JIDM::ProxyAgent object constructs and sends an appropriate PDU response to the remote Manager Application.

Event Reporting

A managed object report events to a given destination (AEtitle) by registering as a supplier in the corresponding JIDM::EventPort (via the standard CosEventChannelAdmin::SupplierAdmin interface returned by a JIDM::EventPortFinder object) and then supplying events to that channel.

Note that any managed object may register itself as a CosEventComm::PushConsumer or a CosEventComm::PullConsumer in a remote JIDM::EventPort.

As explained in The JIDM::EventPortFactory Interface, different strategies to resolve how CORBA managed objects finally report events can be implemented. Sending Event Reports illustrates one possible scenario where CORBA managed objects register themselves as PushSuppliers or PullSuppliers in a single object (called EventReporter) which in turn is registered as a PushSupplier in one or more remote JIDM::EventPorts. Basic steps are summarized as follows:

1. At creation time, the EventReporter object invokes the find_event_port() operation exported by a JIDM::EventPortFinder object in order to find references associated with CosEventChannel::SupplierAdmin interfaces supported by a remote JIDM::EventPort object. It can try to find references for:

   • Various JIDM::EventPorts, each of which is bound to one title contained in the list of destinations defined for the EventReporter object.

   • A single JIDM::EventPort bound to a wildcard address (only valid if automatic event forwarding recipient manager resolution is supported).

2. The JIDM::EventPortFinder object creates a proxy JIDM::EventPort object if it does not exist in the gateway. At the time it creates a given proxy JIDM::EventPort object, it performs the necessary initial operations to obtain the reference to the CosEventChannelAdmin::SupplierAdmin object associated with the new JIDM::EventPort object.

   The EventReporter object registers itself as a CosEventComm::PushSupplier for each destination.

3. The EventReporter registers itself as a CosEventComm::PushConsumer in every local event channel that is necessary.

4. CORBA managed objects report events by using the standard event notification services.

5. Each event notification being generated is finally received by some event channel, connected to the EventReporter object.

6. The EventReporter object supplies the event to JIDM::EventPort objects corresponding to the different destinations.

7. The proxy associated with each JIDM::EventPort in the JIDM gateway constructs an appropriate eventreport request PDU and sends it through the management communication endpoint it holds.

Footnotes

0.

See the discussion on the term title in Design Principles.