The Lost Art of Separating Concerns
In a short article, Mark Baker claims the default approach to SOA development fails to properly separate concerns, and describes how this is different in Web architecture. (More at InfoQ.)
When I discussed the article with Mark, one of my comments was this:
If I put on my WSDL-defending hat (which is quite hard for me these days), this doesn’t convince me. Changing from real time to delayed is not an implementation, but an interface change.
To Mark, this is clearly an implementation change, so he asked whether I was really serious. My reply was
Yes, that was intentional. The question is what, exactly, constitues semantics. If “result contains stock value at time of request +/- 10 seconds” is the postcondition, delayed vs. realtime becomes part of the operations semantics. Putting information about non-syntactical aspects into the operation name is a valid strategy. Isn’t it?
I remember Jacek Kopecky using “add” vs. “substract” as an example - if the operation is just called “calc”, how do you know what to do when “calc(2,2) is called?
If I understand your goal correctly, you want to convince those who aren’t already convinced. I’m just trying to anticipate what some of them might say :-)
Looking at the comments, it seems I anticipated correctly :-)
Yup, good call. It’s rather ironic that the more I incorporate the Web into my way of thinking, the harder it becomes to think or explain things in terms that SOA/CORBA/DCOM folks can relate to.
Of course the “right” way to partition systems (whether social, technical, etc) is a difficult problem that we have been struggling with since the early days of mankind. I don’t think we’re any closer to a major breakthrough here. In fact, in IT we probably haven’t learned much since Parnas. Heck, most people in IT these days have probably never heard of or read Parnas!
But I’m not sure that Mark is correct in saying that his proposed interface is “maximally general”. Why not take the argument a step further and remove the semantics of GET (plus PUT/POST/DELETE) from the interface as well? Surely we only need one verb: EXECUTE; all else will be implementation nouns. Won’t this be a superior design?
-Mike.
Of course EXECUTE or doIt() would be the maximally general interface — with the downside that the infrastructure cannot distinguish between reads and writes, and thus cannot be optimized e.g. for caching. GET, PUT, POST and DELETE are actually compromises, sort of methods with “generic meaning” - whatever your resource is, it’s likely that these operations are shared among them.
Yeah, but I’m not sure how useful the HTTP caching model really is as we move from a predominantly read-only web to one where reads and writes are more equally balanced.
Consider a REST version of the common applications supporting the day-to-day transactions of most businesses (SAP, Oracle, etc). Updates to core business entities such as “customer”, “product” and “order” happen frequently but irregularly during the day. Unless the data is modelled in third normal form (or higher), updates to one entity might also affect the other (e.g. order modification affecting product stock on-hand quantity). With the crude HTTP caching mechanism (“Cache-Control: max-age” and “Expires”) and lack of a system providing consistency or transactional integrity between individual HTTP operations (e.g. inspecting “product” separately from “order”), I suspect the only way to deliver a useful system is to disable caching entirely.
And who says that GET, PUT, POST and DELETE are the only common and useful verbs? Surely that depends on your conceptual model and assumptions about the system you are describing?
I believe that the REST folks are in danger of making a category error in considering the web as a complete and universal information system. As I’ve said before, the current web deals with largely read-only information and is in fact a fairly simple set of intermediaries, not information endpoints. Now we are starting to consider the real requirements for these endpoints, I suspect the simplicity of the REST model will break down and we’ll find a lot more common verbs and other requirements not satisfied by the current web.
For example, it appears that the REST guys are adding the verb set from WebDAV also (which incidentally could help to solve some of the data integrity problems described above, if clumsily). This is only the beginning…
-Mike.
Mike: As usual, all valid points. I’ll address them in a new post.