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

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