Web services cache 之三
Web services cache主要用在什么地方？
从产品来说，通常用在client-side, server-side, proxy。
Client side
相对而言是web services client所在platform.如一个web services client的java application，如一个部署在application server上的web services client端程序。
主要服务逻辑是，
client 通过本地地代理去发送web services请求，platform先check一下cache，如果有并且合法，就返回cache。如果没有则真正的发送数据去访问远程web services。得到response，缓存数据，并返回本地web services client的请求。当有下次请求的时候，直接返回cache。
Server side
当一个web services部署在platform上，接受其他client发送的请求。当请求的信息是已经发送过的信息，直接返回cache住的response，如果没有，则让web services执行逻辑，返回数据。缓存，以供下次使用。
Proxy
本质上和client/server side 的cache是一个逻辑。就是缓存response信息，当有重复请求的时候，返回cache，不真正执行业务逻辑，或者远程访问。
结合上篇文章，就可以比较完整的描述web services cache了。
可以在各种不同的位置设置cache，对于每个cache可以进行相应的设置，如TTL，或者Invalidate，或者Polling的方式来应对数据的失效。
从产品来说，通常用在client-side, server-side, proxy。
Client side
相对而言是web services client所在platform.如一个web services client的java application，如一个部署在application server上的web services client端程序。
主要服务逻辑是，
client 通过本地地代理去发送web services请求，platform先check一下cache，如果有并且合法，就返回cache。如果没有则真正的发送数据去访问远程web services。得到response，缓存数据，并返回本地web services client的请求。当有下次请求的时候，直接返回cache。
Server side
当一个web services部署在platform上，接受其他client发送的请求。当请求的信息是已经发送过的信息，直接返回cache住的response，如果没有，则让web services执行逻辑，返回数据。缓存，以供下次使用。
Proxy
本质上和client/server side 的cache是一个逻辑。就是缓存response信息，当有重复请求的时候，返回cache，不真正执行业务逻辑，或者远程访问。
结合上篇文章，就可以比较完整的描述web services cache了。
可以在各种不同的位置设置cache，对于每个cache可以进行相应的设置，如TTL，或者Invalidate，或者Polling的方式来应对数据的失效。