asp.net webservice output caching options and issues

We use WS as a fa·çade to underlying enterprise service components which handles all biz logic. And it was found some of the calls were to fetch some data that can be cached. So i thought of list out caching options i have,

1. Cache at client
2. HTTP 1.1 cache-capable device in the call path (Proxy server?)
3. Cache at WS layer
4. Use caching application block to cache data in ES

I am skiping the usual issues like caching in distributed environment, cache volatility, cache expiration policy, etc, just to concentrate on cache storage options.

Client cache is technique that i use in almost all apps i design. Hands down i should say a pretty simple approach, client had to be designed cache-aware and it will own all caching and its issues. Depending on cache data size and complexities; rich/smart or web app client will reap benefits accordingly.

HTTP 1.1 cache-capable devices, i haven't used this in any of my projects and i'll have to drill further to know the pro/cons on this one. But i heard there are some limitations to use HTTP cache for asp.net webservices

I'll defer the WS layer cache for a paragraph

Only way i see of caching in COM+ is using caching block, i can store cache with help of
Memory mapped file stream (it's an unmanaged code, do i like to use an unmanaged code? but if u think a while, windows is not a managed code that doesn't mean it is bad. If in next update of caching application block, p&p group implements a managed version of mmf storage, the client will no way know about this change and everybody is happy. Win FX (all new Win32 API) is all managed, ASP.NET 2.0 is 90% managed code, is looks like the trend will continue, its just a matter of perception)
SQL database (do i want to take the overhead of network? anyone has to weigh the benefits of caching over the network overhead)
Singleton object (Remoting? The popular and untruthful myth that remoting is hard, bad and its going away. I am no more going to reiterate, there will be a clear path of migration to Indigo and p&p or GDN will take care of this)

Ok now the fun of caching in WS, options ...
1. CacheDuration attribute, ok i set this for 60 secs and open the WS test page in IE and invoke the webmethod and i invoke again to see it output is cached, NO it was not cached. I google a bit and find it’s not me alone who is stumped by this.
**Webmethod caching doesn't work in WS test page in IE and works if used with a proxy class**, i had a strange feeling whether client proxy is somehow returning the data and not making the WS call, actually it not doing any of those WS call is actually made and its WS is the one which returns the cached output.

2. Applciation/Cache object, can use a Application or System.Web.Cache class and i have a feeling that CacheDuration attribute will in turn use one of this internally.

3. [Credits: Senthil] Having a private static variable in the WS class, this one bowls me out, somehow i was blind folded by words *HTTP is stateless* and I illiterately assumed that is applicable to WS. But i have to a doubt on how this will work in IIS process recycling, either in IIS5 (aspnet_wp) or IIS6 (w3wp.exe), will this static member data go away or retained during process recycling?