KM: How do you think Shale compares to Seam? Is it an either-or proposition?

CM: Darn Gavin ... until Seam came along, Shale had the "framework built on top of JSF space" pretty much to itself :-).

In general, both Seam and Shale start from a common vision: build on top of the infrastructure that JSF already provides, avoid reimplementing redundant features, and focus on adding value (or improving ease of use) instead. From that starting point, however, we've taken somewhat divergent paths to get there, in several areas.

With regards to overall application architecture:

• Seam's original core vision was to bind JSF components to EJB3 session beans, with the somewhat radical idea to eliminate the typical backing bean adapter layer you see in JSF apps, and just use a session bean as the backing bean with UI event handlers.
• Shale stayed pretty close to the originally articulated JSF approach, but focused on providing some additional "events" (in the view controller APIs) of interest to the application developer—like a prerender() method to set up the data you need for a particular response, whenever that view is about to be rendered.
• Interestingly, Seam has more recently featured the fact that you can use POJOs for the backing bean as well as EJBs. This certainly broadens the potential market for Seam deployment to environments that don't support EJBs, but there is actually something else (not having anything to do with Seam) that holds back acceptance of EJBs as backing beans: the EJB spec requires you to package those EJBs separately from your webapps, and deploy the whole thing as an EAR. If you could just define an EJB3 session bean in a WAR, this whole idea would have been much more reasonable—if you need the extra features that EJBs offer over POJOs (transactional support, scalability, security, etc.) just add the @Local annotation and recompile. I hope the next version of the EJB spec makes this possible.
• It's also interesting that both Seam and Shale (along with JSF in general) endorse the "view helper" design pattern (in the vocabulary of the Core J2EE Patterns book), where the controller tier of your architecture is distributed into individual classes for each view or set of related views. People who like the architecture of Rails applications will be very comfortable with this approach, because Rails likes the same pattern.

With regards to "conversation scope" or "dialog scope":

• Both frameworks recognize a fundamental missing feature that really belongs at the servlet API level, but can be addressed based on the JSF request processing lifecycle in the meantime.
• Seam's approach seems :-) to me to feel somewhat procedural—you start and stop a particular dialog by executing particular methods with annotations that demarcate the dialog boundaries, and then use injection and outjection to manage the conversational state. I need to spend more time looking at it, but I have this nagging concern that outjection will tempt you to violate good separation of concerns design principles, because you can really go update anything.
• Shale's original dialog support was inspired by Spring Web Flow, but with a particular focus on being able to reuse existing JSF views (and their backing beans) both inside and outside a conversation. That meant, for example, that the conversation needed to be managed externally from the application provided components (in Shale, it's done with a custom NavigationHandler), with navigation outcomes being used to drive state transitions within a conversation, as well as entering and exiting a conversation.
• The original Shale implementation had some pretty significant limitations (one window/frame only, no support for back buttons, etc.) that were addressed in 1.0.4, thanks in large part to seeing how Seam dealt with the low level issues here. We didn't copy the Seam approach exactly, but learned a lot about what was required.
• Today, Shale's dialog manager provides a generic abstraction layer for conversation management across potentially multiple state machine implementations. A basic implementation is provided for simple cases, while a more sophisticated implementation based on State Chart XML (SCXML), a technology popular (among other places) in the telephony industry, can be used for more sophisticated requirements.

In other areas, Seam and Shale are more complementary than competing. When looking at what to use for a particular application, I would tend to pick one or the other conversational management approach, but then look at the individual other features of each framework to see what you might want to use together.

KM: So, if developers are in need of features other than conversations and enhanced backing bean integration, it might make sense to use both Shale and Seam.

CM: Yes ... you could, for example use Shale's view controller callbacks, or the integration with Tiles or Commons Validator, along with Seam.

KM: So, what is your day job now at Sun, and how does that relate to your work with Apache?

CM: As I mentioned earlier, after JavaServer Faces 1.0 was released, I took on a role as architect for Java Studio Creator. Over the last few years, we released several versions of this product, most recently in the form of the Visual Web Pack that runs directly on top of NetBeans 5.5.

Then, however, it was time for me to switch roles again—I am now what amounts to the "Web 2.0 Architect" for the Java Tools division. My primary responsibilities are to chart out a strategy for how we (Sun) should approach the next generation webapp development paradigm, and (most particularly) what kinds of support we should provide with tooling and runtimes. So, I've been spending a lot of time learning about scripting languages (primarily Ruby, JavaScript, and PHP), and about some of the popular development frameworks based on those languages (like Rails). It's been a pretty intense time of learning—I'm not an expert yet, but trying to get there :-).

With regards to my work at Apache, my day job continues to be more in parallel to that rather than directly depending on it. One thing I'm sure you have noticed is the vast increase in the amount of software that Sun has been contributing to the open source community—continuing the trend started years ago with things like Open Office and NetBeans, and culminating most recently with the release of the JDK itself. As you might imagine, developers who have been used to a typical closed source development model can find this kind of thing a bit disconcerting, so I spend some amount of my time helping people understand how open source development works. Apache's model has proven to be quite successful (although it is not the only successful approach), so it's easy to use that as a reference point when designing things like a governance policy for our new projects.

Page:   1  2   3   4