Jorgen points to a
presentation he’s giving at an
comparing Service Oriented, Resource Oriented, and Object Oriented architectural styles.
This is somewhat similar to my REST Compared
presentation, though mine was done at a lower level.
I’ll jot down some comments here as I read it.
Slide 10, “In other words, architecture styles are design patterns for the
structure and interconnection within and between software systems.”. Sort of.
Architectural styles are pattern *languages*, not just patterns.
Slide 12, “Two main types of distributed software systems”. This distinction
seems quite arbitrary to me, and a superficial distinction at best.
Slide 13, Request/Response systems. Here, an association is asserted between
request/response and RPC. I consider those entirely orthogonal issues. I know RPC systems
which aren’t request/response (e.g. Orbix+Isis), and I know of request/response system
which aren’t RPC (HTTP). Perhaps it’s just a terminology issue, not sure.
Slide 16, Object Oriented 1. “Communications are implicitly stateful”; I don’t
think that’s the case. Some are, like EJB/CORBA, but some aren’t, like MTS/COM (or
whatever it’s called now; Biztalk?)
Slide 19, Resource Oriented 1. I wouldn’t include SQL here, since it’s not
resource centric. If you wanted to create a “data oriented” super category,
then you might include it and resource-oriented, and file-oriented (FTP), etc..
in there. It also says that resources have state and identity, as if to suggest
that they don’t have behaviour like objects. That’s not the case, they do have
Slide 21, Resource Oriented 3. POST isn’t for “partial updates”, it’s for
triggering the “behaviour” part of identity/state/behaviour.
Slide 22, Resource Oriented 4. “Resource Oriented” is not an architectural
style. REST is the only resource oriented architectural style I know about,
though any REST extension would also be so. I suspect that any resource
oriented architectural style will be either REST, or a REST extension like
the Semantic Web, or ALIN.
See also slide 24.
Slide 23, Service Oriented 1. “Communications are implicitly stateless (all
requests are sent to the same service endpoint)”. That reason doesn’t have
anything to do with stateful/statelessness, AFAIK. If it was meant that the
message is sent to the same in-memory object, then that would be implicitly
*stateful*, as knowing what “the same” is requires a memory between invocations
on the server, and that memory is state. From the discussions I’ve had with
Web services proponents,
that service oriented architectures are state neutral; they can be stateful or stateless.
Slide 28, Web Services vs. REST 1. “There is no real conflict between the
general idea of Web services and the REST approach”; excuse me?! 8-O There is
a fundamental and inescapable conflict between the two. They cannot peacefully
co-exist. That Web service definition you quoted is completely
incompatible with the REST architectural style. End of story.
Slide 29, Web Services vs.REST 2. “The total set of Web services specifications
provide a superset of the REST approach”. Absolutely true. Yet by doing this –
creating a superset – most of REST’s important architectural constraints are
obliterated. A superset (in this sense of the word) of REST is not REST. Architectural
styles combine via constraint intersection, not union.
Slide 32, “Choosing Between Architectural Styles”. Resource oriented styles
don’t revolve around cacheability. That’s a small part of the advantages of the
style. There is nothing that is read-only/mostly/idempotent specific about its
style. It’s simply optimized for coarse grained data transfer, like document based
service oriented styles, only more loosely coupled via late binding. Anyhow, even
if you disagree, you should at the very least try to defend that position; there’s
nothing in there that does that.
Slide 33, “Combining Architectural Styles”. See slide 29 comment above.
You cannot combine styles in this way, and hope to preserve the constraints
that are giving you your desired properties … which brings me to a general
point about this presentation; despite the very a propos snippets up front
from the likes of Fowler, Shaw, Kazman, etc.., very little of that experience
appeared to be reused in the rest of the presentation. For example, I would
have expected the presentation to talk about the architectural properties
of each of the styles presented, and extract from that the domain of applicability.
Slide 34, “How to avoid the Choice of Style”. Yikes. As Neil Peart wrote,
“If you choose not to decide,
you still have made a choice”. This is a recipe for failure. Even SCOUT2
assumes an architectural style, though a mostly constraint-less one (which is
a bug, not a feature).
In general, I had high hopes for this, but with all due respect to Jorgen,
it needs a lot more work. Not only does it misrepresent the value of the
approaches represented without backing up its claims, but it evaluates them
in a context very different from the one accurately(!) described in the first
few pages by the gurus of the field of software architecture.