Odd Theses - A Look Inside JBoss Rails & Cloud with Bob McWhirter
Odd Theses - A Look Inside JBoss Rails & Cloud with Bob McWhirter
Join the DZone community and get the full member experience.Join For Free
Developers today not only have a plethora of languages to choose from, but also a vast array of virtual computing platforms on which to deploy these increasingly multilingual applications. To better facilitate this paradigm shift, JBoss Engineer Bob McWhirter has been busy working on two interesting projects at Red Hat: JBoss Rails, a JBoss AS5 deployer for enterprise Ruby on Rails applications, and JBoss Cloud, a collection of scripts and rakefiles to build cloud server images. In this exclusive interview, he looks at the application and future direction of these two projects.
DZone: We're speaking today with Bob McWhirter, software engineer at JBoss, who is currently involved in researching and prototyping new open-source projects. He currently maintains a blog at Odd Thesis. Bob, what is this Odd Thesis?
Bob McWhirter: Well, Odd Thesis is a way that I've been using to constrain my work, since I'm doing research and prototyping and it's basically open-ended. And so I've come up with theses of what I think could be possible with JBoss technologies, and then I go out to prove or disprove if they would be possible. And so far, I've been relatively successful. [img_assist|nid=7629|title=|desc=|link=none|align=right|width=92|height=180]
DZone: What has been your biggest revelation in your research?
Bob: My biggest revelation so far is that JBoss AS5 is an awesome foundation to do anything with. Again, it's very simple to do JBoss-deployed Rails. It's just a great piece of software to work with.
DZone: What is JBoss on Rails?
Bob: So JBoss Rails is my attempt, to basically run Rails applications under the JBoss AS5 App Server. This has been made possible because the JRuby guys have already been out there working on the Ruby interpreter for the JVM, and Nick Sieger created JRuby Rack, which allows you to deploy Ruby apps on an App Server. The problem with that, though, is you have to build WAR files and deploy them the same you'd deploy any other WAR file.
So, with JBoss Rails, I was attempting to be able to deploy a Rails app right where it sits on disk, which would still allow for the live editing of your models, if you're using controllers, and seeing the changes reflected live in your running app, which is great for the test-and-edit cycle, as you move back and forth between your browser and your editor.
DZone: Why not Groovy, Grails or say, Scala support?
Bob: Well, Scala is interesting to me. I am going to take a look at that here in the future. As far as Groovy and Grails support, my view there is that there is already a lot of stuff done in that world, and that these people are going to be typically, Java programmers who are looking for alternatives, so that's not really enlarging our market, to kind of start speaking corporately.
Where, if we look at Rails developers, these are people who don't have a Java environment yet, and that's a larger market for us to go after. We can bring more people into the Application Server fold by preaching other development languages, such as Scala, or Rails in this case.
DZone: How do I develop, test and deploy my applications using JBoss Rails?
Bob: If you're a typical Rails developer, there's just been a few ways, no matter what your deployment environment is, to develop your application. You can either use system-wide VMs, or you could do what's called vendor remedying, which is, where you basically pull every dependency into your Rails app. JBoss Rails requires you to vendorize everything. So you pull Rails itself into your source tree. You pull all your plug-ins into your source tree. This is because we can't really count on the system to have these system-wide libraries. So that's really a best practice, regardless of whether you're using JBoss Rails or not.
The one other big change you have to make with your language is you've got to use to use JDBC instead of the native Ruby drivers. So that's a new thing.
And we provide the JBoss Rails plug-in that makes it really easy for you to go and fix up your application. It will look at your configuration and figure out which JDBC driver you need, and it will go install it into your source tree. And then, also, extra little handy things for like deploying your app over to your JBoss home and getting your server up and running.
DZone: Have there been any specific changes made to the new Microcontainer model or the application server to accommodate JBoss Rails?
Bob: Well, not specifically to accommodate JBoss Rails, but as I was saying, AS5, it's implemented the JBoss Microcontainer which starts off as an inversion-of-control container, like so many other that are out there at this point. And then it also adds this whole deployer framework, which is a way to get additional beans going inside your bean stack, basically. And so, using that really provided this great foundation to build the Rails deployer, which goes out there at looks for a Rails app and knows where to look for configuration files and ways that these trials should be served on the web and everything.
And it runs the Rails deployer, which is popping up POJO inside a Microcontainer, which brings in the services running in AS5, and then you have your Rails app online. It's magic.
DZone: It sounds like it, definitely. But it also sounds like it's fairly easy now, given your new Microcontainer model, to build in support in for multiple languages. As you discussed, you may decide to do something similar for Scala.
Bob: Right. I mean, as long as there's an interpreter for the language, or some way to evaluate the code in a given language within the JVM, then, yeah, absolutely. A Microcontainer in AS5 will make that super-easy, because we're just dealing with POJOs and just creating objects here and there and setting up some configurations through meta-data. There's a lot of moving parts, but they're all very, very small. Very few of the classes that make the JBoss Rails possible are more than 80 lines of code. There's just not a whole lot, necessarily going on in there.
DZone: What direction would you like to take this project in?
Bob: I think one of the ways we can go with Rails is start providing a lot more of these enterprise services that the Rails world simply doesn't really have yet. I mean, coming from a Java EE background here, we're used to so many services being provided by the JSRs and everything, the JDK and all the specs we follow. But the Rails world has pretty much been looking purely at web. It only answers the servlet aspect of things.
I've worked on a little bit of scheduler stuff. So, for your Rails app, you can have scheduled tasks, cron jobs, written in Ruby, that are deployed right along with your app as you deploy it. And that doesn't exist within a normal Rails application at this point.
And I think providing more enterprise things, like integration with the Drools rule engine, or the ESB, or even asynchronous messaging with one of our JMS solutions.
These are now things that we can provide to Rails people in a nice, end-to-end package that's enterprise-grade that's simply not available if you choose Mod, Passenger or any other, like Mongrel, for your deployment that is purely web-centric.
DZone: Well, it sounds really revolutionary. I mean, being able to code using the language of choice, and still gain the out-of-the-box Java EE services that were provided, previously only to enterprise Java applications. I guess the question is, is Ruby now becoming more a language of choice over Java, now that we do have these services available to almost any language that does deploy to the JVM?
Bob: Well, I this it is just a matter a choice. I mean, I think certain shops will always be happy sticking straight with the JSRs and the stacks and doing everything with Java and annotations and everything, just because that works with their development model. And that's fine. I'm not trying to convert these people. But, I also see that there are a lot of Ruby shops, a lot of Rail shops out there at this point and there are other little languages, Python or ZOPE or PHP or whatever. And these are people who - a lot of Java developers look at them and laugh at this point and say, "Oh, that's an immature language or industry technology."
I remember Java 1.1.8 and we were there at one point ourselves, and I see that these are all people who can benefit from the experience we've accumulated as Java guys in the enterprise.
And we can provide that to them, instead of looking at it as language wars, where we see Ruby or Rails as just another progressive model that can runs perfectly well under the JVM, that brings a lot more to the table and, hopefully, brings something to our table.
DZone: Switching gears a bit, Bob, you are also working on another project called JBoss cloud, tell us about that.
Bob: Right. So, JBoss cloud, is basically my attempts to make easy to run JBoss edits to the Rails edits or to the apps or whatever they are, usually, within the cloud, whatever that may be. So, I view the cloud to be an OS level virtualization. So, looking at Amazon EC2 or if you were running your own data center full of Xen or KVM, or whatever, VMware, I don't consider things like Google's app engine to be the cloud, or I guess that Sun has the grid engine or something.
So, you're basically getting chunks of computer tasks, that's not the cloud. I want to drop the whole operating system stack out there to virtual hardware, that's the cloud.
DZone: Is there any direct connection between JBoss cloud and the JBoss Rails project?
Bob: Other than the fact that I'll be able to deploy my Rails app on the cloud, no not at all. Anyone can take any WAR file, ultimately into the cloud or EAR. You know, it's anything that you can do on JBoss, I want to be able to do JBoss on the cloud, including my Rails stuff, but it's not limited to that.
DZone: So, what are some of the biggest challenges associated with building applications for the cloud then and also deploying them to the cloud?
Bob: So, working mostly with EC2 is the definitive common cloud we can all talk about, and it is - it relates back to like, if you're running a lot of VMware, that you don't have multicast available to you yet. So, the EC2 is kind of doing that to really keep everybody isolated and not sending noise everywhere. So if you don't have multicast, that can really affect cluster formation when you boot up a lot of the AS5 nodes, and so that's one thing we've got to work around, use JGroups gossip servers to get around that.
Another problem, you know, most cloud environments are booting these machines on DHCPs so you don't even really know the address of where these machines are popping up necessarily without doing some extra poking. So you've got to do some reconfiguration like the bind address for AS5, so it's listening on the public IP address, whatever that turns out to be.
So, we use some tooling from another group within Red Hat called Thincrust and that helps with a lot of this reconfiguration stuff, upon first boot. The machine can figure out who it is, where it is, what its configuration needs to be, and you can change your config clouds before AS5 comes up.
DZone: How does virtualization make clustering and scaling easier?
Bob: Well, I mean virtualization removes a lot of the roadblocks that you face when you start trying to cluster in a traditional environment. I mean, when you're clustering traditionally, you're looking at, you know, stacks of hardware, and so it's probably installing things manually, inserting certain CDs or, you know, ssh-ing into things and configuring each of your nodes. But once you start thinking in terms of the clouds, you're looking at putting a lot more work in upfront to make sure you have these images that you can just go launch out in the cloud without any effort.
And so, with this upfront work that I'm doing for everyone at this point, it will hopefully make it easier that to cluster, all you have to do is go launch three instances of the AS5 and be done.
So, you know, this upfront work it makes the reconfiguration easier and it solves all those problems within in the cloud and embodies best practices, if you will. It will make the actual launch of the cluster easier down the road when people decide they're going to cluster.
And, with a cloud, you're looking at a very fungible resource. They're all very homogenous and so you want to make sure you have your tooling, and your configurations are set up so that you can go from cloud of three nodes to four nodes, or go from a cloud of three down to two very easy without having to get a system up at 4 AM and have to go and ssh into a machine before you can change things.
DZone: So, Bob, you'll be presenting JBoss Rails and JBoss Cloud at the upcoming JBoss Virtual Experience event on February 11th. Can you give our readers a brief preview of what you'll be covering in the presentation?
Bob: Yeah. So, there, we've got a half hour, we kind of split it across different projects. We hit the high levels of everything. I jump through the Rails stuff, I talk about the plug-ins that make it easy to use Rails, kind of dive a little bit into the Microcontainer workings of the various deployers that make it possible, mostly to give people an idea where they can go looking for code perhaps. And then, we talk about the cloud stuff, and there I demonstrate how we stitch together these server images for your front-end servers with mod clusters, to your back end servers with AS5.
And then I wrap it all up with a little demo through the slide deck of deploying onto a VM2 cloud. VM2 is just simply a little layer I wrote to VMWare that makes it behave somewhat like EC2 so you can register images and spin out multiple instances of an image.
And so, it's just a really quick jaunt through the whole scenery.
DZone: Bob, can JBoss users begin using JBoss Cloud and JBoss Rails today and where would they go to download the software?
Bob: Yeah, if you head over to OddThesis.org, I would certainly say you can use JBoss Rails today. I mean, OddThesis itself runs on JBoss Rails; it's actually a somewhat older version. I haven't deployed there lately but it's perfectly usable; it should work without any surprises. For the cloud stuff, we're still working on that. I have not produced any images lately that people can go easily launch in EC2 or download themselves. But, the project, if you feel like building it yourself, if you have a Fedora system, you can start producing images all day long which you can launch in your virtualization environment.
I hope to soon have a release of JBoss Cloud that includes a full portfolio of images from front end with mod cluster and JGroups configuration, AS5 notes and even a postgres server image.
So, you get everything you need all together in one portfolio of servers. I hope to have a release of that in the next month or so and then that will, certainly, be very usable for people.
DZone: Well I encourage our members to go over to Odd Thesis to check out Bob's blog and to download the images. Any final words of advice for our readers?
Bob: Not right off hand, just keep learning all the cool new stuff that's coming out with AS5, because they're really opening the world for everyone.
Opinions expressed by DZone contributors are their own.