Now that we are coming close to the final release of EE6, which includes some great technologies we've been leading, it's time for us to consider where we want to go in the future on a number of fronts. But the one I'll look at in this entry is probably one of the most important (it's certainly one of the ones most developers will encounter.) What component model should you be using when developing EE applications in general and specifically when looking at JBoss projects and associated platforms? The interesting thing about frameworks, or probably more specifically about frameworks and Java, is that if you ask 10 developers which one they prefer you'll probably get 11 different answers. So obviously you could try to please all of the people all of the time and probably fail miserably, ending up not being able to please any of the people any of the time, or you could take a pragmatic approach and concentrate on a few of the more popular candidates out there that the majority of people are comfortable with, or even better yet, prefer.
Over the last few years we've spent a lot of time and effort on developing a component model ourselves: Seam. Now Seam began life with some very specific goals in mind, but over the years through community users as well as involvement in the JSR 299 standardization process, it has grown in power and popularity. For instance, Seam is now used regularly in our SOA Platform and pulls in more features from other projects such as jBPM and Drools. In parallel we've seen an increasing number of people ask what is the component model that they should be targeting for applications running across different projects and platforms? In the pure EE space there are a number of answers. In SOA there are just as many. What's really needed is something that can unify these various approaches and provide a single solution. Of course there may be times when developers want to or need to stray outside this, but those should be the exception and not the rule.
So this is where Seam comes in: for the majority of users it shouldn't matter whether you are developing on EE or SOA, for example, if the component model is sufficiently powerful and flexible. As I said before, power and flexibility are at the core of Seam, thanks to the excellent work of Gavin, Pete and the team. Therefore, that future for all of our projects and platform is Seam. The team are already working closely with those projects and platforms, such as ESB and SOA-P, to ensure that new versions of Seam take into account their unique requirements. Importantly though, some of those projects had already decided that Seam was right for them even without any modifications to it, so it's likely you will see closer and quicker integration than some thought possible.
But what will this mean for developers, particularly those who don't want to use Seam? Well as I said at the start, we are not abandoning other popular frameworks and will continue to support them as we do today. In fact the Seam team are doing a lot to work more closely with those alternatives, particularly through standardization. But for the majority of our community and customers this will mean they won't have to worry about learning a new component model when they move between platforms. It will also mean that projects can target Seam as the standard for their community, making the work of assembling our platforms from individual projects that much easier and more efficient when the same component model is used throughout. Reusing components will become a reality not for one or two projects, but for them all. And not just now, but well into the future!