In the Spotlight - Keith Donald

Today I am delivering a presentation entitled Spring for Java Server Faces at TSSJS in Las Vegas. The presentation looks at how JSF and Spring fit together, and walks the audience through approaches to integrating these two technologies.

The slides are available for your viewing pleasure, and for you to use as you see fit.

In the presentation, I outline two approaches to integrating JSF and Spring. The first approach is what I call “JSF-centric”, which is the integration approach most folks with a traditional JSF background employ today. The second approach is what I call “Spring-centric”, which is a new, groundbreaking approach to JSF integration driven by the work done in the Web Flow 2 distribution.

There are two demos in this presentation, one showing an example of a “JSF-centric” Spring web application, and another showing a “Spring-centric” application that uses JSF as the UI component model. There is also a comparison of the two demos at the end of the presentation.

To review and run the demos mentioned in the slides:

1. Use SVN to checkout https://springframework.svn.sourceforge.net/svnroot/springframework/spring-webflow/trunk.
2. Access the build-spring-webflow directory and run ant. You’ll need ant 1.7 to build.
3. After the build completes, fire up Eclipse and import the spring-webflow-samples projects into your workspace. The booking-jsf project shows the “JSF-centric” approach. The swf-booking-faces project shows the “Spring-centric” approach.

Enjoy!

The Web Flow team has been working hard on Web Flow 2. We just reached our 4th milestone and will enter release candidate status as early as next week. The 2.0 final release is scheduled for the end of the month.

Between now and 2.0 final, we’d like your feedback! If you are an application developer currently using Web Flow 1.x, or evaluating Web Flow for use in your project, please give 2.0 M4 an evaluation and let us know what you think. If you are a web framework provider integrating the Web Flow engine into your framework, we encourage you to evaluate the refined hooks in 2.0 M4 and give us a shout out.

In the next few paragraphs, I’ll provide 2.0 M4 highlights for application developers using Web Flow and framework developers integrating it into their own web frameworks:

Application Developers

First, by far the best way to evaluate the latest Web Flow feature set is to take the reference applications included in the distribution for a spin. There are two reference apps in 2.0 M4, both flavors of a “Spring Travel” trip booking application. One flavor shows Web Flow integrated into Spring MVC with JSP views, the other shows Web Flow integrated into Spring MVC with JSF views. (see: How to Deploy)

One of the major themes of the 2.0 release is ease of use. Web Flow 2.0 M4 introduces many new features that simplify implementing flows, and we would love your feedback on those. Specifically:

• We have introduced a simplified XML flow definition syntax. Take the latest Spring Travel reference application for a test drive to see it, or compare the old version of one of our example flows to the latest version. What do you think? Much of the simplification comes from enhanced use of EL and simpler tags for executing actions. For example, you can now use EL to execute any method on any Spring bean, in addition to any flow variable.
• We have introduced integration with Spring Security 2. The Spring Travel reference app shows how to secure a flow using the “secured” element. You can also secure states and transition elements as well.
• There are several new “rich web” features in 2.0 M4. You can mark a view-state a “popup” and its view will be rendered inside a popup dialog for you (a Dojo popup by default). You can also use the new “render” tag inside a transition block to request partial rendering of a page after processing an Ajax event. Finally, try turning Javascript off in the Spring Travel application and notice how the application continues to work. We’ve worked hard to build in support for degradation, which is important for our customers that cannot rely on Javascript being available on the client.
• We have significantly reduced the length of a FlowExecution key. The 1.x key format had flow execution URls looking something like this: http://localhost/booking?_flowExecutionKey=_c1E11178E-485F-3913-98BA-86E17A09FA3D_kE977CB0B-47FE-3319-A688-FE4F4FFFCE2.
  The default 2.0 format gives you simpler URLs like: http://localhost/booking?execution=c1v1, where the first number is your conversationId and the second number is your view (or continuation) id. The URL format is still configurable of course.
• There is more to checkout; see the release announcement for a description of additional new features.

Framework Developers

One of the goals of Web Flow has always been “make it focused on doing one thing really well [implementing flows], and make it easy to extend”. The core of Web Flow plays the heavy-lifting role of providing the most complete flow engine available. In this role, we encourage other framework providers to build on our work and for them to let us know if integration is not as easy as it should be. The Grails community is already doing this, having incorporated Web Flow into Grails for implementing flows in Groovy (Grails is built on Spring MVC, and Web Flow is a natural MVC extension, so the fit is there).

There are a couple of things we are doing in Web Flow to make it easier to integrate for framework developers. First off, there are essentially three main extension points:

1. The FlowExecutor SPI allows the Web Flow engine to be embedded in another environment, such as a web framework. This is how Web Flow integrates into Spring MVC, for example. We view Spring MVC as the definitive Java-based MVC platform, but if you cannot use it as a base this hook is there for you.
2. The FlowBuilder SPI allows you to incorporate another syntax for defining flows. Our XmlFlowBuilder ships with the Web Flow distribution. Graeme Rocher developed a Groovy-based flow builder for Grails.
3. The ViewFactory SPI allows you to integrate a view framework into Web Flow for rendering views within a flow. This is how Spring Faces provides JSF support for Web Flow, and also how the RSF team at The University of Cambridge is integrating Web Flow with their framework. Other candidates for integration using this extension point I can think of include Wicket, Flex, and perhaps GWT.

Each of these extension points has been simplified in version 2, and the ViewFactory extension point is new. 2.0 M4 also introduces a new “AjaxHandler” extension point for integrating Ajax request/response handing, with a implementation that works with Spring Javascript. We’re also currently working with the IceFaces team on integration with their Ajax component library in time for 2.0 final.

The generally available release of Web Flow 2 is right around the corner. Help us make it as easy to use and extend as possible!

Spring Web Flow 2.0 M2 has just released. I am particularly excited about this release because it sets the foundation we need to realize the bold vision we have for our community for the future. In this entry, I’ll explain what that vision is, and exactly what this foundation will enable. I’ll also go into detail about the architecture of Web Flow 2.0, and compare it to the 1.0 version.

The Spring Web Flow 2.0 Vision

The goal of 2.0 is to evolve Spring Web Flow as a controlled navigation engine to offer significantly improved support for JavaServerFaces, flow managed persistence, and asynchronous event handling (Ajax) natively. The new Spring Faces project will build on Web Flow 2.0 to provide first-class support for JSF views in a Spring environment. In addition, Web Flow will continue to provide first-class support for Spring MVC-based views, allowing native JSF and MVC views to be used to full-power, even in the same application if desired.

* UPDATE: The vision above was updated on 1/11/08 after considering large amounts of feedback from the Spring community since The Spring Experience 2007. Based on that feedback, Spring Web Flow 2.0, scheduled to release in March 2008, will remain focused on the orchestration of controlled navigation and application transactions in a web application, usable as a complement to Spring MVC in an action-based MVC environment and JavaServerFaces in a component-based environment. When used with JSF, Spring Web Flow 2.0 can power an entire JSF-based web application as a “black box” or can be mixed with standard JSF navigation handlers that implement free-navigation requirements. 2.0, therefore, will be an evolutionary release adding first-class support for JSF and Ajax, supporting Java 1.4+, and providing full backwards compatibility with the SWF 1.0 flow definition language.

Now I’d like to go into a little more detail about the Web Flow 2.0 engine architecture, and how it compares to version 1.0. First lets start with a little 1.0 history.

A Little 1.0 History…

In Spring Web Flow 1.0, the SWF controller engine cared for one half of the web request lifecycle; the half related to request processing, often called the action phase. The other half, the render phase, was pushed off on the caller: either Spring MVC, Struts, or JSF front controllers. This can be shown in the SWF 1.0 architectural diagram below:

The primary benefit of this architecture is it makes it natural to introduce Spring Web Flow onto existing projects. Whether you are using Struts, Spring MVC, or JSF, you can plug Web Flow in to handle your more complex user interactions, and use plain controllers for the rest.

The downside of this approach is it makes it difficult to apply application control logic during the view rendering phase of the request lifecycle without resulting to front controller specific adapters. Consider, for example, the desire for a flow-managed persistence context. Such a context should be allocated when a new flow execution begins, de-allocated when it ends, and disconnected after intermediate view renderings while we wait for the user to continue. If view rendering is not under the flow’s control, how do you issue the disconnect callback at the right time? Similar problems exist in the areas of exception handling, concurrency management, and security.

Another downside of the SWF 1.x approach is it requires duplication of effort to “fit” Web Flow in to some environments, particularly a JSF FacesServlet. In the JSF case, both Web Flow and the JSF implementation were fighting over control over the URLs and how to manage server-side state.

Enter Spring Web Flow 2.0

Beginning with Web Flow 2.0 M2, the entire web request lifecycle is now under the control of Spring Web Flow, including the view rendering phase. Furthermore, Spring Web Flow can now render responses using any view technology, with first-class support for Java Server Faces and Spring MVC-based views. In effect, this means SWF 2.0 is one of the few in its class that offers a unified controller model for all types of user interactions — stateless and stateful alike — with support for multiple view technologies as well. This also means the entire web request lifecycle can now be observed using native Web Flow execution hooks, allowing for security, exception handling, performance management, concurrency management, and persistence context management policies to be applied centrally at the proper points in the request lifecycle
The new SWF 2 architecture, shown running inside a Spring MVC DispatcherServlet, is shown below:

Java Server Faces

The first view handling strategy supported is Java Server Faces. Through the Spring Faces project, the SWF engine can now act as a container for JSF and fully drive the JSF UI component lifecycle, combining all the strengths of the SWF application controller model with all the strengths of the JSF UI component model. As a result of this, we bring the following to the table for our community:

• A Spring-centric way of configuring and deploying a Spring Web application that uses JSF. To get up and running, you deploy a Spring Web Servlet and point it at your bean definition files, very similar to how you configure a Spring MVC web app today. No faces-config.xml or any other special JSF artifacts are required. This makes it very easy for Spring users to take advantage of JSF without any of the traditional drawbacks. You can even use JSF inside a Spring MVC DispatcherServlet if you desire, when running in “embedded” mode.

• Automatic support for POST+REDIRECT+GET pattern to prevent duplicate submits and browser warnings when using browser navigational buttons. This is possible for the same reasons: Spring Web Flow supports this pattern natively, and we have integrated JSF into our model.

• Flow-managed UI component state. This is particularly interesting as use of JSF traditionally implies a large amount of HTTP Session state for storing the component tree. JSF component state is now fully managed as SWF FlowExecution instance state, which means how that state is stored is a function of the flow execution repository in use. This means it is possible to implement a JSF app with no session storage whatsoever. This also means session storage is never allocated for stateless or “REST-ful” interactions. It also means when session storage is allocated for stateful flow executions, the amount of storage allocated is less and the scope of that state is defined (and generally shorter in practice compared to your traditional JSF web application).

External Systems

The second type of view handling strategy we have proven is the ability for the SWF engine to communicate with external systems and conversational contexts over HTTP (though the API is protocol independent). A good example of this is what a e-shopping site might use a third-party like paypal for. Lets say you are guiding the user through a e-shopping experience, and as part of that experience you need to pause and redirect the user to paypal to complete a payment authorization process. Paypal, after taking over control for authorizing payment, will then call you back so you can resume the user’s e-shopping experience from where you paused. This is supported generally by passing the external service a callback URL it redirects to when it is done.

Such a pattern is now supported natively by the SWF engine. To do something like this, you would simply issue an “external redirect” to the external system. Spring Web Flow now handles embedding the proper flow execution callback URL in the redirect that is sent to the external system.

Resources

The third type of view handling strategy we have proven is the ability to serve resource content (images, javascript files, css files, etc) from resource bundles such as .jar files. We have a pre-defined “REST-ful” flow installed by Spring Faces for serving Javascript and CSS resources needed by the Ext and Dojo libraries, when Ext and Dojo JavaScript widgets are rendered by Spring Faces JSF components.

Spring MVC Views

Finally, the fourth type of view handling strategy we have proven out is the ability to serve Spring MVC-based views. This allows existing Spring MVC view templates to work as they always have with Web Flow 2.0, which is important for our existing Spring MVC and Web Flow users.

Conclusion

This post provided a high-level overview of the goals of the Spring Web Flow 2.0 release, and the architectural groundwork laid in the recent Spring Web Flow 2.0 M2 release. Watch for follow up entries that highlight the key new features in M2, and the new features we are busy implementing now for M3. Jeremy Grelle, lead of the Spring Faces project, particularly has a lot exciting to talk about regarding the new JSF and Ajax support!

When Sun scheduled my JavaOne 2007 session on Spring Web Flow for Friday, the last day of the conference, I wasn’t sure what to expect. I was honored to have been accepted again this year, but I wondered what I would see in terms of attendance presenting on the last day of the 4-day conference.

I could not have been more pleased with how things transpired. When I checked in at speaker setup on Thursday 800 people had pre-registered for my Friday session. Fifteen minutes before my talk was to begin the room had reached that number. In the end, 1000 JavaOne attendees came to room 307-310 of the Moscone center to experience an adrenaline-powered Spring Web Flow test drive.

Spring Web Flow Test Drive

In this blog I am hoping to re-create some the most exciting parts of my JavaOne Web Flow presentation. Checkout the screen cast below to see what was personally the most exhiliterating part of the presentation for me–building out a search flow from the ground up for deployment in a Java Server Faces (JSF) environment.

This search flow lets you enter some search criteria, see some results, execute a new search, and browse a result’s details if you choose (existing WebFlowians will recognize this as the JSF version of the familiar Phonebook sample application).

When watching the screen cast note how Web Flow manages all navigation and state for the application, while standard JSF components care for view rendering and model data binding. Also note even when I screw something up I can quickly fix it and get back to work because I never need to restart my server or switch my editor.

The Spring IDE visualization of this flow is below:

Get the code for this demo here. If you are using Eclipse with Web Tools you can import phonebook as an Dynamic Web Project and fire up the webapp inside your IDE.

Spring Web Flow at Spring One

Be sure to catch Erwin’s talks on Spring Web Flow at SpringOne on June 20th-22nd. He’ll be presenting two very interesting sessions that show how to put this product to work.