Open Messaging Interface (O-MI), an Open Group Internet of Things (IoT) Standard – Introduction

 

Objective

The Open Group Internet of Things (IoT) Standards have been developed to fill an interoperability gap identified in the context of the IoT. In order to achieve its full potential, the IoT requires a trusted and secure, open, and unified infrastructure for true interoperability. Without this, continued lack of trust and parallel development of disparate solutions, technologies, and standards will lead it to become an ever-increasing web of organization and domain-specific intranets. The IoT standards will provide this infrastructure, as explained in greater detail in the White Paper: An Introduction to Quantum Lifecycle Management (QLM).

Overview

The IoT tends to be defined in different ways by different people. The Open Group IoT Standards definition is based on an IoT where products can have varying degrees of “intelligence”, from barcodes or RFID tags that have only an identifier to smart houses, vehicles, and other products that have advanced sensing and actuating capabilities, as well as powerful processing, memory, and communication capabilities. The lifecycle concept of the IoT Standards requires that the O-MI must be able to provide interoperability between products and with all other information systems that consume or provide information that is relevant to the product lifecycle. Despite the focus on product lifecycles, it is also the intention that the IoT standards would be applicable to lifecycles of “anything”, such as humans, services, projects, electronic documents, etc. Therefore, the O-MI has been specified in the most generic way possible.

The IoT Standards connectivity model is similar to that of the Internet itself. Where the Internet uses the HTTP protocol for transmitting HTML-coded information mainly intended for human users, the IoT Standards use the O-MI for transmitting lifecycle-related information mainly intended for automated processing by information systems. The O-MI fulfills the same purpose in the IoT Standards as HTTP does for the Internet. In the same way as HTTP can be used for transporting payloads also in other formats than HTML, the O-MI can be used for transporting payloads in almost any format. XML might currently be the most common text-based payload format but others, such as JSON, CSV, etc. may also be used.

A defining characteristic of the O-MI is that O-MI nodes do not have predefined roles, as it follows a “peer-to-peer” communications model. This means that any O-MI node can act both as a “server” and as a “client” and therefore communicate directly with each other or with back-end servers. Typical examples of exchanged data are sensor readings, alarm or lifecycle events, requests for historical data, notifications about availability of new data, changes to existing data, etc.

The main properties and requirements for the O-MI are:

  1. O-MI messages can be transported using most “lower-level” protocols. This signifies that protocols such as HTTP, SOAP, SMTP, files on mass storage media such as USB sticks, text messages on mobile phones, etc. can be used for transporting O-MI messages.
  2. Three possible operations: read, write, and cancel. Read is for immediate retrieval of information and for placing subscriptions for deferred retrieval of information from an O-MI node. Write is for sending information updates to O-MI nodes. Cancel is for cancelling subscriptions before they expire.
  3. O-MI nodes can request current and historical data with an immediate response. This is done by the read operation. Information is retrieved as a response message.
  4. O-MI nodes can send data to each other at any time. This is done by the write operation.
  5. Subscriptions can be made for deferred retrieval of data from other O-MI nodes. This is done by the read operation if the interval parameter has been set. If a callback address is provided, then the data is sent using an O-MI response message at the requested interval. If no callback address is provided, then the data can be retrieved (polled) by issuing a new read request with the ID of the subscription (this is particularly useful if the requesting node is behind a firewall or using NAT).
  6. Allowing different payload formats both for requests and responses. An O-MI message can transport actual information using any text-based format (standardized, proprietary, …) that can be embedded into an XML message. It is even possible to use different payload formats in different return elements of an O-MI response.
  7. All requests and responses can specify a Time-to-Live (TTL). If the message has not been delivered to the “next” O-MI node before the TTL expires, then the message should be removed and an error message returned or sent to the message originator, if possible.
  8. Enable synchronous communication between nodes. Any response message can include a new request, which is useful, for example, in control applications. It also provides a possibility to perform “client-initiated” communication with nodes that are located behind firewalls or NATs.
  9. Publication and discovery of data sources, services, and metadata. Publication of new data sources, services, and metadata can be done with the write operation. “RESTful” URL-based (HTTP GET) queries (in addition to read operations) allow the discovery of them, including discovery by search engines.

    Note: Format and semantics used by different data sources, services, metadata, etc. are not part of the O-MI; their format and semantics are specified by other standards, such as the O-DF or similar.
  10. All requests can specify a list of target O-MI nodes. The receiving node(s) are then responsible for re-routing the request to the target O-MI nodes, or sending back an error message to the requesting O-MI node in case of failure.

Conformance

This standard specifies conformance requirements for O-MI messages, O-MI nodes, and O-MI messaging interfaces in O-MI nodes. Communication Protocols for the O-MI through Error Handling and O-MI XSD Schema are normative. O-MI and XML Schema through JSON Mapping and Examples are informative.

Normative References

The following standards contain provisions which, through references in this standard, constitute provisions of the O-MI standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards.

Terminology

For the purposes of this standard, the following terminology definitions apply. When used in this way, these terms will always be shown in ALL CAPS; when these words appear in ordinary typeface they are intended to have their ordinary English meaning.

Can Describes a permissible optional feature or behavior available to the user or application. The feature or behavior is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.
May Describes a feature or behavior that is optional for an implementation that conforms to this document. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.
Must Describes a feature or behavior that is mandatory for an application or user. An implementation that conforms to this document shall support this feature or behavior.
Shall Describes a feature or behavior that is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.
Should For an implementation that conforms to this document, describes a feature or behavior that is recommended but not mandatory. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. For an application, describes a feature or behavior that is recommended programming practice for optimum portability.
Will Same meaning as “shall”; “shall” is the preferred term.

Future Directions

The Open Group IoT Standards will continue to be maintained by the QLM Work Group of The Open Group Platform 3.0™ Forum. They may be revised to correct errors or to incorporate changes based on implementation experience.

Also, O-MI contains normative provisions for use of XML, and an informative example indicating how JSON could be used. A future standard could contain normative provisions for use of JSON.

⇒ Communication Protocols for the O-MI