restlets for RPC?

[Geoff Boushey]

I'd love to get some feedback on the possibility of using REST for remote procedure calls (or the sort of problem addressed by RPC).

Right now, I have a time and data intensive algorithm that can take anywhere from 2-30 minutes to run. This algorithm is just one part of a process, but it is by far the most computationally expensive. Our current approach is to place the code on a dedicated server and run it through remote procedure calls.

I've just started looking into this, and Apache Axis looks very promising - and I'll admit that part of its appeal is that it was extremely easy to get up and running with it. Essentially, it appears to require little more than creating a special java class with the method calls I need and a special extension.

I'm interested in restlets in general, but for the task at hand, would they offer substantially more than I would get out of axis? Or is this sort of internal RPC issue not really what restlets are designed to handle?

Looking forward to reading RESTful web services. Thanks.

[Sam Ruby]

It sounds to me like you are trying to GET a document. Why not assign that document a URI, and simply GET it? What additional functionality is Axis providing for you in this scenario?

[Geoff Boushey]

Hi Sam,

Truthfully, I'm early enough in this that I can't be sure there is any advantage over writing a small script on my own.

The algorithm needs a set of input parameters, and I need to send back machine readable information on how to process it - ie, whether it ran, how it ran, how long it took, whether there were any flags or warnings, what output (if any) was produced, where it can be found... and the client (machine) will act on this information. So I think ome kind of XML response over HTTP would probably be the easiest way to go.

It looks like Axis will produce a lot of this for me, with very minimal effort, so it seems more appealing than writing my own. I also like the idea of being able to use tomcat and what appear to be very simple java classes to expose methods. But I don't just want to jump on the first easy framework I find, which is why I'm investigating a few others (I found out about restlets while I was googling around about Axis).

- Geoff

[Frank Carver]

I completely understand about not wanting to leap onto the first passing framework. What I think you may be skipping over is that REST itself is not framework specific. You can do REST without RESTlet (in fact, the web as a whole does REST pretty well using mainly Apache).

My suggestion would be to first think about the overall workflow of your problem. What data needs to move around in order to get the job done, and under what conditions and rules. Then, when you have some sort of understanding of that, you can think about mapping it to the REST operations: GET, PUT, POST and DELETE.

Once you have a feel for a few example requests and their data you can evaluate implementation frameworks. RESTlet is apparently covered in Leonard and Sam's book, but REST is also possible using plenty of other technologies including my own Mojasef, the raw servlet API, and equivalents in many other languages.

[Peer Reynders]

Originally posted by Geoff Boushey:
Right now, I have a time and data intensive algorithm that can take anywhere from 2-30 minutes to run.

Originally posted by Sam Ruby:
It sounds to me like you are trying to GET a document. Why not assign that document a URI, and simply GET it?

Now I'm assuming your not suggesting a blocking request for a response that may not be issued for 30 minutes.
So is your thinking along the lines of:

GET a new ProcessInstance (the URI to your new "document") from a ProcessInstance Factory URI.

PUT the input parameters to your ProcessInstance URI

GET the results from your ProcessInstance URI. The representation carries the status and the result. The status will indicate whether the process has finished - if it has, the result won't be empty.

DELETE the ProcessInstance when you no longer need the results.

[ June 15, 2007: Message edited by: Peer Reynders ]

[Frank Carver]

Originally posted by Peer Reynders:
So is your thinking along the lines of:

GET a new ProcessInstance (the URI to your new "document") from a ProcessInstance Factory URI.

PUT the input parameters to your ProcessInstance URI

GET the results from your ProcessInstance URI. The representation carries the status and the result. The status will indicate whether the process has finished - if it has, the result won't be empty.

DELETE the ProcessInstance when you no longer need the results.

That sounds mostly like what I was expecting, although I'd probably make the request to create a new empty process instance a POST. I'm hesitant to allow two GETs in a row to the same URL to return different data - that defeats one of REST's greatest strengths, cachability of GET responses.

[Frank Carver]

Thinking about it a bit more, I would probably also consider providing some sort of "index page" which listed active processes, so that the detailed status of any active process could be requested if desired from its own URL.

I'd also be tempted to make the final output of each process available on its own URL, different from the status URL for that process, and different from any other data URL. requests to this URL could block until available if desired. Client code which does not care about intermediate status could just wait. Client code which wishes to be asynchronous and show progress could poll the status URL and only access the data URL when the status URL reports it as ready.