Pete Muir on Seam 3, Contexts and Dependency Injection for Java EE (JSR 299)

DZone recently caught up with Pete Muir to get an update on JSR 299, Seam 3 and the forthcoming JSF 2.0 specification.  In this interview, Pete examines several implementations of JSR 299, recently renamed from WebBeans to Contexts and Dependency Injection for Java EE. He also provides a preview of some of the improvements we can expect to see in Seam 3.0 and JSF 2.0.  

Download the Podcast Here (~8MBs)

The complete transcript of the interview has been provided below:

DZone: We are sitting today with Pete Muir, core developer on Seam, WebBeans, and RichFaces. The last time we spoke with Peter, he was focusing on extending Seam beyond JSF and building the WebBeans reference implementation. Hi, Pete. It's good to talk to you again.

Pete Muir: Hi, It's good to talk to you too.

DZone: Pete, what is JSR-299? What's up with all the name changes?

Pete: JSR-299 is a specification that JBoss sponsored/led from about two or two and a half years ago. And the idea really was that we had identified a gap, which was you had EJB for writing your business logic, and you had JSF for writing your view. And then you needed a way to tie these things together. That's really where Seam came from. And then the idea of 299 was to take some of these ideas and take other solutions that would address this problem in areas such as Guice and Spring and work with those and produce a specification out of it.

So 299 has been going for about two or three years now. It initially was called WebBeans and that name stuck for a long time, until about three or four months ago, when it got renamed to Java Contexts and Dependency Injection, which reflected where it's gone and perhaps was a bit more the way of writing Web Beans, and this focus has changed it more towards a dependency injection context.

So it became Java Contexts and Dependency Injection and then it changed slightly again to become Contexts and Dependency Injection for Java Enterprise Edition. So that's exactly its current name.

What we've done as well is, for the reference implementation we've kept the name WebBeans -- that's the name of the project for the reference implementation.

DZone: What kind of use cases does JSR-299 focus on? Are there any implementations?

Pete: Yeah, sure. 299, as I've alluded to, is really focusing on writing applications that are primarily focused towards the web and being able to write view layers. For example, for humans to work with JSF or Wicket or other view layers like GWT or Flex, but also being able to use this as a model for writing your components for something like RESTful solutions that maybe you could use JAX-RS on the front end or something like that.

So JSR-299 doesn't define a view layer, it doesn't define a way of interacting with the outside world, it uses other specifications for that purpose, as I said, like REST or a view layer like JSF or a messaging solution like JMS. And yeah, it's primarily focused on developing web apps. That's been the primary focus.

As for implementations, obviously we're working on the reference implementation at JBoss, being the spec lead. And we're also responsible for producing the reference implementation. There's an implementation from Apache called Open WebBeans, which is coming along very nicely. I think also there's another implementation from Caucho, who produce Resin.

What they've (Caucho) have done is actually quite interesting. Many application servers have, at their core, some sort of dependency injection framework, and obviously you have the same problems there as you have everywhere. JBoss, for example, uses the JBoss Microcontainer, which is a general purpose framework for wiring together an app server. And what Caucho has done is actually build their app server based on the 299 dependency injection semantics, and used that as sort of a core engine to build their app server. And that makes it useful, because then you can use the 299 stuff in any place, just automatically.

DZone: That's great. So WebBeans is a JBoss implementation. Is there anything else that JBoss will be providing around 299?

Pete: Absolutely. This is a good point. Obviously you've got a specification, and the specification defines that 299 will run in Java Enterprise Edition or it'll run in a servlet container or any container, in fact, in which the EJB Lite, the embeddable EJB, container is available. It also defines that it will run with any servlet or any JSF application. We wanted to take this a bit further. So the first extension we provided is the ability to run in any servlet container without the EJB container available. So you can just run in plain Tomcat or plain Jetty, for example. This is a very popular platform for developing and implementing applications, today.

We've also been doing a little experimental work, getting it running in Java SE. So nowadays with the WebBeans application, you can actually run your application just in plain Java SE; you don't need anything like EJB or anything on the classpath.

So there, of course, you lose a lot of the functionality of 299 where it interacts with other EE specifications, but you've still got all the dependency injection and all the contextual nice stuff that 299 brings.

As I said, 299 defines that it works in servlet, which is pretty much most web environments with Java. It also defines additional things for working in JSF. Again, we wanted to take is a step further, so we've provided first-class support for Wicket.

With WebBeans, this means you can inject your WebBeans directly into a Wicket class, into a Wicket page, or something like that.

We're also looking at integrations with other frameworks. So, for example, if you wanted to get your Spring app and wanted to have your Spring app run with WebBeans, you can build a bridge, which is currently in the works, that will allow you to inject SpringBeans into the WebBeans and vice-versa. And that would run in any 299 implementation, not just the JBoss one.

And we're also going to continue to provide a lot of what we've provided in the past. Things like additional modules for building applications that the enterprise edition doesn't provide, like security or reporting through PDF or Excel, sending emails, that kind of thing we'll also continue to provide.

And again, those modules will be able to run on any 299 implementation, not just the JBoss one.

DZone: You mentioned Wicket integration with WebBeans there. Is there currently any support for integrating Flex applications with WebBeans?

Pete: That's a great question. Maybe I'll just give a little bit of background and then jump into the question. The way I always view this is, there are currently two types of view frameworks today. There's the server side rendering ones, ones like JSF and Wicket. And then there's the client sort of ones, like GWT or Flex.

And they fall into different categories and they really address different use cases. I would often say that they can be complementary or at least - you're choosing between one use case or another and then you choose your framework. They're not directly competing again each other in some ways.

So with that background, you'll see that we've initially concentrated on the server side rendering frameworks.

I think there's definitely a good case for using the client side rendering frameworks like Flex or GWT here with 299. With WebBeans, you can obviously write your business logic on the server side interacting with your EJBs or your messaging or whatever, and communicate that to the client side using any technique you like.

You could use REST web services, or you could use the older WS-* framework or something like that. You could use something like Seam remoting. That hasn't been ported to WebBeans yet, but we're going to support things like that, like a JavaScript remoting solution.

So those are a number of ways in which you could use 299 for your business logic, and then see your view layer interacting a little bit in a fairly loosely coupled fashion. More for a generic services layer than for direct integration. The direct integration is interesting. It's not something we've looked at in terms of WebBeans, actually.

At the moment the main effort is focusing on Seam, and there are couple of projects out there that really have done this work, one of which is a project from the Granite DS guys. They've really done a great job of really almost natively integrating Seam with Flex and allowing you really - if you inject Seam beans into your...I can't remember what the markup language you use for writing in Flex is, but you can inject them directly in there and use it straight from there.

They've written a load of code to allow you to send managed entities, for example, across the wire and then come back across the wire having been modified on the client side, still as managed entities. They've done a huge amount of work there.

We're going to definitely see that sort of work continuing into the WebBeans series as we go forward.

DZone: Pete, do you have any data on the current marketplace in terms of JBoss user base - is there  a predominant combination of frameworks that people are using out there today?

Pete: Yeah, sure. I don't actually have any specific data, so what I'm going to say, I guess, is more my gut feeling than anything else. My feeling is the majority of people with Seam are still using JSF. And certainly for a long time Seam was primarily focused on JSF. More recently, we've started looking at other frameworks like Wicket or Flex. I think the other one we see the most interest around is definitely Flex. That's the second most popular framework after JSF. So as we go forward, yeah, definitely improving support for the frameworks.
But I don't have any concrete data to discuss.

DZone: Could you describe some of the performance and scalability enhancements you've made to Seam since the 2.0 release?

Pete: Absolutely. There have been a number of minor performance and scalability enhancements made to Seam since the 2.0 release. We did some performance analysis, some scalability analysis ourselves. And there were quite a few improvements to the Seam code base. Looking forward towards WebBeans and 299, which is sort of the topic of this discussion, there were a number of things we learned from writing Seam, from the design of Seam, which obviously has an impact on performance.

It's all very well saying that you can optimize the implementation, but there were a number of design problems with the Seam core that were very hard to work around, to get excellent performance out of it. There were a number of issues there, which required you to work around things in a particular way to get great performance.

So with 299, we were actually able to take all of these lessons and build them up to a performant design, so things happen in a much faster way. That was really the first thing, I guess, that we've actually improved the performance in the build and design.

The second thing is, again, we've taken the lessons from the core implementation and integrated those into the WebBeans release.

So really the key things that WebBeans does to make your application more performant and more scalable - and this is also a usability thing, actually - is to take as much of the translation of how you do your dependency injection, how you do the wiring design and to do it all at one time, to do it all as early as possible.

This is great, because not only do you get your errors reported back to you sooner - you deploy your app and you get your errors reported back. If you've got tooling, the tooling can actually highlight those errors for you as you develop.

But also it makes it much more performant, because now we have knowledge about what we're going to do at runtime and then we can just do things and it runs without having to calculate these things. We just know what to do straightaway.

So I haven't unfortunately managed to schedule any scalability and performance analysis of JBoss with WebBeans, which is something we're going to be doing before the release of the 1.0.0 release of WebBeans, but my instinct is that it runs a lot faster than Seam, so I'm pretty happy about that.

It shows that the design of the implementation, the choices that we've made, have really paid off.


DZone: So how does Seam 3.0 fit into the picture?

Pete: We talked a bit about this earlier. We talked about 299 and the additional modules JBoss would provide. This is really where Seam fits in. If you think about what Seam provides today, Seam really provides three or four things. It provides a core for the contextual dependency injection engine. It provides a number of enhancements to JSF. It provides a set of modules and a set of extra additional functionalities you commonly need when building an application. And it provides tooling for the development environment that works well with all the bits we've selected.

Obviously, if you take contexts and dependency injection itself, those in 299 and the specification for WebBeans, we've taken most of the lessons we've learned with JSF and fed them back into the JSF spec, so most of those go into JSF 2.0, which then really leaves the two other things, right? It leaves this application stack, taking all these integrations with other frameworks, all these modules we think you need for developing applications, and it leaves the tooling.

So what Seam becomes is much of an overarching framework, overarching grouping of these modules, which you can use to build your application, with good tooling, with good integration between them. So that's really how Seam 3.0 looks to me, going forward.

DZone: Is JSF 2.0 a significant move forward based on some the lessons you've learned from the current version of the spec?

Pete: Yeah. JSF 2.0 is a very big step forward in my opinion. I was on the expert design group and helped design quite a few of the features, so of course I'm going to say that. But let me just give you a brief idea of the kind of things that have gone into JSF 2.0. I've been at a couple of conferences recently, where people were presenting on this, and I realized after about three talks, not all the features had been covered yet. We'd had three hours of just going over the features and outlining them and we still were nowhere near covering all of them.

You've got Ajax support built in, so that's based on things like ICEfaces and Ajax4JSF. Facelets is built in and Faces has been extended to allow easy component creation, declarative component creation, using Java to create components....

All of the page parameter stuff from Seam has gone in, which will allow you to do bookmarkable URLs, RESTful URLs and you can do navigation like this.

What else is in there? There's much better exception handling. There's an event system so JSF now fires off all sorts of events through its lifecycle. You can register listeners and do things with that. That's great for framework integration, but it's also great for the users as well.

There's a lot of standardization around resource handling, which is good for framework interoperability. Other framework interoperability improvements to allow different component sets can work together.

A huge number of sort of smaller features taken from Seam and other places like Apache. So missing methods on classes and missing functionality on various components.

There's been a big upgrade to the lifecycle of components. A lot of the lessons learned from Trinidad, Apache Trinidad, we're taken and integrated in and hopefully there's greater performance, better performance for the system, with a much lower memory footprint. I think that's like key ones, but there's lots of small ones.

In my opinion, it's a huge step forward and it's where JSF needs to be. And I think the spec is going final in a few weeks time now. So it should be ready JavaOne.

DZone: How will Seam 3.0 support legacy Seam applications?

Pete: Absolutely. This is a really good question and one that we have to address. I've already alluded to one part of the solution in saying that we'll have this Spring bridge that you can take your applications, and you can inject Spring components into WebBeans et cetera. Well, this is the same thing for Seam 2.0 components, so that you can easily take an existing library of Seam 2.0 components or something like that and inject them into WebBeans and vice-versa, and you can inject your WebBeans into Seam.

That will be the first thing we'll offer. We'll offer that for the 1.0.0 release of WebBeans. But that sort of thing ought to give the full ability to run you Seam app in the WebBeans container and that's just the ability to allow the two to interoperate. We also plan to do a full sort of emulation layer. I think that's the descriptive term for it, right?

What we'll do is we'll emulate the Seam 2.0 functionality running on Seam 3.0, so you can run your Seam 2.0 apps natively. And we're going to be looking for a lot of help from the community on this one too. We're going to need to identify what are the major APIs that they use in Seam 2.0, so that we can port those first and get those running first.

So we'll be looking for information feedback on what the main compatibility points are, where people use the Seam API for the most part.

DZone: I presume there will be more than enough incentive for people to migrate over to Seam 3.0.

Pete: Absolutely. From my perspective, not only is it a standard - which is great, it means you can run this on any app server basically. But it's a major advancement in the programming model over Seam 2.0. So I think it's a big enhancement. There's a really good reason to write your apps in Seam anyway, and this is much better, a much better model.

DZone:  Pete, it's been a real pleasure reconnecting with you today and getting up to date on some of the stuff you've been working on around Seam 3.0 and JSR 299. Are there any other final words you'd like to express to the DZone readership?

Pete: The obvious one would be, check out some of the stuff we've been talking about today. We talked about JSF 2.0, as I said, that's final very soon. You can download the reference implementation and have a look at some of the example apps. The Apache implementation is also looking good. We talked about WebBeans a lot. We just released, in fact, the WebBeans first feature complete preview of WebBeans, so please download that, try it out.

You can go to the seamframework.org and go to the download section and you can find it there. There are a number of examples apps in there that you can play around with, but there are no big example apps in that download.

What we're currently working on is porting some of the Seam example apps over. You can expect those in about three to four week's time and those are really good examples that really show what you can do with this stuff.

DZone: Pete, thank you very much for your time today.

Pete: Thank you so much.