One solution is to enable the specification of methods as part of the flow. This would allow JSF to navigate not just from page to page but also from a page to a method and from a method to a page. Using this approach, the code is extracted from its specific page context and becomes more reusable. JSF page flow diagrams would now be able to convey more accurate information about what's going on in the application. This is helpful both to someone who plans a new flow, as well as to someone who is trying to maintain existing code and understand the flow of the application.

While we're at it, there's another kind of operation that would be useful to the JSF navigation model - a simple switcher. A switcher would let developers externalize navigation decisions from the backing bean of a specific page to the actual flow layer. For example, Figure 1 contains both switcher navigation - determining the method of payment - and a method call to validate a credit card.

Make Flows Reusable
Although you can use several jsf-config files in a single application, essentially breaking down your application into smaller flows, it's still too hard to create a flow that's truly reusable across applications in JSF.

The idea here would be to define standalone flows that can be incorporated into other flows. And to make things truly reusable, these flows should include a standalone memory scope and a transaction scope. This will let developers incorporate the flow into encapsulating flows without interfering with the transaction and memory scope of the encapsulating flow.

To make the use of the flow even more dynamic, I'd like to see the next iteration include parameter passing to and from JSF flows. These parameters could be used not just to pass information but to customize the behavior of the flow in different invocations. Note that in Figure 1 the flow has two return points that will return a value of "approved" or "rejected" to any calling flow that will reuse the payment flow.

Add Declarative UI to Business Components Binding
This layer has been missing from Java EE for too long. Connecting UI components to data components should be done in a declarative way, without much coding. Binding should take care of not only showing the information in the UI, but also processing updates and sending them to the right component on the back-end.

The Java community is becoming aware of the need to simplify binding. There are already three JSRs revolving around the binding issue. JSR 299-Web Beans, based on ideas from the JBoss SEAM framework, aims to define an annotation-driven approach to connecting JSF to an EJB 3.0 back-end. JSR 295-Beans Binding focuses on binding between Java beans and Swing. JSR 227, based on ideas from the Oracle Application Development Framework, aims to be a more generic binding architecture. It offers a metadata approach to binding that applies the same technique to any Java EE stack including JSF, Swing, and other UIs, as well as EJB 3.0, POJO, Web Services, and other back-ends.

While none of these JSRs has been finalized yet and none of them is part of the Java EE stack, their existence points to the need of a better solution for establishing connections between UI and business services.

Summary
JSF has been a great step in the right direction for Java developers. A big part of its benefit lies in the fact that it's part of the Java EE standard and as such gets extensive support from all the major players in the market. The popularity of JSF is enhanced further by frameworks that use JSF as their basis and then add functionality to address the gaps they see in the spec right now. Frameworks such as Oracle ADF, JBoss Seam, and Apace Shale take JSF productivity to new heights. With the work on JSF 2.0 (JSR-314) now on its way, I'm hoping to see the ideas implemented in these frameworks standardized for the benefit of the Java community.