Archive for the 'ruby-rails' Category

While I’m waiting to board my (delayed, once again) flight to London, I am doing some blog surfing and just came upon this quote from DHH:

“The era of islands is over for most development scenarios. You don’t have to make one definitive choice. Instead, you get to hog all the productivity you can for the common cases, then outsource the bottlenecks to existing packages in faster languages or build your own tiny extension when it’s needed.”

Well, the era of islands did never actually begin for pragmatic developers, to be honest, but anyway I think this sentence, and all of David’s piece, could very well be taken as an endorsement of the work I’ve been doing: investigating the integration between the Ruby and Java worlds.

I like is so much that I’ve just added a slide with the above sentence to my presentation for tomorrow.

And no, I don’t even want to touch the “language wars” thread with a pole. Use the right tool for the job and to each his own.

In the previous episode from this series, I showed you how to use XML-RPC to call Java code from Ruby over the network. In this article, we will do the same, but using SOAP instead of XML-RPC. One advantage of SOAP over XML-RPC is the fact that SOAP endpoints can be described using WSDL and, by using Ruby’s extensibility, new methods can be created on the fly to mirror the methods declared in the WSDL, therefore giving us a lot of nice loose coupling.

Moreover, toolkits exist to automatically create WSDL descriptions from Java classes, so you won’t have to do it by hand. One of these toolkits, and the one we’ll be using in the examples here, is XFire. The most recent version of XFire available at the time I’m writing this is 1.1-RC1. I suspect this example will work just as well when 1.1 final is released. You’ll also need Java5 and Maven 2.

Maven is handy for automatically downloading all the necessary dependencies and running the demo inside a servlet container, using the Jetty6 plugin, without writing much code or configuration. Of course, you can always download all the necessary JARs by hand and drop them, together with the demo code, into the servlet container of your liking.

You can follow XFire’s Quick Start tutorial to set up a simple SOAP service, or you can simply grab a copy of this archive, which adds some more data to the tutorial sample, unzip it and run mvn jetty6:run from its root directory, once you have Maven installed. Go grab a cup of coffee while Maven downloads all the dependencies. Finally test that everything is OK by requesting a copy of the WSDL file from http://localhost:8080/services/BookService?wsdl.

On Ruby’s side, all that is needed is already provided by Ruby’s own core soap library, in particular SOAP::WSDLDriverFactory.

Here’s how you’d call your service from Ruby:

require 'soap/wsdlDriver'
WSDL_URL = 'http://localhost:8080/services/BookService?wsdl'
driver = SOAP::WSDLDriverFactory.new(WSDL_URL).create_rpc_driver
books = driver.getBooks(nil)
p books.out.book[0].title
book = driver.findBook(:isbn => '222')
p book.out.title

A couple of minor nits:

1. The BookService#getBooks method in Java takes no arguments, but if you try to call driver.getBooks without arguments, Ruby complains about a missing argument. Apparently, passing a ‘nil’ value fixes it, but I’d like to know why this is so.
2. XFire add this extra ‘out’ element to its generated schema. This is mildly annoying as you always have to use it in order to access the real values you are interested in.

On the pro side, you can set up all of this with very little configuration. The only configuration that is going to change from one application to another is XFire’s services.xml file which maps service names to service classes, and even this is pretty straightforward:

<beans xmlns="http://xfire.codehaus.org/config/1.0">
  <service>
    <name>BookService</name>
    <namespace>http://sourcesense.com/BookService</namespace>
    <serviceClass>com.sourcesense.xfire.demo.BookService</serviceClass>
  </service>
</beans>

Technorati Tags: ruby, xfire, soap, maven, jetty.

If you’ve been following the previous articles in this series (Part I, Part II, Part III and Part IV) but are not yet satisfied with the range of solutions I presented for calling Ruby code from Java, here’s another one for you.

This one involves running your Java code as a separate process and interacting with it using some form of Web service (XML-RPC, SOAP or a RESTful service). We’ll use XML-RPC for this sample, mainly because it’s very easy to set up and use. You’ll need Apache XML-RPC version 2 to make the code run. Here’s the java code:

public class RPCFetcher {
    public static void main(String args[]) throws Exception {
        WebServer server = new WebServer(8080);
        server.addHandler("$default", new RPCFetcher());
        server.start();
    }

    public Vector fetch(String url) throws Exception {
        URL feedUrl = new URL(url);
        FeedFetcherCache feedInfoCache = HashMapFeedInfoCache.getInstance();
        FeedFetcher fetcher = new HttpURLFeedFetcher(feedInfoCache);
        SyndFeed feed = fetcher.retrieveFeed(feedUrl);
        Vector items = new Vector();
        for (Iterator it = feed.getEntries().iterator() ; it.hasNext() ; ) {
            SyndEntry entry = (SyndEntry) it.next();
            Hashtable map = new Hashtable();
            map.put("link", entry.getLink());
            map.put("title", entry.getTitle());
            map.put("publishedDate", entry.getPublishedDate());
            items.add(map);
        }
        return items;
    }
}

Compared to the previous samples, there’s not much else you need to do, besides creating an instance of WebServer to handle incoming HTTP requests and dispatch them to the appropriate method. However, you need to convert your Java types to something that XML-RPC is able to understand, i.e. strings, numbers, dates, Vectors, Hashtables and little else.

The Ruby client code is much simpler:

require 'xmlrpc/client'
server = XMLRPC::Client.new 'localhost', '/', 8080
entries = server.call('fetch', 'http://agylen.com/feed')
entries.each do | entry |
  p "#{entry['publishedDate'].to_time} #{entry['title']}"
end

Possible drawbacks of this technique are the necessity of having a separate process running and the overhead of HTTP communication and XML-RPC protocol encoding and decoding.

Thanks to Nick Stuart and Erik Hatcher for laying down the basics.