On Wed, Oct 29, 2008 at 7:31 PM, outinsun <[EMAIL PROTECTED]> wrote: > > I am building an application using SOA. I have one service that needs > to embed infrequently updated information that is managed by another > service. I want to avoid having to make RPC calls every time I access > the data in question, but also want to make sure updates to that data > are reflected at the other end. I can't figure out whether memcached > is a logical basis for this kind of application, or is completely > irrelevant. Any thoughts? If irrelevant, any pointers to something > more appropriate?
I do exactly this, I use aspects to store the results of web-service queries in memcached (as compressed XML documents), I can then access these results with a direct memcached retrieval rather than having to go over SOAP and execute all the processing logic behind the service call each time, the speed improvements from doing this were very good for my case. You do have to be aware of a couple of issues i) memcached is ephemoral, that is if you can't retrieve the value from the cache you should be able to go elsewhere to get the data. ii) If your responses are greater > 1 Meg then you can't [without applying a basic chunking algorithm] store the results in the memcached cache (see point i) Other than that it works great for me, I've got Java + .Net web service clients storing the results of historical web service requests,keyed against the request parameters (roughly). - Cj
