[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 "telnet" and "mailto" = 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 "web service" 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"'> = </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"'> = </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"'> = </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"'> = </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 "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 <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 "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.<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 = "SOAP" actually stands for "SOA = Protocol".<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 "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:<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"'> = </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"'> = </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> </= 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"'> = </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> </= 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> </= 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> </= 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'>"Is minic bhris beal an duine a shron.."<br> </span></font><font color=3Dblue face=3D"Courier New"><span = style=3D'font-family: "Courier New";color:blue'> </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.."<br> = = 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 &nb= sp; | Phone (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 | Fax (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> | </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; | <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> </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'> <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 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. </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'> <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'> <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> </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 "Control Interface for the = <st1:place w:st=3D"on"><st1:City = w:st=3D"on">Enterprise</st1:City></st1:place>" 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.<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> </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> </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 "angle brackets in the control = stream". 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> </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"'> = </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"'> = </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"'> = </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. 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"'> = </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"'> = </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"'> = </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"'> = </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 "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.<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"'> = </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"'> = </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"'> &nbs= p; </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> </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> </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> </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; <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'> <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> </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 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. 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.<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> </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> </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> </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> </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> </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 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> </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> </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 "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.<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> </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> </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> </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> </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> </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> </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> </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. <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> </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 !</span></font> <font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt;font-family:"Courier New"'>"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 !</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'> = !</span></font> <font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt;font-family:"Courier New"'>astonish the rest."</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 ! </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'> ! </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]