OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [no subject]


http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm> 

"REST does not restrict communication to a particular protocol, but it does
constrain the interface between components, and hence the scope of
interaction and implementation assumptions that might otherwise be made
between components. For example, the Web's primary transfer protocol is
HTTP, but the architecture also includes seamless access to resources that
originate on pre-existing network servers, including FTP [107
<http://www.ics.uci.edu/~fielding/pubs/dissertation/references.htm#ref_107>
], Gopher [7
<http://www.ics.uci.edu/~fielding/pubs/dissertation/references.htm#ref_7> ],
and WAIS [36
<http://www.ics.uci.edu/~fielding/pubs/dissertation/references.htm#ref_36>
]. Interaction with those services is restricted to the semantics of a REST
connector. This constraint sacrifices some of the advantages of other
architectures, such as the stateful interaction of a relevance feedback
protocol like WAIS, in order to retain the advantages of a single, generic
interface for connector semantics. In return, the generic interface makes it
possible to access a multitude of services through a single proxy. If an
application needs the additional capabilities of another architecture, it
can implement and invoke those capabilities as a separate system running in
parallel, similar to how the Web architecture interfaces with "telnet" and
"mailto" resources."

The Semantics of a rest connector are non-composable - that *is* its
architecture.

A good comparison of the styles of SOA:

http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
<http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html> 


Deriving Web Services from SOA


Everyone knows roughly what a "web service" is, but there is no universally
accepted definition. The definition of web service has always been under hot
debate within the W3C Web Services <http://www.w3.org/2002/ws/arch/>
Architecture Working Group. Despite the difficulty of defining web services,
it is generally accepted that a web service is a SOA with at least the
following additional constraints:

1.     Interfaces must be based on Internet protocols such as HTTP, FTP, and
SMTP.

2.     Except for binary data attachment, messages must be in XML
<http://www.xml.com/pub/a/98/10/guide0.html> .

There are two main styles of Web services: SOAP
<http://www.w3.org/TR/2003/REC-soap12-part0-20030624/>  web services and
REST <http://www.xml.com/pub/a/ws/2002/02/20/rest.html>  web services. 


SOAP Web services


A SOAP web service introduces the following constraints:

1.     Except for binary data attachment, messages must be carried by SOAP.

2.     The description of a service must be in WSDL
<http://www.w3.org/TR/wsdl12/> .

A SOAP web service is the most common and marketed form of web service in
the industry. Some people simply collapse "web service" into SOAP and WSDL
services. SOAP provides "a message construct that can be exchanged over a
variety of underlying protocols" according to the SOAP 1.2 Primer
<http://www.w3.org/TR/2003/REC-soap12-part0-20030624/> . In other words,
SOAP acts like an envelope that carries its contents. One advantage of SOAP
is that it allows rich message exchange patterns ranging from traditional
request-and-response to broadcasting and sophisticated message correlations.
There are two flavors of SOAP web services, SOAP RPC and document-centric
<http://webservices.xml.com/pub/a/ws/2003/09/02/typeless.html>  SOAP web
service. SOAP RPC web services are not SOA; document-centric SOAP web
services are SOA.


SOAP RPC Web Services


A SOAP RPC web service breaks the second constraint required by an SOA. A
SOAP RPC Web service encodes RPC (remote procedure calls) in SOAP messages.
In other words, SOAP RPC "tunnels" new application-specific RPC interfaces
though an underlying generic interface. Effectively, it prescribes both
system behaviors and application semantics. Because system behaviors are
very difficult to prescribe in a distributed environment, applications
created with SOAP RPC are not interoperable by nature. Many real life
implementations have confirmed this.

Faced with this difficulty, both WS-I
<http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm>  basic
profile and SOAP 1.2 have made the support of RPC optional. RPC also tends
to be instructive rather than descriptive, which is against the spirit of
SOA. Ironically, SOAP was originally designed
<http://www.xml.com/pub/a/ws/2001/04/04/soap.html>  just for RPC. It won't
be long before someone claims that "SOAP" actually stands for "SOA
Protocol".


REST Web Services


The term REST
<http://www1.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm>
was first introduced by Roy Fielding to describe the web architecture
<http://www.w3.org/2001/tag/webarch/> . A REST web service
<http://www.xml.com/pub/a/ws/2002/02/20/rest.html>  is an SOA based on the
concept of "resource". A resource is anything that has a URI. A resource may
have zero or more representations. Usually, people say that a resource does
not exist if no representation is available for that resource. A REST web
service requires the following additional constraints:

1.     Interfaces are limited to HTTP. The following semantics are defined:

*	HTTP GET is used for obtaining a representation
<http://www.w3.org/2001/tag/webarch/#representation>  of a resource. A
consumer uses it to retrieve
<http://www.w3.org/2001/tag/webarch/#retrieve-representation>  a
representation from a URI. Services provided through this interface must not
incur any obligation from consumers. 
*	HTTP DELETE is used for removing representations of a resource. 
*	HTTP POST is used for updating or creating the representations of a
resource. 
*	HTTP PUT is used for creating representations of a resource. 

1.	Most messages are in XML, confined by a schema written in a schema
language such as XML Schema <http://www.w3.org/XML/Schema>  from W3C or
RELAX NG <http://www.relaxng.org/> . 
2.	Simple messages can be encoded with URL encoding. 
3.	Service and service providers must be resources while a consumer can
be a resource. 

REST web services require little infrastructure support apart from standard
HTTP and XML processing technologies, which are now well supported by most
programming languages and platforms. REST web services are simple and
effective because HTTP is the most widely available interface, and it is
good enough for most applications. In many cases, the simplicity of HTTP
simply outweighs the complexity of introducing an additional transport
layer.

And getting back to the meat of the matter:

1)    REST is non composable. Its simplicity and elegance are based upon
using URLS for addressing. URLs are not composable. The Compositional items
are in the XML payload that is explicitly bypassed in REST.

 

2)    REST, being URL-based, is not transportable over any messaging based
protocol. Since it skips the XML payload of SOAP, it does not have the
payload that could be re-packaged and delivered by in an alternate delivery
mechanism.

 

REST as the term is commonly understood is parallel to and different from,
rather than orthogonal to SOAP.

 

tc

 

=================================================== 
"Is minic bhris beal an duine a shron.."
   'Tis often a man's mouth that broke his nose.."
                                   Old Irish saying
=================================================== 
Toby Considine               | Phone  (919)962-9073 
Facilities Services          | Fax    (919)962-1102 
University of North Carolina |  
Chapel Hill, NC              |   tobias@fac.unc.edu 
=================================================== 

  _____  

From: Brian Frank [mailto:bfrank@tridium.com] 
Sent: Tuesday, April 19, 2005 11:21 PM
To: Considine, Toby (Facilities Technology Office);
obix-xml@lists.oasis-open.org
Cc: obix@lists.oasis-open.org
Subject: Re: [obix] Issues with 0.7 draft of standard

 

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, <mailto:Toby.Considine@unc.edu>  Toby (Facilities
Technology Office) 

To: 'obix-xml@lists.oasis-open.org' <mailto:'obix-xml@lists.oasis-open.org'>


Cc: 'obix@lists.oasis-open.org' <mailto:'obix@lists.oasis-open.org'>  

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


------_=_NextPart_001_01C545C2.8E5F7640
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40";>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h2
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:18.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
h3
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:Arial;
	font-weight:bold;}
h4
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	page-break-after:avoid;
	font-size:14.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Verdana;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Verdana;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:393969434;
	mso-list-type:hybrid;
	mso-list-template-ids:98617280 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:446972204;
	mso-list-template-ids:-247940904;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l2
	{mso-list-id:508250379;
	mso-list-template-ids:-714947728;}
@list l3
	{mso-list-id:574126986;
	mso-list-template-ids:1031853742;}
@list l3:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l4
	{mso-list-id:603654661;
	mso-list-template-ids:1081652368;}
@list l4:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l5
	{mso-list-id:739064564;
	mso-list-template-ids:-1500092694;}
@list l5:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l6
	{mso-list-id:1282807111;
	mso-list-type:hybrid;
	mso-list-template-ids:-489150034 67698689 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l6:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l6:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l6:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l6:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l6:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l6:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l6:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l6:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l6:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l7
	{mso-list-id:1445614022;
	mso-list-template-ids:-1353156746;}
@list l7:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l8
	{mso-list-id:1640305314;
	mso-list-type:hybrid;
	mso-list-template-ids:-1671550130 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l8:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l8:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l8:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l8:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l8:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l8:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l8:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l8:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l8:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l9
	{mso-list-id:1951282646;
	mso-list-template-ids:232819832;}
@list l10
	{mso-list-id:2059276197;
	mso-list-template-ids:-1022316538;}
@list l10:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p style=3D'background:#F8FCFF'><font size=3D2 face=3DVerdana><span =
lang=3DEN
style=3D'font-size:11.0pt;font-family:Verdana'>From the definition of =
REST:<o:p></o:p></span></font></p>

<p style=3D'background:#F8FCFF'><font size=3D2 face=3DVerdana><span =
lang=3DEN
style=3D'font-size:11.0pt;font-family:Verdana'><a
href=3D"http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_sty=
le.htm">http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_sty=
le.htm</a><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><i><font size=3D2 face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana;font-style:italic'>"REST =
does
not restrict communication to a particular protocol, but it does =
constrain the
interface between components, and hence the scope of interaction and
implementation assumptions that might otherwise be made between =
components. For
example, the Web's primary transfer protocol is HTTP, but the =
architecture also
includes seamless access to resources that originate on pre-existing =
network
servers, including FTP [<a
href=3D"http://www.ics.uci.edu/~fielding/pubs/dissertation/references.ht=
m#ref_107">107</a>],
Gopher [<a
href=3D"http://www.ics.uci.edu/~fielding/pubs/dissertation/references.ht=
m#ref_7">7</a>],
and WAIS [<a
href=3D"http://www.ics.uci.edu/~fielding/pubs/dissertation/references.ht=
m#ref_36">36</a>].
<b><span style=3D'font-weight:bold'>Interaction with those services is =
restricted
to the semantics of a REST connector</span></b>. This constraint =
sacrifices
some of the advantages of other architectures, such as the stateful =
interaction
of a relevance feedback protocol like WAIS, in order to retain the =
advantages
of a single, generic interface for connector semantics. In return, the =
generic
interface makes it possible to access a multitude of services through a =
single
proxy. If an application needs the additional capabilities of another
architecture, it can implement and invoke those capabilities as a =
separate
system running in parallel, similar to how the Web architecture =
interfaces with
&quot;telnet&quot; and &quot;mailto&quot; =
resources."<o:p></o:p></span></font></i></p>

<div =
style=3D'mso-element:para-border-div;border:none;border-bottom:double =
windowtext 2.25pt;
padding:0in 0in 1.0pt 0in'>

<p style=3D'border:none;padding:0in'><font size=3D2 =
face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana'>The Semantics of a rest =
connector
are non-composable - that *<b><span =
style=3D'font-weight:bold'>is</span></b>*
its architecture.<o:p></o:p></span></font></p>

</div>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>A
good comparison of the styles of SOA:<o:p></o:p></span></font></p>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><a
href=3D"http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html";>http://=
webservices.xml.com/pub/a/ws/2003/09/30/soa.html</a><o:p></o:p></span></=
font></p>

<h3><b><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:
Verdana'>Deriving Web Services from =
SOA<o:p></o:p></span></font></b></h3>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>Everyone
knows roughly what a &quot;web service&quot; is, but there is no =
universally
accepted definition. The definition of web service has always been =
under hot
debate within the <a href=3D"http://www.w3.org/2002/ws/arch/";>W3C Web =
Services
Architecture Working Group</a>. Despite the difficulty of defining web
services, it is generally accepted that a web service is a SOA with at =
least
the following additional constraints:<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l9 level1 =
lfo11'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>1.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>Interfaces
must be based on Internet protocols such as HTTP, FTP, and =
SMTP.<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l9 level1 =
lfo11'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>2.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>Except
for binary data attachment, messages must be in <a
href=3D"http://www.xml.com/pub/a/98/10/guide0.html";>XML</a>.<o:p></o:p><=
/span></font></p>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>There
are two main styles of Web services: <a
href=3D"http://www.w3.org/TR/2003/REC-soap12-part0-20030624/";>SOAP</a> =
web
services and <a =
href=3D"http://www.xml.com/pub/a/ws/2002/02/20/rest.html";>REST</a>
web services. <o:p></o:p></span></font></p>

<h4><b><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:
Verdana'>SOAP Web services<o:p></o:p></span></font></b></h4>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>A
SOAP web service introduces the following =
constraints:<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l2 level1 =
lfo12'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>1.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>Except
for binary data attachment, messages must be carried by =
SOAP.<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l2 level1 =
lfo12'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>2.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>The
description of a service must be in <a =
href=3D"http://www.w3.org/TR/wsdl12/";>WSDL</a>.<o:p></o:p></span></font>=
</p>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>A
SOAP web service is the most common and marketed form of web service in =
the
industry. Some people simply collapse &quot;web service&quot; into SOAP =
and
WSDL services. SOAP provides &quot;a message construct that can be =
exchanged
over a variety of underlying protocols&quot; according to the <a
href=3D"http://www.w3.org/TR/2003/REC-soap12-part0-20030624/";>SOAP 1.2 =
Primer</a>.
In other words, SOAP acts like an envelope that carries its contents. =
One
advantage of SOAP is that it allows rich message exchange patterns =
ranging from
traditional request-and-response to broadcasting and sophisticated =
message
correlations. There are two flavors of SOAP web services, SOAP RPC and =
<a
href=3D"http://webservices.xml.com/pub/a/ws/2003/09/02/typeless.html";>do=
cument-centric
SOAP web service</a>. SOAP RPC web services are not SOA; =
document-centric SOAP
web services are SOA.<o:p></o:p></span></font></p>

<h4><b><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:
Verdana'>SOAP RPC Web Services<o:p></o:p></span></font></b></h4>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>A
SOAP RPC web service breaks the second constraint required by an SOA. A =
SOAP
RPC Web service encodes RPC (remote procedure calls) in SOAP messages. =
In other
words, SOAP RPC &quot;tunnels&quot; new application-specific RPC =
interfaces
though an underlying generic interface. Effectively, it prescribes both =
system
behaviors and application semantics. Because system behaviors are very
difficult to prescribe in a distributed environment, applications =
created with
SOAP RPC are not interoperable by nature. Many real life =
implementations have
confirmed this.<o:p></o:p></span></font></p>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>Faced
with this difficulty, both <a
href=3D"http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm=
">WS-I
basic profile</a> and SOAP 1.2 have made the support of RPC optional. =
RPC also
tends to be instructive rather than descriptive, which is against the =
spirit of
SOA. Ironically, SOAP was <a
href=3D"http://www.xml.com/pub/a/ws/2001/04/04/soap.html";>originally =
designed
just for RPC</a>. It won't be long before someone claims that =
&quot;SOAP&quot;
actually stands for &quot;SOA =
Protocol&quot;.<o:p></o:p></span></font></p>

<h4><b><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:
Verdana'>REST Web Services<o:p></o:p></span></font></b></h4>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>The
term <a
href=3D"http://www1.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_=
style.htm">REST</a>
was first introduced by Roy Fielding to describe the <a
href=3D"http://www.w3.org/2001/tag/webarch/";>web architecture</a>. A <a
href=3D"http://www.xml.com/pub/a/ws/2002/02/20/rest.html";>REST web =
service</a> is
an SOA based on the concept of &quot;resource&quot;. A resource is =
anything
that has a URI. A resource may have zero or more representations. =
Usually,
people say that a resource does not exist if no representation is =
available for
that resource. A REST web service requires the following additional
constraints:<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo13'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>1.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>Interfaces
are limited to HTTP. The following semantics are =
defined:<o:p></o:p></span></font></p>

<ol start=3D1 type=3D1>
 <ul type=3Dcircle>
  <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l1 level2 lfo13'><font size=3D2 =
face=3DVerdana><span
      style=3D'font-size:11.0pt;font-family:Verdana'>HTTP GET is used =
for
      obtaining a <a =
href=3D"http://www.w3.org/2001/tag/webarch/#representation";>representati=
on</a>
      of a resource. A consumer uses it to <a
      =
href=3D"http://www.w3.org/2001/tag/webarch/#retrieve-representation";>ret=
rieve
      a representation</a> from a URI. Services provided through this =
interface
      must not incur any obligation from consumers. =
<o:p></o:p></span></font></li>
  <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l1 level2 lfo13'><font size=3D2 =
face=3DVerdana><span
      style=3D'font-size:11.0pt;font-family:Verdana'>HTTP DELETE is =
used for
      removing representations of a resource. =
<o:p></o:p></span></font></li>
  <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l1 level2 lfo13'><font size=3D2 =
face=3DVerdana><span
      style=3D'font-size:11.0pt;font-family:Verdana'>HTTP POST is used =
for
      updating or creating the representations of a resource. =
<o:p></o:p></span></font></li>
  <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l1 level2 lfo13'><font size=3D2 =
face=3DVerdana><span
      style=3D'font-size:11.0pt;font-family:Verdana'>HTTP PUT is used =
for
      creating representations of a resource. =
<o:p></o:p></span></font></li>
 </ul>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l1 level1 lfo13'><font size=3D2 face=3DVerdana><span
     style=3D'font-size:11.0pt;font-family:Verdana'>Most messages are =
in XML,
     confined by a schema written in a schema language such as <a
     href=3D"http://www.w3.org/XML/Schema";>XML Schema</a> from W3C or =
<a
     href=3D"http://www.relaxng.org/";>RELAX NG</a>. =
<o:p></o:p></span></font></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l1 level1 lfo13'><font size=3D2 face=3DVerdana><span
     style=3D'font-size:11.0pt;font-family:Verdana'>Simple messages can =
be
     encoded with URL encoding. <o:p></o:p></span></font></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l1 level1 lfo13'><font size=3D2 face=3DVerdana><span
     style=3D'font-size:11.0pt;font-family:Verdana'>Service and service =
providers
     must be resources while a consumer can be a resource. =
<o:p></o:p></span></font></li>
</ol>

<div =
style=3D'mso-element:para-border-div;border:none;border-bottom:double =
windowtext 2.25pt;
padding:0in 0in 1.0pt 0in'>

<p style=3D'border:none;padding:0in'><font size=3D2 =
face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana'>REST web services =
require little
infrastructure support apart from standard HTTP and XML processing
technologies, which are now well supported by most programming =
languages and
platforms. REST web services are simple and effective because HTTP is =
the most
widely available interface, and it is good enough for most =
applications. In
many cases, the simplicity of HTTP simply outweighs the complexity of
introducing an additional transport layer.<o:p></o:p></span></font></p>

</div>

<p><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>And
getting back to the meat of the matter:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo6'><![if !supportLists]><font
size=3D2 color=3Dblack face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana;
color:black'><span style=3D'mso-list:Ignore'>1)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dblack face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana;
color:black'>REST is non composable. Its simplicity and elegance are =
based upon
using URLS for addressing. URLs are not composable. The Compositional =
items are
in the XML payload that is explicitly bypassed in =
REST.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana;color:black'><o:p>&nbsp;</=
o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo6'><![if !supportLists]><font
size=3D2 color=3Dblack face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana;
color:black'><span style=3D'mso-list:Ignore'>2)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dblack face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana;
color:black'>REST, being URL-based, is not transportable over any =
messaging
based protocol. Since it skips the XML payload of SOAP, it does not =
have the
payload that could be re-packaged and delivered by in an alternate =
delivery
mechanism.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana;color:black'><o:p>&nbsp;</=
o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana;color:black'>REST as the =
term is commonly
understood is parallel to and different from, rather than orthogonal to =
SOAP.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana;color:black'><o:p>&nbsp;</=
o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana;color:black'>tc<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana;color:black'><o:p>&nbsp;</=
o:p></span></font></p>

<div>

<p><font size=3D2 color=3Dblue face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier =
New";color:blue'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D</span></font><font
color=3Dblue><span style=3D'color:blue'> <br>
</span></font><font size=3D2 color=3Dblue face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";color:blue'>&quot;Is minic
bhris beal an duine a shron..&quot;<br>
</span></font><font color=3Dblue face=3D"Courier New"><span =
style=3D'font-family:
"Courier New";color:blue'>&nbsp;&nbsp; </span></font><font size=3D2 =
color=3Dblue
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:blue'>'Tis often a man's mouth that broke his nose..&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Old Irish saying<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D</span></font><font
color=3Dblue><span style=3D'color:blue'> <br>
</span></font><font size=3D2 color=3Dblue face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:blue'>Toby
Considine&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;
| Phone&nbsp; (919)962-9073</span></font><font color=3Dblue><span
style=3D'color:blue'> <br>
</span></font><font size=3D2 color=3Dblue face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";color:blue'>Facilities
Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
Fax&nbsp;&nbsp;&nbsp; (919)962-1102</span></font><font =
color=3Dblue><span
style=3D'color:blue'> <br>
</span></font><st1:PlaceType w:st=3D"on"><font size=3D2 color=3Dblue
 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
 color:blue'>University</span></font></st1:PlaceType><font size=3D2 =
color=3Dblue
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:blue'> of <st1:PlaceName w:st=3D"on">North =
Carolina</st1:PlaceName> |&nbsp;
</span></font><font color=3Dblue><span style=3D'color:blue'><br>
</span></font><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2 color=3Dblue
  face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
  color:blue'>Chapel Hill</span></font></st1:City><font size=3D2 =
color=3Dblue
 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
 color:blue'>, <st1:State =
w:st=3D"on">NC</st1:State></span></font></st1:place><font
size=3D2 color=3Dblue face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:
"Courier =
New";color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; <st1:PersonName =
w:st=3D"on">tobias@fac.unc.edu</st1:PersonName></span></font><font
color=3Dblue><span style=3D'color:blue'> <br>
</span></font><font size=3D2 color=3Dblue face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";color:blue'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D</span></font><font
color=3Dblue><span style=3D'color:blue'> </span></font><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Brian Frank
[mailto:bfrank@tridium.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, April 19, =
2005
11:21 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Considine, Toby =
(Facilities
Technology Office); obix-xml@lists.oasis-open.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
obix@lists.oasis-open.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [obix] =
Issues with
0.7 draft of standard</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Toby,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The issues you raised are&nbsp;spurious =
-&nbsp;nothing has
changed regarding the requirement to provide a&nbsp;SOAP/WSDL binding =
for
oBIX.&nbsp; Chapter 13 is tagged to cover the SOAP binding.&nbsp; The =
term REST
is used as an architectural pattern which is fairly orthogonal to =
protocol
bindings.&nbsp;&nbsp;&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Brian</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

<blockquote style=3D'border:none;border-left:solid black =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt=
'>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>----- Original Message ----- =
<o:p></o:p></span></font></p>

</div>

<div style=3D'font-color:black'>

<p class=3DMsoNormal style=3D'background:#E4E4E4'><b><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <a
href=3D"mailto:Toby.Considine@unc.edu"; =
title=3D"Toby.Considine@unc.edu">Considine,
Toby (Facilities Technology Office)</a> <o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>To:</span></font></b><font size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'> <a
href=3D"mailto:'obix-xml@lists.oasis-open.org'"
title=3D"obix-xml@lists.oasis-open.org">'obix-xml@lists.oasis-open.org'<=
/a> <o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Cc:</span></font></b><font size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'> <a
href=3D"mailto:'obix@lists.oasis-open.org'" =
title=3D"obix@lists.oasis-open.org">'obix@lists.oasis-open.org'</a>
<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Sent:</span></font></b><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'> =
Tuesday, April 19,
2005 11:09 AM<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Subject:</span></font></b><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'> [obix] =
Issues with
0.7 draft of standard<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span style=3D'font-s=
ize:11.0pt;
font-family:Verdana'>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 &quot;Control Interface for the =
<st1:place
w:st=3D"on"><st1:City =
w:st=3D"on">Enterprise</st1:City></st1:place>&quot; to being
&quot;traditional control protocol with angle brackets&quot;. 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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>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 &quot;angle brackets in the control =
stream&quot;. It
fails, though in several important ways:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>1)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>WSDL
does not support REST, either 1.1, 1.2, or =
2.0.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>2)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>REST is
not composable, breaking one of the two basic principles of Web =
services<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>3)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>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. &nbsp;HTTPS is *<b><span =
style=3D'font-weight:
bold'>not</span></b>* 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.<o:p>=
</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>4)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>5)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><st1:place
w:st=3D"on"><st1:City w:st=3D"on"><font size=3D2 face=3DVerdana><span =
style=3D'font-size:
  =
11.0pt;font-family:Verdana'>Enterprise</span></font></st1:City></st1:pla=
ce><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>
developer tools do not handle or support REST. <st1:place =
w:st=3D"on"><st1:City
 w:st=3D"on">Enterprise</st1:City></st1:place> developers are tool =
users, at
least in all enterprises that reward provable code, predictable =
delivery dates,
team development, and programmer =
productivity.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>6)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>7)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>REST
violates extensibility, because REST parameters cannot distinguish =
between
parts of the message that the recipient &quot;Must Understand&quot; 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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>8)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>9)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l8 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;font-family:Verdana'><span
style=3D'mso-list:Ignore'>10)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana'>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)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in'><font size=3D2 =
face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana'><o:p>&nbsp;</o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>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:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<ul style=3D'margin-top:0in' type=3Ddisc>
 <li class=3DMsoNormal style=3D'mso-list:l6 level1 lfo5'><font size=3D2 =
face=3DVerdana><span
     style=3D'font-size:11.0pt;font-family:Verdana'>information is =
public and
     encryption/authentication are unnecessary; =
<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l6 level1 lfo5'><font size=3D2 =
face=3DVerdana><span
     style=3D'font-size:11.0pt;font-family:Verdana'>nothing terribly =
bad happens
     if a message is lost or duplicated; <o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l6 level1 lfo5'><font size=3D2 =
face=3DVerdana><span
     style=3D'font-size:11.0pt;font-family:Verdana'>there are few =
demands for
     multi-part transaction management beyond what can be implemented =
with HTTP
     sessions or cookies;&nbsp; <o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l6 level1 lfo5'><font size=3D2 =
face=3DVerdana><span
     style=3D'font-size:11.0pt;font-family:Verdana'>There are no =
requirements for
     any transport other than HTTP</span></font> <font size=3D2 =
face=3DVerdana><span
     =
style=3D'font-size:11.0pt;font-family:Verdana'><o:p></o:p></span></font>=
</li>
</ul>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>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. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>Web services toolkits&nbsp;are oriented toward use =
cases
that demand high-security, support for existing enterprise messaging sys=
tems,
message failure is not an option, and industrial-strength transaction
processing is assumed.&nbsp; The REST approach assumes that all these =
features
are provided at the application level rather than being provided by the
infrastructure.&nbsp; 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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>Overall, this is retreating from the =
document-based
transfer model of Web Services to the old-fashioned API. An API method =
looks
like<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana'>Function fnAPI( float =
par1, string
par2, date par3)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>Each part of the API must be known and understood =
by the
end point. A Web Services method tends toward something =
like<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DVerdana><span
style=3D'font-size:11.0pt;font-family:Verdana'>Function fnService( =
document doc1)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>In the WS-Interoperability spec =
(http://www.ws-i.org/),
this argument is summarized&nbsp; in the WS-I Basic Profile by =
specifying
document/literal as the preferred style of communication. RPC/literal =
is also
supported but deprecated.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>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 &quot;must
understand&quot;; others can be marked as optional. Any ERP that =
understands
the &quot;must understand&quot; part can accept the entire request. =
This
flexibility, which the enterprise expects, is tossed out entirely by =
the move
to REST.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>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:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><a
href=3D"http://www.webservices.org/index.php/ws/content/view/full/39565"=
>http://www.webservices.org/index.php/ws/content/view/full/39565</a><o:p=
></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><a
href=3D"http://www-128.ibm.com/developerworks/webservices/library/ws-soa=
-enter2/">http://www-128.ibm.com/developerworks/webservices/library/ws-s=
oa-enter2/</a>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><a
href=3D"http://www-128.ibm.com/developerworks/webservices/library/ws-sam=
ruby.html">http://www-128.ibm.com/developerworks/webservices/library/ws-=
samruby.html</a>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><a =
href=3D"http://www.w3.org/TR/ws-arch/";>http://www.w3.org/TR/ws-arch/</a>=

<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>A quick Google of SOAP and REST will find many =
more
contentious versions.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>In short, if the charter of oBIX is to bring =
Controls
Systems to the <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Enterprise</st1:City></st1:place>,
it fails if it moves to REST.&nbsp; <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span =
style=3D'font-size:11.0pt;
font-family:Verdana'>tc<o:p></o:p></span></font></p>

<p><font size=3D2 face=3DCourier><span =
style=3D'font-size:10.0pt;font-family:Courier'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span></font>
<br>
<font size=3D2 face=3DCourier><span =
style=3D'font-size:10.0pt;font-family:Courier'>Toby
Considine&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</span></font> <font size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&quot;Do
the right thing. It will</span></font> <br>
<font size=3D2 face=3DCourier><span =
style=3D'font-size:10.0pt;font-family:Courier'>UNC
Chapel Hill&nbsp;&nbsp;&nbsp;&nbsp; !</span></font> <font size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>gratify
some people and </span></font><br>
<st1:place w:st=3D"on"><st1:City w:st=3D"on"><font size=3D2 =
face=3DCourier><span
  style=3D'font-size:10.0pt;font-family:Courier'>Chapel =
Hill</span></font></st1:City><font
 size=3D2 face=3DCourier><span =
style=3D'font-size:10.0pt;font-family:Courier'>, <st1:State
 w:st=3D"on">NC</st1:State></span></font></st1:place><font size=3D2 =
face=3DCourier><span
style=3D'font-size:10.0pt;font-family:Courier'>&nbsp;&nbsp;&nbsp;&nbsp; =
!</span></font>
<font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>astonish
the rest.&quot;</span></font> <br>
<font size=3D2 face=3DCourier><span =
style=3D'font-size:10.0pt;font-family:Courier'>Phone
(919)962-9073 !</span></font> <br>
<font size=3D2 face=3DCourier><span =
style=3D'font-size:10.0pt;font-family:Courier'>Fax
(919)962-1102&nbsp;&nbsp;
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</spa=
n></font>
<font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>--Mark
Twain</span></font> <br>
<st1:PersonName w:st=3D"on"><font size=3D2 face=3DCourier><span =
style=3D'font-size:
 =
10.0pt;font-family:Courier'>tobias@fac.unc.edu</span></font></st1:Person=
Name><font
size=3D2 face=3DCourier><span =
style=3D'font-size:10.0pt;font-family:Courier'>&nbsp; !
</span></font><br>
<font size=3D2 face=3DCourier><span =
style=3D'font-size:10.0pt;font-family:Courier'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span></font>
<o:p></o:p></p>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C545C2.8E5F7640--


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]