Toby,
The issues you raised are spurious
- nothing has changed regarding the requirement to provide a SOAP/WSDL
binding for oBIX. Chapter 13 is tagged to cover the SOAP binding.
The term REST is used as an architectural pattern which is fairly orthogonal to
protocol bindings.
Brian
----- Original Message -----
From:
Considine, Toby (Facilities Technology
Office)
To: ''
Cc: ''
Sent: Tuesday, April 19, 2005 11:09
AM
Subject: [obix] 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
!
===================================================
