Seam3

下文转自 Gavin King 的 Blog。不过文章只能在我的 Google Reader 上看到，而不能通过链接打开，所以我也不能提供原文链接了。

 

本人甚懒，就不翻译了。

 

圈子里肯定也有很多人想清楚 Web Beans 和 Seam 的关系，本文就是解答这个问题的。

 

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:

1. the contextual lifecycle, configuration and dependency injection model that forms the essential glue that makes everything work together in a consistent way
2. 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
3. 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 beats the socks off of Seam2 (and everything else out there). 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 application to drop in Seam security, jBPM integration, Drools integration, etc.

Of course, we want to make it 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. Whichever path we take, Seam2 style configuration and dependency injection will be deprecated - Web Beans is a far better realization of the ideas behind Seam2. That doesn't mean you should be scared to adopt Seam now! On the contrary, I don't expect migration to be a very painful task given that the underlying concepts are so similar.