Jorgen points to a presentation he’s giving at an OMG Workshop 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 behaviour.

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, they say 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.