If your architecture involves both Java and Rails on the server-side, there’s a good chance you’ve had to do some creative engineering over the past few years to deploy your application.
In the associated audio interview Bob McWhirter, JBoss Fellow, Codehaus Despot, and creator of TorqueBox, discusses the boundary between Java and Ruby and his efforts to make Torquebox “a real first-class Ruby platform that works the way Rubyists expect”.
McWhirter will expand on many of these ideas during his session at next week’s OSCON Java conference in Portland, Ore.
(For the textually inclined, a full transcript from the McWhirter interview is posted below).
Bob McWhirter: I am Bob, Bob McWhirter. I have a couple of titles, I guess, but currently I am the JBoss Fellow with Red Hat, which means I get to go do research and development and figure out what the next cool things we’re going do are.
Previous to that, of course, I was the founder of The Codehaus, and
I’ve been involved in open source for probably 10 years now, if not
Tim O’Brien: What is your session going to be on?
BM: The session that I’m giving these days is typically talking about
the power of Java, but with the beauty of Ruby, that you don’t have to
start over from scratch just because you change languages. You can
take all the great stuff you know, whether it’s third-party libraries
you’re using or if it’s your own legacy components and be able to use
them and take baby steps into the world of Ruby and to taking
advantage of the beautiful expressiveness of Ruby.
TO: Java programmers learning Ruby. Is that a wave that’s already
passed or do you think that’s a wave that’s just starting to crest?
BM: I think we kind of go in a couple of cycles here, honestly. There
was a big surge in Ruby a couple years ago where a lot of Java people
just got pissed off and annoyed with Java enough to jump over to the
world of Ruby. That was kind of a rebellion, if you will, kind of a
heartbreak where they gave up on Java and moving over to Ruby.
I think now, though, we’re seeing a more rational kind of move of
people who want to just add Ruby to their toolbox. Not necessarily
trying to rebel against Java and get away from Java, but just trying
to get away from quite so much Java.
One of the things I’m seeing more of is where people are taking their
legacy components, but let’s say, rewriting a front end in Ruby. Their
view layer or whatnot, or maybe building small little departmental
type of applications with Ruby just to get their toes wet. And really
evaluating it in earnest, as opposed to as a rebellion or as a
fed-up-ness with Java or whatnot.
We support CDI in TorqueBox, so you can inject your Java bit over into
your Rails application and use them. You can get started really
quickly and really easily with your existing stuff and just “let’s
throw up a new web page that’s written in a Rails app or a Sinatra app”.
I think we’re just at the beginning. I think as JRuby gets better and
as things like TorqueBox continue to improve – and particularly if we
ever get, let’s say, a supported offering behind it where you can go
choke Red Hat’s neck if something breaks – then I think that will give
more enterprises the comfort level they need to move over to Ruby or
to start experimenting more with Ruby.
I don’t think it’s passed us by. I don’t think we’ve missed this boat
and we’re going to lose it to Scala, however it’s pronounced, or
anything. I think the market will continue to grow for Java people who
are moving over to Ruby.
Torquebox: What problem does it solve?
TO: You were working on Ruby and Java stuff for a while, a couple
years now, three or four years?
BM: Yeah, a little over two now, about two and a half.
TO: Why did you start paying attention to this?
BM: It’s a little on the winding road. I joined JBoss four years ago,
I guess, and I joined as a manager and I learned pretty quickly that
I’m not a very good manager. So I took a sabbatical from the job for
about three months. With a friend of mine, who I now work with, we
started trying to do a startup and we, like any other startup, we did
it with Ruby on Rails.
I really liked that environment and I had used Ruby on Rails before,
of course, building the Codehaus. I really liked it, but my sabbatical
was up, the startup failed, and I had to go back to this Java
Corporation. I’m thinking, “Well, what can I do to take my love of
Ruby on Rails and still get a paycheck from the Java Corporation?”
Thankfully, JRuby exists, and start gluing it onto JBoss AS. Being a
fellow thankfully meant that I didn’t have to produce revenue pretty
quickly or anything. So I could take the time to look at how do we
take JBoss AS5, at that point in time, and glue JRuby to it and make a
good experience for Rubyists. And also give Java people an
alternative, if you will, a way to start playing with Ruby without
having to change their entire platform.
My first goal was really just to get Rails running on top of JBoss
using JRuby. Then from there it’s like, “Well, we got that done. Let’s
add to it. Let’s do more. Let’s make it enterprise-y.”
TO: Coincidentally, JRuby was a product of Codehaus. It still is.
BM: Yeah, it’s had a weird history. Charlie Nutter kind of drives it
now with Thomas Enebo. But they weren’t the founders. I’m not sure who
actually started the project. At some point it was over at Kenai for a
while, Sun community. Then part of it was at Codehaus. Then I don’t
know what Kenai is up to or Java.net.
It’s unfortunately one of those projects that’s scattered around. But
the fact that it’s having some touches with Codehaus, I think, does
make it easier for me to work with those guys and get to know them and
have a little mutual respect because TorqueBox ultimately benefits
them and JRuby certainly benefits TorqueBox. So it’s a very symbiotic
relationship I have with those guys.
TO: What was the main technical problem that you were trying to solve?
BM: It’s really kind of two-fold. The first problem doesn’t involve
JRuby Rack. It actually involves Warbler, or previous to that it was
GoldSpike, I believe it was called. Which is where you can take your
Rack application or your Rails application, bundle the JRuby Rack and
stuff it inside a WAR file. Then you go deploy this WAR like you would
any other WAR file. Your app server doesn’t know anything other than
The problem I have with that is that I’m having to stuff everything
inside a WAR file, basically a packaging step. One of the beauties
about Rails work is that you can edit your files there, live, on
disk. You have your whole source tree laid out and your app is running
from that source tree on disk. There is no compilation. There is no
packaging. I edit a model. I edit a view. I edit a controller. Those
changes are picked up live. If I have to stuff everything inside a WAR
file I’ve broken that quick development cycle. I now have to edit
code, package, deploy, and then test.
With regular Rails development I just edit and I go to my browser and
hit refresh and I see my changes immediately. That was what I didn’t
like about Warbler as far as a way to deploy Rails applications on
Java app servers. Certainly made it possible, but it didn’t make it
fun and easy and it lost a lot of the cool stuff you get from
developing in Rails in the first place.
Now, that’s not such a big deal if you’re developing just vanilla
Rails apps that run the same way under MRI, traditional Dbase Ruby or
run under JRuby inside a WAR. You can develop under one platform,
package it and deploy under another. But there you’re only dealing
with the web part of the problem.
That’s the second half of what I was trying to attack, was that our
apps are so much more than web and Rails is only just web, Rack is
only just web. But what we do for daemons, what do we do for handling
message queues, that kind of stuff.
That’s where I find a lot of the fun development going on in
TorqueBox. We get to take these functional solutions that the Java
world has and map them down to the Ruby APIs or create Ruby APIs for
them and make it a joy to work with like message driven Beans, if you
will, from Ruby where you never have to think about message driven.
Once you do that then you can’t do this kind of stuff under MRI,
traditional Ruby, so you can’t just develop an app under MRI and
bundle up in a WAR and send it over to your app server. So that’s
where we decided to try to make TorqueBox a real first-class Ruby
platform that works the way Rubyists expect. No more packaging in to
WAR files or anything with Warbler.
Then also give them more than just the web components. That’s where we
start bringing the message listeners, start bringing scheduled jobs
and daemons and things to the app server.