Issues with 0.7 draft of standard

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-128.ibm.com/developerworks/webservices/library/ws-soa-enter2/

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

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.

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

obix-xml message