Ruby and WS

January 29th, 2008  |  Published in code generation, dynamic languages, productivity, Ruby, services, WS-*, WSDL  |  5 Comments  |  Bookmark on Pinboard.in

Via Stefan Tilkov: Assaf Arkin talks about his upcoming book, Ruby in Practice. I don’t know anything about the book, but it sounds interesting.

Assaf talks about having a nice Ruby interface for WS, and also talks about wrapping Websphere MQ with Ruby. It reminded me of some work I was doing about a year and a half ago, when I still worked for IONA: developing a Ruby wrapper for Artix. I left there before it ever saw the light of day, so I doubt anyone will ever see it, but it was pretty cool. It was implemented using only customer-visible C++ APIs, and it afforded at least an order of magnitude reduction in the number of lines of code required to get anything done. It used WSDL4R to interpret a WSDL definition at runtime and dynamically generate accessor functions for the service, i.e., there was no up-front static code generation. You could point the client at the service, and if the service supported access to its WSDL (typically via a ?wsdl query string added to the service URI), the client could download the WSDL and dynamically generate everything required to access that service. I wrote about how to develop such Ruby extensions in my Sep/Oct 2006 IC column.

I remember presenting an example of the system in an internal sales engineering meeting where the original C++ and Java code required 70-80 lines of code while the equivalent Ruby code was only 7 lines. It wasn’t 7 lines of obfuscated expert-only Ruby, either; it was quite easy to read and understand. The SEs, most of whom worked only in Java and C++, kept looking at it and scratching their heads. They’d say, “Hey, you forgot to do this!” and I’d say, no, that happens right here. And they’d say something similar about another required action, and the answer was always the same: no, it’s in there. Basically, Ruby allowed me to hide a bunch of crufty, verbose, uninteresting but required boilerplate and focus only on service interactions. Waaay nicer than the equivalent Java and C++, for sure.

On a related note, just prior to that project, I did some work with Apache CXF to develop a server-side JavaScript and E4X JAX-WS capability. Since I no longer work in the middleware or WS worlds, I haven’t kept track of that code, so I don’t know if CXF still supports it or not. But either way, given the fact that JRuby now exists, there’s no reason that someone couldn’t take that work and redo it in JRuby. It would be pretty straightforward.

Responses

  1. Patrick Logan says:

    January 30th, 2008 at 12:23 am (#)

    This reminds me of Windward Solutions’ Smalltalk implementation of CORBA. I only used a few CORBA implementations for a few languages (Java, C++, and Smalltalk), but the Smalltalk implementation was far and away the easiest to use.

    Something about simple dynamic languages, or something.

  2. Stefan Tilkov says:

    January 30th, 2008 at 1:45 am (#)

    I wonder: why even bother with WSDL (even within the WS-* space) – wouldn’t it be better to simply use a “duck typing” approach and turn a Ruby-style invocation, probably combined with an E4X-style builder pattern, into the corresponding SOAP message?

  3. steve says:

    January 30th, 2008 at 9:13 am (#)

    Stefan: in general that would work, but I worked at the WSDL level because Artix uses WSDL as an abstraction over multiple protocols and message formats, other than just SOAP over HTTP. This IC column (pdf) describes that approach. For example, Artix lets you use WSDL to describe existing CORBA services, MQ services, etc. By having the Ruby client operate at the WSDL level, the client can access services regardless of their underlying distribution technology, as long as Artix supports it.

  4. Labnotes » Rounded Corners - 188 (Catching up) says:

    January 30th, 2008 at 1:51 pm (#)

    [...] want to know what lies ahead, where to go next. The people who can point you there are the ones not locked-down to yesterday’s technology: The SEs, most of whom worked only in Java and C++, kept looking at it and scratching their heads. [...]

  5. Rajith Attapattu says:

    January 31st, 2008 at 1:27 pm (#)

    Steve,

    I enjoyed the blog post as well as the Sep/Oct 2006 IC column. I write most of my web based testing tools in python using web.py or cherry py. I also use python/ruby scripts heavily as a configuration tool for my broker testing. It’s a lot more powerful and expressive than editing some XML or meddling with a GUI.