|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
- Object Management Service - Service to represent and manage object definitions in the system
- Resource Registry - Maintains persistent information about system resources in form of objects
- Datastore - Service and container capability to persist immutable objects (that are not resource objects)
- Common Science Data Model - Science Data sets are resources with complex object structures
- Common Message Format - Every message contains one object (and referenced objects) in the message content
- State Repository - Transient process state is saved as objects
- Associations between Objects - First class references between objects
- Object Specifications
- Service Interfaces - Service and object interface generation
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.
|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|
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.
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.