After a rather long development cycle the JBoss AS 5 RC1 is only a handful of days away from its release. InfoQ caught up with project lead Dimitris Andreadis to discuss the new features and release timeline. Dimitris also comments on Java EE 6 features, the advantages of JBoss AS with respect to competition and their choice of having a pluggable components model instead of sticking just to OSGi:
InfoQ: Could you give us a short list of the main features of this release and the key additions from the earlier versions? Also a short mentioning of the new APIs?
In JBoss AS5 the majority of visible new feature additions comes from taking all major JBoss subsystems to the next level:
JBoss Messaging 1.4 replacing the older JBossMQ is now the default JMS provider. JBM supports clustered Queues and Topics out-of-the-box along with transparent fail-over and intelligent message redistribution. Messages can be replicated in memory across nodes avoiding disk I/O, or be persisted to any popular relational database using paging techniques with support for very large messages. JBM demonstrates impressive performance and things will only get better with the new append-only journaling storage that comes down the line.
JBoss WebServices 3.0, with full support for JAX-WS/JAX-RPC, attachments with XOP & SwA, and a host of WS-* standards. JBWS moved to a pluggable architecture that allows the replacement of the underlying WebServices stack, so you can swap JBossWS-native, with Sun Metro or Apache CXF. Thus you should be able to use the webservices stack best suited to the problem at hand.
Clustering in AS5 supports buddy replication for SFSBs for improved scalability and passivation for clustered web sessions to control memory usage. EJB3 Entity & Hibernate caching is very much improved because we can now use separate caches for Entities (invalidation cache) and Queries (replication cache). There are also other performance improvements in the underlying JGroups protocol stack.
JBoss Transactions is the default transaction manager for JBoss 5. JBoss TS has already been tested in the AS 4.2 series together with JBoss Web, the servlet container in JBoss 5, an implementation based on Apache Tomcat with support for native APR-based connectors for achieving scalability and performance characteristics that match and exceed that of the Apache Http server.
In term of APIs, AS5 is an implementation of Java EE 5 so you would expect to find implementations for all the related APIs. For most of the APIs "new" to Java EE 5, like EJB3, JAX-WS, JPA, etc., implementations already existed in our JBoss AS 4.2 series, however, with JBoss AS5, the conformance requirements are certainly more strict due to increased coverage of TCK testing.
Info: The fact that version 5 of the JBoss Application Server had a rather long development cycle has been criticized several times. At least with respect to other containers. Why is that? Did the 4.2 release contribute to this delay at all?
Certainly JBoss AS 4.2 and the first version of the Enterprise Application Platform (EAP 4.2) took their toll on AS 5. We were thin on resources and the productization effort that follows the Fedora/RHEL model was something new to us (JBossians). On the other hand, 4.2 was a stepping stone and a testing ground for various JBoss technologies (e.g. JBoss Transactions) that were ready before AS5 could be released, so it's good that those pieces went out to the community faster.
On the other hand, the sheer scope of AS5 was something that, in my opinion, nobody had realized when this effort started about 3 years ago. Creating from zero a completely new kernel, switching from MBeans to POJOs, integrating AOP to the lowest level, unifying metadata handling across subsystems, altering the classloading system, aspectizing the deployers, in other words changing the internal architecture and replacing the guts of the application server, while maintaining backwards compatibility with the majority of existing services, that was just too much work with big challenges in every step of the way.
Another logistics problem came up by introducing proper SPIs to the various internal subsystems. This is good in the long term because it allows extreme plugability and an ala-cart usage of the JBoss projects in different runtime environments (e.g. standalone EJB3 or embedded into a different appserver). However having to maintain dozens (I've lost count) micro-projects imposes a significant overhead. Add to that the pain of moving such a large codebase to maven2 and you get the idea.
Of course, for the end-users, the developers that want to use JBoss, those are internal implementation details and the delay of a fully certified Java EE 5 JBoss is an annoyance to them. I can only apologize to those users and thank them for their patience with the hope that as soon as AS5 is out and any initial glitches resolved, the results will be rewarding.
JBoss AS5 is not just a Java EE 5 appserver. It encompasses the vision for a state-of-the-art server runtime environment for the next generation of JBoss projects.
InfoQ: With the final beta released on February would you like to tell us about when RC1 will be out? When do you think the final version will come?
CR1 (Candidate Release) should be out really soon at the end of June (we are almost there). This will be followed up by CR2 release in the beginning of August. Depending on the community input we receive from the CR releases we will decide on the final delivery date.
Getting JBoss AS5 out is currently our top priority.
InfoQ: What's JBoss's perspective on the Java EE 6 feature set which is currently under debate and in particular the profiles?
Personally I have mixed feelings over the proposal of profiles in Java EE 6. The primary purpose of having a Java EE specification is to provide the developers with a comprehensive tool set of EE technologies so that applications have a greater chance of being portable between compliant runtimes. By reducing this set of technologies to a very small subset (e.g. profile A) you are forcing the developers to add non-spec compliant extensions, thus decreasing the portability of EE applications.
Now the ability to have streamlined configurations so that you can avoid carrying the runtime overhead of technologies you are not using, this is a completely different thing. From the early days JBossAS shipped with three pre-defined profiles (minimal, default and all, and a few more if you were using the jems installer) and you always had the freedom to further slim down the server configuration to what you actually use. Don't want JMS, just remove that particular subsystem. But this is just an implementation detail of the platform provider.
What is important is for the broader set of Java EE technologies to be comprehensive, generally useful and current. The introduction of EJB3, JPA, JAX-WS were huge boost to the platform. The pruning process is also a step to the right direction. There are parts of the Java EE spec that are really edge cases (e.g. CSIv2), or obsoleted (e.g. CMP) and they should be retired from the platform. However, when discussing whether a basic profile should offer JSP vs. JSF that's just silly; there are good uses of both technologies out there.
I really don't see the point of putting the EE stamp on tomcat (profile A), other than allowing some small player to come up with a couple of extensions to tomcat and advertise that as Java EE. Or having a more beef-up tomcat configuration (profile B) that doesn't let you do web services. So overall, I believe profiles are likely to do more harm than good to the Java EE community.
InfoQ: Recently SpringSource released the Spring Application Platform, a module-based Java application server that is designed to run Spring-powered applications. Does JBoss foresee creating a standalone app server using JBoss technologies (Hibernate, Seam, Messaging, etc) as SpringSource has done?
As you know, you can trim down the JBoss AS configuration to the set of services that you actually need; this has always been possible with JBoss. Now having a pre-defined web configuration, this looks like more like a marketing decision at this point rather than a technical one. Removing capabilities and features is easier than adding new ones. For the time being we have focused on moving higher up the chain by introducing the JBoss Enterprise SOA Platform that adds JBoss ESB, JBoss jBPM and JBoss Rules functionality on top of JBoss EAP. But if there is true market demand, or the Java EE 6 profiles go forward, we'll probably create and support a Web Platform bundle, too.
InfoQ: Using OSGi for server side application is something ubiquitous these days. It is actually the choice for both GlassFish and the Spring Application Platform. JBoss 5 instead will have an architecture that allows for the component model to be pluggable allowing both compatibility with old code bases and inclusion of improved component models in future. Do you find this to be a strategic advantage over your competitors?
Definitely.
Looking back, JBoss was the first Java application server build on top of a dynamic microkernel architecture since 2001. The JMX MBeanServer served as the kernel core with MBeans being the component model for plug-in services to the kernel. This was a great choice at the time but later on as POJO and AOP became the dominant programming model we started seeing the limitations of the JMX core. In a first refactoring step in JBoss 3, we wrote our own JMX kernel replacement (JBossMX) for offering POJO and interceptor support through XMBeans, but it soon became evident that the way forward was a true POJO kernel under our full control.
After 3 years of R&D with JBoss 5 we've learned the hard way that switching kernels and component models can be a very painful process: it is plain wrong to tie in your server internals to any particular component model. Our competition will most likely suffer the same pain when for some reason OSGi goes out of fashion, or some cooler component model comes along. In one sense they look like JBoss 7 years ago.
For JBoss however, the support for a new component model will be as simple as building a new Facade on top of the JBoss Microcontainer. The same way we support natively POJOs, legacy MBeans, and soon OSGi bundles, we will support any other existing or future component model of interest. The power of abstraction to its best!
InfoQ: Regarding the pluggable component models, will the developer be able to share information between them and have them collaborate?
Yes, and that's the beauty of it. Since all the components in JBoss irrespective of type (POJOs, MBean, Spring Beans, OSGi bundles, etc.) share the same back-plane they have the potential of being wired together by the MicroContainer with dependencies and aspects applied across the different component models. We are still at the early stages of understanding the capabilities and limits of the MicroContainer technology, designed by our mastermind Adrian Brock, but the possibilities look certainly very interesting.
InfoQ: Do you have any comments regarding the future directions of the JBoss AS that you would like to share with the InfoQ audience? What comes after version 5?
Well, our primary focus at this point is to deliver AS5 of so I don't want to make too many predictions about the future. What I do know is that AS5 will provide a healthy foundation and a fully extensible, cross component model, aspect integration runtime environment on top of which innovation can happen at a much faster pace. In this regard I expect AS6 to come out a lot quicker than the time it took us to create AS5!
There are areas that we will certainly give more attention, like OSGi support and improving the management features of the server especially in the context of large deployments. There is also a lot of innovation in the pipeline coming in through the various JBoss projects; and with the opening of Java we can expect to see improvements in the JVM itself and some tighter integration with the application server, especially on the Linux side of things.
For more information regarding the JBoss AS and related products you can visit: http://www.infoq.com/jboss