--- 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 +-