First, a quick announcement. We’re wrapping up Ruby In Practice and heading towards final review. Finally.
If you already bought the early access edition from Manning, you’ll get a new PDF with the remaining chapters. If you didn’t, Pat Eyler is running a blogging contest and giving away a free copy. The rules are simple: blog about your Ruby In Practice adventures, and let Pat know about it. I’d love to hear about your experience with Ruby.
With so many Ruby books on the shelf, we decided not to focus on the language itself, but cover the things you use Ruby for. Most of the topics we cover in Ruby In Practice deal with business applications. Yes, that dreaded enterprise stuff. But why not, when Ruby helps you do things simpler and better?
If you’re still sizing up Ruby for your next project, here’s a few things we get to cover in the book (and a couple we don’t).
HTTP and REST
Although some people confuse them, HTTP and REST are not one and the same,and we keep to that distinction.
We have one section dealing with HTTP and covering the basics: URI, open-uri, Net::HTTP, Mongrel. The REST part expands on it to deal with resources and representations, and does so using Rails 2.0 and ActiveResource.
One reason we picked Rails is the wonderfully pragmatic way it uses HTTP and REST. It’s a smart application of Web Architecture practices, one I can point to people and say “here, learn by example”. Even if Rails is not your cup of tea, I recommend looking at it inspiration and ideas. Other people’s experience, amplified.
SOAP
Wish I could say the same about SOAP. Let me summarize SOAP4R: it smells like Java code built on a Monday morning by an EJB coder.
To its defense, once you get SOAP4R working, it does what you expect it to do. It’s just not pretty, simple or fast about it. SOAP4R is WS-I compliant, so you can use it to interoperate with Java and .Net. In the book we show you how to use it effectively, but clearly SOAP4R is not going to win you over to the WS-* side. If anything, you’ll learn to appreciate the simplicity of REST even more.
There’s also ActionWebServices. Although it cleans up the SOAP4R API, it does so by using Ruby annotations and focusing on RPC-style services. If you are using SOAP, at least do it right with contract-first design and doc/literal messaging. We start the example with a WSDL service definition which we use to generate the client and server code, and SOAP4R was the best option we’ve got.
Two recent additions that appeared too late for inclusion in the book are WSF/Ruby (Axis/C with Ruby bindings) and using JRuby in combination with Axis/J.
Axis has killer support for SOAP, WSDL and various other WS-* specs, not to mention performance and stability. All good things, but right now both options mean working with the low-level APIs. It feels more like coding in C and not what you’d expect to find in Ruby.
For the motivated, here’s a cool project idea. Build a Ruby Goodness WS-* API that can use SOAP4R, WSF/Ruby or Axis/J as the underlying stack. I’d love to see something like that.
And speaking of Ruby Goodness APIs for enterprise messaging …
WebSphere MQ
WebSphere MQ is one software product that captures so well the essence of Enterprise computing. That thing has more knobs and switches than a Boeing 747 cockpit, legacy support going back to the ENIAC, and command line tools that only its mother can love. It comes with an Eclipse-based management tool full of usability mistakes that refuses to admin anything (on my machine, at least).
On the other hand, it’s WebSphere MQ. It has all the options you’ll ever need, broad platform support from PC up to the biggest meanest of mainframes, and everything can be managed from the command line, or scripted. So what’s
not to love?
I know what you’re thinking, WebSphere MQ and Ruby are the opposite extremes, putting both in the same room would be an hilarious blind-date gone bad. It so turns out the two have great chemistry.
J. Reid Morrison developed a beautiful Gem, literally, and in the span of a few hours working with it, RubyWMQ became my favorite add-on feature for WebSphere MQ.
RubyWMQ is a thin wrapper around the C client library. I always preferred working with the WMQ API over the complex abstraction that is JMS. Call WMQ::QueueManager.connect to establish a new connection, WMQ::Message.new to create a new message. No JNDI lookups, factories, sessions, just WMQ served straight up in all its glory.
Here’s the surprising part. Even though the entire thing is written as a C wrapper on top of a C API, it has all the right Ruby idioms that make it such a productive pleasure to use.
One example we get to cover in the book:
queue.each(:sync=>true) do |message| puts message.descriptor[:msg_id] puts message.data end
Guess what happens when the processing block raises an exception? It moves to process the next available message, while letting WebSphere MQ deal with re-delivery, backout and dead-letter queuing of the failed message.
The simplest processing loop you’re going to write will buy you the reliability that WebSphere MQ is known for. No heavy-weight app servers, no XML inversions, just simple, intuitive code.
It gets better.
ActiveSalesForce
Knowing what a pain WebSphere MQ is, I set aside enough time for this exercise. Installing the beast took forever, but once I got to the Ruby part, everything just flowed and I ended up with time to spare. So I decided to up the stakes.
The WMQ example consisted of a small Ruby program that collects XML messages from various applications and stores them in the database. What would it take to create these records in SalesForce?
One line of code and one configuration change later, and I’m running the program with messages coming over WebSphere MQ and sales leads popping up in my SalesForce dashboard.
Couldn’t be simpler.
Wrap Up
When it comes to Ruby, REST support is ahead of the curve, SOAP support is as bad as most other languages, and nothing like what you can expect with Java/.Net.
You’re also going to be disappointed if you live for the rush of setting up an ESB that can JMS messages on one end and JCA on the other, coding for generic APIs, and writing XML configurations like there’s no tomorrow. Ruby favors simple steps to get the job done over big infrastructure purchases.
But how well do you know Ruby? Just a scripting langauge that can also serve Web pages? Think again. Ruby got skills, the little language can do serious heavy lifting. How many languages you know that can wire your message bus to online services with just a few lines of code?
Ruby and WS :: Steve Vinoski’s Blog