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.  

 

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 

  !

===================================================