I began considering the implications of SOAP for Building Controls since the summer of 2000, when I killed some time (so I thought) at a conference by sitting in on a talk by Don Box, chair of the SOAP committee, presenting what was then version 0.9 of the standard. It was clear at that time that SOAP was going to be the means for integration and coordination of services across virtual enterprises comprised of hundreds of corporations.
What really opened my eyes, though, was the guy sitting next to me. As we chatted during breaks, he described himself as a chief software engineer for a manufacturer of UPnP (Universal Plug and Play) chipsets, something that if I recall properly, he was making for considerably less than $10 each. He was there, he said, because he figured that he might be able to incorporate the entire SOAP protocol, incorporating open-source code already available on the web, it would cost him less than $2 per chip-set, but that the value and market of for his chip-set would grow immensely.
I do not know if he has brought this to market, yet; I do know that this idea, of SOAP everywhere, was electrifying to me. When I returned to the University, we re-vamped our plans, drew up a new roadmap, and began looking for a system based upon the concepts that are now being defined in oBIX.
Recently, I have been going through some of my old SOAP and XML related correspondence. I came across a letter written in the spring of 2001 to a well thought of building automation system vendor.
The vendor in question had listened politely to us as we described our requirement for a completely open system, one that would allow many users to get direct access to the information they required, one that was ready for decentralized exchange of information with other control systems. The system we described would allow tenants to get direct access to the information they needed as it fit into their business models, not those of central monitoring and control.
The salesman, who was quite good, nodded, and then claimed that that was exactly what he was selling. The system was open because it was written in Java. The system let tenants harvest data directly because they could go to a web page and drill down when they wanted to look at data. His PowerPoint included the same slide all presentations seemed to have, a slide showing his system was open because all data was gathered to a single server, and we could make reports for tenants from there.
In other words, the same tired presentation and the same story we heard from everyone: web pages with proprietary data formats somehow constitute data sharing, an cross-platform programming language somehow means open standards, controlled access to carefully vetted stale data from a central server is somehow live access to operating data.
We have come a long way, but we are not there yet.