SOFEA, a flawed approach to a presentation architecture

I'm doing a bit of research into presentation technologies for use in J2EE apps, with accessibility as a particularly key requirement, and an eye on SOA, and extensibility (porlets or not?), among other things. I ran across a year-old article on TSS about a white paper and blog by Ganesh Prasad, Rajat Taneja and Vikrant Todankar.

The basis of the article is that for the purposes of the presentation layer, the architecture should consider three elements, application download (which may be loading a web page, or downloading a rich client), presentation flow, and data interchange. They essentially argue that these must all come together in the client, thus reconciling the thick-vs-thin client camps by effectively defining server-side control of presentation as an anti-pattern called Front Controller.

I tend to agree with two of the commenters on the TSS article, Keith Weinberg and Ivan Smirnov, in that SOFEA is an approach which works in some circumstances, not all.

Actually, I would say the conceptual split between application, presentation, and data defined by the SOFEA paper is fine and useful, a slightly different approach to describing MVC. But the authors are quite insistent that the MVC can only live in the browser using AJAX or else an actual thick client. This is an arbitrary definition which, if followed dogmatically, means SOFEA is useless in a number of situations, including my own.

The number one reason is accessibility, which I mentioned above as a requirement. SOFEA requires all users to use a browser which fully supports the flavour of AJAX used by the application, which cuts out a number of devices and browsers (most mobile phones, for instance, and screen readers) and users in locked-down IT environments.

The power of assembling the presentation on the server-side is that it can be delivered to a broad range of devices. I don't quite buy the idea (as the SOFEA authors responded to the above posters) that the presentation sitting anywhere but the browser automatically classifies it as an anti-pattern. The browser is an arbitrary place to draw the line, if the architecture of an application joins the application, presentation, and data following a "good" design pattern, the fact that it does so on computer A rather than computer B is irrelevant.