Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

July 19 2011

Ruby is for Java

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.

An Interview with Bob McWhirter on Torquebox, Java, and Ruby


(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 longer.

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.

OSCON Java 2011, being held July 25-27 in Portland, Ore., is focused on open source technologies that make up the Java ecosystem. (This event is co-located with OSCON.)

Save 20% on registration with the code OS11RAD

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 WAR file.

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.

May 08 2011

Feeding the community fuels advances at Red Hat and JBoss

I wouldn't dare claim to pinpoint what makes Red Hat the most successful company with a pervasive open source strategy, but one intriguing thing sticks out: their free software development strategy is the precise inverse of most companies based on open source.

Take the way Red Hat put together CloudForms, one of their major announcements at last week's instance of the annual Red Hat Summit and JBoss World. As technology, CloudForms represents one of the many efforts in the computer industry to move up the stack in cloud computing, with tools for managing, migrating, and otherwise dealing with operating system instances along with a promise (welcome in these age of cloud outages) to allow easy switches between vendors and prevent lock-in. But CloudForms is actually a blend of 79 SourceForge projects. Red Hat created it by finding appropriate free software technologies and persuading the developers to work together toward this common vision.

I heard this story from vice president Scott Farrand of Hewlett-Packard. Their own toe hold on this crowded platform is the HP edition, a product offering that manages ProLiant server hosts and Flex Fabric networking to provide a platform for CloudForms.

The point of this story is that Red Hat rarely creates products like other open source companies, which tend to grow out of a single project and keep pretty close control over the core. Red Hat makes sure to maintain a healthy, independent community-based project. Furthermore, many open source companies try to keep ahead of the community, running centralized beta programs and sometimes keeping advanced features in proprietary versions of the product. In contrast, the community runs ahead of Red Hat projects. Whether it's the Fedora Linux distribution, the Drools platform underlying JBoss's BPM platform, JBoss Application Server lying behind JBoss's EAP offering, or many other projects forming the foundation of Red Hat and JBoss offerings, the volunteers typically do the experimentation and stabilize new features before the company puts together a stable package to support.

Red Hat Summit and JBoss World was huge and I got to attend only a handful of the keynotes and sessions. I spent five hours manning the booth of for Open Source for America, which got a lot of positive attention from conference attendees. Several other worthy causes in reducing poverty attracted a lot of volunteers.

In general, what I heard at the show didn't represent eye-catching innovations or sudden changes in direction, but solid progress along the lines laid out by Red Hat and JBoss in previous years. I'll report here on a few technical advances.

PaaS standardization: OpenShift

Red Hat has seized on the current computing mantra of our time, which is freedom in the cloud. (I wrote a series on this theme, culminating in a proposal for an open architecture for SaaS.) Whereas CloudForms covers the IaaS space, Red Hat's other big product announcement, OpenShift, tries to broaden the reach of PaaS. By standardizing various parts of the programming environment, Red Hat hopes to bring everyone together regardless of programming language, database back-end, or other options. For example, OpenShift is flexible enough to support PostgreSQL from EnterpriseDB, CouchDB from Couchbase, and MongoDB from 10gen, among the many partners Red Hat has lined up.

KVM optimization

The KVM virtualization platform, a direct competitor to VMware (and another project emerging from and remaining a community effort), continues to refine its performance and offer an increasing number of new features.

  • Linux hugepages (2 megabytes instead of 4 kilobytes) can lead to a performance improvement ranging from 24% to 46%, particularly when running databases.

  • Creating a virtual network path for each application can improve performance by reducing network bottlenecks.

  • vhost_net improves performance through bypassing the user-space virtualization model, QEMU.

  • Single Root I/O Virtualization (SR-IOV) allows direct access from a virtual host to an I/O device, improving performance but precluding migration of the instance to another physical host.

libvirt is much improved and is now the recommended administrative tool.

JBoss AS and EAP

Performance and multi-node management, seemed to be the obsessions driving AS 7. Performance improvements, which have led to a ten-fold speedup and almost ten times less memory use between AS 6 and AS 7, include:

  • A standardization of server requirements (ports used, etc.) so that these requirements can be brought up concurrently during system start-up

  • Reorganization of the code to better support multicore systems

  • A cache to overcome the performance hit in Java reflection.

Management enhancements include:

  • Combining nodes into domains where they can be managed as a unit

  • The ability to manage nodes through any scripting language, aided by a standard representation of configuration data types in a dynamic model with a JSON representation

  • Synching the GUI with the XML files so that a change made in either place will show up in the other

  • Offering a choice whether to bring up a server right away at system start-up, or later on an as-needed basis

  • Cycle detection when servers fail and are restarted

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl