Re: [obix] Issues with 0.7 draft of standard

[Keith Gipson <kgipson@myfacility.com>]

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 ===