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

Assaf,

Thanks for the support, and excellent questions!  Comments inline.

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Assaf Arkin
> Sent: Saturday, February 15, 2003 4:33 PM
> To: dorchard@bea; www-ws-arch@w3.org
> Subject: 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.
>

Are you suggesting a scenario where there's a URI and an effectively empty
POST request?  The problem is that how can you cache that?  You'd have to
somehow mark the POST as being idempotent, so that the cache would know that
it didn't have to get a response from the resource.  That's exactly what GET
does.  I think the key part of the GET semantic that's explicit in 2616 is
that the GET is idempotent, therefore caches can do their mojo.

> 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?
>

I would say that you are using RESTful SOA.  I still don't think that
"RESTful" is the right term, I'm still struggling.  It's something more like
"Direct manipulation of Resources" instead of "indirection manipulation".
That is, if you indirectly manipulate a resource, there's too many variable
places for the "real" resource/service identifier to be in the message for a
proxy to figure out whether it can cache, etc. the representations.

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

Fair enough.  I should probably say something like "Security intermediary".
I was thinking of authentication servers as well.

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

Aha...  So URLs are opaque to the consumer, that is don't make any
assumptions.  But URLs can certainly be non-opaque to the URL provider.
There are many reasons, particularly partioning of the security realms, and
simplicity in application development (like /en and /fr subtrees), for doing
this.

I still think we( web services community) should come up with some best
practices on how to structure URIs wrt WSDL, to make it simpler for security
and application deployment...  But separate area of discussion.

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

I'm not quite following, I can't quite picture the URLs.  I'm working on a
few different scenarios to show these two styles, maybe that will help with
these - not quite darned ready to post yet..

How would the service identification be different that the resource
identification?  Taking your first and third scenarios, is the difference
between these that the service identifier (say the nefarious getStockQuote)
is part of the URI in the first case, and not part of the URI in the second
case?  The URLs might like something like:
/stockservice/getStockQuote?symbol=BEAS and /stockquote?symbol=BEAS.  If
this is right, I'm not sure that you can do a cache of the 3rd result,
because the service identifier (stockPriceServiceHighPayingCustomer or
stockPriceServiceFreebieMoocherCustomers) would have to be inside the
message somewhere, so the cache wouldn't know which representation to
return.  Or did I put the service identifier in the URI and not the
resource? :-)

Cheers,
Dave

Received on Monday, 17 February 2003 15:23:59 UTC