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.

Thursday, May 15, 2008

Spring MVC or JSF+?

Background

My business unit is trying to standardize if we can on a single Java-based Web framework going forward to simplify the Web development process, especially as individual developers move from one division to another, or centralized support groups need to maintain multiple applications from multiple divisions.

At the enterprise level within my company, the architecture group says that they will provide support for either Spring MVC or JSF+ (where the + represents the accompanying technologies you would use to provide a more maintainable application and a more rich user experience, e.g. Facelets, Richfaces, etc.).

Now my business unit is trying to decide which of these two frameworks, Spring MVC or JSF+, is the most appropriate to standardize upon for our development community.

What follows are some considerations based on discussions we've had internally thus far.

Please provide any feedback you might have based on your experience with either of the two frameworks. Are any of the perceptions or claims below inaccurate? Are there key considerations that we are not even thinking of that can help us to come to a reasonable recommendation? Any feedback you have is welcome.

Feedback To-Date

  • In general, our business unit divisions who have developers coming from a component-oriented programming model background seem to prefer having their developers remain with this programming model when migrating to Java Web app development.
    • It provides a more familiar programming environment
    • It would hopefully make developers more productive as they would have less of a learning curve
  • For those Web application developers that are already coming from a Struts background, obviously their learning curve would be much less steep if they were able to continue to use a page-based, action-oriented Web framework like Spring MVC.
  • Knowledge of / Experience with Frameworks
    • Within our company, there appears to be a greater amount of experience with Spring MVC than with JSF currently.
    • Within the industry, it seems that there is a greater amount of experience with JSF if you are to look at developers' resumes, the greater amount of books and other documentation available, etc.
  • Training
    • A "Comprehensive Spring Training" course that includes about a 2.5 hour session on Spring MVC authored by SpringSource and tailored to our company's needs by another business unit is already available through our training center.
    • An additional "Spring Rich Web" course is also already being jointly planned.
    • No training modules are yet available internally for JSF, but obviously many are externally.
  • Migration of Developers' Skill Sets
    • If we were to choose Spring MVC, component-oriented developers would have to learn a new programming model.
    • If we were to choose JSF, action-oriented developers would have to learn a new programming model.
    • Either way, training and re-tooling would have to take place.
    • Anecdotally, it is probably true that we have more component-oriented developers than action-oriented ones.
  • Vendor Lock-in
    • With Spring MVC, you can write controllers in such a way that they are effectively annotated POJOs, but even the annotations introduce a Spring dependency.
    • In all likelihood, we would want to extend some of the controllers that Spring provides based on the use cases for a particular page flow.
    • Thus, most likely, selecting Spring MVC means that applications built using it depend upon it, and they can't easily be ported to another Web framework.
    • With JSF, you're really just dealing with a specification, so although the JSF RI provided by Sun is the currently recommended RI, there is nothing that ties you to it specifically.
  • Maturity / Market Penetration
    • The first RI of JSF and the first version of Spring MVC both seem to have emerged around the same time in 2004.
    • From a vendor and tools perspective, there has been much more traction around JSF, especially in terms of providing a "drag and drop" user experience for component developers.
    • That said, SpringSource itself is now a vendor that offers support for its entire Spring portfolio (including Spring MVC), and the Spring IDE does a decent job at getting users going on building and visualizing Spring-based applications.
Issues / Concerns

  • If we're using a combination of technologies for developing JSF applications like Facelets and JBoss Richfaces, would there be an Eclipse plug-in / extension or (if we could justify the cost and complexity) yet another IDE that could simplify and automate the usage of those technologies together?
  • If the push from the industry seems to be towards migrating complex UI interactions to the client via Ajax and Flex, what value would JSF+ add on top of this?
    • For example, if we were to standardize on Spring MVC for the Web framework, Dojo for the Ajax toolkit, and (when appropriate) Adobe Flex for very rich components that it simply does not make sense to do in Ajax, how would JSF+ improve this picture?
    • In addition, if we try to follow our company's enterprise standard of using Dojo for Ajax, and a component library like Richfaces is leveraged, what if Richfaces didn't use Dojo under the covers or it used a different version of Dojo? Would it interoperate properly with any Dojo-enhanced elements of the page that perhaps did not come from a JSF component?

Some Potential Options

  • A member of our working team proposed that we recommend the use of Spring MVC as our Web application framework, given its relative familiarity to existing action-oriented developers, its simplicity, modularity, and the overall trend towards doing components more using client-side versus server-side technology.
  • There was some definite resistance to this idea, at least until we have some greater insight into where these two frameworks stand in the industry today and what their roadmaps are for future enhancements.
  • The possibility of supporting both frameworks was also discussed, but we are trying to narrow down the use of technologies to one wherever possible from an IT simplification perspective if that is plausible.
  • It was also mentioned that Spring MVC supports using JSF as its view technology (just as it supports JSP and Velocity), but it is unclear whether that hybrid approach would really provide any benefit to component-oriented developers who would still have to learn the Spring MVC request life cycle.

Next Steps

  • Obtain greater insight into and share with the working team:
    • The market penetration of each framework
    • Perceptions of these frameworks by major technology advisory firms like Gartner, Forrester and Burton
    • The future short-term and long-term plans for each framework
      • For example, JSF 2.0 and Spring MVC 3.0
      • As another example, how the Spring JavaScript and Spring Faces components of Spring Web Flow 2.0 might shift the playing field
    • The potential consequences (whether negative or positive) of eliminating one framework or the other from our development environment.

Wednesday, May 30, 2007

Lou Dobbs vs. Reality -- Who Will Win?

I read an article in the New York Times today that talked about how a Lou Dobbs guest incorrectly cited the number of leprosy cases inside the United States over the past 3 years as being 7,000, when that total applies to the number of cases over the past 30 years.

It's bad enough that this lie was ever allowed to air, but instead of Mr. Dobbs, when confronted on "60 Minutes" about it, accepting the possibility that an error might have been made on his program, he boasted,
“Well, I can tell you this. If we reported it, it’s a fact.”

What media outlet, whether mainstream or not, can afford to be so cocky about its accuracy in the age of instant, bottoms-up fact checking via the blogosphere?

Aside from this, I just feel like "Lou Dobbs Tonight" is not really a news program, but an editorial program with the filtered (and apparently in some cases, falsified) news sprinkled in to make it feel legitimate.

Just like the corners of newspapers containing news-looking ads are required to contain somewhere the word "advertisement", shouldn't there be a disclaimer at the start of "Lou Dobbs Tonight" that says something like "For Infotainment Purposes Only"?

Monday, May 28, 2007

Online dating blurs the rules

So I met this guy on Yahoo! Personals and he seemed like a really cool guy. We talked on the phone for over a half hour on Thursday, and I enjoyed it. I then said we'd continue the conversation tomorrow, as it was late. But I never called back, and neither did he.

Then on Saturday, I gave him a call to see if he was still up for doing something on Sunday or Monday, as we had discussed earlier in the week. I never heard back.

Is it the fact that this started through an online dating site that the rules of courtesy don't seem to apply (both for me not calling him back originally on Friday, and for him ever calling me back at all)? I know nothing was ever set in stone, but somehow I feel like because we started online, the ephemerality of it all just makes it seem like less of a big deal if someone doesn't get back to someone else.

Maybe I should try bars again. :-)

Sunday, May 27, 2007

Amazon Movies Unboxed on My TiVo

I tried out for the first time yesterday Amazon's Unbox Video-on-Demand service and its integration with TiVo.

The link process between my Amazon and TiVo accounts was quick and painless, and the process of ordering a movie rental couldn't be more straightforward.

Unfortunately, even with a fast 802.11g wireless network, the download of the movie ("Casino Royale") onto my TiVo Series 2 took almost as long as the movie itself runs. More importantly, all motion (whether it was a car chase or simply the movement of people across a room) was distractingly blurry throughout. It kind of felt like you were watching the movie in a perpetual, drug-induced haze.

Maybe Amazon Unbox through TiVo works well for movies in which there isn't much action, but for action films, I think you'll start to get dizzy just watching them.

I think this is a great first try, and I look forward to future improvements.

Giving the President His Props

I was home sick the other day and had the opportunity to watch President Bush conduct his apparently 35th (according to CNN) press conference in the Rose Garden outside the White House (transcript available).

I was not surprised at all at his continued stubborn insistence in the belief that the world is safer without Saddam in it (it's not; see "Iraq"), nor his repeated attempts to link 9/11 to the need for the Iraq invasion (there are no such links, though he's done a good job of giving al Qaeda an opportunity now to set up camp in Iraq).

Where I was pleasantly surprised, though, is in some of the language that he was using (I think for the first time in some cases) to praise some of the elements of the Iraq Study Group Report and in even (I couldn't even believe my ears) liking to "see us in a different configuration at some point in time in Iraq". I'm not saying "we've turned the corner" on Bush's Iraq policy, but I was at least heartened by the slight change in tone.

Where I think the President deserves the most credit, though, is in actually making some articulate, reasoned arguments for a comprehensive immigration reform bill. Here's a sample:
People will come here to do work to feed their families, and they'll figure out ways to do so. As a result of people wanting to come here to do work to feed their families, there is an underground industry that has sprung up that I think is essentially anti-humanitarian. It is an industry based upon coyotes -- those are smugglers. Good, hardworking, decent people pay pretty good size money to be smuggled into the United States of America.

There is a document forgery industry in America. There are people who are willing to stuff people inside temporary shelter in order for them to evade the law. I don't think this is American. I think the whole industry that exploits the human being is not in our nation's interests. And the best way to deal with this problem is to say, if you're going to come and do jobs Americans aren't doing, here is a opportunity to do so, on a temporary basis.

I would much rather have people crossing the border with a legitimate card, coming to work on a temporary basis, than being stuffed in back of an 18-wheeler. And I would hope most Americans feel that, as well.

I'm not saying President Bush has all the answers, or that there are not serious flaws in the immigration bill that need to be addressed. I'm just saying that at least on one issue, President Bush has taken the time to think about some of the alternatives, and has realized and articulated that the ones espoused by the most conservative people on this issue in Congress are simply not workable. Hopefully some of those conservatives were listening.

Richardson's MTP Implosion

I saw Gov. Bill Richardson on Meet the Press this morning, and wow, was I disappointed.

I had heard great things about him, especially in terms of his experience with international diplomacy and energy efficiency/independence. And I heard some great ideas from him on both fronts during this interview.

But when asked why he decided to join the board of an oil refinery company that recently bragged it would have even bigger profits due to the squeeze on supply, he answered, multiple times, "I have to make a living", in some form or another.

Is there no other way to make a living than by working for the board of a company whose policies typically directly contradict yours with respect to energy efficiency and independence?

What is Richardson's ethical guidelines for choosing to serve on the board of a company? Has he none?

Another thing that disturbed me was his switch in stance on the assault weapons ban. He originally voted for it, but then voted to repeal it as a representative of the state of New Mexico. His argument? He's a Western governor and he needs to represent his constituents. Well, he's not going to be a Western president!

I know this gets into the gray area of what views an elected representative should espouse once in office--his/her own or that of his constituency--but I honestly believe that if you think giving uzis to hunters is unnecessary one day, you shouldn't change that view on another day because you're now in a position where that view is unpopular.

Lastly, Governor Richardson simply needs to do a better job of doing his homework before he speaks.

He was originally for the comprehensive immigration reform bill when it was announced, but now he's against key provisions. The reason? When he announced his initial support, he had only read the bill's summary! Um, if you served in Congress for over a decade, it shouldn't be a shock to you that the devil is in the details. It's perfectly acceptable to say when asked whether you're for a piece of legislation, "While I like the ideas that this bill puts forth in summary form, I'm going to the responsible thing and take some time to study it before I make any judgments one way or the other." What the heck would have been wrong with that?

Governor Richardson has some great ideas, and some real passion to him, but I don't feel his MTP interview was a demonstration of his presidential qualities.