Many have been wondering about the status of JBoss AS 5.0, so I thought I would give more visibility in what we are achieving.
First, a bit of history. In 2001, JBoss was the first application server to feature a complete micro-kernel architecture (based on JMX) - both for applications and for services. In the following years, we gathered a great amount of expertise in that field. In parallel, we did a lot of research in projects like JBoss AOP, JBoss Remoting, embedded EJB3 and decided we needed to be ready for the “next generation” AS architecture. This led to the start of “JBoss AS 5.0″ three years ago. The idea was to move to a much more generic micro-kernel architecture that could suit multiple “personalities” (OSGi, JMX, pure POJO, etc.) and fully componentize (through APIs and SPIs) and aspectize our AS down to the bare minimum “Lego blocks”. Also, we wanted our new runtime to have full manageability features as a core aspect, not as an afterthought. The magnitude of these core changes came at the expenses of a reliable roadmap - hence the multiple delays in releasing JBoss AS 5.0. BTW, if you want to read more about the new architecture of JBoss AS, you should definitively read Dimitris Andreadis’s excellent interview at InfoQ.
So, was all of this just a fancy engineering exercise? No, not at all. This investment will have a drastic impact on the overall JBoss Enterprise Middleware offering, its longevity and its ability to adapt to market changes. If you take a 40′000 foot view of the AS market, you can essentially split it in three layers:
- The base runtime
- The core middleware services
- The programming model/API & language
In the case of JBoss, the runtime is the JVM. You can find many non-Java VMs regularly pop-up here and there, but none of them is close to approaching the level of engineering this ecosystem has put into the JVM. The JVM is pretty generic, can support multiple languages and has about 15 years of heavy engineering practice behind it. From mobile phones to Azul appliances, the JVM has shown great abilities. Would another VM come up with better features, fine, let’s move to it: now that the JDK has been made open source, we could adapt it to any other environment while keeping compatibility with the previous generation JVM.
As for the second layer, the middleware services, this is where JBoss excels. We have built rock solid, scalable and flexible middleware services (security, persistence, transactions, remoting, clustering, etc.) that can be re-used among our various platforms, they are our “Enterprise Lego Blocks”. JBoss AS 5.0 will make use of the last generation of all of these services: JBoss Messaging, JBoss TS (ex-Arjuna/HP TM), etc. Again, unfocusing from JBoss AS for a minute, these are Lego blocks that can be leveraged by *any* middleware environment, any platform: you can be a EE5 developer, a web developer using so-called “thin-frameworks” or integrating two legacy systems, this doesn’t change anything: you’ll always need to rely on security, transactions, remoting, clustering, etc. And you want those services to be the best ones. We have spent a enormous amount of work in the last years to build and strengthen those.
The last layer, the language/programming model/API, is what developers will interact with. Which one is best? EE5? Seam? Spring? Grails? Well, you’ll end up with as many opinions as developers. The rule usually being that the more fashionable these APIs are, the less they will last (i.e. boring == good). Consequently, this third layer needs to be the most flexible and rely as much as possible on the enterprises Lego blocks from the layer below. Languages and APIs are often a matter of taste; relying on secure, scalable, stable, manageable and clustered services is usually NOT a matter of taste. Our architecture has been designed from its foundation to accommodate huge agility in the programming model, at a low R&D marginal cost.
So, where does that put us? JBoss AS 5.0 is the first release which will give us the ability to cleanly separate those three layers. The JBoss Microcontainer abstracts us from the runtime environment and our core enterprise services have been completely componentized and aspectized so they can be fully leveraged from any higher level framework/API/language.
This new architecture means your investment in JBoss is a long term one. Our core architecture is not dependent on any fashionable spec or language du jour: personalities can be plugged in and out, à la carte, you don’t have to make a bet on which API is “the” API you need, and then be locked in one of the few AS implementations that implement such API - possibly relying on weaker core middleware services.
Now, while the decision to move to this next generation architecture was very strategic and will prove to be a key differentiator in the next few years, it is fair to wonder what was the impact of such a decision on the availability of an EE5-certified AS. Did we alienate many customers by being so late with an EE5-certified offering? Truth be said, not really. JBoss AS 4.2/EAP4.x already provides compatibility with the key EE5 specs (including EJB3) and this was more than enough for most of our customers, and by no means a show stopper. We do have a number of customers who are eagerly waiting for a 5.0 release and we are in close touch with them. But what is interesting is that about 80% of those customers are not waiting for an EE5-certified application server, but want to leverage specific features of our AS 5.0 architecture (mostly our JBoss Microcontainer).
Anyway, onto some more specifics now. JBoss AS5.0 RC1 just got frozen and will be released this week. This is a very important release as the release criteria were aggressive . We are now working against RC2 (count 6-7 weeks - summer time) and GA should follow closely thereafter
: we are now above 99.x% EE5 TCK and our AS5 testsuite has less than 1% tests failing.