On May 14, 2009, at 6:32 PM, Ido Ran wrote:
> Hello,
> I'm developing an application using Glassfish V2 which has two
> modules: EJB and Web (RESTful).
> The Web module expose RESTful resources which are backed by EJB
> session and/or entities.
>
> As a client I have a .NET application which communicate with the web-
> module using standard HTTP. and everything is working good.
>
> The thing is I currently missing two important pieces which maybe
> compliment to each other. The pieces are notification (signal that
> something has changed on the server and the client need to be
> updated), the other piece is cache on the client side.
>
> I've done some research on the web about notification in REST
> architecture and the answer I've got is there are non, or in other
> words it can be implemented using polling.
> That's what make me think maybe cache is the answer.
> Since I have a smart client, meaning an application which store
> state, not only get the state from the server and present it, I have
> the ability to cache the server answer on the client side and poll
> on the server every now and then (I'll leave the time span for
> someone more close to the customers than me).
>
Polling is an OK solution for many scenarios. It is also possible to
utilize Comet-based techniques for when notification is required, but
it is not ready yet for Jersey. See the Atmosphere project for
development in this area:
http://atmosphere.dev.java.net
Jean-Francois will have a working prototype real soon :-)
> So, finally, the question is how jersery can help me implement cache
> by means of etag, modified-since and other built-in (or need to be
> implemented by me) features.
>
See the pre-condition methods on Request :
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/Request.html
A simple example of this utilized in the Sparklines sample [1]:
http://fisheye4.atlassian.com/browse/~raw,r=1422/jersey/trunk/jersey/
samples/sparklines/src/main/java/com/sun/jersey/samples/sparklines/
SparklinesResource.java
You will need to implement the application-based functionality to get
the last modified date or etag of the resource to compare against that
of that in the request using the pre-condition methods.
As for the client side, Jersey does have an client API, but there is
currently no caching support for this, so you will have to write that
yourself, or integrate an existing caching API with Jersey. Such
caching support can be supported by a client filter. Definitely
looking for contributions in this area.
Paul.
[1]
http://download.java.net/maven/2/com/sun/jersey/samples/sparklines/1.1.0-ea/sparklines-1.1.0-ea-project.zip