I'm currently researching whether BlazeDS for accessing Java Objects from a Flex client makes sense.
BlazeDS is supposed to be much more efficient than other alternatives such as JSON or SOAP.
Unfortunately it seems that Adobe's open source BlazeDS does not allow one to use HTTP's caching infrastructure. This pretty much renders the more efficient binary AMF protocol pretty much useless for scaling to many users. Fewer requests are almost always better than smaller requests.
Live Cycle Data Services Adobe's commercial variant of BlazeDS has sophisticated offline support. This might help to get things cached, but first it's commercial and second it might be to complicated, if you don't intend to develop full offline capabilites.
[Update:] More information in this blog post.
BlazeDS is supposed to be much more efficient than other alternatives such as JSON or SOAP.
Unfortunately it seems that Adobe's open source BlazeDS does not allow one to use HTTP's caching infrastructure. This pretty much renders the more efficient binary AMF protocol pretty much useless for scaling to many users. Fewer requests are almost always better than smaller requests.
Live Cycle Data Services Adobe's commercial variant of BlazeDS has sophisticated offline support. This might help to get things cached, but first it's commercial and second it might be to complicated, if you don't intend to develop full offline capabilites.
[Update:] More information in this blog post.
11 comments:
Prove it.
Hi Anonymous,
There's not much to prove.
Actually BlazeDS currently does use a POST request with the HTTP header indicating that nothing should be cached.
I currently see not way around this, other than maybe patching BlazeDS.
Good Caching is crucial in Web based applications. For more information just check the Yahoo Link in my blog post.
Doing no request will always be faster than making a (small) request.
Regards,
Markus
Hi Markus,
You have to also consider that RIAs in Flex are architected very differently than typical web applications. In a typical Flex application most requests to BlazeDS's servlet handler will be to either get data (which is then usually held in memory on the client until the user closes the page) or to update data. Most of the time when these operations are performed the response will be different so caching doesn't provide much. If a developer decides that something should be cached they can easily store that data in a Local Shared Object (a big, binary cookie in Flash) - or if the app is using AIR then it can save the data in the local SQLite DB. There are also emerging open source frameworks that assist in handling this caching.
-James (Adobe)
Hmmm. With a 'stateful' Flash/Flex front-end, there will be less requests made to the server as only the data is generally requested once the interface SWF has been downloaded. For the sort of application where the data is changing frequently, not caching makes sense to me. Besides you can always implement a level of caching on the server-side to prepare the data. I fail to see how this affects scalability. If your data isn't going to change then there's no real need for BlazeDS. Just load it as gzipped XML or something you can server up with a cache HTTP header.
Use the right tools for the right things.. I think BlazeDS is most effective when you need the push type asynchronous , long request type calls, for immediate updates. Its not an all in one solution, that I believe you are trying to use it for.
I don't think you understand what BlazeDS is for. You aren't going to be download HTML from it that you would want to cache. You are going to be downloading data. I wouldn't want my transport to arbitrarily decide what data to cache and what not to. I would want to build and control that caching code myself. Not doing that can break transactional isolation in an application.
So, I think you need to understand the tools and enterprise development before declaring that you don't think something will work.
I agree with the general consensus. Caching data is done on the client, not the server, with RIAs. During the user's session there is no need for data caching because the application is stateful, those objects stay in the client's memory. I think that the key is proper architecture. Analyze why you think you need to cache the data...
Check my new post for answers to your comments:
http://kohlerm.blogspot.com/2008/08/blazeds-does-not-make-use-of-http.html
Hi TJ,
Sure, I'm talking about caching on the client.
But with HTTP the server can decide how long the data should be valid, which can be "overriden" by the client/browser by using the refresh button.
The server might know that the data will only change once a day (for example), because the data is expensive to get. Therefore it doesn't make sense that the client gets this data again and again.
Regards,
Markus
Markus you probably wouldn't be meeting with such resistance if you hadn't come out so positive that BlazeDS doesn't scale while providing no evidence.
Hi Gregory,
I don't think I need evidence in form of a benchmark. IMHO it should be pretty clear that an application that needs to get data from the Internet will always face the problem of latency and should therefore minimize the number of roundtrips. I provided a Link to a Yahoo page, with very good background information.
Minimizing the number of round trips will also take care that the server has less work to do, which will allow better scaling.
Regards,
Markus
Post a Comment