Should a service just exist for caching?

Question

Should caching, which is a cross cutting concern, be ever turned into a web-service?

The question might be a little weird, but I feel in SOA, a service should be identified based around a business solution, and we should not expose services whose only responsibility is to cache Objects. This does not seem to be a business function at all. If anything it seems like a performance improvement.

Should we ever introduce and implement a service just to cache data? Wouldn't that be a hindrance to thinking in terms of your domain model itself? I mean whenever you need an object to be cached within another service, you will have to move this class to the cacheService.

What is the general opinion about this?

Answer 1

I don't think this is a very good idea, typically the concept of caching is to make data available and keep it closer to the point of usage. Moving this out to a true software as a service or other service model, in a traditional sense limits that ability.

Cache needs to be something fast, local and readily available.

Answer 2

I think improving performance for users is a business function. I think your question really is whether you should factor out your caching to a single service, or do it internally to other services. The answer, as always is, it depends. But it certainly can work to have a dedicated caching service. For instance, Google does this for memcache.

EDIT: Again, there's more than one way to skin a cat. BUt you don't necessarily have to cache the definitive Person object. Another possibility is to use the caching service for rendered data, say a PDF account statement. For instance, Hi5 (a social networking site), uses memcache to cache fully prepared user profiles.

Answer 3

if that service acts as a Facade to the previous non-cached service then yes, it could be "its own service". Especially for read-only or read-mostly data, this makes sense. But remember that caching like threading is a treacherous domain. It is easy to "do" but extremely difficult to do "correctly", and done incorrectly it can cause a ridiculous amount of problems that are difficult to debug and difficult to fix once you find the cause. Think about it this way, Content Distribution providers like Akamai built their entire business on providing caching as a service.

Answer 4

I would agree with your thinking that web services should expose business functionality. The idea of a cache web service seems like a bad idea.

Thinking about this from a usage perspective, what does this mean really? It seems to imply that clients would first hit the cache web service to get an object. If it's not there, they'd need to get it from the real web service then "push" the object back into the cache? That's asking a lot of a client. Any caching workflow should be transparent to the client.

If however your talking about backing some related web services with a cache that's "hidden" (and transparent) from the clients, used solely for the purpose to making the entire family of web services more responsive, then yes it might be a good idea.