Skip navigation

We've discussed some of the fallacies that are rumbling through our industry at the moment. Now let's get to some facts and what JBoss is going to do to address them. And this brings us finally to our position and vision behind JBossEverywhere: it is ludicrous for us to discard the experiences, code and communities that we've built up over almost a decade of development. JBoss and open source middleware are intricately linked. Since it's inception back in the early 2000's, JBoss has had various missions and has succeed at them all. Some closed source companies have had to change as a direct result of JBoss. Some have even gone out of business. It's arguable that JBoss has also contributed to the success of a number of other open source projects and companies. Since the acquisition by Red Hat, the JBoss brand has grown more and more successful too. But fundamentally our success is not simply the revenue that we make, though of course that's important (we all like to get a monthly salary!), it's better measured in the number of projects and platforms we have and their technical and community maturity. This isn't looking for plaudits, it's simply a fact.

 

For the past few years we've been focused on Enterprise Middleware as it is defined in the context of J(2)EE and hence servers and mainframes. That isn't going to go away and Red Hat/JBoss will continue to be a strong voice in the JCP Executive Committee as well as the most popular implementation. But we see so much more applicability for what we have when we look beyond these environments. And yes, that means beyond the current definition of Cloud. As I said above, there are more processors sitting relatively idle today that people will want to tap into eventually. Some of those processors may well be sitting in your home or office now. Rather than those communities having to reimplement the wheel, we will be working with them to ensure that the perfectly good wheels we've got can be positioned in those deployment environments too. We are seizing ubiquitous computing.

 

So where will we be in the next 5 or 10 years? Well for a start I'm pretty sure that Java will still be the dominant runtime language and that the Java EE 6/7/8 Application Servers will be at the forefront of enterprise deployments, with the JBoss implementations at the front here too. But developers will always want to use other languages that are more domain specific. For JBossEverywhere this just means that we'll be ensuring that our runtime is available across a much wider set of deployment environments and exposed through as many other languages as makes sense to our communities. If that means we have to develop new projects from scratch, then we will. If it means we have to write in other languages then we will (TorqueBox is only the beginning!) If it means that we have to modify some of our existing projects to better sit in, say, a car engine management system, then we'll make those changes. But I believe strongly that many core enterprise requirements can be met today and in the future by our existing implementations.

 

Now you might ask why I'm so positive about the future of Java and Enterprise Java, when we keep hearing so much doom and gloom? Well I'm not going to suggest that there aren't problems with the current Java processes and if we were happy enough to be lead through this period then we'd have problems. But we are a leader and we won't sit idly by and let things stagnate. You only have to see this with some of the new standards we're pushing, such as JSR 347. And a lot of our rearchitecture of JBossAS 7 and the modular services container gives the ability to look at multitenancy and multi-core approaches.

 

So can I make a fairly obvious mission statement to attract the soundbites? How about this: if JBoss doesn't seize the ubiquitous computing landscape then it will be displaced by others? I think that counts So how are we going to do this? Here are my four steps to succeeding.

 

  • Step 1: make our projects highly embeddable and dynamically configurable. Take a look at the keynote for an example!
  • Step 2: make our projects and platforms available through a range of different languages and not just on the JVM. Scala for instance!
  • Step 3: make our projects known about and open to a much wider community of users and developers. Just because someone isn't interested in using a project within an application server, doesn't mean they are irrelevant. For instance, jBPM 5 running on Android!
  • Step 4: keep pushing for improvements in the Java language and the JVM, as well as looking at other domain specific languages or extensions.

 

So if you're in our communities or just thinking about moving into the Java space, what should you do? Well here are a few recommendations:

 

  • Get involved with our communities are feed in your requirements, as well as code.
  • Encourage your developers to experiment with other languages that run on the JVM, and our implementations if possible, such as TorqueBox.
  • Talk with your teams about their mobile requirements - they will almost certainly have them and knowing about them now will be better for you than having them creep up at the last minute!
  • Create a tiger team to specialise on constrained device applications.

 

JBoss defined open source middleware for the last decade, and arguably influenced strongly closed source too. We are defining it now for the next decade at least! If you want to stick with legacy frameworks for developing languages, then knock yourself out. We'll work well with them, just as we do today. But really, we can do so much better! JBossEverywhere isn't about telling you what you already know you need! It's about showing you what you will need in the future. This is not just about improving JBoss technologies, but about improving the way in which people will work and interact!

I've been talking about the ideas behind JBossEverywhere for a long time and diving into details during and after the keynote. I've also presented on these concepts since to several JBUGs and other groups. Most of the people I've spoken with just "get it", but there have been occasions where I've had to dive into a bit more detail to fully explain what I mean: some things that may seem obvious to me aren't necessary that obvious. Plus I've been asked that despite the vision, what is our stand or position? Well hopefully this article will settle things so we can move on and get this done. Before I go on though, it's worth stating that this will be an unapologetically Java and JBoss specific article: I can make many of the same arguments you're about to hear more generally about middleware, but I'm not going to do that!

 

OK what is our position? Well let's look at some positions or visions that have been attributed to others in the same area we operate. One of them is that Cloud is the death of middleware. Hmmm. Now if that statement had been made by vendors who don't have a vested interest in persuading you to move away from existing middleware implementations to their own, or who don't have any investment in middleware, I might give it more than a few seconds thought. Now of course you could say that given my position, I'm hardly being objective either, and to a degree I can see your point. However, I've lived through 3 decades of middleware standards and implementations, including DCE, CORBA and J(2)EE. My background is heavily influenced by scientific method and analysis, so I try to be objective even when it may go against perceived business sense.

 

So let's just assume that for the rest of this article I'm writing with my professorial hat on and not my Red Hat, OK? And let's think about that statement: "Cloud is the death of middleware". What does it really mean? I think we first need to look at what is meant by middleware, which is pretty poorly defined. Given the vendors involved, I suspect it's more Enterprise Middleware that is assumed. So what is being suggested is that security, transactions, reliable messaging, availability etc. are no longer required in the Cloud? Give me a break! Let's look at a human-centric equivalent of (public) Cloud: outsourcing. If you've ever been involved in outsourcing something, such as IT or a call centre, then you'll have drawn up a set of questions or rules by which the prospective recipient who will run the outsourced effort must be held. These would include looking at their plans for high availability, security of your data (particularly if they host data on behalf of your competitors) and especially how to get in contact with then 24x7 in the case of a problem. If you don't have such a set of criteria and you have outsourced then please let me know so I can make sure I never use you and that if you have any of my data then I can scrub it from your system now!

 

Public Cloud, or at least public PaaS, needs good middleware and needs it now. When you look at what PaaS really is, then defining it as Middleware as a Service is not going to be far off the mark. Why isn't it defined this way? Well just look at where the term PaaS comes from and that will give you your answer. Middleware techniques and protocols have been developed and honed for well over 4 decades and in many cases haven't changed for years. Of course Cloud offers new problems and challenges, such as multitenancy, but some things remain fundamental. And what about scalability? Hmmm, have you ever looked at the Web? That's a pretty big system! It dwarfs any Cloud data centre and works pretty well. So let's put this one to bed: Cloud isn't the death of middleware! Far from it.

 

Before moving on, let's tackle a related statement: that Java Application Servers are either heavyweight or dead. Again, this isn't being said by people in an objective manner. I've already discussed this issue separately, and you should take a look at that for completeness. However, the general gist of that article is that a good implementation of the Java EE specifications need not be heavyweight, bloated or irrelevant to applications that don't need all of the enterprise capabilities. Java EE 6 and beyond are the right stacks to consider, both for small scale and large scale applications, and specifically JBossAS 7. Maturity of implementation is critical in these areas for very obvious reasons, and we have a set of best-of-breed components that other vendors are trying to replicate and continuing to fall short on their aims! The concept of the Application Server will evolve over time, pushed by requirements and restrictions on different deployment environments, but let's not try to kid ourselves that somehow it simply isn't needed: it is, but what *it* is tomorrow will look very different from what it looks like today. And guess what? JBossAS 7 is *it*!

 

Another position I've heard recently is that Java needs to make itself relevant in the Cloud or cede the space to languages such as Ruby. That's so profound and visionary. (Where did I put those sarcasm markups?) That's about as obvious a statement to make as, say, a football coach telling his team that "If we score more points than our opponents then we'll win." Come on, surely we can do better? If any language cannot adapt to changes in the industry then it will be replaced by those that can. That's the way it's been for decades, and no I'm not going to drag up the COBOL reference (oops!) Java, the JVM and Java middleware is already relevant to a large part of the community that wants to move to the Cloud. Of course there are challenges, and I mentioned some of them before, such as multitenancy, which need to be better addressed in the language itself. Statements like that may make good soundbites, but not much more. (I really wish I could remember where I mislaid my sarcasm markups!)

 

As a community I have faith that we'll make those changes and we are definitely involved in pushing those changes forward at a much quicker pace than we've been used to before. But the Cloud, and specifically PaaS, isn't going to be a mono-language area. There will be many different languages for different use cases. But where we stand on this should be fairly obvious, particularly if you roll up both of the positions we've considered so far: for Enterprise PaaS you need Enterprise Middleware, and if CORBA taught us anything it's that you can have a single runtime written in a language that isn't used by your developers and as long as that runtime is good (efficient, reliable, manageable etc.) then your users/developers won't care. They'll see all of the advantages and none of the disadvantages that they associate with the underlying language. We're seeing that already with projects such as TorqueBox, where Ruby developers can use the application server without ever having to know Java. And we'll be seeing more of these kinds of projects from JBoss in the future, but read on.

 

But even looking at these previous two statements they are far too narrowly focused. Yes Cloud is important today, but it's not where we should be putting all of our attention. That needs to be in the area of ubiquitous computing, which should subsume Cloud and mobile. Let's look at mobile for a few moments, and with apologies to others, I'll state what seems to me to be a fairly obvious fact now: there will only be two dominant platforms in the future; iOS and Android. Of course there'll be needs for niche players, but the old order has fallen. Smart phones will dominate and the types of applications that people want to write on devices, such as phones or pads, are already increasing in complexity. Native applications aren't going away any time soon. Yes, I know this kind of bucks the trend, with others pushing for thin clients in general such as the Chrome Book (and yes, I know this isn't for a mobile phone but stick with me on this). But look at it this way: if all we wanted to do was run a browser on the phone to access applications or data that are hosted elsewhere, then we probably should have stopped innovating with the hardware a few years back!

 

There are billions of phones on the planet. But there are tens of billions of processors, including those in your washing machine, games console or car engine management system. Many of them are more powerful than workstations from 2 decades ago! This is ubiquitous computing. It's pretty obvious that the types of applications that will eventually be written for them will grow in complexity and store more information locally. (I've lost count of the number of times I lose wireless or phone signal on my phones and pad!) Application developers, whether on the phone or embedded devices, will want the kinds of capabilities that we take for granted in the JBoss world, including messaging, transactions and security. This is ubiquitous enterprise computing!

 

So now on to the second part of this stand ...

Filter Blog

By date:
By tag: