Where does JSF really add value? Event driven applications and the web, contrary paradigms.
The JEE Ecosystem got bigger and bigger due to the increasing market impact of Java. More and more frameworks were integrated into JEE. After JEE5, JSF became also a part of the standard set of frameworks. Most mistakes are made when deciding whether to choose JSF or not. SUN Microsystems defined JSF as “an API for representing UI components and managing their state”. So one of the primary goals was to build server-side user interfaces which react to events (like mouse-clicks) and manage states (e.g. caching form entries after leaving a dialogue). This leads to a Rich Internet Application (RIA) which should behave like a desktop application. Now two paradigms are connected to each other, and they do not really fit. An HTML Website sent over HTTP can not carry a state by default, it can not trigger events in a direct way and it is not possible to interact with the operating system (everything is running in a browser thread which isolates the website). Finally, the idea of JSF is to provide an event-driven architecture like that of desktop applications based on request-response driven distributed model of websites. To deal with the issues, JSF makes use of cookies, javascript, JSF User Sessions and a so called JSF component tree which represents the state of all components. The user session is saved in the RAM of the application server for every user until a timeout is reached. The “view” of the user also contains a component model which is synchronized with the session on the application server to reach the “sicky state” behaviour. If you descide to connect the two worlds (web application and desktop application) you have to live with the consequences of such a model. This may lead to different workarounds (for example working with bookmarks is difficult in such an architecture).
JSF only feels good, if it is used as it’s meant to be. I.e. for Internet Applications which behave like desktop applications.
Most poeple, companies or software architects choose JSF because it is part of the JEE standard. They assume that it is the industry standard and that it cannot be wrong to use it, regardless of the functional and non-functional requirements. There are several non-technically-related shaky arguments for such a decision. Like “enterprise support, a ‘proven’ solution, included in standard” which sometimes leads to self-protection of decision makers in case of a project failure. This does not minimize the project risk. Quite the opposite, it leads to shift the liability onto the software developers, by forcing them to think in paradigms that don’t fit the customer requirements. Other circumstances can also lead to similar sub-optimal decisions. For example lack of experience, fear of getting in touch with new technology or third-party regulations when choosing a framework. Also, having experience and expertise with a single product or technology can result in the assumption that this is the “silver-bullet”, meaning comparisons between the different frameworks and technologies are skipped. Result: The aim is the ability to deliver something, rather than aiming for quality and maintainability.
Decisions based solely on self-protection are really risky.
What else is omitted from the rose tinted articles about JSF? One thing is the Post-Back Pattern: JSF is based on the so called “post back architecture”. This is how it works: 1. A page is loaded. 2. All requests are now sent with HTTP-POST. 3. The client recieves the result and processes it with javascript. Steps 2 & 3 are repeated until the client leaves the page. After the client leaves, the session is still available until the JSF session timeout (and longer if resources are bound to the JSF session). This has several disadvantages:
- There are no direct ways to address resources like there should be in HTTP (HTTP-GET)
- No XML/JSON service interaction, communication made of proprietary javascript functions
- Memory consumption caused by session and component-tree synchronization
- Hard to test (This issue may not be up to date)
A lot of sub-optimal design decisions have been made in the JSF architecture.
JSF is a really complex framework, because a lot of things are affected under the hood. The complex six step phase-model is an example of how to handle states (see: step diagram). The complexity is not the only issue; cpu-time for processing the steps for every request and the RAM which holds the user sessions for each synch in the component tree must also be considered. Java-Script was a must have in JSF 1.0. After JSF 2 many things changed, for example graceful degradation was implemented to be more fault tolerant to users with java script limitations. Due to JSF’s complexity and because it is so expensive to fulfill simple requirements, frameworks like JBoss Seam are getting more and more popular. The goal of such frameworks is to eliminate complexity at architecture and API levels. If you are forced to work with JSF, JBoss Seam is one of the best solutions to get out of the complexity, though JSF is still running behind the scenes, which affects application speed and scalability.
Compared to other frameworks JSF is complex, CPU and RAM intensive.
Many business applications can be classified as “data capture / store and modify / CRUD” software. High Performance is not an issue here and a large part of the user interface consists of reusable components like input forms & text fields. Component Libraries such as IceFaces and MyFaces come into play. In this context the concept of a “plug and play” component solution works. Such applications can have complex data input tables and validation rules, resulting in large, complex calculations, but the design of the page is simple. On the other side are websites with a lot of design and content. If you are forced to implement such things with JSF you’ll end up with a bloated codebase, which is hard to maintain.
There are domains where JSF adds value.
However other people say that JSF is the silver-bullet and that all problems can be solved with JSF?! You should not trust these people! Most of the stuff that you can find (online articles, java-magazine, …) are from people who clearly recommend JSF. Most of them are biased because they work with JSF every day and their company advises customers to use it. So why lower their own worth on the market? They will not write about the workarounds in their software solutions, the bad experiences they had once JSF was in place and all the scalability problems. A long time ago I bought the “Java Magazine”, which is mostly full of articles from consultants to boost their own value. The quality varies a lot from article to article. The main article was called “Web Frameworks, Struts, JSF and ZK compared”. The author talks about JSF as a more modern framework than Struts. I think the paradigms of event-driven and request-response driven architectures are incomparable. Problems with the component tree or real world experience with big projects were not mentioned. I know from projects where custom JSF user-session recycle services have been developed to prevent memory overflows with only a few hundred concurrent users.
Trust yourself! Evaluate different frameworks. Read about technical details and do not trust the hype a technology is given.
So, what is the next big thing for the future? After the growing market impact of javascript due to application development for Apple IOS and Android, architectures like SOFEA have good chances in the future. The biggest problem is that there is no standard stack defined which brings all of the necessary javascript frameworks together. Until then it is better to stick with the Spring (MVC) stack or Grails.
MphasiS, an HP Company, has also done evaluations of JSF for big, complex projects. The results reflect my experience. Check out this excellent article by Mohan Borwankar. Click here to read the Article of Mohan Borwankar.
You shold also check out this presentation from reliabledesigns.
comments
Leave a Reply