May 2014 |
[an error occurred while processing this directive] |
“Open Cloud”
allows us to mix and match web services |
Ken
Sinclair, |
Articles |
Interviews |
Releases |
New Products |
Reviews |
[an error occurred while processing this directive] |
Editorial |
Events |
Sponsors |
Site Search |
Newsletters |
[an error occurred while processing this directive] |
Archives |
Past Issues |
Home |
Editors |
eDucation |
[an error occurred while processing this directive] |
Training |
Links |
Software |
Subscribe |
[an error occurred while processing this directive] |
Keep the Cloud Open is a first attempt at describing what redefining “Open” in the Cloud might mean.
If we are not clear on Keeping the Cloud Open there is a dark side, a
concern of an evolving trend towards Proprietary Cloud. I grew up in
the industry during the DDC revolution and saw the floundering of the
early proprietary DDC systems that evolved quickly with amazing
capabilities, but rapidly became obsolete and impossible to maintain.
Several early DDC system companies failed and those that succeeded were
liberated with the development of open protocols with total project
integration and interaction with several vendors.
Large automation companies resisted “Open” until forced to open their
proprietary ways by their clients. Open meant losing control for these
companies which is of course what the client needed and wanted. A new
paradigm is in the definition of large companies, in the past large
companies were limited to large building automation but in the cloud
the likes of Amazon, Google, plus several others dwarf these companies
and raise new questions as to data ownership and interaction.
I fear a repeat of history for some upstarts that are ignoring known
open standards and protocols while attempting to claim ownership of
your data. Their fate is known but it may be painful to you if they are
your present cloud service provider.
I am concerned about companies providing Proprietary Cloud to gain
control. The term “Proprietary Cloud” is not normally used because of
the negative connotation but words like ‘closed vendor’ cloud or
‘managed cloud’ are used to politely describe my concern.
Cloud Standards or flavours are not well understood, or specified or
requested, and this allows large companies to build fences around your
data and who can control your web services. The very thing pitched to
set you free may trap you. Understand and take ownership of your data
and insure “cloud openness” which is yet to be clearly defined. We have
provided an review of Open Cloud Definitions as a first step to start
our journey to understanding the true implications of keeping our cloud
open.
From my Classification or what ‘things’ are called, I write:
Conclusion: If
we are to keep the cloud open and as useful as possible you cannot
allow unstructured naming of anything, you must take ownership of your
classification or what ‘things’ are called.
The dangerous potential trend to a proprietary cloud is fuelled by
overall security concerns and the instant value of included web
services in the proposed Proprietary Cloud.
How do we avoid Proprietary Cloud while still involving our clients and the many vendors and our new and existing web services?
How do we build “Open Cloud” that allows us to mix and match web services to our Corporate enterprise goals?
Our past open progress could be lost in a cloud, if we do not heed our
past experience of 30 years we may be giving up control rather than
gaining it while we move past the IOT to the WOT.
In this column, Getting Over the Internet of Things - Toby Considine of TC9, writes:
Ken Sinclair
has been doing a great job stirring the pot on open systems and open
standards, and open interfaces revolution in buildings and “things”. It
is only as the buildings industry matures in how it uses these
specifications that it will move past the unproductive arguments over
the best protocol to something more useful. While we argue about the
Iot, the WoT is coming.
The IoT is
nearly 40 years old, now. I am arbitrarily taking the development of
X10 in 1975 as its beginning. The IoT is a nest or proprietary things
serving single applications or single vendors. The IoT is the family of
single-scope products that the cable company and the home security
company is using to expand their offerings. It is a dead end.
[an error occurred while processing this directive]Throughout
this year, I have been writing about some of the ways to get past the
IoT. OBIX has always been about reaching to people and the enterprise.
Therese Sullivan has introduced a new acronym (MQTT) to
AutomatedBuildings this month that speaks of another route in her
article IoT Opens to Mobile Messaging Standards. Enterprise computing,
and personal computing, is all about combining protocols, using what
William Cox calls the Architects Palette. The enterprise architect
selects standards and blends them. This blending is a critical step on
the road to the Web of Things.
Some writers
and researchers are using the Web of Things (WoT) to name a
semantically aligned IoT. The Web of Things moves beyond the parochial
standards that we keep inventing in buildings (and elsewhere) and moves
to higher level i.e., more abstract semantics. Like the Internet of
Things, everything in the WoT has an URI (which is different than
everything has an IP address…). In simplest illustration, in the Web of
Things, there is no BACnet Light, no ZigBee IP Light, and no KNX light,
not even an X10 light, there is only a light. That light is slowly
being placed into a context using standard ontological methods, but
that is taking two steps ahead.
This does not
mean the end of the domain protocols. Far from it. Building protocols
are the best for using internally to building applications. Buildings
have seen over-extensions of domain protocols from the other side in
recent years, as the smart grid folks tried to get buildings to abandon
their domain specific languages to use those of the utilities. If you
are inside a BACnet (for example) application, of course you should use
the BACnet light. Just don’t expect anyone from outside your niche to
adapt their language to yours.
OBIX has
always been first and last about common low-level semantics. In the
current drafts, wherein we broke out encodings and bindings, we were
reaching to enterprise-style composition, to expanding the palette.
MQTT is another expansion of the palette.
Understand and take ownership of your data and insure “cloud openness” which is yet to be clearly defined.
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]