Content Caching for SOA
Layer 7 Gateways let you use policy logic to cache data that is unique to a user or a group of users. If the data is related to a single user, you can define a cache key that is unique for a single authenticated user. If the data is common to a group of users, you can use policy logic to ensure unique data cache entries for that group. This helps to reduce subsequent calls to external sources, speeding up performance.
Layer 7’s “Save to cache” assertion lets you set the cache store; the key to store and lookup your data in the cache, and the length of time your data should be cached for. Note that Gateway cache keys are automatically hashed.
This tutorial will focus on content caching for a group of users that belong to a group named "basic". The users of group "basic" have access to a Web service proxied by a Layer 7 Gateway, which receives requests and validates each user’s HTTP basic credentials. If the user is found to belong to group "basic", they will be granted access to the Web service. The data returned by the Web service is then cached for subsequent users of group "basic". If the data does not exist in the cache, data is retrieved from the back end; otherwise the cached data is returned to the user.
Implementing User-defined Caching
The following is a sample policy constructed to cache the data for the group “basic”:
1. Log in to the Layer 7 Policy Manager
2. Select tasks->publish SOAP Web Service from the menu
3. Enter the location of the service WSDL file and click next
4. Give the service a custom resolution path
5. Click Finish
6. Add the Require HTTP credentials assertion to the policy
7. Optionally add the Audit messages in policy and Customize soap fault Response assertions (to help with debugging and auditing while making your policy)
8. Add the Authenticate against internal identity provider assertion to the policy.
9. Right click on the Authenticate Against internal identity provider assertion and click Select Target Message
10. Select the Request to be the target message.
11. Add an At least one assertion must evaluate to true assertion to the policy
12. Add an All assertions must evaluate to true assertion to the policy
13. Under that all assertions must evaluate to true assertion, add an authenticate user or group assertion to the policy to validate the user belongs to the group basic.
14. Add a context variable named Group to the policy. Save the group name basic in the context variable. In this example, the group name basic has access to the service, and that group name is saved in the context variable. If the user does not belong to the group basic, the policy will be falsified and they will not have access to the data.
15. Add another context variable called URI and store the request URI in it.
16. Add an At least one assertion must evaluate to true assertion to the policy
17. Under that assertion, add a lookup in cache policy assertion.
18. Open the properties for the lookup in cache policy assertion and set the key to: ${group}/${URI}. This will cache data for the group basic for this particular URL.
19. Add a Template Response assertion to the policy. If the cache lookup is successful, the response found in the cache should be returned to the user using the template response.
20. In the template response properties dialog, enter ${Response.mainpart} as the value to return to the user. This is the cached data from the cache lookup assertion.
21. Add another All assertions must evaluate to true assertion to the policy.
22. Under this assertion, we will assume that the lookup in the cache has failed, so the call to retrieve the data for the web service will be performed. The HTTP(s) routing assertion should be placed here to make the web service call to the back end.
23. After the HTTP(s) routing assertion, add a store to cache assertion to store the response in the cache with ${Group}/${URI} as the key to store the data.
24. The completed policy looks like this:
Now, when a user of group “basic” makes a call to the Web service the policy will check the cache for the data. If the data is in the cache, that cached data is returned to the user. If the cache does not contain the data, the call is made to the back end Web service to retrieve the data, and then it is stored in the cache for the next user that belongs to the group "basic". The cached data will be returned to any members of the group "basic" until the cache times out.
This same policy can be modified to cache data for a single user instead of a group by simply replacing the ${Group} portion of the cache key with the user's ID instead.