OSI Support Services

These services are:

• OSI management caching and tracking services

• OSI management collection service

• Dynamic management of ASN.1 values

Additionally, the OSI Management Information Repository functionality is described in a non-normative section at the end of this chapter.

OSI Caching and Tracking Services

Overview

Any managed object that has been configured with the ability to cache may also be optionally configured with the ability to dynamically update its cached attribute values in response to change notifications received from the underlying managed object. This ability is known as tracking. If a managed object is a tracking object, it will update its cached values in response to the notifications defined by the OSI Systems Management functions ( ObjectCreation(), ObjectDeletion(), AttributeValueChange(), StateChange(), and RelationshipChange()).

The caching and tracking functionality is intended to provide improved performance. The goals of providing this functionality are:

• Transparency:
  A client application executing normal management operations on a managed object ( get, set, action, etc.) must see no difference in behavior (other than performance) whether the operations are executed against a non-caching (regular) managed object, a caching but non-tracking managed object, or a tracking managed object.

• Flexibility of configuration:
  Configuration of caching and tracking is available at multiple levels: per proxy agent (all managed objects managed by a given proxy agent), per managed object class (all managed objects of a given object class), and per specific managed object.

OSICaching Module

Description of OSICaching Module

The interfaces OSICaching::CacheConfigurator, OSICaching::PerAttributeCacheConfigurator, and OSICach-ing::PerClassCacheConfigurator are all abstract and should not be instantiated directly. Only the interfaces OSICaching::ProxyAgent and OSICaching::ManagedObject may be instantiated as concrete objects.

The attribute cache of any caching managed object is loaded with attribute values when the cache is initialized. This might happen at different times, such as after successful creation or before first access to the real managed object. Not all attributes of a managed object need be cached. The list of attributes that are cached for any given managed object may be configured at multiple levels, including the proxy agent level, the managed object class level, and on the individual managed object itself. The actual list of attributes that are in any given managed object's cache is the union of all the attributes requested to be cached at all these levels. The ability to selectively cache only certain attributes of interest affords the flexibility of not caching attributes that may be changing rapidly and dynamically in the underlying managed object, such as PDU counters, gauges, and clocks.

It is important to note that the cache is a read-only cache, and that there is no access to directly writing the cached attribute value. The managed object implementation automatically updates the cached attribute value when the appropriate attribute-changing or attribute-retrieving operations occur.

If the cached value of an attribute is valid, any request to read the value (such as in a get operation) will result in the request being serviced from the cache, thus precluding the need to contact the underlying managed object. If the cached value of an attribute is no longer valid (because its expiration interval has passed since the last update), any request to read the value will trigger an attribute fault, and will result in the request being serviced from the actual attribute value in the underlying managed object. A request to read the value of an attribute that is not in the cache is always serviced from the underlying managed object, as is the case for any regular (non-caching) CORBA managed object.

The attribute cache of a managed object is updated with the latest attribute values when a CMIS operation is successfully performed. At this time, the cache reflects the same attribute values that are reported back to the manager in the response, if those attributes are in the cache. Other cached attributes that are not affected by the operation will continue to retain their prior values. As soon as an attribute value in the cache is updated as a result of a CMIS operation, the expiration clock for this attribute is reset, and the duration of validity of this updated value will now be the full duration of the applicable expiration interval; this applies regardless of whether the previous cached value of the attribute had already expired or not. Specifically, the expiration timer for a cached attribute value is reset back to its full applicable duration when any the following occurs:

• A get operation has triggered an attribute fault and has been serviced from the underlying managed object, and the cached attribute value is updated to the same value reported back in the get response.

• A set operation has been successfully serviced, and the cached attribute value is updated to the same value reported back in the set response.

• An explicit request is made to the managed object to refresh the cached attribute value from the underlying managed object.

The duration of validity of any cached attribute value may be configured by the application. An application may cause a cached attribute value to remain permanently valid by setting an expiration interval of 0. This means that the cached attribute value never expires and an attribute fault to read the value from the underlying managed object is never necessary.

The cached value of an attribute is considered to be invalid when any of the following occurs:

• The applicable time interval for the duration of the validity of the cached value has expired

• An explicit method call is made to invalidate cached attribute values.

In these cases, any attempt to read an attribute value always triggers an attribute fault.

An application may explicitly invalidate the cached values of an OSICaching::ManagedObject by invoking the method invalidate_cached_values() on it. This invalidates all its cached values immediately, even if their expiration intervals have not expired. An application may explicitly cause the cached values of an OSICaching::ManagedObject to be refreshed using the current values from the underlying GDMO managed object by invoking the method refresh_cached_values() on it. This also resets the expiration interval of the cached values back to their full duration.

A managed object's cache may be configured at multiple levels. In general, the list of attributes to be cached, and the expiration intervals for each, may be provided at the level of a proxy agent, a managed object class, or an individual managed object. The methods to apply these cache configuration policies are available on OSICaching::ProxyAgent and OSICaching::Man-agedObject. Note that the cache configuration interfaces on OSICaching::ProxyAgent imply that the caching policies apply to managed objects controlled by that ProxyAgent; they do not imply that the ProxyAgent object itself has any caching capabilities.

The levels of cache configuration available are prioritized. From the most general to the most specific, the levels are:

• Proxy Agent:
  Applies to all managed objects controlled by the proxy agent.

• Managed Object Class:
  Applies to all managed objects of that managed object class.

• Managed Object:
  Applies to that individual managed object.

The cache configuration policy specified at a more specific level overrides the cache configuration policy specified at the less specific level. In particular, the following should be noted:

• The list of attributes to be cached for a given managed object is the union of the list of attributes requested to be cached at all applicable levels without the list of attributes that have been specifically removed either using the override_specific_settings parameter or using the operations at the managed object level.

• If the same attribute is requested to be cached at multiple levels, the expiration interval for an attribute that is specified at the most specific level applies.

The caching policy in OSICaching::ProxyAgent established by the methods inherited from PerAt-tributeCacheConfigurator applies to all indicated attributes wherever they occur in any managed object, regardless of class. This permits the establishment of a caching policy for all occurrences of the same attribute in a proxy agent, even if there is no caching policy established at the managed object class level or managed object level, in that proxy agent. The caching policy established by the methods in OSICaching::ProxyAgent that are inherited from the PerClass-CacheConfigurator interface apply to all indicated attributes only if they occur in the managed objects of the indicated managed object class.

The methods on OSICaching::ManagedObject, including those inherited from PerAttributeCacheConfigurator, apply to the actual attributes in the managed object itself. These methods permit the addition or removal of attributes in the cache, changing expiration timeouts, refreshing cached values, or invalidating cached values.

While configuring the caching policy on a ProxyAgent or ManagedObject, a list of CachedAttribute structs (an attribute identifier coupled with an expiration interval), may be supplied. While configuring the caching policy on a ProxyAgent, a list of CachedObjectClass structs (a class name coupled with a list of CachedAttribute structs) may be supplied. If any of these lists is an empty sequence, it is interpreted to mean all. In addition, when empty lists are used, default expiration intervals are associated with all relevant attributes. Thus, a caching policy that applies to all attributes in a ProxyAgent, a ManagedObjectClass or a ManagedObject, or a caching policy that applies to all attributes of all managed object classes in a ProxyAgent, can be easily enforced by invoking the appropriate methods with an empty list argument.

The methods CacheConfigurator::set_default_expiration_interval() and CacheConfigura-tor::set_caching_enabled() permit the caching policy to be changed on a level-wide basis, at either the ProxyAgent level or the ManagedObject level. If set_default_expiration_interval() has never been called, the default expiration interval is considered to be zero (i.e. the cache never expires). The methods CacheConfigurator::get_default_expiration_interval() and CacheConfigurator::is_caching_enabled() indicates the state of the level-wide caching policy, at either the Proxy-Agent level or the ManagedObject level. The set_default_expiration_interval parameter will affect only those attributes that are cache-enabled. The override_specific_settingsparameter allows the flexibility to either retain any existing custom expiration intervals for some attributes, or change the interval to the specified value for all cache-enabled attributes including those that have custom expiration intervals.

This specification permits multiple ProxyAgent objects to represent the same underlying TMN agent. It also permits these multiple ProxyAgent objects to have different caching and tracking characteristics. For example, one ProxyAgent representing a particular TMN agent may have caching and tracking capabilities, while another ProxyAgent representing the same TMN agent may not. This implies that a ManagedObject accessed via the first ProxyAgent may be configured for caching and tracking, whereas a ManagedObject accessed via the second cannot be so configured.

The caching and tracking configuration applied to a ProxyAgent object apply to all managed objects references obtained from it. It should be noted that an IOR for a ManagedObject may be obtained from a ProxyAgent in several different ways:

• By doing a resolve() on the NamingService in that ProxyAgent

• By invoking a create() operation on the ManagedObjectFactory in that ProxyAgent

A client application which obtains a ManagedObject IOR for a particular underlying GDMO managed object from a caching and tracking ProxyAgent will be able to take advantage of caching and tracking, whereas the same client application obtaining another ManagedObject IOR for the same underlying GDMO managed object from a non-caching and non-tracking Proxy-Agent will not be able to take any advantage of caching and tracking. Caching and tracking capabilities, therefore, are properties of the IOR of a ManagedObject, and not necessarily of the underlying managed object itself.

The following rules apply when changes are made to the caching policy after an existing caching policy has already been applied to various attributes:

• Any change to the caching policy (list of cached attributes, attribute expiration intervals, etc.) made on a ProxyAgent applies only to ManagedObject references subsequently obtained from that ProxyAgent, unless the parameter override_specific_settings is set to true. That is, existing ManagedObject object references are not affected. If the parameter override_specific_settings is set to true, then the caching policy for all existing ManagedObject object references affected by this change in the ProxyAgent, is updated to the one specified.

• Any change to the caching policy (list of cached attributes, attribute expiration intervals, etc.) made on a ManagedObjectClass applies only to future ManagedObject object references of that class obtained from that ProxyAgent, unless the parameter override_specific_settings is set to true. That is, existing ManagedObject object references of that class are not affected. If the parameter override_specific_settings is set to true, then the caching policy for all existing ManagedObject object references of that class affected by this change in the ProxyAgent, is updated to the one specified.

• Any change to the caching policy made an individual ManagedObject object reference is applied immediately to the ManagedObject object reference. The parameter override_specific_settings is ignored.

Any method that changes the caching and tracking policy may throw exceptions such as NoSuchAttributes, NoSuchClasses, etc. The semantics of the exception are that all known OIDs are treated as requested, and the unknown OIDs are returned in the exception.

OSITracking Module

Description of OSITracking Module

A tracked attribute in a managed object is an attribute whose value in the cache is dynamically updated by way of notifications received from the underlying managed object. The ProxyAgent implementation dynamically updates its cache based on any information made available to it in notifications emitted by the underlying managed object, including at least the standard Systems Management notifications of object creation, object deletion, attribute value change, state change, and relationship change.

When a cached attribute value is dynamically updated as a result of notification tracking, the expiration timer for that cached attribute value is reset back to its full applicable duration of Validity, regardless of whether the prior cached value was still valid or had expired.

As with caching, tracking may be configured on a per proxy agent basis, per managed object class basis, and per individual managed object basis. These have the same meaning and same levels of overriding as caching.

An attribute value in a managed object may only be tracked if it is also cached. In particular, the list of attributes configured to be tracked must have been configured to also be in the cache at a prior time. Any attributes that are requested to be tracked at any given level, but are not in the cache configuration at that particular level, are ignored.

Mechanism to Obtain Cached/Tracked Services

An additional set of Criteria are specified to gain access to these value added services, if available. These criteria are specified in the following tables.

Basic OSIMgmt ProxyAgentFinder Criteria repeats the basic OSIMgmt criteria needed to create an OSIMgmt::ProxyAgent. For use with caching and tracking, the criteria specified in Alternative for Caching/Tracking OSIMgmt ProxyAgentFinder may replace these, by specifying an already existing OSIMgmt::ProxyAgent, that represents the domain to be cached (and maybe tracked). Destruction of the original OSIMgmt::ProxyAgent is the responsibility of the application that created it.

In addition to either one of the above, the criteria specified in More Criteria for Caching/Tracking OSIMgmt ProxyAgentFinder must also be provided for caching (and tracking) to be activated.

The values passed with the criteria names ( caching and tracking) are implementation-defined. Each implementation should specify what the appropriate values for these criteria should be.

If caching is specified for a ProxyAgent using the criteria specified in Basic OSIMgmt ProxyAgentFinder Criteria, then it is an implementation issue whether there are really two separate ProxyAgents, one that does not support caching and another that does.

Collection Service

Overview

This service is patterned after the CORBA Collection Service specification (see reference [CORBASer-vices]), and reuses some of the concepts defined there. However, no direct interface re-use is attempted to be able to provide highly typed interfaces specific to OSI management environments and that take into account the distributed nature of the collections being manipulated.

It defines an OSICollection::Iterator interface, to be able to navigate, traverse and manipulate the collections:

• Enumerated collection:
  The collection membership is explicitly controlled by the client; any arbitrary set of managed objects may be added to the collection, according to any grouping criterion convenient to the application

• Rule collections:
  The collection membership is defined by some rule (in this case, a scope and filter specification). All managed objects that satisfy the rule are the members the rule collection.

OSICollection Module

Iterator Interface

This interface also adds a number of operations for different purposes:

• To manipulate the iterator position:

  • Restart, resets the iterator to point to the first element in the collection

  • set_to_next_element, moves the iterator to the next element in the collection

  • set_to_next_nth_element, moves the iterator n times

• To control and monitor the state of the iterator:

  • invalidate, sets the state of the iterator to invalid

  • is_valid, checks validity of the iterator

  • is_in_between, checks whether the iterator points to an element, or is in between elements

  • is_equal , checks if both iterators belong to the same collection and point to the same element

• To manipulate the lifecycle of iterators:

  • clone, makes an exact copy of the iterator

  • assign, changes the state of the iterator to match the one assigned to it

  • destroy, destroys the iterator

Note that OSICollection::Iterators are managed iterators, as explained in the CORBA Collection Service specification. This means that the status of the iterator is always known, never undefined, specifically in the event the collection contents change.

The possible iterator states are:

• valid, pointing to an element of the collection

• invalid, pointing to nothing (for example, past the end of the collection)

• in-between, not pointing to an element but knowing what its position in the collection is

A valid iterator remains valid as long as the element it points to remains in the collection. If the element is removed, the iterator goes to the in-between state. Certain operations require the iterator to be in a valid state (like all the *_at operations), while others work even when the iterator is in an in-between state (like get_n_elements). An iterator becomes invalid when it points to nothing (for example, it has been moved past the last element).

BaseCollection Interface

Specifically, it provides operations to allow:

• Manipulation of the collection and its elements

  • retrieve_element_at, retrieves an object at an specified iterator position

  • is_empty, identifies whether the collection has any elements

  • create_iterator, creates an iterators on the collection

  • destroy, destroys of the collection

• Specific operations to be performed on all objects in the collection

  The following operations, perform_get, perform_set, perform_action, perform_delete, all perform the corresponding CMIS operations on all the objects in the collection, returning the results via the RepliesHandlers passed in as parameters. For a more detailed discussion of both the different CMIS operations and the handler callback objects, see the corresponding sections on the OSIMgmt chapter in this specification. Also, the semantics assigned to the presence or absence of the handler object references are those specified in the OSIMgmt chapter as well.

If an object in a collection returns the standard CORBA exception OBJECT_NOT_EXIST when performing one of these global operations, the collection will inmediately remove the object from the collection, as this type of exception is definite.

EnumCollection Interface

The member managed objects of an enumerated collection are added, removed and replaced from the collection on an individual basis ( add_element, add_element_set_iterator, remove_element_at, replace_element_at), or in batch mode ( add_elements, remove_all).

It is important to note that an OSICollection::Collection object does not maintain any specified order among its members. No assumption should be made regarding the retrieval order, as compared to the insertion order. However, ordering within the collection is implementation-defined; this means that any two traversals of an iterator over the same collection will return managed objects in exactly the same order if no membership manipulation has occurred in between the traversals.

RuleCollection Interface

• A base object, that specifies the base of the scoping specification for this collection

• A scope specification, as defined in reference X720 and in OSI Management Facilities

• A filter specification, as defined in reference X720 and in OSI Management Facilities

Once created, the governing rule of a rule collection cannot be changed, because doing so may invalidate the existing collection membership. When a CMIS operation is invoked on a rule collection, the indicated base managed object, scope, and filter that form the collection's governing rule are the parameters used to invoke the scoped operation on the actual agent or agents that are spanned by that rule.

A CMIS synchronization (atomic or best effort) may also be specified for a rule collection. This synchronization parameter is used in the scoped request that is sent to the agent(s) when a CMIS operation is invoked on the rule collection.

When an iterator is requested from a rule collection (via the create_iterator() method), then a snapshot of the collection's membership is taken to serve the iterator. This snapshot must reflect the best available knowledge of the managed objects that meet the collection's defining rule at that time.

CollectionFactory Interface

In particular the CollectionFactory interface allows:

• Creation of an empty EnumCollection - create_enum_collection()

• Creation of an EnumCollection as a copy of another Collection. If the copied collection is a RuleCollection, a snapshot of its membership is taken at the time of creation of the EnumCollection - create_enum_collection_from_collection()

• Creation of a RuleCollection specifying its base managed object and scoping/filtering rule - create_rule_collection()

• Creation of a RuleCollection specifying its base managed object by reference to an OSIMgmt::ProxyAgent and the class and instance names of the base object, plus the scoping/filtering rule - create_rule_collection_by_name()

Dynamic Management of ASN.1 Any Values

Overview

This facility extends the one above to support CORBA::Any values that originate from an ASN.1 specification that has been translated into IDL via the JIDM Specification Translation algorithm (see reference [XOJIDM]) in a way that is closer to the original ASN.1 type.

Note that all operations that may be performed through this interface may also be performed directly using the basic CORBA::DynAny interface. Additional functionality provided by this interface is the access to ASN.1 specific information, that might have been lost in the translation from ASN.1 to IDL (specifically, type constraints), and the ability to use the original ASN.1 names, instead of the translated IDL names. Also, mechanisms are provided to deal with common ASN.1 constructs such as OPTIONAL, DEFAULT and anonymous elements, in an easier manner.

The behaviour of DynAny objects has been defined in such a way as to enable efficient implementations in terms of allocated memory space and speed of access.

In order for this interface to be fully operational, and provide the above mentioned advantages, some mechanism (not specified here) to access cross-domain information is needed. The most likely scenario for this is the use of an OSI MIR (see OSI Management Information Repository). Aletrnative implementation mechanisms are possible.

The ASN1::DynAny IDL is patterned after the CORBA::DynAny IDL, with the following differences:

• Defined within an ASN1 IDL module, rather than within the CORBA module

• The factory for these objects is explicitly defined as a CORBA object, rather than using the ORB pseudo interface. The way to get a reference to such factory is implementation specific.

• Names of ASN1::DynAny subtypes resemble the names of the ASN.1 construct, not those of IDL.

• It inherits from the CORBA::DynAny interface, and redefines some of the behaviours.

• While the CORBA::DynAny interface relies on the CORBA::TypeCode of the value being processed, the ASN1::DynAny reuses that information, plus that provided by a simpler ASN1::Kind type.

ASN1 Module

However, note that ALL operations are possible through the unextended CORBA::DynAny interface. The extra added value provided by the ASN1::DynAny extension is the fact that ASN.1 constraints might be checked by the implementation, if possible (this is not a mandatory conformance point for this facility, but a quality of implementation issue).

Description of ASN1 types and operations

Kind type

If the CORBA::TypeCode does not correspond to an ASN.1 type, the special kind of ak_none is used. In this case, none of the extended interfaces may be used (they will all return an appropriate exception: Invalid, InvalidValue of TypeMismatch).

Exceptions

• Invalid means either the ASN1::DynAny is not initialized (for read operations) or it is incom-patible with the operation being performed

• InvalidValue means trying to insert the wrong type/value. This exception would also be raised in case an ASN.1 constraint is not satisfied when inserting a value

• TypeMismatch means trying to extract the wrong type

• InvalidSeq means the sequence used does not have the appropriate structure or types

Type Identification

Lifecycle

Insertion Operations

In addition, there are different insertion operations per primitive ASN.1 type, even if they map to the same IDL type. In this way, the interface is more type safe (in the ASN.1 sense).

For example, if we have MyType::=INTEGER(1..500), then either insert_ushort or insert_asn1_unsigned16 would work. Both could check for the bounds, and return InvalidValue if the constraint is violated.

Note that there is nothing to insert an ASN1_Recursive: you have to use the appropriate type to be inserted (whatever would go in the any) if using the ASN1::DynAny interface, and insert_any if using the CORBA::DynAny interface. Again, if the wrong type is to be inserted in the any, then the exception could be raised.

Extraction Operations

In addition, there are different extraction operations per primitive ASN.1 type, even if they map to the same IDL type. In this way, the interface is more type safe (in the ASN.1 sense).

For example, in the case introduced above, either get_ushort or get_asn1_unsigned16 would work.

Note that there is nothing to extract an ASN1_Recursive: you have to extract the appropriate type (whatever is in the any) if using the ASN1::DynAny interface, and get_any if using the CORBA::DynAny interface. If the wrong type is to be extracted from the any, then the TypeMis-match exception should be raised.

Navigation Operations

Enumerated Interface

NamedNumber Interface

SetSeq Interface

In addition to the operations to navigate the components, getting names, and inserting/extracting sequences (inherited from the CORBA::DynStruct interface), equivalent operations are provided with the ASN.1 counterparts. Specifically, field names, and insert/extract sequence would use ASN.1 type names, instead of the IDL equivalents inherited from the CORBA::DynStruct inter-face. Another difference is that in the ASN.1 sequences, fields that have the OPTIONAL or DEFAULT clauses might be omitted. Additionally, there are methods to insert absent/present optional (and defaulted) and also to check for the presence and value of such fields.

Choice Interface

SetSeqOf Interface

DynAnyFactory

• IDL Factory methods
  Create the CORBA::DynAny subclasses appropriate for the provided typecode. The returned objects might be narrowable to one of the ASN1::DynAny interfaces, if the IDL type was indeed coming from an ASN.1 type.

• ASN1 Factory methods
  In the absence of ASN.1 typecodes, the ASN.1 module nickname and type name are used as the mechanism to identify the type being created. In this case, the returned object already exports the appropriate interface. If the specified type does not match the factory operation being used, the InconsistentKind exception is raised.

OSI Management Information Repository

This specification does not provide any standard interface for an OSI MIR, therefore allowing implementations of CORBA/TMN systems to provide this functionality using any appropriate mechanism.

An OSI MIR provides two services:

• Model description:
  The translation from GDMO and ASN.1 to IDL leaves some information elements untranslated. For example, some constraints on ASN.1 types, or some inheritance relationships in GDMO class hierarchies, cannot be translated into IDL. An OSI MIR can fill in the missing information for applications that need it, by providing a full description of the original GDMO and ASN.1 syntax.

• Translation description:
  Some implementations, in particular those dealing with both OSI and CORBA domains, may need to know the correspondence between GDMO/ASN.1 and the IDL representations of a model. For example, an implementation might need to know that the IDL enumerated value selecting the globalForm choice of X.711 ASN.1 AttributeId syntax is named globalFormChoice_1. An OSI MIR can provide information on this mapping.

An OSI MIR allows managers and agents to dynamically access all information on a certain model, both as an original GDMO/ASN.1 model and as the equivalent IDL model. Among other things, this makes it feasible to dynamically process management requests without necessarily having any compile-time knowledge of which GDMO/ASN.1 documents and modules were processed and what mapping rules were applied for translation into IDL. With the assistance of an OSI MIR available at run time, an application may:

• Check the validity of values with the constraints applied to their syntax

• Translate management requests from one domain (CORBA or OSI) to another.

This specification allows implementations of CORBA/TMN systems to choose any approach to building an OSI MIR for providing dynamic, run-time metadata support to their applications, including, but not limited to, the following:

• An OSI MIR may be provided as a stand-alone proprietary CORBA facility with its own exposed IDL interface.

• An OSI MIR may be provided as a repository which is an extension of the CORBA Interface Repository.

• An OSI MIR may be an internal repository within a CORBA/TMN system, with no exposed interface and hence no CORBA visibility to applications; it may be reserved only for internal use by the CORBA/TMN system implementation.