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!