Skip to end of metadata
Go to start of metadata
This page describes the Common Object Model that is the framework for the description of all messages, resources, events, and associations in the system.


The Common Object Model has a prominent place in the ION system architecture. Objects and in particular their specifications are data interfaces between the ION system entities. An ION process communicating with another ION process, e.g. to request a service operation, makes use of objects of defined specification to send parameters and another object to receive responses. Objects are also used to represent the persistent information (metadata) about system resources, within the Resource Registry.

See the following ION system elements

Common Object Model Schema and Interfaces

See CIAD COI SV Service Interfaces for a description of the procedure to define object and service interfaces in YML files, generate Python language stubs from these interfaces and load them into each Capability Container and the system.

Types of Objects

Type Description Representation Python implementation Notes
Enum Defines an enumeration Encoded as 1-based integer value constrained to one of the enum values. IonEnumObject
Object Defines a composite object structure A dict value with a key for each attribute. Internal key "type_" encodes the type of the object. Other internal keys may exist for persistence purposes, such as "_id", "_rev" to be ignored by the application. Attributes can contain lists and dicts. Nested objects are recursively represented as a dict. IonObjectBase
Message Object Defines an object defining a type of message See object. IonMessageObjectBase

Object Interface Specification

See CIAD COI OV Object Specifications and CIAD COI SV Service Interfaces.

Common Object Model Encoding

The figure below shows the flow of information between the outside of the OOI Network and the system's processes. Within the ION process space, the common object model applies to all objects used for persistence and messaging. In particular, the following transformations exist between the common object model and the outside of the system.

  • Datastore object encoding/decoding
  • Messaging object encoding/decoding
  • Service gateway object encoding/decoding

Figure 1. OOI Object Encoding and Decoding (OV-1)

The figure shows the flow of information from an HTTP service request (red arrows) from the service gateway via messaging to a service operation. The service operation persists the received object (or persists a new object created based on the received information), retrieves another object from the datastore (green arrows) and provides it back as a service response, via messaging and the service gateway to the HTTP requester.

Concepts and Details

The figure below expresses the core concepts and their dependencies around the Common Object Model.

Figure 2. OOI Common Object Model (OV-7)

A Meta-Object Model provides a language to specify types of objects, composed of types attributes and nested objects. It also provides mechanisms to subtype objects, annotate them with comments and decorators. The format used in Release 2 is YAML. See also: Object Specifications

The Object Model itself represents the collection of known object types within the system. More object types can be added to the system during runtime (see Object Management Service).

Object specifications are projected into the implementation technology space and their programming languages. For Release 2, this is the Python environment.

The Capability Container provides a Language Specific Object Builder that can instantiate object types for use by ION processes. The Capability Container provides the framework to encode objects within messages and to persist objects in datastores, such as the Resource Registry.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.