DZone recently sat down with Sacha Labourey, CTO of Red Hat Middleware, to discuss the upcoming release of JBoss Application Server (AS) 5. In this interview, Sacha discusses the new microcontainer architecture and previews some of the new and updated core middleware services such as JBoss Messaging, JBoss Cache, the transaction monitor engine and JBoss DNA. He distinguishes JBoss ESB from the messaging and Web services platform, talks about Bill Burke's new RESTEasy project and also highlights some of the key features in the upcoming Web Beans specification. Finally, he provides his thoughts on Glassfish and the Spring Application Platform, looks at the evolution of the application server market and talks about where he sees the market heading in the next five to ten years.
The complete transcript of the interview has been provided below.
Editor's Note: This interview was conducted in mid-August 2008 and was published on August 21st, 2008.
DZone: We are sitting in Neuchatel Switzerland with Sacha Labourey, CTO of Red Hat Middleware. Sacha, can you tell us a little bit about yourself and what you are currently doing at Red Hat?
Sacha Labourey: Hi. Yes, absolutely. So welcome to Switzerland. I am very happy to receive and host you today for this interview. I'm the CTO of JBoss. Since we recently moved to a division structure at Red Hat, I am co-leading the JBoss Division with my partner-in-crime, Craig Muzilla. We are in Neuchatel today simply because I was born here. There is nothing fancy about the new Silicon Valley of Europe. It's just my place, that's where we started the European operations for JBoss long ago. That's where we are.
DZone: Sacha, I'll start with the question that has been on everybody's mind, especially those in the JBoss community - when can we expect to see the final release of JBoss AS 5?
Sacha: Anytime soon. It's a number of weeks away, probably two months away. We are finalizing the work for the various release candidates. We are very close to GA.I know it has been a very long trip for us as well. But, we think we have great things coming in the pipe. So, it was worth the wait. It's coming.
DZone: Now, gutting and re-architecting an app server from the ground up is certainly no small task, especially for an app server as complex as JBoss. In this case, the process took almost three years. The question that a lot of people have been asking is were there more than just technical issues at play here?
Sacha: That's a very good question. Intuitively people usually think that it is an issue with the J2EE spec and how much time it took us to implement this pretty significant update of the J2EE spec.
But actually, it is not the case. If you look at the EJB3 container for example, I think JBoss has been the first company on the market to provide an EJB3 implementation of that specification.
So, actually, the EE services have been ready for quite some time. In fact, where we spent our time was mostly on the base infrastructure for the application server. That is where we spent actually most, if not all of our engineering resources, building a new Microcontainer and also moving some of these core services to the next generation of their implementation.
Things like the messaging infrastructure, the transaction infrastructure, but also the Microcontainer, I guess we are going to spend a bit of time today speaking about the Microcontainer and what it brings to the market. But, this has been the biggest part of the work.
Also, very basically as we expand the size of the JBoss code base, we also grow the complexity of what we have to manage. It is true that during that process we also had to simplify the way we build our application server, the way we decompose the various modules in ways that allow for more flexibility.
We probably had at some point a too monolithic build environment for our application server, which has slowed down our work. So, that is more of a detail that had slowed down our development at some point. But, that is the kind of things that we faced as we build a much more powerful application server.
DZone: What were some of the main technical challenges in the re-architecture?
Sacha: Again, the build environment and the growing complexity of the application server has been one. But, we have spent also a big amount of time on redesigning our new Microcontainer.
So, JBoss has been one of the first, if not the first company to provide an application server on the microkernel. That was back in 2002. If you remember, at that time the default design for an application server was truly a monolithic stack, where you would receive a big block called an application server.
You would run it and that's it. You could not really define what you wanted to do, to use what you did not want to use. At that time, JBoss was really liked by developers because they could really trim down their application servers to the bare minimum.
This was not just useful for developers. It was useful for OEM, for ISV. They have been big consumers of that technology. We wanted to push that to the next step with the Microcontainer.
We spent a lot of time to get that right. It is not an easy task. This Microcontainer is really at the heart of many different paradigms, things like class loading, metadata, AOP (Aspect Oriented Programming), dependency injection, dependency trackings, and so on.
It is really difficult to get all of this right. So, we did that. Then, obviously, we had to modify the various services, the enterprise services so that they fit in that new paradigm.
We have gone through that now. I am happy to report that it's doing great and it's a major positive shift for the AS family.
DZone: Can you give us an overview of some of the new core middleware services we can expect to see in JBoss AS 5?
Sacha: Yes, absolutely. What we have done is we have revamped some of the most important services we had in the past. For example, the messaging implementation is brand-new. We used to have a service called JBoss MQ. We have moved to JBoss Messaging.
JBoss Messaging is truly amazing. It has impressive performance. You can find some benchmarks on our website. We provide some native layer integration if you want. If not, we just revert back to pure Java behavior.
It is fully clusterized - we can cluster in terms of load balancing or in terms of failover. We have a very different way to cluster this environment. It is all based on the JBoss Cache technology that we have been using for the last five years with JGroups for the application server clustering. Everything is based on this common layer.
JBoss Messaging is really a step forward when it comes to messaging. I don't think you will find any other Java open-source messaging implementation that can beat that level of functionality and performance.
We also included the new transaction monitor engine as part of the app server. If you remember back in 2004 or 2005 - I think it was back in 2005 - we acquired the Arjuna Transaction Monitor both from Arjuna and Hewlett-Packard.
Now, we have integrated those components as part of the application server. This transaction engine is rock solid. It has more than 20 years of expertise in transaction management. It was the first JTA and the first JTS transaction management implementation on the market. So, we have amazing expertise there.
It is also extremely fast. It provides again JTA and JTS behavior. That is going to be a pretty important change, especially for the banking industry.
We also did some changes in the Web services arena. We implemented a brand-new Web services stack, compatible with EE 5. And also what we provide is an abstraction layer so that you can actively plug multiple backend stacks if you so desire.
You might want to take the Sun implementation, the Apache implementation, plug it behind and it is going to have no impact whatsoever on our application server. So, that is the kind of freedom of choice we want to bring to the end-user.
There are many changes there. The list would be too long. But, I can tell you it is pretty long.
What the Microcontainer brings as well is a different way to configure the application server. One of the issues we had in the past with JBoss is that the configuration was pretty easy to do by editing files. But, if you actually wanted to do change on-the-fly and expect these changes to survive restored, it was slightly more complex to achieve.
We have completely decoupled the metadata management from the application server. It's something we call the profile service, and this profile service, as you can imagine, is fully pluggable. It could be simply a set of files, it can be a database, it can be a JCR repository. And the idea here is to end up with a unified way to store metadata for one node or a cluster or a farm of JBoss instances, and very quickly provision new instances.
That also, just to relate it to the other project we started called JBoss DNA, aimed at building a complete registry and repository for not just the application server, but our entire SOA platform strategy.
DZone: Will there improved support in AS5 for RESTful applications?
Sacha: Yes, absolutely. Bill Burke has been working on a new project called RESTEasy, and the final specs should be approved in a couple of weeks if not days. And we're going to be one of the very first to implement those specs. Bill Burke made sure to implement this in a very JBoss-ish way.
Our aim is to try and always keep things simple for the developers, improve performance, but also to make it easy to get rid of it if you don't need it. So, RESTEasy is a project where we started to implement those features, and that's something we can use as part of JBoss 5.
DZone: When would I need to consider using JBossESB versus simply using JBoss Messaging in the web services stack?
Sacha: That's a great question. In fact, in the last three years, the boundary between these two environments has somehow melted. And obviously it's a continuum. So, on one extreme, you will obviously use JBoss Application Server. For other kinds of projects, you would obviously use JBossESB.
But, if you look at the boundary in the middle of this continuum, it's not that obvious what you should be using in some cases. And that's very close to the JBoss way of doing things, which is where we see us providing a product in this market as this very flexible Microcontainer, being able to provide multiple personalities.
You can see it as a JMX Microcontainer, as a OSGI Microcontainer, as a simple POJO-based Microcontainer. And then a set of services, enterprise services. And these services will always be the same somehow, independently of whether you are driving an ESB based application or an EE based application, you'll still need security, you'll still need transactions, remoting, messaging, and so on.
That's not a big deal from an engineering standpoint. We always go back to the same concept. The difference is how you package them and what's easier for you as a company. And it also depends on what level of expertise you have.
If you have already trained all of your team on an application server, well for a basic integration scenario, maybe that's fine for you to use some in EJBs, some Web services concepts. And so, it's not just a technical issue. It's also what kind of expertise each company has in house.
At the end of the day, it's mostly the way you package that technology and make it easy to use it - that's going to be different. Not so much the technology below. So, we're trying to blend this concept as much as we can to make sure that users that implement applications using an app server and teams using the same concept to implement an ESB-based application can move smoothly from one to the other.
They should not face a wall of different concepts, different services, different ways to configure the services. We want to make it as smooth as possible to move from one camp to the other.
DZone: If my application doesn't currently require many of these core services, such as clustering and transaction management, wouldn't a standalone server container, such as Tomcat suffice?
Sacha: Absolutely. In fact, we do provide standalone support for Tomcat. So, we do have so customers that only use Tomcat as their server container and that's all fine. However, that would not be what I suggest. When I visit customers and they ask me this question, my typical answer is, "Well, why don't you use JBoss App Server?"
If you think about what JBoss App Server is, it's really this Microcontainer plus a set of services on top of it. Tomcat is one of those services. As you might know, JBoss is probably the biggest contributor to the Tomcat project. It's a very important project for us, and Tomcat code base is integrated; it's part of the JBoss application server.
So, why not simply take JBoss AS, use the Tomcat service, and possibly not use anything you don't need, such as a messaging implementation, a transaction manipulator, and so on? So, from a custom point, from a custom deployment, custom development, it's going to be the same as using Tomcat.
On the other hand, you're going to teach your team, you're going to educate your team to learn JBoss. You're going to define some operational processes to go to production that use JBoss. And that means that the day you're going to need some additional services such as messaging, such as CORBA, such as transactions and so on, well, that's easy. You just deploy these additional services and that's it. You don't need to retrain your entire workforce. You don't need to redefine your operational processes, and so on. It's already there.
I think, it's a much better choice to actually use JBoss and trim down to its bare minimum, meaning Tomcat, and then grow with it, rather than try to just stick to Tomcat standalone. And the day you need something bigger, the day you need more services, then you need to retrain everybody, learn new things, and redefine all of your processes.
DZone: In an earlier interview with DZone, JBoss architect David Ward described the JBoss Microcontainer as, "An IOC container on steroids." How is this different from the earlier hot deployable services model?
Sacha: So, first of all, the previous model was pretty based on JMX. JMX is a fine spec. It actually defined many of the concepts we need today, but it doesn't go far enough. I would say that it was an excellent first implementation of what a microkernel should be.
But, if you look at the need and the requirements that came up in the last years, I think the market liked this approach and now they're asking for more. JMX is not enough. Some of them want OSGi. Others want JMX. Others might just want to rely on pure POJO. So, we have to provide a solution that can address all of these needs, and that's what we do through the notion of personalities.
At the core of the Microcontainer, you just have POJO, and then you can map some personalities to see this POJO as OSGi containers or JMX. And we have a notion of deployers also, and we can take, for example, a Spring deployment file and map this to JBoss POJO concept class loaders and metadata, and so on. So, we can map all of these concepts on the market and make them live on top of the Microcontainer.
Standards are very important, but they come and go. So, we need to have an infrastructure that makes it possible for customers to invest in a solution that is flexible enough to survive multiple generations of the standards. So, that's what we're doing.
Furthermore, as I said before with the configuration of the application server, we had to completely review the way that we restore and retrieve metadata for applications and services running on top of the microkernel. We needed something much more flexible. So, that's what we did with the profile service.
We also wanted to have AOP as a first class citizen on top of the Microcontainer, so that all of the typical enterprise aspects, such as security, persistence, and so on, are injected into this object through an AOP layer, and so on and so on.
So, really what we did is we took the expertise we had in the last four or five years with the JBoss microkernel, and we retrofitted those into the new JBoss Microcontainer. So, we were already leading the pace in the past with the JBoss microkernel, and we keep doing so now with the JBoss Microcontainer.
[boat horn in the background]
Sacha: See that's not a fake recording. We haven't just put a painting of a lake behind it. That's a real boat announcing its arrival.
DZone: I think, it's great that there's flexibility offered in the language and API layer. In your recent blog entry, you mentioned that there's a rule where the more fashionable an API or a language is, usually the less it will last. In other words, the more boring a language or an API is, the better. Can you clarify that point a little bit?
Sacha: Yes, it's something we see quite a lot today, actually. If you look at Java, it has been kicking and alive for 15 years now. Ten years for J2EE and EJB. It's a long time. So, obviously, it's a mature technology. We see many new products or specifications or just buzz coming around claiming that they're the next big thing.
Maybe, they are, but you know what, probably not. Statistically many of these new buzzes are just going to disappear as they came. Still, it's not a good reason to neglect those. So, I think, it's very important to recognize the value of the runtime as being a great way to gain independence from the hardware vendors. That's something we tend to forget now because it's a given. Right?
Before Java came out, it was very important to hook your application development to a specific language, to a specific operating system, and sometimes even to a specific architecture. Hardware architecture.
Now, we have totally abstracted that, and what we see is that middleware is going through the same set of changes. Even if we see a new buzz coming up every week or so, the fact is that enterprise middleware services are here to stay.
I don't see many new concepts to challenge transactions or security or persistence. All of those are a great concept that will stay for the foreseeable future. What we just need to do is to provide an environment where it's fairly easy to map a new API, a new programming model, new languages on top of this concept and make it easy to move from one to the other.
Not that we want to incent people to develop their application in 15 different languages, but we need to be able to cope with this rapid change on the market, going from one standard to the other. So, what I wanted to say is, if we were to just implement the current procedure leveraging line of this new buzz, what do we do tomorrow? We're just guessing.
We need to make sure that whatever we develop as our core infrastructure is here to stay, can cope with future changes, then we can implement any kind of new programming model that the market wants, but that should not impact their investments in JBoss.
DZone: We're seeing a move towards a more modular server architecture in the industry. OSGi actually is being considered by many to be the component model of choice. Was this ever considered as an underlying component model for AS 5?
Sacha: First of all, it's great to see that the market is moving in that direction. For a long, long time, the default was to have the monolithic application servers. So, moving away from that trend is certainly a good thing for the market.
Why OSGi, why not OSGi? I love OSGi for a very basic reason. It's a standard and we love open standards, so just for that reason I think it's great. Now, the question is, is it enough for us? And the answer is no.
Why do we think we must provide an OSGi implementation to our customers? We don't think that we can afford to actually have OSGi as a core implementation of our Microcontainer. The kind of concept we need to provide to our enterprise services is to go beyond what OSGi provides today.
Would we be fine to standardize some of this concept as part of OSGi or any other spec? Absolutely. So, we think there's value in this concept. If the market thinks the same, then let's go, let's standardize those. But, the reason why we did not choose OSGi for the core implementation of our application server is just because it was not enough for what we need.
DZone: JSR 299 or Web Beans API attempts to standardize the model that JBoss advocates, which is a blending of EJB3, JPA and JSF to provide a comprehensive web application architecture. This JSR will also be included in two of the three Java EE6 web profile options. In your opinion, Sacha, how will Web Beans change the way applications are fundamentally built?
Sacha: I think, what's going to be very important with Web Beans is that it's going to reduce the change of paradigm that you face when you develop with the JPS and JSF and with JPA. I think, EE for too long has been too much of a marketing spec.
A Frankenstein of specification, which is all of the specs that were included as part of EE were great. There is a basic aspect, enterprise aspect, that everybody keeps using on a daily basis.
But, when you look at the way they are aggregated together as part of the EE spec ... well, look at J2EE 1.3 for example or even 1.4, it's not a big spec, it's a tiny little spec. I think, we needed to make a much better job of integrating those specs together so that the experience for any developer is much better.
Today, with EE 1.4, when you move from one layer to the web layer to the EJB layer, you can tell you feel it, right? You have to possibly redevelop your data objects, you have to make some specific naming look-ups, and so on. So, you can really feel a big gap between all of these layers. The goal here is really to glue all of these layers to make it seamless and make it easy to navigate across these layers.
The bottom line I think is that we're going to gain a lot of productivity, in terms of development, and the learning curve for EE development is going to be further reduced.
DZone: What impact do you see the concept of virtualization having on how middleware products are built and provisioned?
Sacha: Actually, you could argue that a middleware container such as an EJB container or an EE application server is already a virtualization layer.
What it brings you is that it abstracts away many concepts from the operating system. From that standpoint it is the virtualization layer.
What we see now is many companies wondering, why do I need all of this complexity to deploy my applications? Why do I need to configure my application server, my operating system, my Java virtual machine, then make sure that all of that pipeline is properly configured and properly optimized in terms of threading, I/O, and so on.
I think that we start to see a great gain here taking place with the so-called software appliances where you end up having a core operating system, just the services you need plus the JVM, plus some application server, all bundled in a single binary.
Then, you can deploy that on any virtualization layer. It can be KVM for Linux, it can be VMWare, it can be Microsoft virtualization layer, anything. But, at the end of the day, what it means is that you're moving away from one app server that needs to be certified on a set of Java virtual machines which themselves have to be certified on a set of operating systems and possibly on a set of hardware, different hardware configurations.
By moving towards software appliances, you actually end up with one bundle for each virtualization technology - KVM, Xen, VMWare and others. That radically reduces the work that a company needs to do to actually deploy provisions as technology in production.
Furthermore, it opens the door to the cloud. If you want to take the same software appliance and push it on Amazon EC2, for example, that's possible because RHEL (Red Hat Enterprise Linux) for example, that is a case for other layers. RHEL is one of the default operating systems that is supported on Amazon's EC2 so that makes it extremely convenient to provision middleware in the cloud and in the enterprise.
DZone: Do you ultimately see this as the future of the application server market, let's say looking into the future five to ten years from now? Is this where we're heading - hosted enterprise applications with services provided out of the box?
Sacha: I think actually we're going to see two very complementary things. On one side, we're going to see a move much more in the direction of enterprise runtime a la carte where you cherry pick the services you need for specific need. You might need to integrate applications or systems, you might need to develop a new application, whatever. But, you'll be able to cherry pick the services a la carte. So, that's on the flexibility aspect.
But, flexibility usually means more complexity, and that's what we want to avoid. That's where all of these new provisioning systems, the software appliances and so on are going to bring much more simplicity. So, we're going to get more power, less complexity. That's what we can expect from middleware and operating system vendors in the future.
From that standpoint, even so, JBoss is strongly committed to operating system independence. JBoss keeps running on Windows, AIX, Solaris, HP-UX, and so on. We also want to make sure to completely leverage the assets of this company and make sure that our customer can benefit from a completely integrated solution.
I think, in the future, it's going to be increasingly important to further split some of the notions, which today are still linked way too much as part of a monolithic entity. I think, metadata is something that will be very important. What I call metadata, you know, it's a non-fancy name to describe everything that is being done in the various repositories out there.
When I look at the way that you configure an operating system, or the way you populate an LDAP tree, the way you get access to the topology of your network, everything you need to manage; when I look at the configuration of an application server on ESB, or when I look at the various steps which need to go in an application before being validated and being able to go to production, all of that is just metadata, whatever fancy name you want to put on that.
Being able to extract all of that information as part of a unified metadata repository, I think is going to be a great step forward to enable the kind of provisioning we will need in the next years. Today, I think, we go through way too many ad hoc and manual processes to get there. We're not going to get the kind of economy of scale by doing so. We need to radically go to another level.
We also need to largely improve things from a productivity standpoint. It needs to become even easier to develop applications, to integrate these applications together. We see some interesting work being done in terms of mashup, in terms of SOA and so on, but all of those concepts are still atomic work being done independently one of the other. We're going to see this work blend together to form something better.
So, all of that work is going to take place in the next few years or so. That's going to be very interesting. But, it's true, if you look at the history of operating systems, operating systems have been there for, what, more than 40 years. It's still a very young market. If you look at the middleware market, and even more the application server market, it's far from being a mature market. You still have a lot of work to do to make it a complete commodity.
So, we're going to see a lot of innovation taking place in the next 5-10 years.
DZone: If I was looking to choose an application server and I had three choices in front of me - Glassfish, the Spring application platform, and JBoss - with as unbiased an opinion as you could give, how would you educate somebody on making the appropriate choice?
Sacha: I think, it's pretty easy. It's JBoss.
Sacha: To bring more beef to this, let's take Glassfish first. I have to admit that Sun did a fine job in the last years. If I look at the history of the application server at Sun, the only thing you knew is that if one day the app server was called the same thing as another day, it just meant that they had changed the name an even number of times. They went through so many releases, so many bad products and so on.
I think Sun went through a very difficult time. And this time they made some good choices - first they went to open source, and they've changed their way of developing software. I think, this is a good thing. Still, I think the Glassfish application server is still a very immature application server. Sun still has to prove a lot in that field. They've done a great job in the last 10 years to build the ecosystem and to create specs, and so on.
But, as they move from this position of being a referee of the Java ecosystem to being an actor and wanting to make real business, I think it's a pretty big shift, both for the Java ecosystem, but also for them as a company. What we see in the field is that they're actually making very little business just because they don't have the credentials to do so.
For SpringSource, it's a slightly different situation. Let's switch the Spring framework and services from the Spring application server. I think the Spring framework has shown that it was very successful in companies. Many companies are using the Spring framework to develop their application, and that's great, because that's very complimentary to any application software out there. You see many applications running Spring on JBoss, Spring on WebSphere, Spring on Weblogic, and so on.
You could argue that thanks to the EE portability, Spring has been able to bring even better portability to move away from one app server to the other. JBoss being frequently the target destination of such migration, we largely benefit from Spring as a tool to ease migration from one vendor to JBoss. So, that's the good thing about Spring, and we're glad to support the customers deploying Spring as a Spring framework on top of JBoss.
Now, the Spring application server is interesting, first because it comes very late into the party. If you looked at this market six years ago, you probably had like 20 or 25 app server vendors, and now you just end up with three or four. So, the fact that SpringSource decided to jump into that market so late is a very interesting challenge they decided to take.
I think, what's important for customers is also how strong the services are. Right? It's one thing to have a nice framework, but it's a different thing to provide a strong and robust implementation of those enterprise services. I wish them good luck, but it's going to be a lot of hard work to get that right, and it's going to take them years before having a solid foundation. So, it's an interesting challenge.
DZone: Sacha, do you have any final words for our audience?
Sacha: Yes. I'd like to welcome them as part of the JBoss.org community, make sure they participate in what we're doing. We see great work being done by the community, and would like to encourage that even more. And more specifically for the DZone community, I think you've done a terrific job in the last quarter to really increase the profile that DZone provides, the kind of material and so on.
We're constantly pushing some new material to DZone, so it's probably a great place to go if you want to learn more about what we're doing and the next products we have in the pipeline.
DZone: Thanks, Sacha. We hope to be back in Neuchatel soon for a vacation.