Re: [obix] Issues with 0.7 draft of standard

[Aaron Hansen <ahansen@tridium.com>]

Hi Keith,

I think REST and the object model are two separate issues.

1. The object model doesn't require knowledge of new data types.  New types will be created using only syntax and concepts from the base object model, so parsers can generically handle new types with requiring knowledge of say, a vendor's specialized types.   Also, I think you are confusing specification versus implementation and that you fear every vendor will implement points in a different way.  That is not the case, we will define the standard point type that everyone will use.  While we create the standard types, vendors can extend them and create their own (the same way the various oBIX verticals may create their own standard types).

2. REST implies two things (to me at least):
  A. Every resource is addressable as a uri.  Having every resource be uniquely addressable is no different than WS-Addressing (every resource has it's own WSDL document) being pushed by SOA heavy-weights, so I don't think there is a conflict with SOA.  I think it's the WSDL port type, or contract, of each resource one really cares about in SOA (but now we're out of my territory).  I don't like the idea of every resource having it's own WSDL simply because no one's tools support that kind of environment (for now) and I, like you, prefer a single uri for the SOAP service.

I don't think REST differentiates between the two uri's you gave, so in fact, the real identifier could be in the query string.

As for wild card queries, that is at a different level than us, it's not something we ever intended on implementing because it puts to much pressure on the control vendor who is not a search/software vendor.  That can be implemented on top of what we are doing; easily if your vendor implements a pure HTTP interface... Google and the other search vendors have solutions that you can purchase to index your web resources (IMHO this is really the whole point of REST).

  B. Every resource can only support a small set of operations (the HTTP ops - GET, POST, PUT, DELETE, TRACE, OPTIONS).  The new spec only specifies four in the same vein at WS-Transfer (get, put, create, delete).  If WS-Transfer was a standard and we used it, I don't think anyone would be complaining.  oBIX will have only one WSDL port type so once again, new types don't introduce new stuff.  However, how a resource interprets an operation is specialized.   Posting to point would have different consequences that posting to a schedule, and each would take different arguments (see #1).  The name of the operation is a hint at best, think of what addSpecialEvent would mean in a non-English speaking country.  The real meaning is in the documentation.

Anyway, I've spent way too much time on this email.  I hope I haven't made too many mistakes, and in some way addressed your comments.

Best,
Aaron


Keith Gipson wrote:

I agree with you Toby. 

Although REST is an architectural "style", it moves oBIX in a direction where a
user has to have full understanding of the data (types) they are looking for?
This is exactly why API's are so difficult to use in the first place, because
of strongly typed parameters and functions.

One of the main principles of REST is that the resources (URL's) should be
nouns, instead of verbs? For example:

http://www.myfacility.com/points/analogpoints/AHU12RaTemp
instead of:
http://www.myfacility.com/points/GetPointData?ptid=AHU12RaTemp

Doesn't this obviously get away from the SERVICES-oriented nature of web
services? What about partial matches and wildcards? "AHU12*", etc. where you
only have partial information available (such as the name only and not the
point type?).

Currently, if I need to access any one of several "Big 5" controls vendor's
systems, I have to figure out which service to use from their API, if it's an
Analog Input point, I have to use 

LPCSTR GetAnalogInputValue(pszPtName, LPCSTR *rgszPtParams, BOOL fFromCache);
if it's an AnalogOutput, it's:
LPCSTR GetAnalogOutputValue(pszPtName, LPCSTR *rgszPtParams, BOOL fFromCache);

and so on, and so on...

So, when I'm developing my interface, I have to explicitly know the "type" of
point it that I'm dealing with. 

Easy enough? 

Well, what if it's a user setpoint for an Air Handler? Is that a Pseudo Analog
Input (or Output), an Analog In, ??? I'm stuck with having to know "too much"
about the system I'm trying to get the data from.

This is the danger of coming up with a rigorous, (too) well defined
architectural style that will not be simple and extensible. Clearly, as you
pointed out, this is a major issue. Maybe I'm issing something, if so, it won't
be the first time; but it just seems like it's getting way to complicated.

                                       Keith
Keith E. Gipson
Chief Technology Officer
Impact Facility Solutions, Inc.
www.myfacility.com and soon...
www.mybuilding.com
kgipson@myfacility.com
"facility management, on demand!"



--- "Considine, Toby (Facilities Technology Office)" <Toby.Considine@unc.edu>
wrote:

  

I am very concerned about direction the specification takes in v0.7,
specifically retreating from SOAP to REST. With this change, oBIX retreats
entirely from being "Control Interface for the Enterprise" to being
"traditional control protocol with angle brackets". This means that except
for a few specialized consultants, oBIX will become oblique to the
enterprise developer. My sense from talking to companies in the wider OASIS,
whose votes will be required to make oBIX an OASIS standard, is that if this
direction persists, the oBIX draft will fail to get OASIS votes, and thereby
not be accepted as a standard.

 

 

The charm of REST is, clearly, its simplicity, and its similarity to the way
things have always been done. To the extent that a point service is all that
we want, it is the simplest way to get there. Clearly it is the easiest way
to put "angle brackets in the control stream". It fails, though in several
important ways:

 

1)    WSDL does not support REST, either 1.1, 1.2, or 2.0.

2)    REST is not composable, breaking one of the two basic principles of
Web services

3)    REST supports no security standard other than encryption. This means
any security will have to rely on either multiple calls to establish
cookie-based security for session management, or perhaps hard-coding those
IP addresses an oBIX gateway is able to communicate with. Because of (2) you
can toss out such specs as WS-Security, WS-Trust, WS-SecureConversation,
WS-Policy, and WS-SAML. There is no way to hold a Kerberos token inside
REST. This will require oBIX to implement its own security. These concerns
will have to be implemented by the provider at the application level.  HTTPS
is *not* an answer to this. In essence, we will have recreated the
architectural problems of Johnson's NAEs and NIEs, which had no security
model and so retrteated to custom encryption DLL's to cover up this fact.

4)    HTTPS does not encrypt the URL; the entire action is included in the
URL. While URL-based APIs are simple to use, they have no defense against,
for example, play-back attacks.

5)    Enterprise developer tools do not handle or support REST. Enterprise
developers are tool users, at least in all enterprises that reward provable
code, predictable delivery dates, team development, and programmer
productivity.

6)    REST is not transport agnostic meaning that with this transition, we
have eliminated all Message-Oriented Middleware-based transport schemes,
eliminating many major tools relied upon in the enterprise environment.

7)    REST violates extensibility, because REST parameters cannot
distinguish between parts of the message that the recipient "Must
Understand" and parts that can be ignored - increasing the demands on the
developer whose application will have to implement these features while
reducing interoperability between systems.

8)    The poorly understood distinctions between XML and HTML, including
case, Unicode overlaying, escaping, et al. make URI-based API's prone to
breaking and unpredictable results.

9)    Without WSDL, there is no way to define ad hoc discoverable
interactions between systems. This means every application can only be as
good as the individual integrators up front understanding of every component
of the system; I had hoped this is what we were getting away from with oBIX.

10)                       We will not be able to use reliability standards
such as WS-RX keeping oBIX from producing streams that can handle
life-safety issues (composability again)

 

 

It can be argued that large-scale REST applications do exist. It is true
that you can use REST for interactions with eBAY, Google, and Amazon. I must
point out that every developer interacting with these services is committed
to developing a custom interface with the one big player in their space.
This works only because:

 

*	information is public and encryption/authentication are unnecessary;

*	nothing terribly bad happens if a message is lost or duplicated; 
*	there are few demands for multi-part transaction management beyond
what can be implemented with HTTP sessions or cookies;  
*	There are no requirements for any transport other than HTTP

 

Each of these interfaces took a strong focus on careful, standard, and
particular business process, the type of effort I have not sensed a lot of
enthusiasm for w/i the TC. 

 

Web services toolkits are oriented toward use cases that demand
high-security, support for existing enterprise messaging systems, message
failure is not an option, and industrial-strength transaction processing is
assumed.  The REST approach assumes that all these features are provided at
the application level rather than being provided by the infrastructure.
There are some variants of REST for which it might be tolerable. It is a
great way to easily access Read Only points. It would be nice for an oBIX
discoverable node to be able to reference the stand-alone sensor across the
hall. To me, this would be more appropriately accomplished by something like
XML-RPC, which fits better into WSDL-2.

 

Overall, this is retreating from the document-based transfer model of Web
Services to the old-fashioned API. An API method looks like

 

Function fnAPI( float par1, string par2, date par3)

 

Each part of the API must be known and understood by the end point. A Web
Services method tends toward something like

 

Function fnService( document doc1)

 

In the WS-Interoperability spec (http://www.ws-i.org/), this argument is
summarized  in the WS-I Basic Profile by specifying document/literal as the
preferred style of communication. RPC/literal is also supported but
deprecated.

 

 

This document-centric approach is what gives services their power and
flexibility. Different parts of the document might be focused on business
process, others on a whole set of interactions, still others on defining a
set of [subscription points]. An identical document might be sent to
multiple ERPs with different results, as it may be successful, if indicated
in the document, for an ERP to accept a request that it only understands
partially. Different parts of the document may be marked "must understand";
others can be marked as optional. Any ERP that understands the "must
understand" part can accept the entire request. This flexibility, which the
enterprise expects, is tossed out entirely by the move to REST.

 

Clearly, this is a contentious matter outside the oBIX community and some
research does reveal that REST does have some strong partisans. There is
some effort to support something REST-like in future versions of WSDL. But
these are only in edge-cases and we shouldn't rely on edge-cases to build a
standard. I feel we have mistaken simplicity of mock-up for completeness of
solution. Many of the readings on REST vs. SOAP are strongly slanted one way
or another. Members of the committee that want to read some other
perspectives may want to review the following fairly balanced treatments:

 

http://www.webservices.org/index.php/ws/content/view/full/39565
<http://www.webservices.org/index.php/ws/content/view/full/39565> 

 

http://www-128.ibm.com/developerworks/webservices/library/ws-soa-enter2/
<http://www-128.ibm.com/developerworks/webservices/library/ws-soa-enter2/>  

 

http://www-128.ibm.com/developerworks/webservices/library/ws-samruby.html
<http://www-128.ibm.com/developerworks/webservices/library/ws-samruby.html>


 

http://www.w3.org/TR/ws-arch/ <http://www.w3.org/TR/ws-arch/>  

 

A quick Google of SOAP and REST will find many more contentious versions.

 

In short, if the charter of oBIX is to bring Controls Systems to the
Enterprise, it fails if it moves to REST.  

 

tc

=================================================== 
Toby Considine      ! "Do the right thing. It will 
UNC Chapel Hill     ! gratify some people and 
Chapel Hill, NC     ! astonish the rest." 
Phone (919)962-9073 ! 
Fax (919)962-1102   !            --Mark Twain 
tobias@fac.unc.edu  ! 
=================================================== 

    

=== message truncated ===