JBoss Seam 1.1 Indepth: An Interview with Gavin King

Seam 1.1 CR1 has just released, with the full GA coming within a couple of weeks. Major new changes include the ability to run SEAM without EJB making it useable in any appserver and even Tomcat, a new concurrency model, ICEFaces/Ajax4JSF integration, and Rails-like code generation/command line tools.

InfoQ spoke to SEAM creator Gavin King (who is also speaking at the QCon conference in London in March) to go indepth on the new release and what matters. For more background context, see also InfoQ's Seam 1.0: Rethinking web application architectures coverage.  

Gavin talked about what's new and cool in SEAM 1.1 from his perspective:

First, platform support. Seam 1.0 was extremely well received in the JBoss community and has been adopted by lots of JBoss users and also by quite a number of people who use Seam with Hibernate on Tomcat. There are also a few people using Seam on GlassFish today. But there were some teething problems on GlassFish, and it just plain didn't work on J2EE environments like WebLogic. We heard a huge amount of feedback that people wanted to use Seam, but couldn't because they were stuck on an application server that did not yet support EJB 3.0.

So, Ram Venkataraman (one of the product managers at JBoss) called me up and knocked some sense into my stubborn head. I was arguing that EJB 3.0 integration was a central part of the vision and that we would look confused and silly if we started to back off of that. He finally said "you know as well as I do that Seam works anywhere!". Well, that was not quite true then, but it is true now. You can even run it on WebSphere.

Second is the new concurrency model. With the death of the old paradigm of coarse-grained synchronous request/response, the assumption that concurrent requests in the same session are very rare is totally turned on its head. It's now absolutely essential to have strong constructs for managing session-level concurrency.

Third is the integration of ICEfaces and Ajax4JSF. Seam is the killer platform for Ajax. Without a conversation model, Ajax can't possibly scale. Most people don't realize this yet. If all those little fine-grained requests have to hit the database each time, you are in trouble. You need to have contextual state cached on the server, either in memory or on local disk.

Fourth, James Williams (one of the SEs at JBoss) has got Rails envy and wanted us to have a commandline tool. Much earlier on, I had put together an Eclipse-based reverse engineering tool using Hibernate Tools that could create a Seam application from an existing database, but I was never really happy with it. The generated code was over-complex and we did a bad job of keeping it up to date with Seam releases. So, I put together a simple application framework (think of it as a DAO framework if you like), James built a Grails-style commandline tool using Ant, and we merged the code into the main Seam distribution. It's now super-simple to get started with Seam, create a project, create some simple actions, reverse engineer an application from the database.

There are too many other new things to list. Asynchronous methods, an enhanced XML configuration format, atomic conversations, features for building RESTful applications, much more.

SEAM developer Michael Yuan also blogged more about SEAMs POJO component model (an alternative to EJB), eliminating the appserver dependency.

Asked about Atomic conversations, Gavin explained:

An atomic conversation is basically a conversation where you can make changes to your persistent objects over many requests to the server, but those changes only become persistent when the conversation ends (or at some other well-defined point). This is a really common thing to want to do in Ajax-based applications.

The first thing to consider is that it only works with Hibernate. We fought really hard to get this functionality into the EJB 3.0 spec, along with Sun, Sybase and others. Some other members of the expert group decided they didn't like this stuff or were scared of it because they didn't quite understand it completely and they blocked it, and that is a real loss to the community. Hibernate offers this feature as an extension to the spec. Seam 1.1 supports this in its conversation model, but only when Hibernate is the underlying JPA provider.

SEAM also improved it's clustering abilities for developers building apps using POJOs:

The most important thing is that Seam-managed persistence contexts (these are conversation-scoped persistence contexts) can be clustered extremely efficiently, without the need for a lot of state replication. We can actually do this more efficiently than the EJB container can cluster extended persistence contexts, because the EJB3 spec requires certain behaviors that it probably doesn't need to require (we will try to get this changed in the next rev of the spec).

If you're already using EJB stateful session beans, not much else is new in the clustering model. But if you aren't using EJB, you don't have stateful session beans, and you have not traditionally had good constructs for holding state across requests in a clustered environment. But we wanted people stuck on J2EE application servers to be able to use Seam! This meant that we had to really work on a model which would support efficient clustering of plain JavaBean components, for people who couldn't use stateful session beans. So now we have a solution which is not quite as efficient as SFSBs in JBoss, but at least can be used anywhere

On the new concurrency model in Seam:

The most important element of it is that Seam serializes the processing of all requests that take place in the same long-running conversation context, on the same machine. We also provide robust constructs for serializing access to components that have a scope larger than a conversation (eg. session scope). Note that Java synchronized keyword does not count as robust since it has no deadlock detection.

Gavin told InfoQ that Seam has been well adopted within the JBoss community and is recieving over 5000 downloads a month. One reason it never got far out of the JBoss community is because Java EE 5 support is not yet widely available across the appserver ecosystem, which is why the EJB 3 dependency was made optional in Seam 1.1.   Gavin compared Seam's current maturity and community as the early days of Hibernate, except that:

What is completely different about Seam is that people have started to build really serious and interesting large-scale applications with it, right off the blocks, because for certain types of requirements you almost can't live without it. If you're using jBPM for business process management in a web application, you're crazy to not use Seam. If you already use EJB 3.0 and JSF, Seam will simplify your life so much that you would be silly to not use it. If you want to build an Ajaxified JSF application using ICEfaces or Ajax4JSF, you will run into all kinds of performance and concurrency problems if you don't use Seam. And there is simply no comparable alternative solution for any of these cases, apart from build-it-yourself.

Talking abut specific interesting customer use cases, Gavin mentioned Lexicon Genetics, a life sciences company who built a workflow management system Seam and JBPM for managing the lifecycle of batches of mice used as test subjects. Another example is Nuxeo 5 who migrated their popular content management product from Python & Zope Java with Seam (see InfoQ coverage). "Their comment was that Seam helped them get their new platform up and running in just a few months. These were guys who were coming from a Python/Zope background, they were used to a highly productive environment. So don't let anyone tell you that enterprise Java can't be productive. A lot has changed in the past 18 months."

Gavin acknowledged that "the riskiest bet we made with Seam was picking JSF for the view layer," particularly considering the poor adoption and perception it had in the community at the time. JSF had no clear Ajax strategy and had some missing features Seam had to find workarounds for.  However, looking back Gavin explained how the choice to use JSF worked out for the better:

The bet paid off. JSF created an ecosystem of quality addons like Facelets, ICEfaces, Trinidad, Ajax4JSF, RCFaces, Seam, XULFaces, etc. A lot of this stuff is starting to get really mature and the various projects are talking to each other and trying to make sure everyone works smoothly together. This is exactly why you need standards. Without the JSF standard I would have had to have built JSF, Facelets, ICEFaces and Seam from scratch by myself. This would have taken a really long time. That's exactly why there is no comparable ecosystem for any of the other web frameworks out there. So JSF has leapfrogged the competition in the past year. The recent opensourcing of ICEfaces ups the ante again.

Look around. No other programming environment in any language offers anything remotely as rich in terms of user experience, back-end grunt, developer productivity, scalability, operational manageability as the stack of Facelets/ICEfaces/JSF/Seam/jBPM/EJB3/JavaEE. Ruby on Rails is so 2005.

Gavin also clarified the difference between Seam and the Web Beans (JSR 299). Web Beans is a JSR to formalize some of the same ideas that were implemented in Seam into the JCP standards. JBoss will provide the RI for Web Beans, based on the Seam codebase. "It's much too early to say how similar the final specification will be to what you see in Seam today."

Future versions of Seam will focus on Seam/Security and Seam/WS:

Seam/Security is a dynamic ACL-based security model for Seam that Shane Bryzak is building on top of Drools. Today, Java EE security is a disaster, and one of the weakest links in the platform (along with the truly atrocious Servlet spec)."

Seam/WS brings Seam's conversation, orchestration and stateful component model to SOA. You'll be able to write stateful components that take part in a Web Services conversation, and orchestrate the conversation using jBPM. Of course you'll get all the same nice Seam functionality that people love so much using Seam for web applications.