- From: dorchard@bea <dorchard@bea.com>
- Date: Wed, 12 Feb 2003 22:01:31 -0800
- To: <www-ws-arch@w3.org>
I am proposing the following text for the Web Services Architecture document. I have attempted to define a "service oriented architecture" style, in the context of Roy's thesis, and talk about the properties of this style. I plan to follow up this with the scenarios of different styles of construction to illustrate these assertions about properties of the styles. Properties For the purposes of this document, the properties used will be those defined in Dr. Roy Fielding’s thesis, chapter 2. To summarize, they are: Performance (User Perceived and Network), Scalability, Simplicity, Modifiability (Evolvability, Extensibility, Customizability, Configurability, Reusability), Visibility, Portability, Reliability. Architecture Style In addition to the styles described in chapter 4 of Dr. Fielding’s thesis, and the REST style introduced in Chapter 5, this document introduces “Service Oriented Architecture”. SOA’s are described regularly in literature. This document will describe SOA in relation to Dr. Fielding’s thesis. An SOA is a derivation of the Layered Client Server style (3.4.3). It adds the constraint of stateless connections, that is where the all the data for a given request must be in the request. This is different from stateless in that a stateless connection could have a session ID that a server uses to connect the request to the appropriate session. REST provides a generic interface through 4 particular constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. SOA uses the first 3 constraints, that is it uses URIs, it manipulates resources through messages containing representations, and self-descriptive messages. SOA uses application specific vocabularies as the engine of application state, rather than hypermedia. Most importantly, SOA allows for resources to be modeled as Services. That is, it is possible and probable that a SOA service will not expose the resource directly via a URI, but will use an intermediary resource with an identifier. We are faced with a very interesting technical conundrum in this description however. I probably won’t describe this very well, but here goes. It is certainly possible for a Web service to be non-REST compliant. That is, it does not support GET, and even embeds the equivalent of GET inside a POST request. However, it is fact that the Web carries messages that contain Representations. So how can a Web service both: 1) non-REST compliant and 2) exchange representations? These seem to be in contradiction. The reconciliation is that a SOA service may not be “on the web”. Being “on the web” is about supporting a generic interface to a URI, particularly the HTTP GET method for http: schemed uris. And this is completely consistent with the web as it currently exists. An HTML page that is a result of a POST is a representation of the status of a Resource. But that resource is not identified with a URI (you can’t do a GET on it). The URI that the form is POSTed to does NOT identify the resource that the web page represents. There are 2 resources in play. The first, identified with a URI, is a gateway resource. The second, not identified with a URI and not on the web, is hidden from the web by the first URI. There is a decoupling of the resource identifier from the resource that the form data is sent to. Typically the resource identified by the URI is a gateway of some kind. And this is completely acceptable to REST. Nobody in the world has suggested that the Web is broken because FORM POST URIs are not directly accessible via browsers. We still consider the form result to be a web page. Thus we can consider the result of a SOAP POST to be a Web service message with a representation, yet not “on the web”. SOA has two derivations: RESTful SOA, where the service is modeled with the representations exchanged through direct manipulation of the resource identifier, and Service-centric (maybe gateway would be a better name) SOA, where the service is modeled with representations exchanged through an intermediary identified by the resource identifier. A classic example of service-centric service is the “getStockQuote” in the HTTP POST body. There are other examples, as described in the SOAP 1.2 primer, that show better examples of service-centric services than the infamous getStockQuote example. This distinction does not differentiate between WSDL or non-WSDL defined styles, as that turns out to be orthogonal to the styles. That is, Web pages and Web services can both be described by WSDL, and both are possible without WSDL. The RESTful SOA has the advantage better visibility, as the firewall can simply examine the generic interface to determine the action being performed. Intermediaries, such as HTTP routers or caches, can simply look at the method. An example is that a cache can look at the GET and the identifier, and return a cached representation. This is much more difficult if the method is in arbitrary places in the POST. Re-usability can be higher as the service may be available on the Web as a URI may be transferable. The Service-centric SOA has the advantage of protocol independence. There are limitations to HTTP that can be ameliorated by the use of SOAP. In cases of Service-oriented applications, such as messaging systems, it is easier to build applications in an SOA style. There may be higher Network Performance as the representations could be for multiple services. Constructing some types of applications may be simpler using Service-centric SOA. Cheers, Dave
Received on Thursday, 13 February 2003 01:03:57 UTC