A Look Inside the HornetQ Project with Tim Fox
A Look Inside the HornetQ Project with Tim Fox
Join the DZone community and get the full member experience.Join For Free
Learn more about how to Prevent Slow or Broken APIs From Affecting Your Bottom Line.
JBoss HornetQ is an open source project to build a multi-protocol, embeddable, high performance messaging system. With the recent 2.0 release of the project, DZone caught up with HornetQ project lead Tim Fox to learn about the latest features, the project's scope and how it fits in to the overall JBoss portfolio of products.
DZone: Tim, can you tell us a little about some of the work you're currently doing at Red Hat?
Tim Fox: Yes, thank you. I'm currently the messaging lead at JBoss, so that basically means I lead the JBoss Messaging and HornetQ projects. I'm also the founder of the HornetQ project. I've been employed at JBoss since 2005, which is just before Red Hat acquired JBoss, about a year before. And ever since that point, I've basically been working on messaging.
Initially, I was working on, when I was first brought on, I was brought on to work on the JBoss Messaging project, which had just started at that point. As time went on, I founded the HornetQ project and moved over to that.
DZone: Many of our members are probably familiar with the JBoss Messaging project and it sounds like HornetQ is an evolution of that. What is the goal of HornetQ and how does it fit into the overall portfolio of JBoss projects?
Tim: Sure. So HornetQ is a project to create an extremely high performance messaging system. It's an example of message‑oriented middleware. I'm sure, most of you guys, you're familiar with what message‑oriented middleware is. If you're not, our competitors in this space, in the closed source side it's, for instance, WebSphereMQ, TIBCO EMS, SonicMQ, Weblogic JMS. On the open source side, we have, for instance, ActiveMQ and OpenMQ. So those are the other messaging systems. So that's basically what the project has to do.
Two of the main design goals, from the beginning with HornetQ, are extreme performance and ease of use. So, right from the beginning we've tried to design it with those two things in mind. Currently, HornetQ is actually an unsupported community project.Moving forward, the plan is to integrate HornetQ into Red Hat and JBoss products and provide support through our usual subscription model.
As I said, HornetQ is an open source community project. We're always interested in meeting new developers who would like to help out in some way. We try to be as open as possible. Most of our work goes on our IRC channel. So if anyone wants to help out, people interested in getting involved, then just come by and talk in our IRC channel and have a chat.
DZone You team recently released the 2.0 GA for the project. What's new in this particular release?
Tim: Right, yes, we've actually released the GA [just a few weeks ago]. So this is a combination of about two years of development. I'll give a sort of recap, a history, of JBoss and HornetQ. Because JBoss has been a little bit confusing, over the years, had several different messaging providers, and users can, understandably, be a little bit confused.
Originally, we had, back with JBoss 4, there was a messaging system called JBossMQ, which was the original messaging system in there. And that was basically superseded by JBoss Messenging, which is a completely new messaging system. Now, we released JBoss Messaging 1.0 several years ago, and that became the default messaging provider in JBoss Enterprise Application Platform.
And then, just about a couple of years ago, we started work on JBoss Messaging 2. Eventually we got to the point, we realized that actually, we pretty much noticed that the codebase was 100% different from the JBoss Messaging codebase. So we thought, well, we should really rebrand it. So we spun it off as a different project and that's when HornetQ was born.
So it's kind of a migration, it's a transition, from JBossMQ to JBoss Messaging to HornetQ. And they're all different messaging systems. So, as I said, we released, the GA release was yesterday. This is really the culmination of a couple of years of solid development.
DZone: What are some of the performance enhancements you've made in the latest release?
Tim: Right, sure. So, there are two main areas. One is performance on the wire, and it all comes down to our use of this project called Netty. I'm not sure if you're familiar with it.
But, basically it's a low‑level Java NIO library, written by a guy called Trustin Lee, who is the author of Apache MINA, that I suspect you've heard of. So he's currently a JBoss employee. So he worked very closely with them, with that team, to basically get extremely good performance on the wire.
And then we have our secret weapon, I guess, which is our high performance journal. So, the other side, where often the performance bottleneck, and the messaging system is the persistence, the disk storage. And some of the older messaging systems would use a relational database, which is kind of a bit slow and clunky. Relational databases aren't really ideally suited to persistent messaging data.
So, with this system is a very high‑performance journal, which is basically written in 99‑percent Java. But we also have a small layer of native code that's accessed by JNI. And what this does is, when you're running on Linux, it detects that you're running on Linux, and then it automatically enables a bit of native code which allows us to pass into Linux asynchronous file IO. And basically, what this does, it allows us to get much faster persistence than would be possible in pure Java.
So, when you're running on Linux, you're going to be that much faster, basically. Now, if you're not running on Linux, that's fine, too. It will automatically realize that, and it will just use standard, 100‑percent Java NIO. And this also gives you very good performance, too.
DZone You mentioned something interesting there, Tim, about the relational database model not working as effectively with JMS architectures. Can you tell us a little bit about why that's the case? What alternatives should we be looking at when working with messaging systems that have certain performance and scalability needs? Is the RDBMS a dated method of persisting data in high performance systems?
Tim: I mean, for a messaging system, I would say yes. You will find, nowadays, most messaging systems, they have their own journal of some form or another. So other messaging systems do have journals, but we believe our journal is unique in its use of asynchronous IO on Linux.
DZone What are some of usability improvements you've made in the latest release?
Tim: Yeah, definitely. So one thing we kind of realized with JBoss Messaging is one of the key things, you want strong adoption of your project, and it needs to be fairly usable. You need to have really good documentation. A developer needs to be able to download it and get started within five minutes, or a lot of people will just get bored and they'll walk away and they won't even evaluate it.
We tried, from the beginning, to make sure we've got really good documentation. So we shipped with, we have a 200‑page user manual that covers every aspect of HornetQ in depth. We also have a quick‑start guide, which gets you going very, very quickly.
And also, we actually ship with about 75 examples, which should run out of the box, and the examples pretty much cover just about every feature in HornetQ that you can think of. If you want to use a particular feature, you just cd into the examples directory and run the example, and it will just run straight off. So all these things are really to try to make the life easier for the developer and get people started, get people going, as easily as possible.
DZone How does HornetQ differ from the JBossESB project?
Tim: OK, that's a good question. OK, so HornetQ is a messaging provider. Now, JBossESB is kind of almost working at a higher level. So JBossESB can work with many different messaging providers. Basically, it works on top of the messaging provider, and adds extra functionality‑‑you have kind of complex routing and XML transformations and all this kind of stuff.
Also, if you want to kind of integrate between heterogeneous‑‑imagine if you wanted to integrate between a messaging system and some web services. Then you'd do that kind of thing at the level of the JBossESB. You wouldn't do that at the level of the messaging system. But with HornetQ, we're interested in talking to other HornetQ servers. If you want to then integrate that with other kind of systems in your enterprise, at that point you'd be looking at using JBossESB.
DZone So JBossESB sounds like it's better suited for an SOA, heterogeneous environment, whereas, when you're looking for those performance gains within a purely Java environment, HornetQ is the right solution.
Tim: Well, that's true. But HornetQ's not limited just to Java environments. Going ahead, especially with 2.1, we're going to be looking at support for other protocols and clients in many different languages. And you can actually already use HornetQ with StompConnect, which allows you to use any of the Stomp clients, which are available in many different languages. Although the actual server is written mainly in Java, the APIs will be accessible from non‑Java environments, too.
DZone You mentioned some of the upcoming features, like REST support. Are there any additional features we can expect to see in the 2.1 release and, I guess, beyond?
Tim: Definitely, yeah. So, for 2.1, there's a lot of exciting new stuff we're going to be looking at. As I mentioned before, one of the main drives of 2.1 is interoperability and implementing different protocols.
Right now, HornetQ has a JMS API and also has its own core API. But going ahead, we're also going to be looking at REST support. And obviously, REST is a pretty big thing at the moment, a lot of popularity around REST. So we're going to be teaming up with the REST‑* project. It's a new project with JBoss to create various REST‑related specifications, and mainly most of the work's been done by Bill Burke.
One of the things they're doing, and we're going to be having more input into this, is a REST specification for messaging. And once that's done, the idea is we'll implement that in HornetQ. So you'll be able to do REST over HTTP. So you'll be able to have a simple HTTP client and kind of interact with the messaging server using the REST paradigm.
That's one thing. Another thing I've noted with Stomp. Now, Stomp is a protocol that's a Codehaus protocol. It's a very simple messaging protocol. And there are lots of clients already available for Stomp. I think it's got C, C++, C#, Erlang, Delphi, you name it, Python, Ruby, it's pretty much got clients more or less in any language or script. So once you implement Stomp, that client it'll be usable in HornetQ as well.
DZone: So Tim, in the 2.1 release an, it sounds like you'll be supporting different application types and protocols. Does this create possibly too much redundancy between the kinds of problems JBoss ESB solves and HornetQ solves?
Tim: I think it's more synergies, really. I mean the way I look at it is the messaging provider for HornetQ is kind of just the messaging provider. And ESB is kind of at a higher level. And it kind of is the glue that joins those things together forming a kind of overall message bus. I don't really see any conflict there, no.
DZone Taking a step back, Tim, how do you see the message oriented middleware market evolving over the next several years?
Tim: That's a good question. Actually, I think a lot of stuff is going to be coming down to interoperability. Right now sometimes you have Java messaging systems that are mainly used by Java clients. I think what's going to be really important is that are you going to be able to have clients in many different languages that's going to have to be able to talk to the messaging system in a very simple way. Simplicity is going to be key. Complex protocols, I don't think is going to be successful because they're just too complicated for people to learn. If somebody writes in a scripting language it needs to be able to interact with the messaging server very easily. I think simplicity is going to be key. I think the REST approach is going to really take off. It's important for messaging servers to be kind of multilingual as well and speak to many different protocols.
DZone: How can people get involved with the HornetQ project and learn more about it?
Tim: We have a website, on jboss.org. So if you just type jboss.org then you can easily find HornetQ, or you can actually go to hornetq.org and that will redirect there. That's our main website. And then there are lots of links off there that will tell you where the forums are are and where the IRC is, and where the downloads are.
The best place to find developers is at IRC. We have a public IRC channel on freenode.
We're trying to keep the project as open as possible. So pretty much all the day‑to‑day work goes on there. So anyone is free to just join the channel, be a fly on the wall, try and help out a bit.
DZone Tim on behalf of the JBoss community, thank you very much.
Tim: Thank you.
Opinions expressed by DZone contributors are their own.