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?
> I believe server-side validation is often done simply because the web framework being used did not provide good client-side validation
No, server-side validation is done because you can't trust the values submitted in the incoming request.
Client-side validation is useful for users because it gives them direct feedback, but it doesn't guarantee valid data.
Posted by Martijn Dashorst on November 02, 2007 at 07:26 PM MDT #
Posted by Matt Raible on November 02, 2007 at 07:53 PM MDT #
Matt:
I truly believe that problem projects or applications do not have clear separation of concerns, e.g. I know of a Tapestry project 75% complete and I'm dying to get a peek at it. They're stuck on some technical issue and if the data, service, and web tiers were clearly separated, a complete application is in order and can be finished maybe if 1) they dump Tapestry or 2) fix the technical Tapestry issue.
I'm trying to get all the interested Java users on my ProdigyFish site to post their ideas on web application requirements. I'm going to work on what a web application developer would consider perfect instructions and provide this document to the public and to clients. Also when requirements become an issue, I'm independent and work stops until things are clear.
Aside from the web frameworks, I still think database/Hibernate/Spring is the best foundatation. So for me, that's already answered. But can you isolate these layers from just the web layer in every case using any web framework? I think that rates the framework. I've been thinking about this a lot. Development should be what my dad called "hustle" work. Plug in the earbuds, crank the rock-n-roll, and just code. And when you hit a technical brick wall, something is wrong with the architecture.
Posted by David Whitehurst on November 02, 2007 at 07:55 PM MDT #
Posted by sudhir on November 03, 2007 at 06:25 AM MDT #
We have been building web applications using all these principals laid out by SOFEA except that the client-server data exchange is not service-oriented. In our applications, i8n and server-side validation is a must and we have developed a proprietary stack to solve these two issues.
In my opinion, in most cases when you develop web applications, you can safely remove "SO" from SOFEA. Service-oriented is good but in most real world business requirements we are facing you can simply serve JSON or XML data using traditional post and Spring MVC. Surely you can use web service but they may be overkill. Most time when we need to develop web service, it is because a third party requires it.
So, I totally agree this is a new architecture style, but putting "SO" in front makes me think the authors are buzz-word seekers because this new architecture does not require "SO", or significant enough without "SO". I would call it "FEDA" for "Fron End Driven Architecture" to cover more grounds because the key point here is to use front end to drive the flow (join the acronym club :-).
I totally agree with Matt that with this new architecture style the back end becomes very simple (the burden is at the client). Especially, component-based frameworks like JSF is facing a hard time. In our applications, we use request-based framework (Spring MVC) to drive the back end and we find it is very efficient.
Posted by Ye Zhang on November 03, 2007 at 02:36 PM MDT #
> So, I totally agree this is a new architecture style, but putting "SO" in front makes me think the authors are buzz-word seekers because this new architecture does not require "SO", or significant enough without "SO". I would call it "FEDA" for "Fron End Driven Architecture" to cover more grounds because the key point here is to use front end to drive the flow (join the acronym club :-).
I agree that there's likely better acronyms than SOFEA, but I don't know if FEDA is it. I think this is similar to the Ajax story in that the technology has been around for a long time, it just hasn't had a good acronym placed around it. If we can get a good acronym like James Jesse Garrett did, this could really take off (at least, that's my guess/hope).
Posted by Matt Raible on November 05, 2007 at 06:29 PM MST #
Thanks for your enthusiastic support of our SOFEA idea. You seem to be a bigger champion for the cause than ourselves :-).
You had mentioned that you were working on a reference implementation using Grails, YUI, etc. We'd be very interested to see how you go.
Regards, Ganesh
Posted by Ganesh Prasad on November 13, 2007 at 01:40 PM MST #
You imply that "service oriented" implies "web service" which implies "WSDL hell". That seems to go the wrong way for me. Thinking of "service oriented" as an architecture that eg. amazon uses to structure their monstrous application, exposing those services to the public where intended, seems to be a good thing.
Decoupling your front- and backend via services (be it JSON[P] or XML or whatever) and exposing those backend services to everyone enabled the success of a lot of those "big" applications we see these days. It seems to scale...
Btw., I'm working on a (now quite complete) jQuery based client-side validation library.
Posted by Jörn Zaefferer on November 20, 2007 at 05:31 PM MST #
Posted by Raible Designs on December 14, 2007 at 05:10 AM MST #
I think the challenge for SOFEA is creating the client. We are talking web, so the client really needs to be an extension of a popular JavaScript library - for example dojo, prototype, scriptaculous, yui, ext.js. These libraries have a huge uptake in the JavaScript world. Create a good SOFEA extension to these libraries (even better, a single extension with bridges to different underlying JS libraries), and any developer group should be able to plug in their own SOA backend. I think the uptake could be dramatic.
Having developed my own client to a SOFEA architecture, there are plenty of tricks in creating a smooth View/Controller implementation in the browser. For each SOFEA project to try and reproduce that is akin everyone writing their own JS libraries prior to the appearance of the aforementioned players. Unfortunately my client sits on top of a less popular library (the DomAPI), and I would love to one day move it over to perhaps ext.js, and even donate it to the project.
The SOA backend does become simple, and in my case uses hibernate/spring/axis and that's it. FWIW, my SOFEA implementation is a consumer app you can access at http://www.applebox.com.au. Just click browse DVDs and you're away. Install firebug and watch the SOAP service calls as they happen.
Posted by Simon Gilligan on January 13, 2008 at 04:02 AM MST #
I can sympathize with a lot of the thinking behind SOFEA, but got turned off by the following statement:
Get real! The server-side interaction models will be totally different between these two approaches, at the level of fundamental semantics (versus syntax details). Pick one or the other approach and go with it.
How many VCRs ever existed that supported both VHS and Beta? How many do today?
Posted by Craig McClanahan on March 20, 2008 at 07:48 AM MDT #
http://jsorm.com
Posted by Avi on May 01, 2008 at 01:27 AM MDT #
Posted by uberVU - social comments on December 01, 2009 at 04:49 AM MST #