February 16, 2003

Response to Mark Baker's comments on my Architecture Styles presentation

As promised, here is my response to Mark Baker's comments on my Architecture Styles presentation:
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.
That�s not how I read the literature in this area, but I would love to have some more specific pointers on this topic.

I think our opinions may diverge significantly because of this point, but it's worth further discussion.

Slide 12, "Two main types of distributed software systems". This distinction seems quite arbitrary to me, and a superficial distinction at best.
I think I need to elaborate on this point some more in the next revision.
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.
I think it�s time to drop the term RPC from this presentation, as people have too many pre-conceptions as to what it means. I was using it here in its most generic form � a request containing input data parameters and returning output data parameters.
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?)
But MTS is NOT an object-oriented interaction style in its pure (original) form � request messages are sent to an �endpoint� and the server infrastructure works out which implementation instance to use to execute the request based on things like activation policies. The likes of COM+/DCOM added a real object-oriented request style to allow stateful communications with particular object instances, and this got bolted on to MTS in a bastardized and wholly inappropriate form IMHO.

So, I believe my assertion is still perfectly correct - Object-oriented architectures ARE implicitly stateful.

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.
The example of a row in a SQL DB is still an equally valid �resource� in my mind � you can address it with a query term (a SQL query, not a URI), and you get back a (detached) copy of the resource data.

To me, resource-oriented architectures are not necessarily REST, but REST is a resource-oriented architecture.

I think this is a big discussion topic that needs closer examination, so I am spinning it out into a separate topic.

Slide 21, Resource Oriented 3. POST isn't for "partial updates", it's for triggering the "behaviour" part of identity/state/behaviour.
Well Mark, in your notes about "How Containers Work, or when do I use PUT vs POST" you make the comment:
"POST's job is simply to add something to a container."
That sounds awfully like a "partial update" to me!

Also any �behavior� that accepts as input only part of the resource data and updates the master copy must have the semantics of a "partial update" much like a SQL UPDATE command.

However, I take your point Mark � a POST is not just for "updates", but can perform some other arbitrary "behaviors" too. This is a point I had missed about REST, so I am starting to see some of the real flexibility in the REST approach you keep enthusing about.

I need to clarify this point some more in the text.

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.
�Absence of evidence is not evidence of absence� as they say ;-)
I think your claim is only valid in your eyes, Mark, because you discounted my SQL DB example above, which I claim is still perfectly valid!
Anyway, this topic needs closer examination.
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.
The endpoint itself IS completely stateless � it can handle any number of requests for any number of different operations and services simultaneously, and knows nothing about the previous / next request to be handled for each. How the service endpoint dispatches requests to the particular handler object instance is undefined and typically based on activation policies.

This is entirely consistent with the assertion that service oriented architectures are �state neutral� � they can be either stateful or stateless depending on how the dispatching algorithm is configured.

The point is that it is the server that makes this decision, not the client.

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.
And there was I thinking this statement would be an olive branch for you, Mark ;-)

I don�t think the SOAP 1.2 / WSDL 1.2 Working Groups would agree with your comment here, because I believe this is their attempt to include RESTful SOAP in the specs AFAIK.

I still don�t see any real conflict � you can still have requests returning XML data, the only question would be whether the request data must be in XML format or whether it can be encoded into a URL/URI. I am fairly sure the intent is to not preclude the use of pure URI-based requests in SOAP 1.2 / WSDL 1.2.

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.
You can use Web Services standards and do pure REST.
Equally you can use Web Services standards and _not_ do REST.

For me, Web Services embrace both service-oriented and resource-oriented approaches.

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.
I think I will restate this to say that:
�The successful use of resource-oriented approaches revolve around the cacheability of resource data.�
Fundamentally, cacheability IS a big factor as the client implicitly caches a local copy of the resource data at least for a time.
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.
I am not sure Roy Fielding�s dissertation would agree with your assertions here, Mark � see bottom of page 14:
�Since architectural styles may address different aspects of software architecture, a given architecture may be composed of multiple styles. Likewise, a hybrid style can be formed by combining multiple basic styles into a single coordinated style.�
I guess the important phrase above will be "preserve the constraints", which brings us right back to the start point I think - is an architecture style an "interaction pattern" or a "pattern language" for constraints and principles.

I don't think mixing architecture styles necessarily nullifies any constraints on any of the individual styles, but ultimately the discussion will depend on how we answer Question 1 above.

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).
SCORE/SCOUT2 can support the generation of a variety of architecture styles from a common meta-model - all based around the MDA (Model Driven Architecture) specs from the OMG. SCORE/SCOUT2 generally work at the PIM (Platform Indipendent Model) level, and can generate any number of PSM (Platform Specific Models)

Sure you still have to choose which of these PSMs to enact, but products like this are based on the ability to mediate and bridge between styles and approaches in as flexible a manner as you can construct code templates for.

Having said that, this topic is somewhat tangential to the overall theme of the presentation, so I will probably drop it as it is already tight on the time limit for the slot.

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.
Sure a presentation like this will always need more work � life and learning are always a �work in progress� after all.

I am giving it again in April so will be updating it for then with the feedback I receive. As part of the review for April, I will look at the linkages back to the original points in the introduction as you suggest, although slot time is a significant restriction.

I appreciate the feedback Mark, and am attempting to take it on board because I think this is an important topic for Architects everywhere.

Entry categories: Architecture Presentations
Posted by Jorgen Thelin at February 16, 2003 02:00 PM - [PermaLink]
Traceback List
MT: It just works (and it's in Perl)
Excerpt: In the middle of scanning some weblogs (by the way, there's a excellent set of exchanges going on between Mark Baker, Jorgen Thelin and Werner Vogel at the moment about
Weblog: Bill de hÓra
Tracked: February 20, 2003 12:47 AM
Is REST the SQL of the Internet?
Excerpt: In discussions with Mark Baker on my Architecture Styles presentation, I raised the question of whether REST and SQL could be grouped together into what I termed a "Resource-oriented" architecture style. I can see many similarities between the two appr...
Weblog: TheArchitect.co.uk - Jorgen Thelin's weblog
Tracked: March 4, 2003 02:47 PM