Unless you've had your head in the sand for the past 18 months then you can't fail to have noticed the releases of JBossAS 6 and then the move through various betas of AS 7. Well we are on the final leg of what at times has seemed like a marathon and at others like a sprint. The team, which includes the various individual project teams, productisation teams, docs and QE, have been working flat out and I can tell you all that once we are finished with the EAP 6 release we will party!

But when AS 7 finally comes out why should you be bothered, especially if you're a user of one of our current releases? There are many reasons and some of them you would probably expect us, or any vendor, about to release the next shiny new product to talk about. So I could talk about the significant performance improvements we've made across a range of projects, such as HornetQ, JBossTS and Hibernate. I could also mention the reduction in runtime footprint that enables us to run the application server on a plug computer. Of course you probably already know about the rapid boot time and additions to our eclipse tool suite that make it one of the top Eclipse downloads. And you may have experienced first hand the developer-oriented features such as the new logging or streamlined build processes. So I'm not going to mention any of those things!

Instead I'm going to concentrate on a few of my personal favourites as well as those of the rest of the JBoss team. So in no specific order, here are 10 things you really need to know about JBossAS 7:

1: full and web profile implementation of Java Enterprise Edition 6. Of course we've been heading in this direction for a while, with previews in JBossAS 5 and a web profile in JBossAS 6, but this time we'll complete that journey and in style! Implementing EE6 is a challenge that only some vendors can match, but implementing it in a way that really shows the full power and flexibility of the standard is a far better and meaningful approach! Several of the key components within our application server have either been rewritten or updated to become best of breed, such as HornetQ, RESTEasy or Infinispan, or were best of breed to start with, such as JBossTS, Web Services or JGroups. If the whole is greater than or equal to the sum of its individual parts then this isn't just any old EE6 implementation, it's the best EE6 implementation!

2: a core part of EE6 and one of it's greatest improvements over previous versions, is CDI. This is a specification which we lead and drove through the JCP and where we also provide the reference implementation, Weld. The specification grew out of our experiences with Seam as well as various legacy frameworks that rely on XML for bindings. CDI makes the development of complex applications straightforward because it hides all of the complexities of non-functional capabilities such as transactions and security. And importantly it does this through annotations, so that you develop using POJOs, which is far more natural for Java developers than early 21st century techniques!

3: a new modular services container replacing the JBossAS 5 & 6 microcontainer. Now before you roll your eyes and move on to the next item, I know better than most that modular containers have been around for a long time. The original Bluestone Total-E-Server/HP-AS was one of the first implementations and we even created a JSR called the Core Services Framework to try to standardise on this type of architectural approach. And JBoss has had a couple of goes at this too. But this time we went back to basics, with the Modular Services Container, and wrote new algorithms for checking module/service dependencies at deploy and run time, such that only the services you need are loaded and started, and when no longer needed unloaded. You no longer have to trim your deployment to get a minimal memory footprint and start time: we give you them out of the box, and if you add your own services later to create new "profiles" then you can be sure that you'll always get the optimal configurations because the container will enforce that for you. As I've said several times over the past year or so, this is very much a SOA-like approach.

4: no more classloader hell! In conjunction with the MSC redesign, the team also took the opportunity to rewrite the book on how classloaders work. Now how you use classloaders, what type of classloader to use and when, are much more carefully defined. The modular approach makes the scoping of classloaders easier and more narrowly defined, helping to avoid conflicts: now you have to explicitly allow deployed services and applications to see and use dependencies. Oh and as a result of this rearchitecture you'll also see a performance improvement as the application server no longer scans the classpath every time a new class is loaded.

5: testable by design. Over the years we've learnt a lot about testing our projects in isolation and in conjunction with each other. Of course we use Hudson/Jenkins and we also inherited the Distributed Test Framework. But it wasn't really until the development of JBossAS 6 & 7 that we had the need to make sure that they were implemented from the ground up with testability in mind. As a result we have Arquillian which is being implemented in lock step with JBossAS 7 and also proving to be a hit in it's own right. In fact the combination of JBossAS and Arquillian offer an environment that is unparalleled in it's simplicity and power. Factor in other projects, such as Byteman, that allow for far more complex testing, such as fault injection, and you have an environment that will produce the most tested implementation yet.

6: configuration and domain management has been improved significantly. Gone are the days when you had N different configuration files for the M different components within the application server. Now there will be only one! And changing configurations is much better supported through a shell (command line) and programmatically, with both fully synchronised. If you've used Un*x shells then you'll find familiarity with the shell, with tab completion and an extensive suite of commands, which allow you to monitor and manage the application server as well as applications that are deployed on it. But beyond making managing a single instance easier, we've gone much further with clusters. Manual updates of changes to individual cluster members, often an error prone approach, have been replaced with the new domain manager, which automates the process using a master/slave or coordinator/cohort mechanism.

7: RESTful services and interfaces throughout. Of course with the adoption of JAX-RS as part of EE6, REST is now as well supported and available to application developers as Web Services. But that's not the same thing as having core parts of the application server available through REST. In JBossAS 7 we've now got projects such as HornetQ, Infinispan and management, exposing REST interfaces. And other work is being driven through the RESTEasy project as REST-Star, including transactions and security.

8: OSGi has evolved a lot over the years from its narrowly scope beginning. These days it seems that everyone is either looking to implement OSGi containers or develop their applications using OSGi bundles. A while back we announced that we would support OSGi on EAP 5 and beyond, but that we would not be using one of the containers already available. The reasons for supporting OSGi are fairly obvious, including the fact that it has become a de facto standard and we want to continue our mission of portability of applications (plus for some scenarios, such as SOA, a bundle is a very natural choice for deploying a service). But why not use one of the existing implementations? Well for a start we've got our own excellent container implementation. But realistically we want to support a range of models, so we don't want to rule anything out at this point. And our OSGi implementation on the new JBossAS7 container has improved the support significantly.

9: multiple language support. Ok, not quite a feature of JBossAS 7, but because we've made sure that we focus on developers and what they want, we've opened up a whole range of use cases that were rather difficult to do previously. So projects like TorqueBox, which offer Ruby users access to enterprise capabilities, have been able to spring up on JBossAS 6 & 7. And other projects, such as Infinispan, are finding calls for integration with, say, Scala on the rise. This is great, because it helps to showcase JBossEverywhere once again!

10: We've been sure to make the architecture of the application server cloud-friendly, so that it's the perfect substrate for an enterprise Java PaaS (and through indirection and abstraction techniques such as those employed by TorqueBox, for a much wider choice of languages as well.) Of course it's going to be a number of years before the Java Enterprise Edition standard really tackles the cloud through EE7 and EE8, but we are already pushing that envelope. If you're interested in seeing how the future of PaaS will unfold then you can get a glimpse of that by watching JBossAS 7 and beyond.

So there you go. 10 things that make JBossAS 7 stand out from its predecessors and the competition. Hopefully when you try it out you'll agree with some of these and maybe come up with some of your own (some things we may take for granted might be significant improvements in your life.) Over the next few weeks you'll see and hear more from us on AS7. And maybe, just maybe, I'll get a chance to make some more bigger announcements soon!