Something we were looking at doing is having the REST call provide an optional parameter to allow a "push" callback. Basically, in those specific calls (be them polling handlers, or async handlers such as a POST that takes a long time to process), we wanted to allow the optional ability for the consumer of our API to pass in a URL, for example, that we could then call back to. For example, let's suppose the consumer of our REST API is client running inside a web server. Since it is already running in a web server (and presumably one with a static ip/domain name associated with it), there is no reason they couldn't set up a handler on there hand to get "callbacks" sent to them. They could then send in the URL that points to there handler and pass that along. Being stateless, we'd have to store that callback URL in the DB, but when the process was ready, or a change was ready t go back, we can grab that URL and make a call back to the URL with the
appropiate data (be it xml, json, whatever). The URL could be a String that includes the protocol and address, for example,
http://someserver.com/callbackHandler or perhaps some other protocol. We'd probably have to write our API method to handle the various protocols.. indicate what we support, such as http, smtp, email, etc, and then allow the consumer of the API to specify which to use for the callback, maybe even allow multiple incase one is not reachable.
This may not work in all cases... a desktop app for example behind a corporate firewall may have issues with it, but the consumer could alwasy resort back to a poll if necessary.
----- Original Message ----
From: Tatu Saloranta <cowtowncoder_at_yahoo.com>
To: users_at_jersey.dev.java.net
Sent: Monday, September 8, 2008 9:58:49 AM
Subject: RE: [Jersey] Paper tigers and hidden dragons
--- On Mon, 9/8/08, Markus KARG <markus.karg_at_gmx.net> wrote:
...
> on this sector. Maybe someone comes up with a JMS
> implementation (JMS is a
> standard, so we can use it) that is configurable to
> internally use SMTP or
> XMPP as its native protocol, who knows? ;-)
Hmmh? There are multiple high-quality mature JMS implementations
around. But maybe you are thinking of specific bridges from JMS to something else.
But for what it's worth, whenever you are thinking of a poll-based
solution, chances are that message queues might be a better solution.
JMS is obviously the leading candidate, but I would also recommend a quick look at Amaazon's SQS (Simple Queue Service).
It has simple-to-integrate web access API (multiple ones, actually, REST/GET/SOAP), has been in production use for a while, and is very easy to set up.
(disclaimer: my opinion is not objective for this particular product :) ).
For what it's worth, I have used REST + messaging approaches succsefully for large-scale batch processing systems: store data to share in a resource repository, send a message to queue, and then consuming system(s) can process it at their leisure. Queue only sends reference to the resource (optimizes queue usage), and repo (... like, say, s3, which also has neat web access API... :-) ), contains resource itself for cheap storage and fast access.
Just a thought,
-+ Tatu +-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net