Occams razor for oBIX

[manolescue@pandora.be]

I must admit, right off the bat, to being lazy.  If someone has already invented a way of doing something, Ill usually opt for that.  This is how, as a civilization, we build on the past. Faced with the task of designing a new digital radio, electronics engineers do not go to the trouble of re-inventing transistors.  Instead they will search an on-line catalogue for the most suited components: they build on what already exists.

My view is that we should do the same for oBIX: if a technology exists then we should use it and not reinvent it.  In fact, I would go further.  It is incumbent on each author to prove that the target function they are addressing cannot be realized by an existing WS-* technology.  I know this sounds tough, especially when one has labored long and hard over a specification that seems like the best thing since sliced bread, but not doing so could threaten our whole initiative.  Before the red mist of our technology authors righteous indignation begins to rise, let me explain my thinking  and its not based just on laziness.

Let us remind ourselves that we have purposely targeted the interface between our control systems and the enterprise.  For the first time in the history of our industry, we are going to directly interface with the IT industry, represented by major corporations such as IBM, Microsoft, HP, CA etc.  Let us not fool ourselves, we are dealing with an industry impedance mismatch of several orders of magnitude.  In other words, we play by their rules or we dont play at all.  You can liken it to being in a room with a bunch of 5000lb gorillas: its not that they are irritated by you, they are not even aware that you are in the room.

These companies are spending squillions to develop the infrastructure of web services.  So my lazy brain says lets re-use as much as we can and only develop what is specifically relevant to our industry.  Had we taken this approach when we started oBIX there would not have been a lot to go on but in the past two years many new and useful standards have emerged.  Not only can we capitalize on this work - it is essential that we do so.

If you scan the WS literature you will find a lot of confusing technology; much of it apparently overlapping or directly competitive.  An example of this phenomenon is the three eventing standards: WS-Events, WS-Eventing and WS-Notification.  At first sight they all appear to do the same thing.  However recently we have seen some order come from this apparent chaos.  It would appear that WS-Events has quietly been dropped.  

WS-Eventing (created by Microsoft) has been targeted at small systems and will ultimately become a sub-set of WS-Notification (mostly an IBM initiative) which is aimed at large, pan-Enterprise systems.  So if you want something small and simple for a local system, you use WS-Eventing, safe in the knowledge that it can scale later into a large WS-Notification scheme.  In other words, you are not required to implement a ton of stuff that you dont really need.  WS-Eventing is thus WS-Notification-lite.  We saw this before in the networking world with the rise of LDAP which was effectively X.500-lite.  The older amongst us will remember that Unix was Multics-lite.  

Some of you will know that I have been urging us to look at WSDM as a reference management technology.  Microsoft recently produced and offered WS-Management.  A first glance shows that it squarely aimed to be WSDM-lite as it targets the CIM-profile.  WSDM is a huge undertaking and scaled at the pan-enterprise system level with special reference to large data and networking operations.  It builds on years of work in the Distributed Management Task Force (DMTF) and is likely to be a work-in-progress for some time to come.  What is clear is that we are getting a two-tier set of WS standards: large scale, pan-enterprise standards and lite versions which can give a quick win for smaller, localized systems.

Because they are easy to implement, there will be a great deal of support for the lite versions which will soon appear in applications and operating systems.  And this is the reason that we have to use and incorporate as much as we can of them.  To reinvent these basic functions will mean isolating ourselves from the gorillas; they are not going to change what they do for us.  However if we implement our domain-specific elements that they are not interested in, we become the cement to their bricks; building the final working structure.

I therefore urge you to look carefully at the following WS specifications (which all seem to be lite).  Let us gratefully embrace what is in them and only implement what is not.  The DataPoint concept is a stroke of genius and a good example of what we can bring to the party. By working with the IT industry we can leverage our forward efforts faster than other groups who have arrogantly tried to bend WS technology to their way of thinking instead of wisely building on others work.  

WS-Management
WS-Addressing
WS-Eventing
WS-Transfer
WS-Enumeration
WS-Discovery
WS-MetadataExchange
WS-Policy

As Newton said, If I have seen further it is by standing on the shoulders of giants