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

Most excellent.

On Wed, Feb 12, 2003 at 10:01:31PM -0800, dorchard@bea wrote:
> 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.

I guess I don't know what you mean by "stateless connections" then.  The
description you provided, "where all the[sic] data for a given request
must be in the request", sounds a lot like the stateless constraint that
Roy describes;

  "each request from client to server must contain all of the
   information necessary to understand the request"
   -- http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

If it was intended to be the same, then you're incorrect in that last
sentence; it's exactly the same thing.  If the session identifier (the
identifier itself, not what it resolves to) is insufficient information
in order to understand what the message means, then the interaction is
not stateless, since it's taking advantage of stored context elsewhere
(in particular, what the URI resolves to - just as it is with cookies,
though they're not URIs (but could be)).

And earlier you stated;

"I would say that web services architecture allows for stateless web
services."
 -- http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0084

Could you please clarify?  Thanks.

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

I disagree that SOA uses representations, as we've been discussing on
xml-dist-app.  I request that you take it up with Roy if you don't
believe me.

>  SOA
> uses application specific vocabularies as the engine of application state,
> rather than hypermedia.

Right.

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

I don't understand that last part, "intermediary resource with an
identifer".

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

GET support isn't a requirement of REST, it's just one of those "well why
wouldn't you?" things.

I suggest snipping the "does not support GET" part.

> and even embeds the equivalent of GET inside a POST
> request.

Right.  Bad juju.

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

Not at all, as I've attempted to explain in the other thread.  I won't
go into it again here.

Perhaps we can just not include this part, since it's a bit off-the-cuff
anyhow, and it doesn't seem to be critical to explaining the SOA style
which should be the primary objective of this text.  Which gives me an
idea ... what about breaking this out into two sections, one that
focuses just on SOA, and another that compares REST and SOA?

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

Right.

>  The first, identified with a URI, is a
> gateway resource.

"gateway" has a specific meaning in this context (see our glossary) that I
assume you didn't mean to invoke.  I just call those resources
"processors", and I'd recommend that any adopted text do the same.

>  The second, not identified with a URI and not on the web,
> is hidden from the web by the first URI.

I don't believe it's particularly useful to talk about being "on the Web",
or "hidden from the Web", unless those terms are defined.  I can certainly
understand your position, and we probably agree about it, but others may
not, and the implications of that are unclear unless definitions are
provided.

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

Ok, but I'm not sure I understand why that's important, since you're
only talking about response messages.

> The Service-centric SOA has the advantage of protocol independence.

I'm not sure this belongs here.  REST isn't HTTP-specific, and as such
isn't dependant on it, the same way that "SOA", in general, is not
dependant upon SOAP.

If you meant that an architecture that was an instantion of the SOA
style is "protocol independant", whereas the Web (as an instantiation of
the REST style) was dependant upon HTTP, I'd also disagree.  The Web
is protocol independant in different ways; via negotiation, tunneling,
and abstraction.  By "negotiation" I mean bootstrapping upon HTTP's
Upgrade feature.  By "tunneling" I mean sending another protocol through
HTTP, be it via CONNECT or by tunnel-via-a-method.  By "abstraction" I
mean the capacity to build a proxy to other protocols, such as how your
browser makes FTP transfers behave like HTTP transfers.

I don't think any of that needs to go in the arch doc though, since
it's talking about the advantages of REST, not SOA. 8-)

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

I have to disagree there.  I've yet to see a SOA app that wasn't far
simpler to develop than a REST based app.

>  There may be higher Network
> Performance as the representations could be for multiple services.

I don't understand that.

Also, if you want to talk about Web services as an instantiation of
an SOA from a performance perspective, there's a critical issue to
consider.  XML, due to its deterministic failure model, drastically
increases real and perceived latency for message processing.  i.e. a
SOAP processor isn't technically allowed to do any work until it sees
"</env:envelope>", which in large messages (or streams!), may be a long
time arriving.

> Constructing some types of applications may be simpler using Service-centric
> SOA.

I guess I can't argue with that one, but I'm not sure what value it
adds.  Constructing some types of apps may be simpler using rubber
bands and thumb tacks too. 8-)

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Thursday, 13 February 2003 10:05:37 UTC