I mentioned earlier about presenting at a couple of JBUGs this week. Fortunately both presentations were on the same subject: where next for JBoss. Both events were packed. I'm not sure of the exact make-up of the audience in London (and thanks to Atos for hosting!), but in Newcastle we had people from the University as well as several local companies, all either existing users of our projects or considering using them. In Newcastle we managed to duplicate the keynote demonstration too, though this time without the mobile device UIs that we showed in Boston. It went very smoothly! There were some good questions too around some of the underlying aims behind JBossEverywhere and hopefully I persuaded some of the new attendees to come back to future events.

At the London event I didn't have the luxury of the hardware we used for the demo, so instead I took a copy of the official video. Again it was a packed room, with a number of JBoss/Red Hat people there including Manik Surtani (who was wearing almost exactly the same outfit as he did in Boston!) So once I ran through the slides, we watched the video and I took questions again. Some of the key concepts seemed to resonate with folks, although there were specific questions around Cloud and how it relates: as I tried to say in the video, I think this is the future of Cloud, so our current strategy with efforts such as OpenShift are complimentary. Plus as I pointed out during the talk, it's good to have a vision to catalyse people and focus their efforts.

I enjoyed presenting at both events. It was good to hear comments and suggestions. I know that this theme is something that I'll be focussing on quite a bit for the rest of this year, with several presentations already submitted to a variety of conferences and workshops. And maybe other JBUGs if there's interest!

If you've watched the video of my JBossWorld keynote or followed other presentations I've given around the future of JBoss or middleware in general, then you may have heard me talk about JBoss technologies evolving into a fabric, or ubiquitous middleware that is always there, in the background, no matter what device you may be deploying your application on. The name "fabric" springs to mind, though it is used by many others to mean different things. I suppose another word to use might be "ether", given the historical use of the word in the physics community. (OK we would need to ignore the fact that the belief in the ether ended when Michelson-Morley's experiment proved it did not exist.)

Let's stick with Fabric for now though. Well at the Red Hat Partner Summit I was giving a presentation on The Future of JBoss and was talking about JBoss as a Fabric. I've used a number of analogies to try to illustrate what I mean by this, including the distributed operating system one I've used before. Another one I used was that of TCP or UDP: capabilities that we all just take for granted these days, no matter where you're deploying your application these days. Now of course not all of the JBoss capabilities (projects) will be available in all environments. So in the grand tradition of cloud (to which we are most certainly not tying Fabric), I suppose we are talking about Just enough Middleware (JeM), Just enough JBoss (JeJ), or Just enough Application Server (JeAS) - though I've used that one before.

So what next? Well I'm fairly sure I want to create a new project for Fabric so that the wider community can get involved, though I may wait until after AS7 goes final. That means a project name of course, which is a problem as I'm not so good with names. Maybe Aether?

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!

Now that the dust has settled on JBossWorld and we've started to talk about JBossEverywhere, it's time to announce a few things that you should expect to see and be able to contribute to over the coming months and years. I want to write some of these pieces regularly to give everyone an idea of where we are going. Maybe at some point we'll create a JBossEverywhere project so there'll be the usual forums for people to use.

If you recall, one of the aims behind JBossEverywhere is to enable our projects and platforms to run on arbitrary devices. However, that is a relatively straightforward thing to achieve, at least with many of our projects. The ultimate aim is to design and implement an infrastructure that can support an application across a wide variety of environment, ranging from embedded devices through to the mainframe. To achieve this we'll be looking back as well as forward in terms of research and development. Approaches such as disconnected operation and dynamic adaptability from the 80's and 90's, genetic algorithms and event driven architectures from the past decade, and highly asynchronous distributed systems as well as the continuing rise of REST from the last few years and into the next, will be instrumental in the evolution of JBoss. But at the heart of what we will be developing will be core technologies such as JBoss Modules.

Now you may ask "will we be using <fill in the blank> as it stands?" For instance "will we be using HornetQ/JMS as it stands?" There's no stock answer that can be used, except "maybe". If you look at JMS, I think it has several deficiencies as far as Java EE goes, but it's definitely good enough. However, I don't believe it is the right API for a truly asynchronous message-oriented infrastructure. But that doesn't mean our implementation, HornetQ in this case, isn't right for that infrastructure. We've been very lucky over the years and all of our projects that support standard APIs such as JMS, JTA or JPA, tend to have far more flexible and versatile APIs under the covers. We may decide to use some of these APIs as they are, or we could provide more layers on top.

From the perspective of the implementation language, we'll obviously be concentrating on Java, but others such as Ruby, Ceylon and Scala will definitely play a role. We live in a time where multiple languages within an environment or application are the norm and to ignore that fact is either silly or arrogant. I like to think we are neither! So if you are not into Java, that doesn't mean you can't contribute. Quite the contrary: we need you more than most!

There are many questions that remain unanswered at the moment, and just as many that remain unasked. We don't have the answer to them all. I don't have the answers to them all (yet). But the fun bit is a combination of asking them and then searching for those answers. (Understanding the questions that you need to ask is often as informative as finding the answers to them.) But one question I've been asking myself for a few years is: precisely what is the abstraction we're trying to get? Well in a past life I did some work on distributed operating systems, where the abstraction presented to users was of a single, logical OS even if it spanned an arbitrary number of physical nodes/machines. (Let's ignore the facts that hiding distribution is often not the right thing to do!) This is the kind of abstraction I think makes sense for JBossEverywhere: the abstraction of a single logical middleware layer, even if it spans an arbitrary number of machines of an arbitrary type, e.g., mobile, mainframe or laptop. Domain specific APIs, such as Java EE, layer on top of this, adding or hiding capabilities where necessary. Because of course whatever we develop has to continue to be used within our EE suite of projects and platforms.

So does this mean, for example, that you can expect to see JBossAS running on natively on, say, an Android device? Well I really don't see why not, from a technical perspective. And I'd love to see it happen, as it's a logical extension of some things I started (and implemented) almost 2 decades ago! But this will be a long R&D process and the journey will be as interesting and innovative as the end results. And I'm loving the times that I can grab to put more flesh on to the bones of this goal: ubiquitous jboss!

I hope you are as excited by this as I am. How many other middleware vendors offer you the opportunity to get involved and shape the next generation? Most of them will simply say this is how it's going to be, like it or not. But that's not how we operate!

I've been tracking the TorqueBox team for a long time, even when the "team" was really just Bob McWhirter. I like what the team are doing and have even been pulled in to learning Ruby and contributing the initial transactions support. So it was good to be able to attend some of their team meeting at JBossWorld and hear the plans for the future. It was also interesting to realise that TorqueBox is yet another example of JBoss Everywhere: providing the enterprise capabilities offered by JBoss projects and platforms to a wider audience of users and developers than we've done traditionally. Who knows ... at some point maybe we'll look at other languages than Ruby to do something similar. Until then check out TorqueBox and my congratulations to the team!

From the beginning of JBoss, JBUGs (JBoss User Groups) have been very important to us and our communities. They're a great way for the communities to share information and to influence what happens in the projects and platforms. We try hard to help JBUGs promote themselves and develop their own identities, and often we'll work with them to get some of our rockstars to the events they hold. However, over the next few weeks and months we're going to be adding more support to the JBUGs to make them even more compelling and help the JBUG organisers as much as possible. So if you've got a JBUG and it's not on our list, or you just want to be sure that the contact information we have for you is accurate, then get in touch with us as soon as possible. If you've any difficulties going through that route, then you can always contact me directly. My goal is to have a pin on the map in every city around the world and maybe even the arctic/antarctic! With your help we can accomplish this!

It's been a frustrating couple of days. I won't go into details, but suffice it to say that between a certain travel bureau and a certain airline, I've been unable to get to Boston for JUDCon as planned until 24 hours later! But I'm on my way now, with my transactions presentation done, an almost final draft of my session on JBoss PaaS completed, some hopes for the expert panel, and lots of meetings planned. But it's my keynote on Tuesday that has my immediate attention as it promises to be different to the usual format: I'll be outlining our vision for the next few years, which goes way beyond (but also includes) the traditional Java EE landscape that JBoss has been associated with successfully for many years, and at the same time illustrating some of these ideas through a highly interactive and visual demonstration that the teams have been working on for several weeks. This demo will be very intense and implicitly as well as explicitly shows the advancements we and our communities have made in a number of areas, not just Cloud. In fact there's so much going on within the demo that I doubt I'll be able to call out all of the projects within the scope of the keynote without overrunning, so what I think I'll do is get the team to write up an article on it specifically after JBossWorld closes. It's very cool and I'm really looking forward to presenting it to the audience on the day!