I keep getting asked about the relationship between Seam and Web Beans. At a high level, the mission of the Seam project remains unchanged: to provide a fully integrated development platform for building rich Internet applications, based upon the Java EE environment. In Seam2, this platform consists of the following layers:
- the contextual lifecycle, configuration and dependency injection model that forms the essential
glue
that makes everything work together in a consistent way - a set of modules that integrate other technologies such as JSF, jBPM, Hibernate, Drools, Groovy, Wicket and GWT, or solve common concerns such as security, asynchronicity and rendering PDF, email, Excel, RSS
- tooling
The first layer is the part that is addressed by JSR-299. The spec defines a more elegant, more typesafe, more user-friendly, standard solution that is a huge improvement over Seam2 (and everything else out there). The value of this is more elegant, more typesafe, more loosely coupled application code. But for many people, the true value of Seam is that it provides a complete pre-built, pre-integrated stack of technologies, together with tool support. That's not the role of JSR-299.
So the goal of Seam3 is to take the second layer and port it to the Web Beans backbone. This will allow applications using the Web Beans programming model to take advantage of all the integrated technologies that make up Seam. A second immediate benefit is that Seam will integrate much more consistently and transparently with application servers that natively support Web Beans. Seam3 will probably be packaged in a more modular way than Seam2, allowing any Web Beans-based application to drop in
Seam security, jBPM integration, Drools integration, etc. And hopefully, Seam won't be the only project providing infrastructure based upon Web Beans.
Of course, we want to make it's easy for people with Seam2 applications to migrate to Web Beans. There's two possible approaches and I'm not sure exactly which path we will take. We could:
- reimplement the core of Seam as a layer over the Web Beans backbone, or
- simply allow Seam2 and Web Beans to run side-by-side, with advanced interoperability between Web Beans and Seam2 components.
The first option sounds like a lot more work, but I suspect it might be easier than you would think.
