Friday, May 16, 2008

State of Spring Web

For those that are interested, the following is a summary of the notes I captured from a conversation with SpringSource on the state of Spring Web:

Spring Faces

  • Driving JSF in the context of the Spring MVC lifecycle
  • All of the standard JSF components and component libraries work unchanged
  • Bread and butter of JSF is its component model
    • Lifecycle for rendering and updating component tree
    • Could have different vendors integrating with the standard
  • The faces servlet, the front controller code, etc., was not found by SpringSource to be particularly useful
  • When you run a Spring Faces application, you're actually using the Spring Dispatcher Servlet.
  • Spring MVC and Web Flow manage all controller responsibilities (request mappings, navigation rules, etc.)
  • JSF handles view rendering responsibilities as a View implementation
  • The focus of JSF going forward should be on enhancing its UI component model; specifically improving component interoperability, and ease of authoring new components
  • The difference between Spring-centric and JSF-centric approach in SpringFaces is not in the JSF component model.

JSF-Centric Model

  • JSF faces servlet drives everything, including mapping to views, etc.
  • A view-driven approach.
  • State is typically stored in HTTP session.
  • When user initiates an event, the postback lifecycle is invoked.
  • Ultimately that view decides whether to re-render or whether to delegate to a navigation handler to render a new view via faces-config.xml.
  • Only Spring integration is that JSF views will be bound to Spring-managed beans for business logic.
  • Downsides
    • You are limited to standard JSF navigation system
      • Can't go to views based on events
      • Difficult to modularize faces-config.xml if the modules are independent (but can have faces config fragments; extremely verbose)
    • State management not flexible (HTTP session only for every user)

Spring-Centric Model

  • Web Flow becomes the navigation model by plugging into that JSF extension point.
  • Architecture becomes controller-driven instead of view-driven
  • All requests are routed through controllers, which make decisions about which views are rendered.
  • What action-oriented developers are used to.
  • Bringing model and view together, but handling what needs to be done in the controller.
  • Benefits:
    • With Spring MVC, get full advantage of dispatcher servlet which allows you to customize how views are rendered via URLs
    • When controllers are invoked they can use input parameters to execute initialization logic to select the right view, etc.
      • With JSF out of the box, difficult to do initialization before view is rendered, and difficult to clean up after a view is rendered.
      • With Spring Faces, if there's a problem with handling a given request, instead of it being caught in the render cycle (which is difficult to recover from if you've already written out some of the response), you can catch an error before you render the view at all.

The Need for Control Logic / Spring MVC and Web Flow Bundling

  • Either way (JSF-centric or Spring-centric) you need control logic.
    • In JSF, it's managed beans, so typically people have to go out anyway and get something like Shale to allow for initialization prior to rendering, etc.
  • For people building components, nothing different between a JSF-centric approach and a Spring-centric approach.
  • People that have to do the event handling have to know Spring MVC and Spring Web Flow. SWF could be theoretically incorporated into the JSF spec over time to handle events, drive transitions, etc.
  • There is so much synergy between the two, it is not out of the realm of possibility that MVC and Web Flow could be combined in some future distribution of Spring focusing on web applications.
  • There's a need for both technologies.
  • Spring MVC will continue to exist, but the two products may merge at some point for developers to consume.

Benefits of Spring Web Flow

  • More powerful navigational system
  • Finer grained scopes (flow scope, view scope)
  • Reduce amount of state that's stored traditionally with JSF
    • Works with a multi-window application
  • Modularization of Web application
  • Built-in Ajax event model for rendering partial page fragments after responding to Ajax events
  • Spring MVC focuses on stateless, RESTful interactions

Spring MVC and Web Flow Contrasts

  • JSF is stateful by nature, as is Web Flow by nature, so that you can execute all phases of the lifecycle within Web Flow
  • With Spring MVC, only render phase can be executed. You cannot execute the postback lifecycle.
    • Might be able to address this in Spring MVC with custom form controllers, etc., but Web Flow provides this already with more power (flows can be changed without server having to be restarted)
    • You may see demand from clients to do more of the lifecycle within form controllers, but this hasn't emerged yet.

Spring JavaScript

  • Spring JavaScript is bundled with Web Flow at the distribution level, but not at the module level.
  • Spring JavaScript is not tied to Web Flow engine at all.
  • It can integrate with Dojo components that aren't in Spring JavaScript.
  • Spring JavaScript builds on Dojo 1.1 and can co-exist with other Dojo components.
    • The SpringSource Enterprise Bundle Repository, for example, uses Spring JS and Dojo 1.1 components outside of Spring JS, so they definitely work together (e.g. popup, query API, etc.)
  • Would probably have to have another release of Spring JS when another major release of Dojo comes out.
  • SpringSource provides an optimized build of Dojo to try to target the customers it serves (writing less JavaScript), without taking away power of underlying toolkit.


Keith Donald said...

Good notes Mike!

Just a few additional points:

* Spring Web MVC provides the common MVC foundation the higher-level modules of Web Flow and Faces build upon. So what we generally recommend to our customers is for Web MVC to serve as the base web framework, and for the other modules to be brought in where they make sense.

Some questions I would pose to determine when you should use a particular module:

- Are you implementing a REST-ful interface into your web application? If so, using a Spring Web MVC @Controller is the way to go.

- Are you implementing a task, stateful user interation, or multi-step wizard? If so, Spring Web Flow 2 makes these kinds of use-cases very easy to implement.

- Are you building a web application that should look and feel like a desktop application? If so, Web Flow and Faces together ontop of the Web MVC foundation are a great combination.

* As a client-side framework, Spring JavaScript is independent of any server-side framework. Our experience has shown that use of the Spring.js API can significant reduce the amount of Javascript you typically need to write to decorate plain HTML web pages with Ajax. Most of the Spring JavaScript API is quite generic and therefore can be used with new versions of Dojo as they become available. With that said, we are committed to staying current as the Dojo Toolkit evolves, as well as providing optimized builds that make the most useful parts of the Dojo conveniently accessible to our community.



Keith Donald said...

A quick follow up note about Spring JavaScript:

As I mentioned, the Spring.js API is written in JavaScript and is obviously independent of any server-side web framework. With that said, the Spring JavaScript module does provide some convenient server-side integration, including a convenient ResourceServlet for serving up static resources such as .js and .css files from .jar bundles (using aggressive resource caching and compression). In addition, there is convenient support for rendering Ajax Views with Spring Web MVC using JSP+Tiles as the view templating system.

In summary, we expect our customers implementing their views as plain HTML pages using templating systems such as JSP, Velocity, or Freemarker, to use the Spring JavaScript API directly to decorate those pages with Dojo widgets. For those who have chosen JSF, Spring Faces provides a declarative component library that uses the Spring JavaScript API underneath the covers, therefore encapsulating its direct use from the perspective of the page author.



Peter Mularien said...

Excellent post (although it would be nice to see SpringSource put something like this out there). Just curious, when you say "...captured from a conversation with SpringSource..." - did you just call them up and ask? Was this conversation at a technical event?

Theosophe74 said...


I was actually fortunate enough to have a telephone conversation with Keith Donald following my original blog post on Spring MVC versus JSF+. That latest post was just a capturing of the notes from that conversation.

SpringSource actually does a pretty good job at summarizing where they're at when they have product release announcements. But I agree it would be additionally helpful to have a Spring Web Roadmap page on the SpringSource Web site irrespective of any current or pending release that provides customers more of a strategic vision.