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
- 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
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
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,
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