Kito, can you tell us a bit about yourself?

I'm an independent consultant and author, specializing in architecture and development, primarily with web applications and distributed systems. I've been working with Java since 1995, but I've also worked with a variety of other languages and tools, including Delphi, Visual C++, and Perl. In the past, I've been the chief architect of an educational application provider whose primary service offering was built on top of Struts, with aspects of data warehousing, XML content management, and analytics on the back-end. I've also consulted for some large financial companies (I live in the New York area). Currently, I'm working on JavaServer Faces in Action for Manning, as well as a JavaServer Faces community site called JSF Central.

What do you think is the promise of JSF?

If you look at the Java web development space, you'll see that there are way too many "frameworks" out there. I've heard counts of over 30 -- I personally have bookmarks for over 20. As popular as frameworks like Struts and WebWork are, they're only the tip of the iceberg. And this count doesn't include the multitude of other frameworks developed internally by consulting companies and other development groups that haven't been released. Whenever there's a multitude of solutions for a problem, it usually means that there's no adequate "standard" solution.

You don't see 30 different versions of the Servlet API because it's a standard. Sure, there are some things we'd like to see added or changed, but it works well enough as a basic building block. There are some JSP alternatives, most notably Velocity, but the count is far less than 30. That's because, like it or not, JSP works for a lot of cases (and 2.0 is a major leap forward).

So, JavaServer Faces is a standard web application framework. To understand what the term "framework" means, though, you have to look at what's out there. I like to break the current crop into two main categories: user-interface oriented frameworks, and foundation-oriented frameworks.

Foundation-oriented frameworks concentrate on giving our applications structure (for instance, using a variation of Model-2), helping with a lot of utility methods, internationalization, resource management, templating, navigation, and so on. In other words, they provide all of the basic plumbing you need when you're building an application. They don't mask the fundamental request/response nature of HTTP, though. This includes frameworks like Struts and WebWork.

User-interface frameworks concentrate on making front-end development easier, by providing re-usable components (with properties and events) that are similar to the ones we're used to in the desktop development world. By this, I mean things like tabbed controls, menus, grids, trees, and so on. These frameworks tend to simplify the programming model and provide a more component-oriented view of the world, which is closer to the model introduced by tools like Power Builder, Visual Basic, and Delphi and also available in Swing IDEs and tools like Visual Studio.NET. This group includes frameworks like Tapestry and SOFIA.

Often the two camps overlap to some degree. JavaServer Faces is in the latter group; I think of it as a user interface framework. It does, however, provide basic controller functionality, a nice navigation system, and support for internationalization. So there's definitely some overlap.

So, the primary purpose of JSF is to simplify Java web application development by providing a standard web user interface framework. The fact that it's standard means that several tool and J2EE vendors will support it (including Oracle, IBM, Borland, and Sun). This support will allow you to visually build pages by dragging and dropping user interface components and then connecting them to server-side JavaBean properties, data sources, and event handlers. This means that in a lot of cases, you'll have tools for developing JSF apps right out of the box, which means you won't need to spend time wading through 30 or so different frameworks to find the one that suits you and your team best.

In addition, the component-oriented approach to user interface development is generally a lot faster, because the components do a lot of the work for you. If you talk to someone who has developed desktop applications with visual component-oriented tools like Delphi, they'll tell you that web development seems like a ton of extra work. This is because components like data grids and tabbed controls ship with the development tool.

This eye towards components and simplicity has a resounding secondary motive: compete with Microsoft. If you've ever worked with Visual Studio.NET and ASP.NET you immediately see how you can visually build applications quickly, and that's because ASP.NET provides the entire stack. ASP.NET is roughly equivalent to the combination of Servlets, JSP, and JavaServer Faces. So JSF is also a push from the Java community to be more competitive with ASP.NET (specifically ASP.NET Web Forms).

Is this promise really going to come about?

It's definitely going to happen. The vendors I've mentioned (Oracle, Borland, IBM, and Sun) have all announced products, and they're not the only ones. Sun is currently making the biggest marketing push with its Rave tool (now called Java Studio Creator).

In my opinion, it has to happen in order for Java to effectively compete with .NET. In order for developers to be more productive, J2EE needs to have enough standard pieces of the stack so that people can get work done without having to look for additional solutions. That doesn't mean that people won't use other solutions; it just means that they won't have to.

There's another piece of the puzzle, which is a little less certain -- a third-party component industry. I think that's a vital thing for JSF (or any similar framework) to be successful. I'm talking about an industry that is constantly putting out user interface components like powerful data grids, toolbars, calendars, tree controls, OLAP visualization controls, and so on (either commercial or open-source).

In other words, JSF needs companies or organizations like Infragistics and ComponentOne, ones that concentrate on building JSF component suites. Currently, there are a couple of companies, Otrix and SoftAspects, which have already announced JSF components. The third-party user interface component market is pretty large in the Microsoft world (and there are already quite a few ASP.NET WebForms components), but never really took off with Java. Swing never created the component industry we hoped it would; I think JSF will be more successful.

What's new in the JSF beta?

I have to say that I'm quite excited about the beta release. It represents a pretty mature feature-set, and addresses a lot of the issues people had with the early access releases. There are a lot of changes and additions, but my favorite is method binding expressions. Previously, JSF Actions were implemented using a special interface. This meant that you ended up exposing your event handling methods via anonymous adapter classes. I've always thought this was a pretty tedious way to represent what's pretty much a method pointer. Method binding expressions allow you to associate UI components directly with a method of any object living in any application scope, as long as it has the proper signature. There's no longer any need to create separate adapter classes. You can use method bindings not only for Actions, which perform business logic (and integrate with the navigation system), but other event handlers (like value change listeners) as well.

The other major addition is a fully-functional UIData component, which provides the expected editable grid functionality. The component is quite flexible, and can be associated with ResultSets, collections, and arbitrary objects. It's also quite easy to add support for your own data sources.

Personally, I'm also happy to see the addition of Phase events. This allows you to write listeners that are invoked during the request processing lifecycle (which includes phases for applying request values, performing validation, updating the model, invoking the application, and so on). This provides for functionality similar to the page lifecycle events of Tapestry and WebForms.

Other additions include comprehensive state management (both server-side and client-side), simplified localization, support for multiple forms, the ability to support a cancel-style button, and so on. All in all, I think it's a great improvement.

Are there any cool tools / apps that you have seen using this technology that people should be aware of?

Well, the technology is still new, so there isn't a whole lot out there right now. There's a tool called the Faces Console (http://www.jamesholmes.com/JavaServerFaces/console/) that helps with JSF configuration, written by James Holmes, the same guy who wrote the Struts Console. It plugs into a lot of popular IDEs, and is definitely useful if you're currently working with JSF. (JSF configuration is based on XML files, like most frameworks).

There's also Craig McClanahan's struts-faces integration library, which is essential if you'd like to integrate the two. There's a version for EA4 (http://archive.apache.org/dist/jakarta/struts/old/release/struts-faces/), and you can get early nightly builds of the version for the beta (http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/).

Sun has started a technology preview of its Java Studio Creator (http://wwws.sun.com/software/products/jscreator/index.html). You have to sign up for the preview, and Sun may or may not give you access. I can, however, say that the product is looking quite promising. You can expect a beta later this quarter. Also, WebSphere Application Developer 5.1.1 includes beta JSF support (http://www-306.ibm.com/software/awdtools/studioappdev/), but it's based on JSF EA4.

That's about it for development tools currently available, as far as I know.

There are a couple of projects that make use of JSF's rendering technology. One of the unique things about Faces is that it allows you to have separate classes for rendering a UI component. So a simple text box can consist of a UIInput component, which represents the concept of collecting user input, and a Text renderer, which knows how to display a textbox in HTML. You can create separate renderers for different types of clients -- one for HTML, one for SVG, and one for WML, for example. There's already an XML RenderKit from Oberon (http://www.orbeon.com/model2x/xml-renderkit) that basically outputs all of the standard JSF components in a normalzied XML format, that can then be translated (via XSLT) into the desired output format. There's also a new user interface skinning technology, called Xkins (http://xkins.sourceforge.net/index.html) that can be used with JSF. Both are open source.

I think the real power of JSF is a little deeper, though. The rendering technology opens up all sorts of possibilities for non-markup clients (the data can still be translated via markup, if desired). A good example of this is something like what Droplets provides (http://www.droplets.com/). Droplets provides "personalized, thin-client applications that are indistinguishable from desktop software". So there's a User Interface Server, that manages the display layer, but there's a client that's much richer than a typical web client. Droplets is on the JSF expert group, so it'll be interesting to see how their product evolves.

There are also some products that make use of JSF like the Exo platform (http://exo.sourceforge.net/home.html). I expect we'll see more of these as time goes on. I should also point out that there are a couple of open source JSF implementations -- MyFaces (http://sourceforge.net/projects/myfaces/) and Smile (http://smile.sourceforge.net/index.html); MyFaces is much further along. We try to keep track of all of these products at JSF Central (http://www.jsfcentral.com).

What do you think is missing in the current JSF spec?

Let me preface my comments by saying that JSF is still in early access, and it's quite likely that the expert group has addressed these issues internally.

That being said, I think one of the glaring omissions is built-in support for JavaScript (or other client-side scripting languages). It can certainly be done, but it'd be nice to have specific hooks for it like WebForms does. The standard controls don't really do much JavaScript at all, as a matter of fact. They're aimed towards supporting the lowest common denominator. A good example is the UISelectOne component, which can be used to represent a drop-down listbox. A lot of websites use JavaScript to process the selected item as soon as it's selected so the user doesn't have to click a button to submit the form. This sort of functionality isn't currently part of the spec.

Client-side validation is also something that isn't explicitly supported. JSF has Validator classes that can be attached to any input control. But there's no hooks for outputting a client-side version of the validation logic, so all validation is typically performed on the server. I recognize the fact that vendors may add these types of features, but I think they should be standard.

There are some other things that a lot of people have mentioned, like the lack of support for multiple forms on the same page, the inability to support a "cancel"-style button, and the small set of standard controls. These are issues that were addressed in the beta release that came out in December. The most notable addition is a data grid control. I'd still like to see a more powerful mask-type validator (like WebForm's regular expression validator), and perhaps a control designed for date input.

I wouldn't expect the list of standard components to get much larger, though -- and I'm not necessarily convinced that it should. There needs to be room for vendors to provide added value (and for third-party component suites).

What is the future of JSF?

In the short-term, you'll see the final release in the first quarter of this year, with IDE support shortly after it. I think you'll see people starting to build applications using JSF (I've already talked to lots of people who are doing this), and custom components popping up. The IDE vendors will provide a lot of additional components on top of the standard component set as well. Over the long-term, I think JSF will evolve and grow, taking on more of the core web application framework functionality. Other frameworks like Struts will still add advanced features and additional value, but I think more and more basic functionality will be part of JSF. In other words, it will evolve to be the standard way to build Java web applications. And, also, the third-party component market will continue to grow, not just with HTML components (which will be first), but also components and renderers that support other devices and richer clients.

What issues will developers face when using JSF?

For developers that are used to web development and may not have done desktop development, moving to an event-oriented view of the world is a bit of a leap. The programming model for user interface components that generate events is quite different from handling an HTTP request directly. Instead of developing code that responds to the request (as is the case with most non-UI frameworks), you write event handlers (that can be associated with a component). The event handlers can handle action events, but also value-changed events, and any other events that your components may generate. So the model is different, and for some people, it's a big change. But I think that most will find that it's a needed change that simplifies and speeds up development.

How will JSF impact Struts/WebWork/Maverick/etc users?

I said earlier that I think there are two web framework camps: user-interface-oriented and foundation-oriented frameworks. I would classify all of the frameworks you just mentioned in the foundation framework camp. They make the job of building web applications easier and provide a lot of great tools, but they don't mask the fact that you're dealing with a request/response protocol like HTTP. In other words, they don't work in terms of UI components and events, which is the domain of JSF and frameworks like Tapestry. For people that have a lot invested in existing frameworks, it makes sense to use JSF in conjunction with them, since they all provide features that JSF doesn't have. Remember, JSF has basic controller and navigation functionality, but it doesn't have anything like interceptors, Tiles, or transformation pipelines. The integration approach is one that's been advocated repeatedly by Craig McClanahan and the Struts folks. It's more of a possibility for Struts users right now because there's already an integration library, but I expect other frameworks to integrate support in the future. In this scenario, JSF just provides access to user interface components; you would presumably use the existing framework's controller architecture. That's one of the nice things about JavaServer Faces -- it's pretty flexible, and the architecture is quite pluggable; this makes it easier to integrate with other technologies.

Usage with user interface frameworks like Tapestry or SOFIA is a different story. These frameworks will either be an either/or proposition, or integrate with JSF components in the future (like Kobrix has announced with it's TICL framework).

If you're developing an application from scratch (and your release date is around the middle of next year or later), I would see how far you can get with just JavaServer Faces.

You mentioned Tapestry. A lot of people compare Tapestry and JSF. What are your thoughts, and can they work together in the future?

I haven't worked with Tapestry, but from what I've seen, it's quite well-done. It actually reminds me a lot of ASP.NET Page Framework and WebForms (and I know oward learned a lot from WebObjects as well). Tapestry's also been around for a while, so it's pretty mature and stable. I can't really say it's better or worse than JSF, nor can I say how easily you could, for example, use JSF components in a Tapestry environment or vice-versa. I do, however, think it'd be a worthwhile task for someone to pursue.

Would you want to build your app using JSF versus Struts?

Well, like I said, I don't really view it as an either/or proposition. I think lots of people will end up using both -- especially people with existing Struts applications. In general, though, I would tend to use only JSF for smaller applications, especially simple Intranet apps. For larger applications, integrating with something like Struts is the way to go, especially for templating features like Tiles.

You mention using Tiles for templating. Do you think JSF will grow to support these types of features natively, or will we be integrating with Tiles and SiteMesh?

That's a good question. In the short-term, we'll definitely be using existing technologies like Tiles and SiteMesh. In the long-term, I think it's possible, but probably not for a while; I'm guessing that there are other things that should make it into the next revision.

How does JSF compare to what WebForms/ASP.NET has to offer?

Let me preface this by saying that I'm a JSF expert -- not an ASP.NET expert, although I have worked with WebForms.

That being said, I think it's important to point out that ASP.NET is the underlying web application infrastructure, like the Servlet API. So you can have ASP.NET web services, ASP.NET WebForms applications, or something altogether different; and everyone knows there are a lot of different frameworks you can use on top of the Servlet API (Axis, Struts, WebWork, JetSpeed, Portlets, etc.).

JSF competes directly with the ASP.NET Page Framework and WebForms to provide a user interface component architecture, and I think it's very comparable. If you look at where Sun is heading with Java Studio Creator, you can definitely see it. A lot of people have a hard time visualizing what JSF development will look like in an IDE, but it really will allow for a similar experience to WebForms development in Visual Studio.NET. You'll be able to visually layout controls and also modify the underlying JSP tags and the Java code for the form associated with the page. The technology is flexible enough, however, to be used in different ways, and without tools. (This is what I've been doing a lot of, lately).

So, on the surface, the two are quite similar. The underlying models are quite different, however. In WebForms, each page is represented by a Page class that responds to the request. It's a component in its on right, and all of its child components represent the other controls on the form (buttons, grids, drop-down lists, and so on). All literal HTML text is represented using a special control, so there's a full component tree representing the entire associated .aspx file. Typically, any events (such as a Click event) are handled by delegates that wrap methods on the Page itself. The delegates don't have to reference methods on the Page, but it's the way Visual Studio.NET does things by default. So you usually end up with a single page that encapsulates all of the controls for the page, is responsible for displaying it, and handles all events associated with the page. This is what Martin Fowler calls the Page Controller pattern. The Page Framework manages a pool of Page instances, so each Page is thread-safe. This model is very similar to the GUI-based client/server development with tools like Visual Basic or Delphi. WebForms also has the ability to associate component properties with properties of the containing Page (or its naming container) with Data Binding expressions. Data Binding expressions are read-only, however; WebForms won't update the associated property for you.

The JSF world is a little more fluid. Each page is represented by a component tree, but the tree doesn't handle requests itself. Instead, there is a single ontroller that manages the request processing lifecycle, and interacts with the requested component tree as necessary. Since JSF has to inter-operate with JSP, which outputs markup directly to the output stream, the component tree only consists of JSF components; it doesn't manage literal HTML markup defined in a JSP. Events (like an Action event) are handled by JavaBeans-style listener classes associated with the component firing the event. The new beta also allows you to handle events with method binding expressions, which can point to a method of any object in one of the application's scope, as long as it has the proper signature. This avoids the extra work of exposing a method via an anonymous adapter class.

You can associate components with properties of any Java class via value binding expressions, which are a subset of the expression language introduced with JSTL. By using value binding expressions, you can associate a component's value (say an input control), directly with any property in any application scope (application, session, or request). This association is read/write; for input controls, JSF will automatically update the property as well. Faces also goes a step further with event handling by providing a default action listener that dispatches to Actions, which are methods designed to perform business logic and influence navigation. So instead of registering a bunch of action listeners, you just associate Command components with an Action via a method binding. In practice, you can associate each page with a single class like WebForms, but there are also a range of other options. Even if you do create form classes that map to pages, they don't have to subclass from any particular class, because all of the associations between components and model objects is performed via value and method bindings, which are evaluated at run-time.

There are also a few key features that JSF provides and WebForms does not:

• Components can render themselves directly, or delegate rendering to a separate renderer class. This means that it's possible to display the same component in different ways. There are two dimensions to this -- displaying a component differently for the same device (for example, a UICommand component can be rendered as a button or hyperlink), and displaying it for an entirely different device altogether (for example, displaying a UICommand as a button for a WML device as opposed to an HTML device).
• A managed bean creation facility, which automatically creates objects in the specified scope (application, request, session) the first time they are referenced
• Declarative navigation management
• Support for multiple forms on the same page
• Ability to plug in different implementations of core features (view handler, value and method binding evaluation, navigation handler, and so on)

To be fair, managed bean creation isn't as useful given the way WebForms applications are structured, and Microsoft provides more sophisticated navigation with its User Interface Application Block. Also, since there's only one vendor, the need for plugability isn't as great.

So I'd say that JSF and WebForms are pretty comparable; JSF has some additional features, and the two are structured quite differently under the hood. JSF also has a more flexible architecture, and more powerful navigation capabilities (out of the box). WebForms, however, is more mature, a little more cohesive, and already has a bunch of UI components on the market.

Are there any areas of ASP.NET WebForms that you feel are weak?

Honestly, I think ASP.NET WebForms is quite well done. The areas I found lacking are the same ones that JSF has addressed -- particularly navigation, support for multiple forms, and updating model objects.

What is the biggest challenge for industry adoption of JSF?

One of the things that's hurt JSF the most is the fact that it was released to the public really early. It was never really clear which pieces were just place-holders for something better, or exactly what issues the expert group was aware of. So the first thing it has to do is overcome a somewhat negative impression that was created by alpha releases of the product. (The upside, of course, is that the expert group has gotten a ton of feedback.) I honestly think that once people start using it, the benefits of component-oriented development will be compelling. However, I think integration with existing frameworks is key. It's no coincidence that Craig McClanahan is co-spec lead for JSF --- politically, the standard needs a buy-in from the Struts community, as well as other framework communities. (Craig wasn't originally a spec lead for JSF, by the way.) So if people see that they can have their cake and eat it too, JSF will do quite well. Vendor support is key as well, but that part's already in motion :-).

Any thoughts about the sentiment that JSF is unusable without tools?

I don't think this is the case, since I've been doing a lot of JSF development without tools. (Just as you can do Swing, SWT, or any other GUI development without tools). It's certainly designed to be used with tools, but that doesn't mean it can't be used without them.

I do think, however, that those of us who are big IDE users will get a lot of added benefit when the IDEs begin to support JSF. We should see technology previews within the next couple of months. Also, tools will be great for front-end developers as well.

Many people are afraid that JSF is tied too closely to JSP. What do you think?

JSF was designed to work with JSP and other display technologies. But JSP is the only display technology that JSF implementations are _required_ to support. And, regardless of what you think about JSP, this makes sense because JSP is the standard, and a lot of people use it. There's a sample in the current Faces early access release of XUL instead of JSP, but I think more work needs to be done to prove that other display technologies can really be first-class citizens.

Many developers like to have a template where the designers can just open them up and kinda see the look and feel. XMLC is an example of this. With all of the <use_faces<h:input_text... Faces moves away from the elements that designers know (<input type="text"). What do you think about this mismatch?

Personally, I don't think it's a big problem. First of all, Struts HTML tags have the same issue, and plenty of people happily use them. Second, designers will be encouraged to use a JSF designer to build the user interface, as opposed to a normal HTML designer. (Macromedia is on the expert group, but has made no announcements yet). With a JSF designer, visualization is pretty simple - just run the application (or demo). And third, sometimes there's a more technical person - either a front-end template-oriented developer - or a developer who does both back-end and front-end work -- who will be using the JSF tags, just as they use JSTL and other tag libraries today. Lastly, I think it's time to stop thinking in terms of the specific markup - HTML, WML, or whatever - and start thinking in terms of the components themselves.

You mention the differentation between user interface frameworks, and foundation-oriented frameworks. There has been some debate in the community about ASP.NET, and how it uses the Page Controller pattern. Some people say that this is great for quick, and small projects, but isn't as scalable as using other Model-2 approaches. What do you think about that?

I think the primary scalability issue isn't whether or not the Page Controller pattern is being used, but whether each Page object is single-threaded or multi-threaded. One of the primary design goals of ASP.NET is to shield developers from multi-threaded programming, so each Page is dedicated to a single user for the life-time of a request. For any given page, the framework manages a pool of Page instances.

In terms of server resources, managing a pool of Page instances is more demanding than having a single multi-threaded object for all pages. But if you're going to manage a bunch of server-side component instances, it's likely that you'd want to do some pooling anyway. So I think that if you're managing lots of components anyway, the Page Controller pattern isn't so much different. However, if you're comparing it to a more low-level, non-component-oriented world (like simple JSPs with tag libraries), it would appear less scalable.

Every architecture has trade-offs. Additional layers of abstraction often have some sort of adverse affect; the question is whether or not the benefits of the abstraction are worth the penalty.

Some people say that JSF is a step in the wrong direction, and that we should really be looking at alternatives to browser-based HTML applications altogether. What do you think?

I think of Faces as a better way to build the existing crop of web applications -- kind of an evolutionary step in web development, if you will. Since we're all not going to just stop building web applications tomorrow (especially on the Internet), we might as well improve the way we develop them as much as possible today.

JavaServer Faces is also a good technology for thin client applications that aren't HTML-based. I've mentioned WML, but you could also write a Java applet application, or some other non-browser client that works with JSF. We'll see these types of applications evolve over time.

Personally, I think fat clients are great for some applications, like RSS News Readers. But web applications are great for other things, and JSF is a good way to build those types of applications.

PRINTER FRIENDLY VERSION