Open Messaging Interface (O-MI), an Open Group Internet of Things (IoT) Standard – Communication Protocols for the O-MI
In addition to basic read and write operations for querying and writing information (in similar ways to GET/POST in HTTP or get/set-methods in Java programming), the subscription concept is a cornerstone of the O-MI. The conceptual framework used here is the Observer design pattern, which is familiar to most programmers, and notably Java programmers.
In the IoT Standards context, the Observer pattern signifies that an O-MI node can add itself as an observer of events that occur at another O-MI node. In this sense the O-MI differs from, for example, the Java Message Service (JMS) that is based on the Publish-Subscribe model. For many applications the Observer and the Publish/Subscribe models can be used in quite similar ways.
However, the Publish-Subscribe model usually assumes the usage of a “high-availability server”, which the Observer pattern doesn’t. This is why the Observer model is more suitable for IoT applications where products might communicate with each other directly. Furthermore, the Observer pattern can also be used for implementing a Publish-Subscribe structure.
O-MI messages can be communicated through any communication protocol, removable storage media, or similar that can handle XML documents or XML strings. The default and recommended communication protocol is HTTP or HTTPS with the POST functionality. O-MI nodes SHOULD implement this communication method.
O-MI messages can also be communicated using WSDL/SOAP protocols according to this specification. (These are often called “Web Services” but the Web Service concept is not uniquely defined and tends to be used for signifying different things by different people and organizations.) O-MI nodes NEED NOT implement WSDL/SOAP as the protocol for O-MI messages.
HTTP Interface
O-MI messages can be communicated using plain HTTP communication. If so, O-MI nodes SHOULD send requests and callback messages using HTTP POST messages, where the name of the parameter that contains the O-MI message SHALL be called “msg”. How a Minimal O-MI Message shows how a minimal O-MI message can be sent with HTTP POST using the UNIX “curl” utility, where the URL of the O-MI node is http://dialog.hut.fi/qlm/. If it is received correctly, then a reply similar to that in Typical Minimal Response to an O-MI Request should be received. (The URL “http://dialog.hut.fi/qlm/” is provided as an example of a valid URL of an O-MI node. The reader should not assume that a valid O-MI node would be continuously available at that address, nor that it would return the content shown in this standard.)
How a Minimal O-MI Message (No Payload) can be Sent using the UNIX “curl” Utility
curl http://dialog.hut.fi/qlm/ --data msg="<?xml version="1.0" encoding="UTF-8"?><omi:omiEnvelope version="1.0" ttl="10"><omi:read><omi:msg></omi:msg></omi:read></omi:omiEnvelope>"
Typical Minimal Response to an O-MI Request
<?xml version="1.0" encoding="UTF-8"?>
<omiEnvelope version="0.2" ttl="0">
<response>
<result>
<return returnCode="200"></return>
</result>
</response>
</omiEnvelope>
The HTTP GET operation with a “msg” parameter containing an O-MI request MAY also be implemented by O-MI nodes. However, this is not the recommended way of making O-MI requests due to the size limitations of HTTP GET requests that may vary depending on the HTTP server used.
RESTful Interface
The O-MI has been designed to be RESTful whenever possible. This signifies that O-MI messages are intended to be as self-contained as possible, thereby making it possible for O-MI nodes to keep and maintain as little information about session and communication states as possible.
For the publication and discovery of data sources, O-MI nodes SHOULD also implement a URL-based (HTTP GET) mechanism for retrieving a list of available information in a hierarchical way. The paths used in URLs depend on the domain and will normally be defined by the same XML schema (or similar) as is being used for the message payloads. The “accompanying standard” called the O-DF provides a generic payload format that has been specified based on similar requirements and target applications as this O-MI. The O-DF specification is provided in a separate document.
Issuing HTTP GET Request to O-MI Node at “http://dialog.hut.fi/qlm/” for Getting the Available Information about the Data Source “Objects”
wget http://dialog.hut.fi/qlm/Objects/
Response using O-DF to Request for Objects List, within “Smart Home” Domain
<Objects>
<Object>
<id>Refrigerator123</id>
</Object>
<Object>
<id>HeatingController321</id>
</Object>
<Object>
<id>WeatherStation651</id>
</Object>
</Objects>
HTTP GET requests can be performed directly from a browser’s address line. Another possibility is to use, for instance, the UNIX “wget” utility as in Issuing HTTP GET Request to O-MI Node at “http://dialog.hut.fi/qlm/” for Getting the Available Information about the Data Source “Objects”. This request would return just an XML structure with “Objects” as the root element and all the first-level properties of the Objects element as shown in Response using O-DF to Request for Objects List, within “Smart Home” Domain. Then the elements of the retrieved XML structure can be used for drilling further down into the O-DF object hierarchy, where, for instance, the URL http://dialog.hut.fi/qlm/Objects/Refrigerator123/ would return the list of properties (called InfoItems) and possible sub-objects of the object “Refrigerator123”.
Another example payload format is the oBIX (Open Building Information eXchange) standard (refer to www.obix.org). When using oBIX, the URL <server_URL>/obix/ would return an oBIX XML-formatted object with the list of available oBIX services, such as the service “devices”. Then the URL <server_URL>/obix/devices/ would return an oBIX XML-formatted object with the list of available oBIX devices, for which subsequent requests can be made to find out what information each device can provide, their values, and metadata about them.
Contrary to most RESTful specifications, the O-MI does not use PUT and DELETE methods because that would create an explicit link between the O-MI and the HTTP protocol, which would go against the functional requirements set out for the O-MI.
WSDL/SOAP Interface
If an O-MI node uses the WSDL/SOAP protocols, then the WSDL interface SHALL define one function called “notify”. An O-MI node SHALL use the “notify” function whenever it intends to communicate O-MI-based messages using SOAP communication.
O-MI nodes SHALL use the “notify” function both for requests and responses in the same way as the HTTP POST protocol described in HTTP Interface. If WSDL/SOAP is used to communicate O-MI messages, the callback URL SHALL point to a WSDL service with a function named “notify”.
The notify function description is as follows:
String notify(String msg)
The parameter msg SHALL be the O-MI request or response as an XML string complying with the “O-MI XML Schema”. The responding O-MI node SHALL return an XML structure complying with the “O-MI XML Schema”.