The Open Building Information Exchange (oBIX) specification defines generic web services to interact with control systems. While core specification of oBIX (1.x) is going through a long needed refresh, I am focused on oBIX 2.0. We have a solid international team working on defining higher level service interactions both for the enterprise and for peer to peer. This post is the first of several that will try to make more visible the work of the committee as we work on this specification.
A decade ago, Don Box described web services as making interactions between programs look as much like porn as possible. In a humorous response to a question from the audience, Don described a corporate network in which users could surf the web, install WeatherBug on their systems, spend their morning managing their stock portfolios, surfing for porn, and otherwise exchanging un-restricted information across the corporate network boundary. At the same time, common firewall rules restricted program to program communications that enabled the company to do business. Hence, web services made system to system communications look like porn so network administrators would let it pass unrestricted.
In the years since, network management has become more content aware, and many of these applications are more restricted. At the same time, the rise of social networking has opened up many new avenues for information-leakage in and of a corporate network. Instead of XML, JSON is sometimes viewed as the go-anywhere protocol. (oBIX 1.1 adds JSON support.) The key function provided by core oBIX is to make building control communications, or any control and sensor communications, to look like other web traffic, hiding and normalizing the various baseband communications protocols but leaving the message content and interactions unchanged.
oBIX 2.0 defines interactions more compatible with service oriented architectures (SOA). SOA reduces the requirement that a client system understand the processes of a server. SOA hides process details and focuses on service delivery. In buildings, a service doesn’t specify when the air handler will turn on, but when a room will be ready.
We already know that oBIX 2.0 will define how control systems offer service oriented scheduling. We will define how an oBIX server can provide support for smart energy, including OpenADR. Building on the taxonomy services added to oBIX 1.1, we will define a model for system inquiries, including mutability and transferability of discovery and search of control systems, including mutability and transferability of contracts. These features will require extensions to the oBIX lobby.
oBIX 2.0 will also define interactions for peer-to-peer and hive operations between oBIX servers. Information assurance becomes an important issue in wide distribution of systems. With oBIX 1.1 expanding the rage of oBIX bindings and encodings, standard models for authorization & security will become more important.
What I write here will be personal views on ongoing committee work. Let me know what you think!