Jacob Hookom's Blog

July 2006 Archives

SAF2 and Shale: Missing the Buck

InfoQ.com just announced that Struts and Shale (JSF) are finally parting ways. This followed some rather lengthy back and forth on the struts-dev mailing list.

I know I've been blogging about ways for action frameworks and component frameworks to better collaborate, but this isn't what I was really looking for. Hats off to Don Brown for integration within the presentation tier between JSF and SAF2, but I want to see collaboration. The same thing is happening the web services world-- everyone is integrating with each other's types/standards, but no one is collaboration and solidifying on a single standard or methodology.

In the mailing list, Craig points out that even with integration, there's tons of redundancy that will only prove problematic in development. There are things better done in action frameworks than component frameworks and visa versa. To highlight that fact, Don follows up Craig's email with a couple bullets:

1. If your application needs to be built by tool-dependent programmers, pure JSF is definitely the way to go.
2. If you prefer the pure JSF approach for other reasons, use a pure JSF framework, but perhaps use Action 2 to organize and deliver JSON/XML services.
3. If your application has a lot of Struts developers or stateless pages that need pure speed, but in sections you want to use fancy JSF components, use Action 2 as the controller and sprinkle in JSF where needed.

So there's many points of integration between SAF2 and JSF in the tier that I really don't care about from a business standpoint. Fine, split for good marketing reasons, but the fact is that this innocuous debate totally misses what the industry is actually looking for.

Coming from a corporate background, my whole goal is to put as little code as possible in the presentation tier. The only code that you can guarantee long term is the business code with zero dependencies. Yes, I'd like better ways to describe my business model, but the fact that I use SAF2 or JSF (or Axis or XFire or AJAX or XUL or ...) in a particular context is irrelevant.

Here's an examples of collaboration:

• Use the same annotations to describe validation constraints
• Utilize the standardized JPA/EJB for RAD
• Use the same variable/context mechanism, such as the EL-API
• Action signatures are a no-arg method that return a String (check)
• Standardized business component concepts
• Use lower-level interceptor concepts from EJB that aren't deployment specific
• Continue using common annotations

I want to be able to say, here's my business model, annotated with meta data and then just have SAF2 and JSF agree that they'll utilize my MVC-agnostic investment. Flipping the tables if you will with frameworks to gain conventional stability in development across the market. I do believe that annotations are finally the answer with supplemental APIs as described a year and a half ago.

Hopefully the JSR 29x's will help facilitate more collaboration in the presentation tier through standardization. It isn't happening at Apache. The only thing I can really push is that they will not lock my business model into a tier of frameworks that are so volatile and deployment specific. Can I point at 299?

This work is licensed under a Creative Commons License.