- From: Assaf Arkin <arkin@intalio.com>
- Date: Sat, 15 Feb 2003 16:32:53 -0800
- To: "dorchard@bea" <dorchard@bea.com>, <www-ws-arch@w3.org>
David, Great summary of the differences, and I definitely agree with everything said in the first part of the e-mail. I have one question regarding the following distinction: > 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. I cannot imagine a cache engine that will look at the body of the POST message to determine what information to cache, so I would tend to agree that for caching purposes using GET is a better approach. However, if my input message only contains an identification of a resource (in addition to identifying service outside the message) and such identification can be encoded as a parameter in the URL of the HTTP request, I could allow a cache engine (and other technologies) to manage access to that resource. If I choose to use protocol bindings for HTTP GET with URL encoding of the service identifier and resource identifier, am I selecting RESTful SOA as opposed to Service-centric SOA, or am I using Service-centric SOA in a manner that allows the cache to exert more control over messages? Another issue concerns firewalls. Practically speaking controlling individual access to URLs at the firewall level is impractical. Firewalls only work well when there is a coarse-grain identification of services, e.g. a partial path in the URL, or path withour parameters. From a practical perspective using HTTP GET as opposed to HTTP POST does not buy me much. In both cases I would manage access to the service and not the resource, and the portion of the URL identifying the service could be identical. If I understand that all URLs are opaque then I can only control access to the TCP port. On the other hand, if I understand that the URL is a combination of service and resource identifier and given the encoding rule can determine which part of the not-so-opaque URL identifies the service, I can control access at the service level. It seems to me that a service + resource identification encoded in an HTTP GET URL would work well with both cache and firewall, a service identification for HTTP POST would work well with URL but would not allow caching, and a resource identification in HTTP GET URL would allow caching but not fine-grained firewall access control. arkin > > Cheers, > Dave
Received on Saturday, 15 February 2003 19:34:08 UTC