RE: Introducing the Service Oriented Architectural style, and it's constraints and properties.

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