The Open Building Information Exchange (oBIX) Web services specification is feature complete and if not in public review already, will soon be.  Granted, the last time I wrote oBIX would soon be in public review was well over a year ago.  But this time it’s different; really, I’m not making this up.  Anyway, oBIX, which is advanced by the OASIS open standards consortium, is unique among Web services standards and I thought highlighting its special features would peak your interest and, dare to dream, motivate you to participate in the standardization process.

[an error occurred while processing this directive]

In a nutshell, oBIX will allow integrators to connect control systems, such as access control, with enterprise systems, such as human resources.  While today’s requirements say this will be done using points, historical trends and alarms, everyone expects these requirements to evolve rapidly.  Therefore oBIX is much more than just a way to describe points, historical trends and alarms.  It is an extensible model that describes other models - a meta-model.  oBIX allows control vendors to fully describe their proprietary systems and allow enterprises to discover non-standard data and invent new applications for it.

Extensibility is woven into the very fabric of oBIX using something called the contract.  A contract is a list of all the patterns a complex piece of data conforms to.  Contracts are used to describe standardized structures such as points, historical trends and alarms; and they are also used to describe proprietary vendor data.  The beauty of the contract is that new ones can be introduced without changing the oBIX schema.  Here’s why this is important.

In typical Web services built for business applications, introducing new data structures requires new schema documents, and it is a versioning nightmare.  Enterprise tools cannot handle unknown schemas so they simply ignore unanticipated data.  With oBIX, vendors and standards bodies can define contracts and even if a client doesn't know what to do with the new contracts, it can still access and work with the primitive values within.  All data is first class data and will not be ignored by tools.

oBIX is unique in another regard – it is binding agnostic.  Not only is there a SOAP binding so oBIX can interoperate with WS-* (the Web services stack), there is an HTTP binding making oBIX a RESTful standard.  REST, or Representational State Transfer, is the architectural style of the World Wide Web.  While not a standard itself, it is best described as the set of standards that make the web successful.  HTTP, URL, XML and HTML are some of those standards.  oBIX is built upon these standards;  it identifies objects with URLs, represents object state with XML, and transfers objects using the Hyper Text Transfer Protocol (HTTP is the mechanism for transferring web pages).  oBIX servers can be accessed with a web browser and therefore can be indexed by search engines, linked to by other web pages and basically interoperate with any other mainstream web technology.

Have you heard of Applied Javascript and XML (AJAX)?  AJAX is best described as dynamic web pages that make requests in the background and automatically update themselves.  These rich web pages behave like standalone applications but do not require browsers have special plugins.  The preeminent example is Google Maps which if you haven't tried, you should.  The reason being RESTful is important is because building real-time front ends will be as simple as building any other web page.  This is huge; we're talking about rich, easy to build, system independent front ends.

[an error occurred while processing this directive] Being RESTful also means delivering events, such as alarms and changes of value, the way it is done in the web.  Take for example email; most people think messages are magically pushed the recipient's desktop, but this is not so.  The recipient is a client application that periodically polls its email server for new incoming messages.  In the abstract, data has been pushed, which shouldn’t be confused with implementation details.  Really Simple Syndication (RSS) feeds, the technology for web news delivery and portal aggregation is also a client-polled mechanism.  Thus with oBIX eventing, the client tells the server what it is interested in, and then regularly polls the server for new events.  If there are none, nothing is returned.  It is an elegant solution that side steps a lot of complicated middleware issues and this is why it dominates the web.

Lastly, because oBIX is such a flexible modeling language, it has other uses beyond real-time integration.  Specifically, I’m talking about device descriptions.  At my company, we have created our own proprietary XML schema for device descriptions.  To introduce new devices to our product we create XML documents for these devices and feed them into a special compiler that auto-generates the execution code needed by our product.  We will switch to using oBIX for device descriptions and we will encourage our partners to do so too so we can easily share them in an open, portable and machine-readable way.

I hope I have peaked your interest, because I really think if you spend a little more time reading up on oBIX you’ll see its potential to be the enterprise gateway for the entire Machine-to-Machine space.  I urge you to comment on the specification.  Lastly, it is not too late to join the OASIS oBIX Technical Committee and have a substantial impact on this important effort.  Please visit http://www.oasis-open.org/committees/obix for more information.

About the Author

Aaron is a senior software engineer at Tridium, Inc. He is also chairman of the oBIX XML Standards subcommittee tasked with producing the oBIX technical specification. When Aaron isn’t coding or taking meeting notes, he’s designing lights for theatrical productions or producing progressive house music.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]