Sean McGrath asks in a recent article whether the complexity of frameworks like J2EE and .NET is necessary and uses, as a counter example, the web itself as an example of something that is elegant and simple, yet very scalable. This question is at the heart, I think, of the arguments made by the RESTians. The question caught my eye because I was having a conversation with a few of my student yesterday after class about a very similar topic.
Each year, when I teach my class on building large scale distributed systems there is, of course, much more to cover. If I'd taught the class in 1994, we'd have had lectures on HTTP, CGI-BIN, transaction monitors, and CORBA. Now that isn't even one-tenth of the material that could be covered. I've struggled in past years as to how to get messaging worked in and this year I did force an XML assignment into the mix. I would love to have had time to dive into SOAP, WSIL, etc. No such luck. It seems that the body of knowledge that a person building web-based transactional systems needs to know is exploding and the pace is not abating.
Even so, I think I'd have to disagree with Sean's basic premise: "If you look after simplicity, then with the aid of some analysis and precise intervention, scalability will look after itself." I disagree because scalability in almost all cases involves distributed programming. My experience with distributed programming (which began with the SR programming language in 1987) is that it is complex and difficult to do in a way that delivers performance under high load. Threads and transactions are inherently complicated. You can't abstract away resource contention and deadlock. The basic web has none of these problems because it was (and still is for the most part) a read only system. The mutating parts are still localized which is where you see things getting complicated. REST or not, mutation and scalability lead to complexity.
Having been involved in the development of large transaction based system using CORBA and a prayer and then doing similarly sized systems in J2EE, I contend that these frameworks are lifesavers. They do about as good a job of abstracting away some of the hard parts as you could expect. Where I would have had 5 or 6 engineers chasing down failover, distributed transactions, etc. and failing, I can have 1 or 2 and succeeding.
