In this exclusive interview, Mark Little, Director of Engineering at JBoss/RedHat, gives us a snapshot of the JBoss ecosystem and what's being developed. Over the last 12 months, Little says that JBoss has been trying to make it easy for developers to contribute. More of the JBoss projects are being developed so that end users can customize the individual projects, but there is still commonality so that tools can interoperate. Mark talks about Java EE 6, the future of cloud computing and middleware, and shares his thoughts on whether Java really is in better hands under Oracle.
DZone: Mark, can you give us an overview of the JBoss project universe, a snapshot of what’s new and what’s changed over the last 12 months?
Mark Little: So over the last twelve months we’ve done quite a bit in the community and obviously with our product offerings. Probably the biggest thing that we’ve been doing over the last 12 months is trying to make it easier for people in the community to contribute and use those projects. Some of our projects have been re-licensed to try and open up possibilities for them to be used in non-JBoss projects.
For instance, JBoss Messaging was renamed to HornetQ and is now under the Apache license (it used to be under the LGPL license). We’ve also been trying to make the community landing page, jboss.org, more customizable by the individual projects. There was a time where if you went there, all the project pages looked pretty much the same – it was really hard to customize that.
We’ve put a lot of effort into it so that the projects can have a different look and feel, but also so that there is come commonality there because we don’t want people to think that it’s just a collection of different projects, with chaos reigning.
We’re also taking other, non-JBoss projects and hosting those. Although we’re not doing an awful lot of that at this point, we have done a bit of it.
DZone: When we spoke last year you had mentioned that one of your goals had been to establish better synergies between the JBoss universe of projects and the product universe. What’s happened over the last 12 months to better facilitate that?
Mark: We’ve put a lot of effort into making it clearer from the outset, when you go to our community pages, for instance, what the difference is between a community project and a platform (which is what we sell support on) that it may likely be within.
Likewise, if you go to the jboss.com side, where you can download evals of our platforms, we’ve made it clearer what the difference is in that direction.
We don’t want to scare people off, we don’t want people to think that they should never use community projects and force them all into platforms – like I said, that’s where we make our money from, so we need people to buy support licenses – but the community is critical to our success.
But likewise, we don’t want to give the impression that community users, what they’re downloading from a project, is the same as what they might get from a platform – there are significant differences. When we spoke last time, I don’t think it was clear to users on either side of this divide, what the true differences were. To a degree, it’s still not there, but now, if you go to the project and platform pages, it’s a lot more clearer and you should be able to make a much more informed choice and get the right binary.
DZone: We've seen the release of three major milestones for JBoss AS6 since last December with support for some really key Java EE standards: JPA 2, JSF 2, the Weld reference implementation (for JSR 299), amongst others. How has the response been so far to the AS6 milestone releases and the Enterprise application platform 5.1?
Mark: It's been good. We've heard a lot of good community feedback on the AS6 releases that we’ve put out so far.
As you say, really, the thing that differentiates AS6 from the AS5 series is our support for EE6. We are going to see more of that in the next few milestone releases as we move towards the final release of AS6.
Seam obviously plays a really big role in pretty much everything we're doing these days. So we are making sure that that works well with AS6. Weld, which is the reference implementation that we are having to do for the CDI standard will also be supported in there. So we are really pushing AS6 in the direction of simplification of developing applications, which is, to a degree, what really what EE6 did well.
And the feedback we get back from the community at this point is very, very good. In terms of our app platform, EAP 5.1 is going to come out in the next few weeks. We've had some pre-releases of that. EAP 5.0 was out late last year and the response from customers on that, again, is good.
With the migration path that they are taking -- a lot of them are moving from the EAP 4 series up to EAP 5 -- they are seeing the benefits what that brings.
Although, we obviously could not call EAP 5 an EE6 implementation, because we hadn’t implemented everything in that. And obviously EE6 at that point had not gone to standard. We had managed to add a lot of the features that you would expect to see in an EE6 implementation into EAP 5.
When EAP 6 eventually comes out, the migration path to that should be quite natural for them as well.
DZone: You recently put forth some really interesting ideas on your blog about cloud computing and how it relates to middleware. In your mind, does cloud computing replace our notion of middleware?
Mark: I think middleware has been evolving for the last 40 odd years. Ever since two people put two Unix workstations together and decided to do distributed computing with them, middleware was born at that point with the very first RPC.
It's been evolving and it's continuing to evolve. I do not think that cloud removes the need for middleware. I think it maybe morphs what middleware is.
But if you actually look at what people want to do in the cloud, which is typically taking their existing applications, and giving them to somebody else to host because they can no longer afford the administration overhead or the hardware costs, then middleware in the cloud has to play exactly the same role as middleware does today in your internal data center.
You'll need all the same things. You'll need security, transactions, messaging, management. It's all going to be there.
It may be at some point available through slightly different APIs. But fast forward five or 10 years, if cloud is still called cloud at that point, you'll still be able to say well, that's my persistence service. That's my concurrency service. That's my ESB. That's my workflow system. It's all going to be there still.
DZone: Do you feel that cloud platforms such as Google App Engine and Amazon EC2 are adequately addressing enterprise concerns, as you describe them, things like security, transactions, concurrency, to name a few.
Mark: So the short answer is no. Not really. But the longer answer is that's not where they're looking at this point. You can get those things. I'll talk more about Amazon.
You can get exactly those things that I mentioned if you bundle them up into your own deployment bundle. On Amazon it's called an Amazon Machine Image (AMI). So I can create an image and I can deploy that to Amazon.
Amazon will manage it and put it on multiple nodes. What's in that AMI, Amazon doesn't really care about at this stage. But for me, I do care about it.
So if I want security, I want persistence, I want transactions, then it's my responsibility to make sure that everything that my application needs is in that AMI, and that gets bundled up as part of the AMI and distributed out to Amazon.
Amazon, as you know, does make available some kind of core services: messaging and persistence. Google does something very, very similar.
In some cases they are not really up to scratch in terms of performance and scalability at this point. Plus, they're also just two core services out of quite a few.
So I would expect to see the likes of Amazon and Google and to be perfectly honest, anybody who is offering a cloud stack, to start to populate that list of core services that you can expect the cloud provider to have over the next few years.
DZone: What is Red Hat's overall cloud strategy, and how is this driving the JBoss stack?
Mark: So we kind of kicked off announcements about our cloud strategy at JBoss World and Red Hat Summit last year when we talked about a project that was going on and then called Deltacloud. Deltacloud is our infrastructure as a service project that we are productizing.
That work is still going on. We have actually recently taken that project which was originally hosted in‑house and we pushed that out as Apache.
So it is now in the Apache repository and we are hoping to attract many more vendors to come and help us work on that. In terms of how things impact JBoss, JBoss would tend to play more at the platform as a service, maybe the software as a service layer. At this point, I can't make too many statements about where we are going.
But I kind of hinted that we are not suddenly going to be throwing the baby out with the bath water. Yes, there are things that we need to do around cloud.
A lot of the things that we are doing around AS6 and subsequent to that, AS7, and things that we are doing around our solo effort and tooling and CDI, they will all be playing into our cloud strategy, which is middleware that is evolving, but what's already out there is a significant user‑base of EE5, EE6, applications.
And we need to make sure that where we go, we can provide a migration path for those customers. There is a lot of trust that is built up in the community as well as with our customers with us, and we need to make sure that that trust is well earned.
You should expect to see us driving a lot of this through the community first and foremost. We are not going to be rushing product out that's not ready. That's not community ready. We need to use the community like any good open source company should, to get feedback, to make sure that where we are going with things is the right direction.
We can sit in our offices and you know brainstorm about where we think we need to go, and if we do that, and we produce product based purely on it, then maybe we are no better than a closed source company. We really are not that.
We will probably kick things off in that mode. But then we'll say, look, this is what we're thinking. Please don't tear it down. If you want to, let's start from scratch. And let's build it up again from the community.
DZone: We've seen some major consolidation in the middleware market over the last 3 to 5 years – to mention a few examples: Oracle’s acquisition of Sun, VMWare’s acquisition of SpringSource, and of course, Red Hat’s acquisition of JBoss in 2006. How is this ‘marriage’ of virtualization and middleware providers changing our notion of cloud computing?
Mark: I think you will see all of them that haven't made cloud strategy announcements -- it's an obvious buzzword at this point.
However, I do think that, what we call cloud today is the tip of the iceberg of where we will be going in the next few years. Most people when they think about cloud, they're thinking about Amazon. They are thinking about Rackspace and Google. They are thinking about the service side.
Really, if you think about it, there are more devices out there, more sensors out there today, than there are people on the planet. I think there is a cloud, it's just not an Amazon cloud, or a Google cloud. It's ubiquitous computing. It's your phone. It's your washing machine for instance.
My washing machine has a processor in it that is faster than my laptop of about seven years or so ago. I think that the definition of cloud is going to change a lot. Middleware is going to have to evolve, because again, as I said earlier, it doesn't matter whether I'm running an enterprise app on my mobile phone or an enterprise app on my server.
The requirements for that are going to be very, very, similar. So middleware will have to adapt. And I think that's where you will see a lot of these vendors going. They'll be offering their services, their capabilities, as much as they possibly can into these different areas so that as an industry and as users, we can build on the benefits and the maturity of what's gone for the past four years.
We simply cannot afford, as an industry, to stop the world and tell people they've got to ignore everything for the past four years and move in a completely different direction. Even if we didn't have the kind of economy that we have today, it just would not make sense.
DZone: The last time we spoke, Oracle had just announced its intentions to acquire Sun. That was about 12 months ago and obviously a lot has happened since then. We've actually seen the parting of some great minds from Sun. Folks like James Gosling, Simon Phipps. In your mind, is Java in a better place today than it was 12 months ago?
Mark: I think it would be nice if I could sit here today and tell you that I was confident that Java and the JCP was now definitely heading in the right direction. I can't.
Now, some of that is I think down to maybe it's just taking longer for Oracle to subsume Sun and get the strategy right. So now prepare to give them a little bit longer. But it is slightly worrying that I'm not able to say that.
We've had statements from Larry and others about how Java is very, very important. But really what we're lacking at this point is a commitment to open up the process. So we had an online event a few months ago now called Middleware 2020. Josh Bloch from Google spoke at that and he referenced a commitment, or I should say a call from Oracle and ourselves and others at the time about 18 months, 24 months or so ago. And it's available online, where Oracle was saying that they wanted the whole JCP process to be much more open.
There should be nothing done behind closed doors. The licensing issue around Apache, that should be all worked out in favor of Apache. And he was saying that he really expected Oracle to follow through on that.
Like I said, it's a couple of months later, nothing really has happened. People are still prepared to let things go for a little bit longer, but I think that is the direction that things need to go. Oracle said this two years ago when Sun was in control.
If we do not see these kind of changes. If things continue the way they were under Sun, then the whole process is going to stifle. It's going to be hard to attract people in. That would be bad for not just us and Google, it will be bad for Oracle eventually.
So I think from the Red Hat perspective, its incumbent on us to make sure that we keep pushing Oracle. We keep pushing them to a point where they either follow through or they make a statement that is no longer hand‑wavy and let's just drag things along for another 18 months or 24 months.
DZone: Putting on your visionary goggles for a second Mark, what are some of the major technology trends that developers should be paying close attention to over the next three to five years?
Mark: Cloud. Get to know it but don't think that what it is today is where it's going to be in the next few years. Certainly, what we are seeing is a lot more people are playing around with cloud. It's interesting.
It's nice to be able to say I just bought a thousand node cluster and it's only costing me $150. But think about the type of apps that you are developing today, and the type of apps that you may need to develop in the cloud. There maybe a lot of overlap. So you can probably already start to see where there are deficiencies in current offerings. So definitely keep on top of the trends there.
Probably another one would be parallel computing. We talked primarily in academia about parallel computing for 20 plus years. But we really have not had the kind of machines on our desks to make it a reality for everybody, outside of high scale computing where parallel processing has been the norm for a long time.
And one of the problems with that is a lot of the languages that we use today, it doesn't matter if it's Java, it doesn't matter if it's Ruby, or whatever else, they are not very good at making us think in terms of parallel programming.
We cannot easily make use of the additional cores that are on our laptops, let alone our servers. And I think we need to rethink where we’re going because we are being forced into a direction of having multiple cores -- it's no longer an option, it is the default. So we need to think about this. Does it mean changes to Java? Is it just more methodologies? Can we learn a lot from what is being done in academia with CSP (Communicating Sequential Processes), for instance.
And going back like 30 years the old transputers they had, they were highly parallel from the get‑go. And they had language to match that. So I think that this is something that everybody is going to have to get to, whether they like it or not.
And probably the other thing is reliability and fault tolerance. If you look at the trends of failures of machines, of software over the last 30 odd years, you'll see that your hardware has been getting more and more reliable year on year.
Software hasn't. And it's coming down to the human element in software development which is causing more problems now than anything else. And we need to start coming up with again, better methodologies to make sure that when we do say I have finished my application and I want to deploy it into a running environment, that it really is, almost ready.
We'll never get all the bugs out but we need to make sure that it's 99 percent of the way there.