aspose file tools*
The moose likes Web Services and the fly likes restlets for RPC? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "restlets for RPC?" Watch "restlets for RPC?" New topic
Author

restlets for RPC?

Geoff Boushey
Greenhorn

Joined: Jan 21, 2005
Posts: 11
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
author
Greenhorn

Joined: Jul 23, 2003
Posts: 13
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?


Sam Ruby
Geoff Boushey
Greenhorn

Joined: Jan 21, 2005
Posts: 11
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
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2906
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 ]

    "Don't succumb to the false authority of a tool or model. There is no substitute for thinking."
    Andy Hunt, Pragmatic Thinking & Learning: Refactor Your Wetware p.41
    Frank Carver
    Sheriff

    Joined: Jan 07, 1999
    Posts: 6920
    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
    Sheriff

    Joined: Jan 07, 1999
    Posts: 6920
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: restlets for RPC?
     
    Similar Threads
    What is distributed Computing from an Application's Point of View
    Posting to a webservice
    Procedure-style Web Services
    JAX-RPC and JAX-WS
    SCJA Prep