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.
Excellent work guys. I checked the spec and it's really a mayor improvement for Seam and for JEE in general. I can't wait to put hands on Seam3. Just one thing that bother me a bit about Web beans... I personally think that the name does not capture the basis and how general and truly revolutionary the specification is.
WebBeans looks great! The only thing I think, it is missing in WebBeans is a more elegant, more typesafe, more user-friendly way to do navigation. Navigation using xml files and sending values between backing beans using bijection is nice, but I feel that there should be a way to do this programmatically, with plain java, getters and setters, in a typesafe, object oriented, more user-friendly way. The way it was done in WebObjects... the way some have told me it is done in Wicket (but a little more elegant) using standard JSF based components instead of the non-standard Wicket components.
Maybe for WebBeans 2.0 ?
Since version 2, JSF is no longer coupled to Seam Core, and there is support there for alternative view technologies like GWT and Wicket. Web Beans, however, if I read it correctly, is layered on top of JSF so how will non-JSF presentation implementations be plugged into a Web Beans dependent Seam 3?
In addition to 299, there is JSR 314 (JSF 2.0) with significant changes in html templating and Ajax support. What will be the downstream effect on JSF support in Seam?
Well, that's pretty much out of our scope, I'm afraid. It's not the job of 299 to do web framework stuff.
Of course, Web Beans and Wicket should work extremely nicely together, if that is what you're looking for.
On the other hand, I don't think you could possibly identify a JSF navigation outcome in a typesafe way. Wicket is a bit different because there is a class that represents each a page.
No, that's not correct. There's no hard dependency from Web Beans to JSF. Just a built-in ELResolver so that Unified EL can ask the Web Bean manager for Web Beans by name.
Web Beans exposes the Manager API as an integration point for third-part frameworks.
I imagine that Seam3 will probably be built to target JSF2 since that's what's in EE6. But it's not something we've really discussed yet.
If it's not the job of 299 to do web framework stuff, does that mean it will be possible to use it in JSE? Like for example as a complement (IoC framework) for Swing stuff like JSR 296?
So I can use that built-in ELResolver for example, in a Swing JSR 296 based application?
Yes, Web Beans is defined to work on SE, in combination with an embedded EJB Lite container.
You can call Manager.getInstanceByType().
That sounds simply amazing!
Since webbeans is not tied to JSF...
Do you know if there are any plans to integrate WebBeans with plain JSP so that a WebBean can be called from a jsp page using using jsp:useBean or something similar?
This already works! JSP uses Unified EL, just like JSF.
I mean, it just works without needing to call <jsp:useBean>.
Wow. Great news! Can't wait to build a webapp with this!
Hi Gavin,
Any idea when a beta version of WebBeans will be available?
Best Regards,
Ashish.
http://www.ebizss.com/
http://www.ashishkulkarni.com/
How about tooling support for (semi-)automatic migration of source code?
We're targeting February for a beta.
Well, that might be nice, but we have limited resources, and that's a lot of work to do...
I think we can even promise that the final RI will be out by next Feb 29:th!
Biggest suggestions are not the tech, but the process. You all have done an excellent job making J2EE something I started actually using again:
Consistency. Is it a backing bean, a session bean, or a JavaBean? I know they all may be right, but let's trim a bit of the flotsam out of the names and approaches.
Domains. Don't go back and forth between config XML files and annotations. Let's help users take off on the system by letting users choose the way they want to configure their Seam apps, then give them a clear, consistent path through using that tech. Some people like external files. Others like all-in-one annotations. But for anyone starting out, seeing both is frankly overwhelming.
Templating. I keep finding all sorts of tweaks here and there throughout the books. If you want EJB transactions, add this...but what? Why was that not an option before? Probably because I did not know what it meant. So, put the options there, and then with an ANT target let me expose as much of the underpinnings as I want.
Knowledge. There's a lot of materials out there...but could someone version stamp all the docs. Again, trying to learn something, then finding out that in 2.1, it's irrelevant . . . what a waste of time. royal PITA.
Now the offer...if you decide to refactor (something that should most likely be taken by through say 1 functional unit to proof out the impact, etc.), I will absolutely help on that. Sign me up. I love refactoring thing!
. . . TizzyD
I agree that a migration tool would be nice, providing someone makes one ;-)
Most concepts have a Seam to Web Beans mapping so it's not impossible. As in most cases, 80% of it should be semi-trivial. And the remaining 20% takes forever to get right...