Steve Vinoski's Blog

Shell scripts as web services? Perhaps an obvious question, but hasn’t this capability already been around for about 15 years?

Today InfoQ.com published a new article I’ve written entitled “RESTful Services with Erlang and Yaws.” Stefan Tilkov recently asked me if I had anything to contribute to InfoQ, and I thought an article on that topic might be interesting, as I hadn’t before seen anything covering REST and Erlang together.

I think it’s one of those articles that could be much, much longer and far more detailed if space (and time) permitted, but hopefully there’s enough there to whet your appetite if you’re considering developing RESTful web services in Erlang. I really can’t say enough good things about using Erlang and Yaws for this purpose — it’s quite a solid platform.

I’ll be giving a talk on the same topic at both JAOO Brisbane and JAOO Sydney at the end of May and beginning of June, respectively.

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.

As you may know, I’m a columnist for IEEE Internet Computing (IC), and I’m also on their editorial board. Our annual board meeting is coming up, so to help with planning, we’ve issued a call for special issue proposals.

The topics that typically come up in this blog and others it connects to are pretty much all fair game as special issue topics: REST and the programmatic web, service definition languages, scalability issues, intermediation, tools, reuse, development languages, back-end integration, etc. Putting together a special issue doesn’t take a lot of work, either. It requires you to find 3-4 authors each willing to contribute an article, reviewers to review those articles (and IC can help with that), and a couple others to work with you as editors. As editors you also have to write a brief introduction for the special issue. I’ve done a few special issues over the years and if you enlist the right authors, it’s a lot less work than you might think.

As far as technical magazines go, IC is typically one of the most cited, usually second only to IEEE Software, as measured by independent firms. I think one reason for this is that it has a nice balance of industry and academic articles, so its pages provide information relevant to both the practitioner and the researcher.

Regarding the REST and IDL discussion, Joe Gregorio already wrote an excellent explanation six months ago. Perhaps the rest of us should have just linked to it to begin with and avoided wasting our time rehashing it all.

But then again, rehashing is fun! :-) On the same topic, I agree with much of what Dare said, except for this:

When building services with WS-*, you have a WSDL to describe your methods & expected inputs/outputs and XSD schema(s) to describe the schemas for said inputs/outputs. When building a RESTful Web Service, the need for both of these documents does not go away regardless of how often you repeat the phrase “uniform interface”.

I still disagree. The HTTP verb set defines a RESTful uniform interface. When comparing CORBA IDL or WSDL to HTTP web services, that verb set must be considered because it’s the only thing that you can directly relate to IDL and WSDL interfaces. Otherwise, you’re talking apples and oranges. The uniform HTTP interface is the only way for applications to interact with web resources in the same sense that CORBA applications interact with CORBA objects, and WSDL applications interact with WSDL services.

Much of the typical IDL and WSDL definition is devoted to defining one or more specialized interfaces consisting of specialized methods/operations and specialized data types to pass across them. For web resources that use the uniform interface, however, there’s simply no need whatsoever to define interfaces like that. What are you going to do, define GET again and again for each of your resources, each time with exactly the same semantics already specified in RFC 2616? Obviously not.

It’s easy to see that Joe’s OpenSearch document bears no semantic resemblance to a CORBA IDL or WSDL definition. Similarly, an AtomPub service document is nothing like IDL or WSDL either. Both of those documents essentially inform you of service URIs and media types, but they don’t define methods or operations. They don’t have to, because of the HTTP uniform interface. That’s important, and it’s why I disagree with Dare’s point quoted above.

Consider the mindset of the CORBA and WS-* developer. They use systems that force them to always think about all their service endpoints in terms of specialized interfaces. Given how much time I’ve spent in that world (and don’t forget, I still use CORBA too), I know for certain that the concept of the uniform interface is one of the big items that trips these developers up when they try to figure out what REST is about. It’s therefore important to keep the uniform interface as part of the conversation.