RE: Life above the Service Tier
Yesterday I wrote the following:
I hope to develop with Flex, Grails, GWT or YUI + Struts 2 in the next 6 months. These seem like the most exciting technologies for Java web development in 2008.
This post is meant to explain why I think these are the most exciting technologies going forward.
A few weeks ago, a very interesting paper was posted on TSS: Life above the Service Tier. In this paper, Ganesh Prasad, Rajat Taneja and Vikrant Todankar introduce a new architectural style they're calling SOFEA, for Service-Oriented Front-End Architecture. To summarize:
The principles of SOFEA are:
0. Decouple the three orthogonal Presentation Tier processes of Application Download, Presentation Flow and Data Interchange. This is the foundational principle of SOFEA.
1. Explore various Application Download options to exploit usefully contrary trade-offs around client footprint, startup time, offline capability and a number of security-related parameters.
2. Presentation Flow must be driven by a client-side component and never by a server-side component.
3. Data Interchange between the Presentation Tier and the Service Tier must not become the weakest link in the end-to-end application chain of data integrity.
4. Model-View-Controller (MVC) is a good pattern to use to build the Presentation Tier.
Their paper can be downloaded from Life above the Service Tier.
I read this paper earlier this week and enjoyed reading it as well as thinking about the concepts it introduces. First of all, I believe SOFEA only applies to web applications and isn't a valid architecture pattern for web sites. While it may work for web sites, the traditional mechanisms (serving pages from the server side) seems to work well and isn't going away anytime soon.
So if SOFEA is the way of the future for developing web applications, where does that leave all the web frameworks that serve up pages server-side? This includes all Java web frameworks, Ruby on Rails and PHP. I think it leaves them in an interesting situation. They can still be usable if they can serve up the Application Download and the Data Interchange, but otherwise, they seem pretty much useless with this new architecture.
Is a SOFEA architecture a silver-bullet? I doubt it as there's still a lot of unanswered questions. How does SOFEA solve i18n and validation? Is it possible to re-use server-side validation rules in the client-side architecture? Granted this is probably a client-side framework feature rather than a SOFEA concept, but I still think it deserves some thought.
I don't know if i18n is that much of an issue for most applications. Most of the gigs I've consulted on in recent years were English-only, with no plans for internationalization. Validation is often server-side too. However, I believe server-side validation is often done simply because the web framework being used did not provide good client-side validation. How does i18n work in a JavaScript application? Can you bundle i18n scripts in the Application Download and have those read on the client-side - or do you serve up a different version of the application for different locales?
I think the most interesting part of SOFEA is how simple the backend becomes. With Spring and Hibernate (and some type of remoting) it should be easy to develop your SOA backend. But how do you publish those services? Do you still use a web framework on top to handle validation and such, or do you just markup POJOs with @WebService annotations?
Will 2008 be the year for SOFEA applications? It's definitely possible. I'm thinking of starting a Denver SOFEA user group to discuss and promote this architecture style. If I did - would you be interested in attending?