There were several comments to my post about my doubts about BlazeDS scaling well.

James Ward
said...

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)

Thanks James for responding. Yes, I understand that Flex comes kind of from a different angle. A lot of the early Flex applications might have been used to show "real time" data, such as Stock tickers.
And yes with Flex you probably usually only get data from the server, but the same is true for modern web applications. GWT uses a similiar approach for remoting. PURE is a javascript framework that also only sends data. Both GWT and PURE will work well within the Web infrastructure( Web caching proxies for example), because the server can set how long the data should be valid. Actually this meta data about lifetime is send together with the response.
I don't see how I can do the same with BlazeDS.

Yes of course I can build a cache on the Flex side. But that is something that I would have to do in addition and also the life time of the objects in this cache could probably not be controlled by the server.

I therefore still believe that there's room for improvement for BlazeDS.

In a similiar response Stephen Beattie
said...

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.

Basically he says that BlazeDS is for "real time" data only. IMHO that is a major limitation, because I can't see a technical reason why BlazeDS could not support the HTTP caching infrastructure.

Anonymous
said...

[snip] 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.

[snip]

I want to be able to control from my server how long the data that was just send is valid, because the server for example might now that the data will only be updated once a day.