Re: [obix] Issues with 0.7 draft of standard

[Keith Gipson <kgipson@myfacility.com>]

Thanks for the explanation Aaron. 

Forgive me if I made any glaring, incorrect technical assumptions regarding
REST. However, you're right; the two major issues that I think are important
are:

1) Standardization of point types, AND
2) a single uri for each respective SOAP service (a "verb").

Further implications are getting over my my head : ), so...I will do some
research, so as to have a better understanding of the issues.

                                    Thanks again Aaron,

                                    It was nice seeing you in Dallas!

                                                Keith



--- Aaron Hansen <ahansen@tridium.com> wrote:

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