On Sep 8, 2008, at 9:12 AM, Markus KARG wrote:
> In fact, we are planning to redesign our enterprise application so
> it will be a RESTful service in future, but some parts of the app
> (controlling production machines etc.) need to work in "near-
> time" (less than one minute delay). Actually we planned to poll the
> RESTful service once every second by each machine, but that would
> end up in thousands of unnecessary requests per minute. XMPP might
> be the solution, but on the other hand, we do not want to implement
> non-standards (XMPP is not a recommendation yet) into our
> application. So it is interesting to see what will happen in the
> next time 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? ;-)
You could use a form of Comet called long polling. Basically the
client makes a request and the service does not send a response
immediately but waits until a response is ready then returns it. The
client can then make another request and wait. This is fully
compatible with HTTP and with HTTP keep-alive. It may give the the
response times you require.
You could support this using Jersey today by waiting in the resource
method, but that would not be good, because the solution will not
scale, we need to support a suspend mode such that threads are not
tied over the period of waiting e.g. using all that nice stuff that
Grizzly offers. Infact i think it would be possible to combine Jersey
and Grizzlet functionality.
Paul.
>
> Have Fun
> Markus
>
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Montag, 8. September 2008 08:43
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] Paper tigers and hidden dragons
>
>
> On Sep 5, 2008, at 7:21 PM, Markus KARG wrote:
>
>
> Paul,
>
> thank you for posting the link. It was really interesting to read.
> While I share Roy's conclusion, I actually think that XMPP is very
> interesting and maybe in some future the world might accept that
> there are two general purpose protocols: HTTP for polling services,
> and XMPP for pushing services.
>
>
> Could be :-) the sometimes difficult part is to know when to
> correctly apply what technology.
>
>
>
> Maybe JAX-RS 3.0 will support it? ;-)
>
>
> It would be interesting to see if XMPP and RESTful services can be
> combined in terms of a Web application. There may be a lot of
> similarities with XMPP and Comet in this respect.
>
> Paul.
>
>
> Regards
> Markus
>
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Freitag, 5. September 2008 10:17
> To: users_at_jersey.dev.java.net
> Subject: [Jersey] Paper tigers and hidden dragons
>
> Hi,
>
> For those interested in designing HTTP-based systems Roy's latest
> blog entry is an excellent piece of thinking [*] about creating
> URIs and scaling:
>
> http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons
>
> (the comments are interesting too, especially the XMPP and SMTP
> comparison).
>
> When i briefly looked at the REST and XMPP presentation (and the
> blog entries about it) my right eyebrow did raise slightly in
> skepticism as to why the example chosen could not be solved using
> plain old HTTP, but then i moved on and got distracted by something
> else. In the less than 30 seconds it took for me to be skeptical Roy
> had a solution, oh well :-)
>
> Paul.
>
> [*] If It Doesn't Fit, Resource It
> http://www.crummy.com/2008/09/04/0
>