Comparison of Object Models

• goals

• interfaces

• elements of objects

• object specification

• object taxonomy

• object reference

• object selection

Each section begins with a glossary of basic concepts (incorporating relevant ODP terms). This is followed by a matrix comparison of the way the basic concepts are interpreted in the two models, and the section is then concluded with comparative analysis.

Trying to provide a glossary of generally-agreed concepts in object-oriented modeling is a difficult task, and the outcome is inevitably contentious. However, the works of many authorities on the subject have been consulted including Wegner (see reference Weg90), Meyer (see reference Mey88), Goldberg (see reference Gold89), Rumbaugh et al (see reference rumb91), Booch (see reference Boo91) and Kent (see reference Kent91). It is believed that the concepts defined here provide a reasonable basis on which to conduct the comparison.

Goals of the Models

Comparison

Intended Use

OSI Mgmt

Network Management

OMG

Object-oriented distributed systems development.

Internet Mgmt

Management of the Internet and TCP/IP-based networked devices

Interoperability/Portability

OSI Mgmt

At the syntactic and semantic level. No code portability, communications interoperability.

OMG

At the syntactic and semantic level. Code portability. CORBA 2.0 provides interoperability

Internet Mgmt

At the syntactic and semantic level. No code portability. Communications interoperability.

User Advantage

OSI Mgmt

Management of heterogeneous network components

OMG

Transparency to applications of underlying heterogeneous platforms

Internet Mgmt

Management of heterogeneous inter-networked devices

Re-usable Components

OSI Mgmt

Library/catalogue of management information

OMG

Interface Type library

Internet Mgmt

Management Information Base (MIB) specifications

Analysis

Portability

Portability for OSI and Internet management is provided by the the XMP (see reference XMP) and XOM (see reference XOM) interfaces

Interoperability

There are two aspects to component interoperability: agreement on the syntax and agreement on the semantics of information interchange. Achieving interoperability requires conformance to both.

The strategic objective of each group is identical - to promote syntactic and semantic interoperability between heterogeneous computing components. The models differ only in their approaches to specifying such interoperability and their choices of the interface points at which the interoperability is to exist. For OSI Management and OMG, as can be seen in Interfaces, far from conflicting, these choices are complementary.

Re-usability

A common theme running through the statement of objectives of the OSI management and OMG models is that of component re-usability with emphasis on type/object libraries, portability of applications, and heterogeneous management components. Ever since the identification of the software crisis (see reference Naur68) some quarter of a century ago, the re-use of software components has been promoted as a solution (see reference Krug92).

Interfaces

Concepts

Interface

The boundary at which a prescribed specification is supported. The reference model for ODP supports multiple object interfaces and viewpoints. An ODP Interface type is a predicate that characterises an interface. An interface signature can be described using an interface definition language. Interfaces can have behaviour specifications described using formal description techniques.

The three models compared in this document describe the following interface types:

OSI

managed object communication interface, operations and notifications

OMG

programmatic interface between invoker and object

SNMP

get and set operations upon instrumentation variables

Open Interface

An interface that supports a published protocol and at which conformance may be tested

Protocol

A set of syntactic and semantic rules for exchanging information

Carriage Protocol

A protocol to which invocations, notifications, and replies are added to form a complete protocol

Interface Concurrency

The property of an interface such that it will accept protocol elements at any time

Exception

A condition that precludes normal execution

Comparison

Interface Type

OSI Mgmt

Communications interface between a managing-system and a managed-system; an agent, resident in the managed system, mediates between the managing system and a managed object.

OMG

Programmatic interface between an invoker and object. The interface includes signature only.

Internet Mgmt

Communications interface between a Network Management Station (manager) and Device (agent). The agent supports one or more MIBs.

Carriage Protocol

OSI Mgmt

The syntax and semantics of the carriage protocol are defined in ISO/IEC 9596-1 (see reference CMIP91)

OMG

Independent of carriage protocol. Interoperability dictates one or more protocols.

Internet Mgmt

The syntax and semantics of the carriage protocol are defined in RFC 1157 (see reference SNMP)andRFC1448(seereference SNMPv2)

Open Interface

OSI Mgmt

ISO/IEC 9596-1 is an international standard and many managed-object specifications are publicly available, for example, OMNIPoint (see reference (OMNI92)

OMG

IDL is specified in referenced document CORBA98. Standard interfaces have been defined using IDL by object service specifications (see reference COS98).

Internet Mgmt

RFC 1157 (SNMPv1) is an Internet standard; RFC 1448 (SNMPv2) is a proposed draft Internet standard. Many MIB specifications are publicly available for SNMPv1, with on-line access provided via the Internet.

Protocol Model

OSI Mgmt

The remote operations protocol model is one of non-blocking message-passing with normal and exception reply-types. A single initiating message may result in multiple replies.

OMG

The protocol model has two execution semantic styles: at most once (blocking with exceptions); best effort (non blocking, no guarantee of delivery). Delivery of events is not guaranteed by COSS event services (see reference COS98).

Internet Mgmt

The protocol model is primarily manager-initiated message-passing, without guaranteed delivery. A single initiating message results in (at most) a single reply.

Interface Concurrency

OSI Mgmt

A management association which supports operations and transfer of event reports requires interactions to be processed concurrently. Support for confirmed event reports requires interface concurrency.

OMG

Not precluded by the object model

Internet Mgmt

Polling driven, manager controls concurrency. Traps are not confirmed.

Analysis

Interface Types

The choices of interface made by the OSI management and OMG groups reflects their different preoccupations: OSI chose network management communications, while OMG chose software development. These choices are synergistic: object-oriented network-management systems have to be implemented, and implementors will require object-oriented software tools.

Protocol Model

The use of OMG client stubs implies a blocking procedure-call model. However implementation support for a dynamic invocation interface is defined, which allows deferred synchronous operation. OMG implementations can be designed to employ callbacks to the original invoking client application for return of operation results, thus permitting asynchronous operations. However, some implementations of CORBA do not provide a callback location as part of receiving an operation invocation. Thus to be safe, a CORBA operation which is designed to be followed by callback operations should provide an input parameter containing an ObjectReference upon which to invoke the callback.

OSI Management has, through the use of ROSE (see reference XAP-ROSE), chosen a non-blocking message-passing model. Exception handling mechanisms will have to be aligned.

Protocol Specification

There are three aspects to the specification of a protocol: the rules for exchanging information; the semantics of the information; and the syntax of the information. OSI Management has chosen to specify all three aspects, whilst OMG in CORBA 1 has chosen to specify no protocol for interoperability. However CORBA 1 does specify a language mapping to C. Other language mappings are defined by the OMG (including C++, SmallTalk).

CORBA 2.0 provides interoperability between different ORB implementations, and protocols have been specified for use between ORBs.

Characteristics of Objects

In ODP terms, all objects have a type, which is a predicate that determines if an object is of that type. The extension of all the object instances of a given type is called the class derived by that type. Instances of a class are generated to adhere to the specifications of a class template, which specifies the behaviour of the object. Objects are characterised by the interfaces they support. In ODP, an object can support multiple interfaces, bound to a common state.

Concepts

Object

A collection of behaviours that share the same state

State

A stable internal condition of an object

Behaviour

A change in the state of an object

Attribute

A set of data values (that is, a data-type) and qualifiers over those data values; the data values are built from literals

Literal

A set of data values (that is, a data-type) which, by convention, have fixed semantics (for example, integer, boolean)

Encapsulation

A property of an object such that its state can only be accessed by means of prescribed signals across the object boundary or by means of prescribed relationships between objects

Operation

A behaviour of an object. It is normally initiated by the reception of an invocation.

Event

An autonomous behaviour of an object. It may be signalled by the emission of a notification.

Invocation

A signal, possibly parameterised, requesting that an operation be performed by an object

Notification

A signal, possibly parameterised, indicating that an event has occurred

Reply

A signal, possibly parameterised, indicating a response to an invocation or notification; replies are often classified as normal or exceptions

Parameter

A data value whose syntax conforms to that of a prescribed protocol

Method

The implementation of an operation

Qualifier

An additional semantic applied to an attribute (for example, concerning accessibility or default values)

Comparison

Description

OSI Mgmt

A managed object is described by the Management Framework (see reference OSI89) as "a view of a resource that may be managed through the use of OSI Management protocols". A managed object enforces encapsulation, and it is characterised by the attributes it makes available, its behaviour, and the invocations and notifications that cross its boundary. A managed object can optionally present itself as if it were a superclass (allomorphism) of that of which it is instantiated.

OMG

An object is described as "a package of data and code used to implement a computational construct or to model an application entity" (see reference OOM91). An OMG object enforces encapsulation and is characterised by the attributes it makes available, its behaviour, and the signals that cross its boundary. An object may have more than one interface, but only inheritance is explicitly provided as a mechanism in IDL to specify multiple interfaces.

Internet Mgmt

As described by RFC1155 (see reference ISMI), "managed objects are accessed via a virtual information store, termed MIB ... Each type of object has a name, a syntax, and an encoding" (see reference ISMIV2). Internet objects represent individual variables which can be manipulated using SNMP protocol; the Internet SMI provides no mechanism for collecting together all variables which together might encapsulate a resource. Also, in Internet objects, the notion of interface inheritance is not supported.

Object Operations

OSI Mgmt

An operation may be initiated by receiving an invocation. A confirmed operation will generate one or more replies; a non-confirmed operation will not. Exceptions are signalled by means of exception replies. Invocations and replies may be parameterised.

OMG

An operation is initiated either by a generated stub or by the dynamic invocation interface. The normal execution of an operation results in a reply (and the return of control to the invoker). An exception is indicated by means of an exception signal and the transfer of control to an exception handler. Invocations, replies, and exception signals may be parameterised.

Internet Mgmt

An operation is initiated by the receiving of a request. Each request generates a single response (although SNMPv2 Get-Bulk provides a self-repeating operator for conceptual table traversal). Exceptions are signalled as responses. Requests and responses may be parameterised.

Object Events

OSI Mgmt

Behaviour unconnected with operations may be signalled by means of a notification. A confirmed notification requires a reply; a non-confirmed notification does not. Notifications and replies may be parameterised

OMG

Objects which generate events invoke an operation on the event notification service (see reference COS98). Event distribution is via push model or pull model. Event notification service does not indicate failure/success of delivery to Invoker. No standard event filtering is yet defined (other than by grouping originating objects into channels). The receiver of typed events indicates support of each event.

Internet Mgmt

Significant events unconnected with operations may be signalled by means of a non-confirmed Trap notification (intended for infrequent generation by managed devices) or a confirmed Inform-Request (intended for use between managers). Notifications are specified as part of the carriage protocol, and are unrelated to object type definitions. Event philosophy has been characterised as trap-directed polling.

Behaviour

OSI Mgmt

Behaviour can be in any language (natural or formal), but is most commonly written in English. This is normative information and can be subjected to conformance testing. This would normally require an intermediate step to represent the behaviour in a testable form.

OMG

Side effects are permitted but are not specified in IDL. Basic OMG IDL has no formal way to specify what event types may be generated (event generation is independent of interfaces an object supports). A Receiver only knows which channel an event came from (channels can have multiple object sources) but event data could be defined to include originating objectReference.

Internet Mgmt

Textual specification may be included in the description clause of an object type definition, describing the behaviour of an individual variable. This may include description of an entire conceptual table or table row, but otherwise does not specify the behaviour of encapsulated resources. Notification behaviour specifications are unrelated to object type behaviour specifications.

Attributes

OSI Mgmt

An attribute is characterised by a set of data values and qualifiers which specify matching rules, range restrictions, initial and default values, and access restrictions. Attributes can also be manipulated by specifying an attribute group name that identifies one or more attributes.

OMG

An attribute is characterised by an identifier, a type, and an optional read-only qualifier. There is no mechanism for grouping attributes.

Internet Mgmt

An attribute is embodied by an object type specification, which identifies the object name, syntax, description, access, status, and default value (if any). Syntax may include range and/or value restrictions. There is no mechanism for grouping attributes.

Attribute Operations

OSI Mgmt

Built-in operations on attributes are get attribute, replace attribute and replace attribute with default. Set-valued attributes have add-member and remove-member. Built-in operations support manipulation of multiple attributes or attribute groups within a single operation. A built-in operation supports the cancellation of the get built-in operation. Arbitrary exceptions (specific errors) may be specified on attribute operations.

OMG

Built-in operations on attributes are set attribute and get attribute. Built-in operations can only get/set the value of a single attribute within one invocation. Only standard exceptions are supported on attribute operations.

Internet Mgmt

Built-in operations on attributes (object types) are get attribute and set attribute. Aggregate conceptual tables and table rows are supported by the ASN.1 construct SEQUENCE [OF]. Built-in operations are get-next (SNMPv1) and get-bulk (SNMPv2). However, these operations serve only to navigate through conceptual tables; individual object types are the only accessible elements. Built-in operations support manipulation of multiple attributes within a single operation. Some standard exceptions are supported on attribute operations.

Object Life-cycle Operations

OSI Mgmt

Built-in operations to agent for create and delete of object instances. Creator may specify name or may rely on agent to supply name. It has no standard protocol to move object instances between systems.

OMG

No built-in operation for instantiation of object interfaces by client demand. However, factory objects may be defined which allow clients to create application specific object interfaces. COSS (see reference COS98) life-cycle services specify deletion of objects, as well as copy/move of object implementations.

Internet Mgmt

No direct support for life cycle operations. SNMP v2 has notion of special variable in table rows which allows for a set operation to make a new table row available.

Attribute Behaviour

OSI Mgmt

The behaviour of attribute-oriented operations is defined. The interaction between attribute operations is left to the package definition.

OMG

get and set operations are defined for attributes. Behaviour specification is only available through textual comments.

Internet Mgmt

The behaviour of attribute-oriented operations is defined; interaction between operations is not.

Data Types

OSI Mgmt

All primitive ASN.1 built-in types are supported, including BOOLEAN; INTEGER; BIT STRING; OCTET STRING; NULL; ANY DEFINED BY, CharacterString; OBJECT IDENTIFIER; REAL; ENUMERATED; and Generalized Time. The following constructed types are supported: SET, SET OF, SEQUENCE, SEQUENCE OF, CHOICE.

OMG

Primitive types are integer, floating point, character, octet, boolean, and ANY (type descriptor, data fields). Built in access methods exist for ANY type. Aggregate attribute values and operation parameters are supported by the collection types, which are Sequences (variable length ordered list); struct, Union, Enum, Array (fixed size). In IDL, recursion within constructed Type declarations is only allowed if there is an intervening Sequence.

Internet Mgmt

The following primitive ASN.1 built-in types are supported by SNMPv1: INTEGER, OCTET STRING, NULL, OBJECT IDENTIFIER. The only ASN.1 constructed type permitted is SEQUENCE [OF], used to generate either lists or tables. New application-wide types may be defined, but only if they resolve into one of the above implicitly defined ASN.1 types. RFC1155 (see reference ISMI) defines the following application-wide types: NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, Opaque. RFC1442 (see reference ISMIV2) specifies revisions for SNMPv2, including addition of BIT STRING, unsigned INTEGER, and 64-bit Counters.

Encapsulation

OSI Mgmt

Supported.

OMG

Supported.

Internet Mgmt

Not supported (except where encapsulating any individual variable).

Object Reference Data Type

OSI Mgmt

ObjectInstance (Distinguished Name), used extensively as communication interface parameter. X.500 syntax used.

OMG

Object reference (type name Object). Interface operations may employ the object reference type for their parameters. Its syntax is opaque to the application using it.

Internet Mgmt

Object type identifier, appended to an object instance identifier (row index) for objects contained within a conceptual table.

Interface Type References

OSI Mgmt

Managed object class, attribute id, notification id and action id are all specified with a globally unique OBJECT IDENTIFIER value, as well as a document specific textual ASN.1 reference label. Textual reference labels are case sensitive.

OMG

Interface type has global reference id through Module Names. Attributes, types and operations are referred to using scoped names defined within the interface specification. IDL identifiers are case insensitive.

Internet Model

Object type is specified with globally unique OBJECT IDENTIFIER value, as well as document-specific textual ASN.1 reference label. SNMPv2 also specifies globally unique OBJECT IDENTIFIER values for Notifications, Module Identities, Groups, and Compliance Modules.

Analysis

Description

At first sight, the descriptions of objects in the OSI management and OMG models appear different, the OSI Managed object being a ... view of a resource ... and the OMG object being ... a package of code and data .... In fact, both object models enforce strict encapsulation: objects are characterised by how they appear to the outside world, not how they are constructed internally. With the exception of notifications and the support of built-in operations to support manipulating multiple attributes with a single invocation, differences between the models are surprisingly few. In practice, objects from both models will be constructed of code and data and be run on computer processors.

From the ODP perspective managers and agents can be modelled as ODP objects. However, OSI management, OMG and Internet management each limit specification of an object to that of a performer of operations. Invoker behaviour is not specified in OSI management, OMG, or Internet management.

Operations

Both the OSI and OMG models support the notion of an extensible set of operation types, although particular objects are only required to support a fixed set of operation types. The mechanism for invoking such operations is defined by the underlying protocol.

There is a need to define a generic OMG factory object interface to support the OSI managed object M-CREATE operation for managed objects mapped to CORBA interfaces.

Events

The major difference between the OMG and OSI management models is the way of specifying autonomous events.

In OSI, management events are behaviour unconnected with operations; they reflect the active, autonomous nature of managed objects. Typically, event notifications are caused by alarm conditions (for example, loss of signal) in the resource represented by a managed object. The event notifications which an object may emit are specified as part of the Managed Object definition. An event report management function determines which event notifications are forwarded as event reports to designated destinations.

The notion of events has been accommodated in the OMG object services. The main difference between OMG events is that they are specified as being supported by the receiver of the events. In effect, OMG event services models events as operations in the other direction.

Attributes

In OSI management and OMG (unlike Internet management), the models differentiate between attributes and objects:

• there are distinct type systems for objects and attributes

• objects ontologically precede attributes (that is, attributes can only be accessed within the context of an objects)

• there are built-in operations to manipulate attributes.

This is in-line with popular programming models such as Eiffel (see reference Mey88) and C++ (see reference Strou87), but is at variance with models such as Smalltalk (see reference Gol89), where everything is an object. Both the OMG and OSI Models support aggregate attribute types.

OSI Management allows specification of specific user-defined errors on attribute operations, and defines operations to manipulate members of set-valued attributes (add, remove). If OSI management attributes are mapped to OMG attributes, then only CORBA standard errors can be used, resulting in a loss of information. In addition, there would be no way of using CORBA operations to add or remove members of set-valued attributes. An alternative would be to map some OSI managed object attributes to custom CORBA IDL operations, in cases where user defined exceptions or set member operations are required.

Encapsulation

Both the OSI and OMG models have similar notions of encapsulations: the state of an object can only be accessed by means of signals across the object boundary or by means of relationships between objects. However, the OSI management interface definition includes, in addition to operations the object can perform, the notifications that an object may emit.

Object Specification and Instantiation

Concepts

Specification Binding

The irrevocable merging of specifications.

Object Instantiation

The process by which instances of objects are created.

Comparison

Attribute Specification

OSI Mgmt

Attributes and qualifiers are specified independently of managed-object classes.

OMG

Attributes and qualifiers are defined only within scope of Object interface types.

Internet Mgmt

Attributes (object types) are specified individually, not within any object class context. Object types may be aggregated into conceptual tables, but the same object type may not appear in multiple tables. SNMPv2 Textual Conventions may be used to specify behaviour and syntax to be reused by multiple object types.

Binding

OSI Mgmt

Specifications of attributes, operations, and events may be bound into packages by means of a package specification. The package specification may specify additional constraints over the attributes (for example, for example, range restrictions) and over operations and events (for example, for example, constraining variable-type parameters); it also specifies the semantics of the package as a whole (for example, the meaning of a statistics package). IDD

Package specifications themselves may be bound into a managed-object class by means of a managed-object-class specification. These bindings are qualified as either mandatory (a managed-object instance must reflect the specifications contained in the package) or conditional (a managed-object instance may reflect the specifications contained in the package).

OMG

Specifications of attributes and operations are combined into interfaces. Interfaces may be further combined into modules. Optionality is not supported for interface specifications. However, attribute and parameter values can include null choices, and there is a standard NOT_IMPLEMENTED exception type defined for CORBA.

The OMG Event Service has events defined as operations of an interface which operates in the reverse direction (that is, events are raised by the Object invoking an operation). Thus, a managed object can define one or more interface containing all the events which it can generate. The manager needs to support that interface.

Internet Mgmt

Individual object types may be combined into conceptual table rows, but no additional constraints or semantics are imposed there. In SNMPv2, individual object types may be combined into Object Groups which specify the semantics of the group as a whole, but do not otherwise impose additional constraints. Also in SNMPv2, individual object groups and types may be referenced by Module Compliance macros which specify access and/or value constraints permitted for conformance to a given MIB module. Object type status does not indicate presence/absence, its values are current and obsolete. A Module Compliance macro specifies object groups as mandatory or otherwise for the purpose of conformance.

Object Instantiation

OSI Mgmt

Instantiation may be from what alreadty exists, by local means, or by means of a CMIP create operation.

OMG

Instantiation may be from what already exists, or by means of an operation invocation on an application specific factory interface. No standard factory interfaces are defined for CORBA.

Internet Mgmt

Instantiation may be from what already exists, by local means, or by means of a set operation involving a conceptual table row status variable.

Behaviour Specification

OSI Mgmt

Unstructured natural language behaviour clause, with a recommendation to state pre-conditions, post-conditions, and invariants.

OMG

Unstructured natural language, using IDL comments.

Internet Mgmt

Unstructured natural language.

Specification Tools

OSI Mgmt

GDMO templates.

OMG

IDL.

Internet Mgmt

ASN.1 macros (OBJECT-TYPE, NOTIFICATION, MODULE-IDENTITY, MODULE-COMPLIANCE, OBJECT-GROUP).

Analysis

Specification techniques

The major difference in specification techniques is between the OSI Management piecemeal approach and the more monolithic approach taken by OMG. The OSI Management approach of separate specifications bound into packages which are subsequently bound into object classes, is claimed to improve the potential for re-use of specifications. Conditionally-bound packages are a form of late binding. They meet OSI Management's need for controlled variation in managed-object class specifications, but if used liberally they can cause ambiguity for implementors (see reference MPR91). In the OSI Management model, the union of the object-class identification with the identification of the packages present serves as the indicator of a particular managed object's characteristics. For implementors, packages complicate the type hierarchy.

The OMG specification technique is more monolithic over the type and does not admit late binding (it specifies that "the object type is an absolute indication of the characteristics of a type instance"). Re-use is achieved by inheritance (possibly multiple) of interface definitions. However, there is a standard exception (NOT IMPLEMENTED) which must be dealt with by invokers when an object implementation does not support an operation defined in its interface.

Conditional packages can lead to situations where all members of a class may not be the same. Usage of null values for attributes/parameters to simulate optionality does not change this.

Behavioural Specification

The behavioural aspects of managed objects are specified using natural language (see reference SMI91), although it is recommended that such specifications should be expressed in terms of pre-conditions, post-conditions, and invariants. There have been attempts to use formal techniques for the specification of the behaviour particular managed-object classes (see reference SMI91). The OMG also proposes the use of natural language to specify the behavioral aspects of objects.

ODP behaviour specifications will use Formal Description Techniques (FDTs). Dynamic type checking may use assertions about behaviour.

Specification Tools

OSI Management provides two tools for formally specifying the syntax of managed objects and the associated messages:

• a template language (see reference GDMO92) for defining the characteristics managed objects

• a data-definition language (see reference ASN90) for defining the data types associated with attributes and parameters.

The OMG CORBA 1.0 model does not prescribe a language for defining the syntax of the associated messages. For IDL (see reference CORBA98), a language similar to C++ is used to define the programmatic interface signature.

The OMG model defines objects by defining interface operations using in IDL. The word object in CORBA is equivalent to object interface in ODP.

Object Taxonomy

Concepts

Object Type

A predicate over the characteristics of an object. Objects are said to conform to a type.

Object Subtype

An additional predicate over the characteristics of a supertype.

Object Class

The set of objects which are of the same type. Objects in a class can have one or more compatible templates used for the generation and management of objects. Every type defines a class; however, the converse is not necessarily true. In ODP, the term class is used to represent the set of instances that satisfy a type, and a template represents the object specifications.

Object Sub-class

A modification to the template of a superclass.

Inheritance

A mechanism for deriving the specification of a descendant from the specification of an ancestor, such that in addition to its own characteristics, a descendant acquires all (strict inheritance), or part, of the characteristics of its ancestor. A descendant may have a single immediate ancestor (single inheritance) or multiple immediate ancestors (multiple inheritance). The super/sub relationship resulting from single inheritance may be represented by a tree; that resulting from multiple inheritance may be represented by a directed, acyclic graph.

At first glance, the subtyping and subclassing relationships in the OMG and OSI models appear similar. They both involve the development of new types or classes by means of inheritance and by the addition of new predicates or template modifications. The difference is that the subtyping relationship is one of substitutability, whereas the subclassing relationship is one of implementation sharing (see reference Lalon91). Thus an instance of a subtype may be substituted for an instance of a supertype without any change in behaviour visible at the object interface. A subclass, by comparison, shares the implementation of its superclass, and an instance of a subclass cannot always be reliably substituted for an instance of a superclass.

Comparison

Object Class

OSI Mgmt

The Management Information Model (see reference SMI91) classifies managed objects into classes. Class specifications are documented by templates.

OMG

The OMG model specifies objects by their interface. There is no direct concept of Object Class in OMG. However an object template can be derived from the inheritance graph of interface definitions.

Internet Mgmt

The Internet SMI (see references ISMI and ISMIV2) defines object types which classify individual variables.

Taxonomy

OSI Mgmt

Managed-object classes are related in quasi type-hierarchy by means of strict, multiple inheritance. The root of the hierarchy is the managed-object class TOP, which specifies attributes for specifying static properties common to all classes (for example, the actual Managed object class, which of the conditional packages are instantiated, and which classes the instance may respond to requests as). It is legal to inherit from two class definitions which include the same action or attribute, since the properties of the common named operations are merged (for example, get and get-replace become get-replace in the derived class).

OMG

Object types are related in a type hierarchy of supported interfaces by means of multiple inheritance. The root of the hierarchy is the object type object. It is currently illegal to inherit from two interfaces with the same operation or attribute name, or to redefine an operation or attribute name in the derived interface.

Internet Mgmt

Object types are related in a naming hierarchy that reflects conceptual table and object group organisation. The root of the naming hierarchy is the OBJECT IDENTIFIER assigned to the entire MIB. There is no support for inheritance of any type, although SNMPv2 conceptual tables may augment existing conceptual tables specified elsewhere.

Type System

OSI Mgmt

The managed-object types are distinct from other types (for example, attributes, actions, notifications) in the model.

OMG

Object interface types are integrated into a single type-hierarchy for all the types in the model.

Internet Mgmt

Object types are distinct from each other, and from other types in the model.

Analysis

The OMG model support the notion of substitutability by means of subtyping (that is, support for each inherited interface is required when supporting a derived interface). The OSI Management Model supports a similar notion by means of a limited subtyping capability termed compatibility (see reference SMI91).

Representing GDMO managed object inheritance in the case of repeated attributes or actions in the inherited packages will require special treatment when translating to OMG CORBA IDL.

Object Reference

Both object references and names refer to objects, but generally object references have no structure and are implemented as long bit-strings to facilitate effective machine processing. Their main use is to "resolve predicates of sameness and equality" (see reference Kent91). Names, on the other hand, are normally symbolic and mnemonic and oriented towards human consumption.

Concepts

Object Identity

A unique property of an object that unambiguously distinguishes it from all other objects in the universe of discourse for all time.

Object Reference

A unique token used to unambiguously refer to an object during its lifetime. Object references are assigned at object creation time and are never subsequently re-assigned. Thus, the mapping function of object reference to object, if it is valid, is both single-valued and singular (1:1) during the life-time of the object, and invalid afterwards.

Name

A token used to refer to an object. Different objects may be assigned the same name and the object may be assigned different names. Names may be re-assigned during the lifetime of the object. Thus the mapping function of name to object, if it is valid, may be both multi-valued and non-singular, and may change with time.

Access Transparency

A reference to an object does not expose/define the carriage protocol to that object.

Location Transparency

A reference to an object does not expose its location.

Location Independence

A reference to an object remains valid after the object changes location.

Comparison

Object Reference

OSI Mgmt

There is no specific concept of an object reference for a managed object other than the object instance (distinguished name).

OMG

In CORBA, Object Reference is an opaque type (that is, it is not externally defined and thus has no particular format). Objects may have more than one reference. Objects are assigned object references at creation. Object references are local entities and may not be globally unique.

Internet Mgmt

An object's reference is its name (that is, ASN.1 OBJECT IDENTIFIER). All agents use identical names for objects of a given types. In SNMP V2, the community field (or whatever it is now called) can be used to select the particular Agent which will serve as the scope for the object references passed in the protocol operations.

Name

OSI Mgmt

A managed object must have a single distinguished name, comprised of a sequence of Relative Distinguished Names (RDNs), corresponding to a name scope hierarchy of instance containment (not necessarily physical containment). Each RDN is a single, mandatory attribute/value pair associated with the managed object. The RDN attribute value is assigned at object creation-time and may not be changed during the lifetime of the object, although it may be reused afterwards.

OMG

Objects may have an arbitrary number of names. The scope is a name context. Names are distinct from objects - objects need not have names. There is mapping between name values and objects. The mapping may be changed at any time.

Internet Mgmt

An object instance name is formed by concatenating the OBJECT IDENTIFIER assigned to the object type, with either the value zero (for singular objects), or one or more object values representing conceptual table row indices. Index object types do not need to be part of the conceptual table row. Any given conceptual row always has the same index value(s), although that row may be conceptually created and deleted many times over.

Naming Model

OSI Mgmt

A hierarchically-qualified set of naming contexts, based on object containment, is prescribed to ensure object names are unique and unambiguous within an agent system's local context (local distinguished name), as well as in a global context (distinguished name). Aliases are not permitted.

OMG

The Name Service provides a directed, potentially cyclic, graph of naming contexts. This may have many roots. All names are mapped to an ObjectRef (possibly of another naming context). Thus an object may have many names and a single point in the graph may be reached via many routes.

Internet Mgmt

A hierarchically-qualified set of naming contexts, based on the object type registration tree, provides names that are locally unique and unambiguous within a single agent. To provide global uniqueness, object instance names must be used in conjunction with the agent's network address. Aliases are not permitted.

Access Transparency

OSI Mgmt

Unsupported. CMIP as defined in ISO/IEC 9596-2 (see reference CMIP91) is required. CMIP may run over Internet Protocol (IP), LLC I, or OSI lower layers.

OMG

Supported. ORBs may use whatever protocol is most appropriate. ORBs may employ Internet Protocol (IP), or OSI lower layers. CORBA interoperability requires support of a standard protocol.

Internet Mgmt

Unsupported. SNMPv1 or SNMPv2 as defined by referenced documents SNMP and SNMPv2 is required. SNMP may run over a wide variety of Internet and non-Internet transports, as described by RFC1449.

Location Transparency

OSI Mgmt

Not supported when objects are named within the scope of the System object. For OSI management, OSI protocol machines are naturally named within the scope of the open system they are part of, and thus location transparency is meaningless. However, not all managed objects have to be named within the scope of the System managed object, so location transparency is not precluded.

OMG

Supported in CORBA. Lifecycle services include Move operations.

Internet Mgmt

Not supported.

Location Independence

OSI Mgmt

Not supported for managed objects named within the scope of System.

OMG

Supported in CORBA.

Internet Mgmt

Not supported.

Analysis

Object Selection and Address Resolution

Concepts

Selection

The mechanism by which object instances are selected to receive invocations.

Associative Selection

A reference constructed from predicates over the characteristics of objects. Such a reference can resolve to zero or more objects.

Address Resolution

The mechanism by which a name is mapped to an address (see reference Jacqm90).

Comparison

Direct Selection

OSI Mgmt

By name.

OMG

In OMG, an Object Reference is an address, that is, it is all that is necessary to connect to that object, regardless of its current location. ORB interoperability is provided in CORBA 2.0 (see reference CORBA98), which includes resolving object references between different ORB implementations.

Internet Mgmt

By name.

Associative Selection

OSI Mgmt

Support of associative references by means of filters is optionally supported. The syntax and semantics of filters are defined. The scope is the whole, or some sub-tree, of the tree of managed objects. With CMIP, the invocation is made directly on the scope and filter - the agent implementation sorts out the targets.

OMG

Associative reference to a set of names could be done by traversal of the naming graph, or by a Trader Service. A standard OMG mechanism is not yet defined. Commands addressed to a set of objects via an associative reference would require a two phase mechanism: one which resolves to a set of objects via constraint matching on properties of the object's supported services; and the other which iterates over the objects invoking the operation on it. Clearly a scoping and filtering service could be written, but none appears specifically in the current OMG Roadmap (at the time of publication).

OMG has a Relationship Service, which may also provide a different mechanism. The OMG Object Services activity might fast-track a Trader Service (such as ODP trader) which provides associative references employing constraint matching on properties of services supported by object instances. Support for such associative references is permitted but not required. A standard OMG trader has not yet been specified, and it is expected that the ODP trader can be used.

Internet Mgmt

SNMP get-next and get-bulk operators allow reference to a conceptual table entry which is lexicographically after a named entry. The scope is the agent's network address, the entire registration tree, and lexicographic ordering within that tree. However, the receiver of these operation responses must do any necessary filtering out of unwanted variables. RFC1445 (see reference IADM93) defines MIB Views which are subsets of all instances of all object types.

Address Resolution

OSI Mgmt

The model does not prescribe a mechanism for address resolution, but it could be provided by the Directory (see reference DIR91).

OMG

The ORB provides address resolution. Mapping from a name to an object reference is done by the Name Service. An ORB resolves only a single target, and it is an application concern to sort out the targets.

Internet Mgmt

The model does not prescribe a mechanism for address resolution, but it could be provided by any directory service, including the Internet Domain Name Server.

Analysis

The OSI Management model defines specific syntax and semantics of the supporting mechanism. The OMG model does not.

ODP is specifying the syntax and semantics of a Trader service, which is expected to be used for associated selection of OMG objects.