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.
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).
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.
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:
[ June 15, 2007: Message edited by: Peer Reynders ]
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.
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.