Paul,
yes, a pause in @GET was what we had in mind, but we also think that it
wouldn't scale well. On the other hand, our application must be 100% vendor
transparent, so we cannot use Grizzly specials. We'll just wait to see what
new standards arise in the next months. Maybe JAX-RS 2.0 will support
somthing like this.
Have Fun
Markus
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Montag, 8. September 2008 09:32
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Paper tigers and hidden dragons
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