JavaServer Faces - JSF - Powerful and Underestimated.

Project History and Experience.

Starting one year ago, I began researching UI frameworks for developing web appliations in Java. Keep in mind, I'm a Senior Software Engineer with 7+ years of experience, so I do bring some perspective to this research. My goal was to support a fairly complex user interface comprised of thousands of fields. These fields would include most of the standard user interface components such as text, select boxes, check boxes, buttons, tabs, various panels, and rich graphical mapping components. Each user will see distinct subsets of the full system, making the choice of UI framework particularly important.

In early 2005 there were at least a dozen Java web app frameworks, but I quickly narrowed the selection down to a few. There were highly praised but "non-standard" frameworks such as Tapestry, Spring and the now aging Struts. While each of these addressed page flow and validation, each seemed to focus on a JSP or HTML page as the core of the UI layer. If I recall correctly, Tapestry focused on plain HTML as the view layer with special tags embedded. Struts had the largest user base but, speaking from personal experience, can quickly become a cumbersome liability in a large project. Spring promised simplicity and elegance, with a focus on integration with hibernate.

None of these projects addressed the UI View layer in the classic Model View Controller (MVC) Architectural Style. Except JSF. JSF's core focus was a Component based View layer. If I were building a small application with, say 50-100 fields, standard JSP would do just fine with almost any framework or none at all. For a complex application with 1000s of fields, with rule driven inter-dependencies, the full MVC style was needed. JSF components could fire events. They could also be programatically composed, manipulated, and decorated.

I briefly entertained the idea of simply creating my own HTML RenderKit rather than take the potentially steep learning curve of JSF. I'm incredibly glad I stuck thru the JSF initial hurdles. While most of the JSF tutorials out there are for standard JSPs, what I wanted was JSF without the JSP. As the learning continued I thought JSF with JSP was fine, but thought I would need custom components. After months of effort, I have yet to find a need for a component that does not exist in either the core JSF API (per the Sun 1.1 Spec) or the Tomohawk MyFaces Implementation.

After 4 months into implementing this major project, I am ready to fully endorse JSF for anyone who will listen. The concept and style of JSF is incredibly powerful, providing a very rich present or future path for those who are willing to try it. My coworkers are openly impressed with the project and many did not think a web application was capable of this type of interaction. Just a few weeks away from production deployment, I've confidently load tested the application and it should far outperform our current legacy app.

Please forgive the intentionally vague lack of mention of my company or the project specifics. Let's just say that it's a pretty cool project, for a Fortune 100 company, and will be used by quite a few people.


Technical Details. Why you should think about JSF.

1. Composite Components.
Just like Swing, .NET Windows Forms, or most other client side UI Frameworks, JSF components are true components. Due to their object hierarchy, any JSF UIComponent can contain other UIComponents as children. This grants incredible flexibility. It means that you can generate and render from an arbitrarily complex domain Model to an Object Graph of the UI View.

2. Decorators.
Due again to the elegant component hierarchy of JSF, all components can easily be decorated. In this case, I built my own small hierarchy of Decorators that could decorate any UIComponent. There are several domain-specific Decorators I can't mention, but an obvious one that I can is for debugging. Simply pass the Decorator list to the root Model -> Object Graph, and each major section of functionality will be wrapped with a debugging panel showing important state information for the developer.

3. Component Attributes.
Gone are the days of coming up with a naming convention for HTML form parameters and parsing in those same parameters. With JSF Components, you can simply add as many Java Objects as you wish to named keys in the JSF Component. This is similar to "Object Tags" in some thick-client UI frameworks. In this way, when an event is fired for a Component, the Event handler can simply lookup the Object you attached directly to the Component earlier on. This also removes the potential (definite for my application) burden of using HTML form parameters to subsequently look-up objects from another data-store or Model.

4. Event Listeners.
If you use Eclipse, you know about it's code completion and automatic import suggestion. The first few times I implemented JSF Event Listeners, I almost selected the Java Swing ActionEvent import (suggestion) rather than the JSF ActionEvent import. I haven't bothered to compare the API specs of each class, but I can tell you that there is nothing lacking JSF ActionEvent API. You can completely free yourself from the HTTP cycle and simply concentrate on event sources and handlers.

For static applications without a dynamically generated component hierarchy, such as most of the JSF-with-JSP tutorials show, Event Listeners can be bound directly to the UIComponent itself. For my application, which currently has ~ 30 different Listeners/Commands, I realized it was not worth looking up the proper Listener for each control, when on average only less than 1 in 10 would be clicked on per render. Thus, all Command components are bound to a single Command Listener. This Listener, upon receiving an event, looks up the appropriate listener and invokes it with the event.

5. Extensibility
It's pretty easy to develop custom components for JSF. Due to the specific nature of the JSF specification, the MyFaces components can even be used with the Sun Reference Implementation (RI). For those obviously needed components missing from the RI, MyFaces easily separated their core RI components from their extended JSF components (Tomahawk). Other groups both commercial and non-profit/open source are regularly releasing sets of JSF components. As JSF adoption increases, there will be a stream of more and better components.


Conclusion.
Of the frameworks mentioned in the first section, only JSF has two completely separate implementations. Only JSF has the full endorsement of the Java Community Process (JCP). We can be quite sure that JSF will be around for a long time. After such a positive experience with JSF I am confident that others are too. I'm sure that in the near term, more blog entries like this one will show up and build the momentum, respect, and ultimately adoption of JSF. With the excellent extensibility in terms of 3rd party Components, JSF will be ever improving even without a specification update.

I'm not saying everyone should jump to JSF now, but if you are building a complex application in Java for the web, it's worth serious consideration.

Tomcat, ANT, CVS, Success in the Enterprise - Part 1

After two long days of mostly business-side meetings about my group's focus at work, our choices to use open source tools has been validated by a landslide.

First, ANT. When asked who else in the company uses ANT, which I did not know, someone thankfully chimed in and stated that both of the other two main Java-based development groups use ANT with great success.

Second, CVS. The long-since-promoted to management senior manager present had used CVS in the past. Not only was the choice of CVS validated, but there was much relief and satisfaction that we moved from a flat-file-tar.gz archives method of backing up source, to a full-blown concurrent versioning system (CVS).

Most importantly, Tomcat. This is not simply a tool enabling our development - it is a platform that we will use to develop on, deploy to, and run our production systems on. I say systems because we use Apache-AXIS for SOAP serving, and vanilla Tomcat for our web apps.

I found out that one of the major Java groups (which has been flailing about recently) has used (drum-roll) BEA WebLogic for their failing platform. They are riddled with both organizational issues as well as development issues. In short: they move like molassas. This other group has failed to embrace the new cross-enterprise focus on SOAP for our middleware, and takes eons to deploy new and simple features.

The Sr. Management present congratulated us on our success migrating to Tomcat, and hopes that our documentation and technical leadership will be a foundation for other groups to build on.

I always thought that using open source in a large enterprise would be a struggle. Today I know, it is not.

About MySQL, Java, and good Prototypes

Over the holiday period at work most of my team was on vacation. Thus, I was left to "special projects". My group and I decided that a good project-prototype would be a SQL/RDBMS backed complete re-working of an existing form on our website. By form - imagine a form with about 20 complex fields for working with a command-line based back-end legacy system.

The goals of the prototype were simple:
Allow users of a complex app to save their form inputs in named templates.
Allow users to retrieve templates at any time, with an easy/natural UI.
Get this done - including installing MySQL & learning it's quirks in less than 4 days.

I have to say: the OSS community rocked. Soo many people out there using MySQL posted tutorials & FAQs on MySQL <-> Java usage, that rarely was I stuck on a problem. The only thing that got me - more of a Java issue, was that I had an old javax(?)-naming.jar in our web application lib dir (from when it was on JServ) that broke the more recent JNDI naming in Tomcat. Once I removed the outdated ...-naming.jar file, everything fell into place.

Having used JDBC (the java API for database connectivity) I was no stranger to the issues of using an RDBMS concurrently for the many simultaneous users of a web application. I started looking for a database/resource connection-pool and it was immediately clear: Apache-Tomcat includes a very robust connection pool! That was one of the only things I was about to miss from using WebLogic. So - after setting up the Jakarta-Commons based database connection pool (DBCP), I was ready to begin on my code.

In just a few hours, I had a basic schema, users, and a FREE tool for schema mgmt, backups, and general MySQL Admin. The tool I use is SQLYog. These guys realized that they'd never compete with the free tools (php-MySQL) if they didn't have a free 'lite' version. So, with this great windows-UI based tool installed and a few hours work, I was up and running - even with nice printouts of my schema (and html to email around).

To wrap it up - this article is intended to give confidence to anyone considering MySQL as a back-end for any Java project, not necessarily a web based one. The driver works well and the documentation is fantastic. In less time than purchasing and our IT-Unix Support group could have installed any of the non-free/OSS RDBMS systems, I had a fully working prototype ready to show-off. It was good enough, that it's now commissioned into a full project that will include upgrading a few other features and polishing the UI to work in both standalone (IE/FF) browsers as well as PDA browsers such as those in RIM devices.

MySQL + Java + Rapid Development = Success.

Apache, Jakarta, Tomcat, AXIS - more than the sum of their parts

For months now I've read constant articles on slashdot about the merits of .NET vs J2EE. I'm getting sick of it.

I work for a large (1500 people) subsidiary of one of the largest companies in the US. Previous to this company, I worked at several dot-coms in the SF-Bay Area. The dot-coms, with the least money, all spent vast sums of it on proprietary closed-source systems. In the past 5 months at my new job, using ONLY open-source tools in addition to our in-house legacy systems, I've accomplished more than I had in the past several years of dot-com work.

I credit my new found productivity to two things:
1. Good Management.
2. The Open Source Community.

The management issue basically goes like this:
Sometimes you have to make a decision on a project. If you constantly change your goal when you're 60-80% of the way to a release, you're never going to get anything done. At my current job my boss gives us tasks, and lets us run with them until completion. If something much more important comes along, we'll interrupt as needed, but get right back on track with our project goals.

Open Source Community. Wow - I'm seriously, honestly, blown away by the Open Source Community. There are shared, always updated FAQs, Wikis, email lists, and usenet. There is nothing preventing people in the Open Source Community from sharing ideas, code, FAQs, Wiki entries, email, usenet, and more. Have a bug? Fear not - search the public bug database, email the developer-list directly, get an answer for free within hours. What's the cost? Well, as a matter of principle, contribute something back. You don't have to be an elite hacker - even your email to a list & its' replies will serve to bolster the online documentation of a project long after you're done with it.

When we have a new project, and it requires a piece of software, we don't need to deal with any other department. Yup - not purchasing, budgeting, project management, or any other group. It amazes me that at the dot-coms, handling less data in their dreams of expansion than my current company, they insisted on expensive closed-source solutions when viable standards based alternatives existed. Twice in three years at a former company, our entire development team was shut down for a day following WebLogic license expiration. We were too small for our account rep at BEA to feel it worthy of sending us a warning email, so we simply found out one day that our servers were hosed. Can you imagine if that happened in production?

I'll say it now, proudly, I never want to use WebLogic again. I use Tomcat now. It's a reference implementation, is actively developed, has great performance, and oh - by the way, almost every Java webapp-related utility/code/package/component/free software is tested on Tomcat first! Find a bug? Fix it your-self, recompile, and submit the code back to Apache. WebLogic had all kinds of interdependencies on the specific JVM it ran on. These weren't obscure things, but things like core JPDC support - that suddenly stopped working if you ran WL on a machine not blessed by their specific JVM.

And that's another thing: do you really want developers who only think/work at their desks? I've got Tomcat on (1) my Windows 2000 machine, (2) my Linux machine. At work, I've got it on a 4-cpu linux machine and a dual HP-UX machine. Guess what, it works everywhere. Oh yeah - one last thing: want to install on another machine, "just because"? Don't worry about sending your "budget man to the congress", simply download and install. No silly licenses. No explaining to corporate accounting why you need fail-over on this machine, dual-cpu license on that machine, cold-backup licensing on that machine... Just install and go.

This is why, in the last 5 months, I've achieved well over a year of dot-com closed-source platform work done. I don't have to wait for a budget, I was hired to do a job, and these are the standard tools. Apache - the vast majority of the web. Tomcat - I'm guessing the largest percentage of Java webapps are deployed on it. MySQL - oh yeah, InnoDB is ACID compliant the best I can tell, supports well beyond our minimal backup/restore needs, and yeah - it's GPL.

And now, back to the start: .NET vs J2EE. Wow - do the lame media at zdnet and the like get this one wrong. .NET is a fledgling competitor to J2EE. I used it for 6 months at a dot-com. Yes: it has a very slick and nice IDE, with lots of useful wizards. Problem: even to do our most basic of apps, the only components we could find were closed-source, expensive components (i.e. a DataTable-Binding GUI for $500 etc). The equivalent in Java would be at least a half-dozen components that get weeded out to one or two very successful and mature open source components. While there are a great deal of good choices out there, simply drop on over to jakarta.apache.org to see some of the Java projects at the Apache Foundation. Java is mature in a way that .NET is hopelessly behind - it has the support of *Millions of people around the world refining, sharing, testing and releasing great software.

*Note: by Millions, don't think I'm crazy. It's just that I recently read "The Cathedral and the Bazaar" A major point of this was that by releasing software as Open Source, your users become more valuable beta-testers than paid in-house QA testers are on-average. Why? Because they will test in more ways, in original ways, and as long as you have a honest information flow, will give you more valuable feedback than someone blinded by in-house politics and legacy ideas.