Today the NFJS Java Symposium begins which by all respects is an excellent event. All of the topics look very good and I am looking forward to it, but I really could do without JavaServer Faces which I feel is already a failed technology created due to the increasing trend of catching up with ASP.NET. We already had JavaServer Pages which has improved through various revisions Initially the JSP implementation had some issues due to the fact that you could put scriplets right into the HTML, which defeated the purpose of minimizing the mixure of Java code and HTML markup. Then the JSTL showed a powerful way to greatly minimize the need to put scriptlets into the JSP document in order to provide dynamic results. The JSTL is very elegant and more importantly, it provides a shining example of how we should also create our custom tag libraries and all of the issues that plagued JSPs in the early days now seem like a distance memory. But wait, now JSF promises to be the future of Java web application development and it is a huge mistake...
So here we have the deplorable JSF, which is NOT compatible with the JSTL!!! The engineering team working on JSF attempted integrate JSF with JSTL becaue they knew it would be a major shortcoming to leave behind JSTL, but unfortunately they failed to make it happen. And JSF also brings the promise of event-driven web development, which is a direct copy of what Microsoft is doing with ASP.NET. This whole concept for web is just a huge mistake.
The HTTP protocol uses a Request and Response cycle which works extremely well with the Servlet API which emulate the protocol in a straightforward Object-Oriented way. The event-driven nature of ASP.NET and JSF gloss over the protocol layer and simply hide the fact that when a Submit button is pushed that the entire HTML form content is encoded and sent to the remote server for processing. The process is not typically very fast if there is a lot of form content, but JSF will facilitate and encourage the creation of very complicated forms and try to transfer all of that data for every little event which requires server-side processing. It is just bad idea.
Normally you would just attach some Javascript to the form and have it run some things locally on the client-side, but the JSF implementation has not included any Javascript integrations for the client. The JSF configuration allows for fields to require a certain validation, such as length or perhaps a pattern. That is easily checked using Javascript, but JSF will send all of the data back to the server to see if it is valid, and then puke the data back to the client to be corrected over and over until it is OK.
I was OK with doing JSP with JSTL and my own tag libraries. I also like the simplicity of the Servlet API. I do not need lots of XML in my way and I do not need some event-driven scheme layered over the HTTP protocol. The Request/Response lifecycle is sufficient as it is, thank you!
But my biggest beef with JSF is that it once again fractures the standard way to build a web application in Java. The point of having standards is that there is one way to get it done and everyone can learn it, use it and build on that foundation. So now after learning from mistakes with the original JSP spec, then learning to do it better with tag libraries and eventually the JSTL package we all are supposed to dispose of that experience and happily run over to the JSF camp and start over. I say no thanks. There is no point in having many standards to produce web applications which are not cannot work together.
As far as event-driven web applications, I see no reason to cross the client and server boundary for events. The client can send data to the server to be processed and the Servlet container can do it's own event-driven work. Like if I need to load user profile data I could run a service in the container which listens for requests and processes them as needed. Each incoming request would trigger events to fetch user profile data and the listening service can produce them, notify the requester and continue it's own thread of execution, using the resources that it was using without discarding them over and over as a method normally would.
Typically I have to call a domain manager and ask it to load data and then I would get some kind of data bean that I could use to produce the response. With each request, like UserProfile.getManager().getUserProfile(userId) I would allocate a database connection, prepare a SQL statement and execute it. That is slow, but with database connection and prepared statement pooling it can become sufficiently performant. But to take it a step further, if that same domain manager had an inner class running in a loop and waiting for event notifications it could hold onto those resources so they would not have to be allocated over and over. To make it a bit more robust the loop it runs in could have a wait timeout which would allow those resources to be released if there is no activity for an entire timeout period, giving the database resources back to the pool. Now the Servlet container can take in 30 concurrent requests which require user profile data and not require 30 concurrent database connections to do it. As it returns fetches each result row it can look at a queue for requested user profile keys and continue in that loop until the queue is emptied.
The domain manager could also hold a cache of user profile data so that the query to the database could be altogether avoided if the cache for the requested user profile is still current. Of course determining the status of the cache objects could be tricky. One way would be to use a last modified data attached to the user profile which would be updated each time the user profile changes. Fetching just the single date is much more efficient than pulling many fields or doing table joins on the database end. But if you know the Servlet container is the only system modifying the user profile data, the cache becomes much more easily managed.
But that can all be done without JSF or JSP. Heck, you could run these domain manager services outside of the servlet container and use something like JMS or Web Services to broker the data. There are some benefits to such decoupling, but I will not go into that. I just needed to explore some hope that I can maintain the data domain (Model) side of the MVC design without interference from the ever changing JSP/JSF (View) layer.
Posted by brennan at April 16, 2004 10:25 AM | TrackBack