Remember your Web Service Caching
One of the most-overlooked concepts in multi-tiered architectures like the ALUI portal is caching.
I am constantly reminding clients about the nature of the HTTP transactions made for a portal page: “browser to portal, portal to back-end server”. I’ve touched on the first transaction a bit (more to come on this!), but today I wanted to remind you about the “portal to back-end server” part.
Remember that when you make a request for a portal page with portlets on it, the portal will make multiple HTTP requests to the back-end servers for the HTML to render in that page. The trick is understanding that the request that the portal makes is very much like a web browser request, and handles caching in the same way. This means that your custom code should use the appropriate HTTP headers to tell the portal how to cache the HTML so that it doesn’t need to make the request again for a certain amount of time, for a different user, or for a different page. The ALUI development documents talk about this in great detail; check them out!
If you don’t have control of the code on that back-end server, though, another option is to override (or augment) those settings by editing the web service and specifying minimum and maximum cache times, as seen here:
By specifying a minimum cache time, you’re basically telling the portal that once it gets the HTML the first time, it can wait for that long before actually making the HTTP request again to the back-end server, which can greatly increase the response time of the portal to serve up content to the end users.
For another fantastic article written on this topic, check out the “More than 5 seconds on Caching” article written by Ross Brodbeck on BEA’s Dev2Dev site.
