Currently, java.util.Arrays.asList() creates a list that is an extension of AbstractList. If at some point it does not, you could simply create the list yourself (e.g., java.util.ArrayList) and copy the element references from the array.

Applying Advanced Cache Techniques
So far, a very simple cache replacement mechanism has been assumed, as in, cache-forever. But, to realize the full potential of proxy cache we want the data in the cache to be replaced, or at least purged, after some period of time.

Replacement is generally triggered via some event that is either bound temporarily or spatially. Meaning, either a predetermined amount of time has passed or a preallocated size boundary has been exceeded. Some of the most common techniques applied are: time-to-live (TTL), least-recently used (LRU), and least-frequently-used (LFU). It is out of the scope of this article to describe what each of these algorithms means, although, you can probably guess from their names.

However, if we wanted to apply one of these algorithms, we could simply implement another type of cache. For instance, if we wanted to utilize a TTL cache for all of our services that would remove expired entries after 10 minutes (600 seconds), the shell of a TimeToLiveCache would look similar to that shown in Listing 5.

Remember that the proxy cache technique works especially well when the output of a given operation can be guaranteed to be the same for every call to a service or set of services given some predetermined temporal or spatial boundary. Therefore, whatever solution you use, make sure that it does not negate the positive aspects of actually using a cache.

Unit Testing a Proxy Cache
Unit testing is an essential practice in the development of all software, no matter the size or complexity.

All code provided here was developed using the Test-Driven Development methodology (TDD), with the exception of the TimeToLiveCache since there is no real implementation provided. All test cases and their supporting test code have been provided in Listing 6. (Listing 6 and additional source code can be downloaded from http://jdj.sys-con.com.)

In the test code you'll find only five test cases asserting that:

1. EchoService returns the same object that was provided to it.
2. ServiceFactory returns only one instance of a proxy per service.
3. CacheProxy actually caches.
4. CacheProxy can handle a null reference as the set of arguments.
5. CacheProxy differentiates its caches by method name.

For a few of the tests a mock object is used in place of a "real" service that would normally be passed to CacheProxy. Using this mock object allows us to isolate CacheProxy in our tests because, hopefully, the mock object contains very little behavior. Most mock objects should contain only enough logic to record events for investigation later.

There could be one or two tests missing from the provided test cases and there is certainly some duplication in the test code, but, for the most part, the tests provided are enough to cover most basic implementations of proxy cache. In addition, if you are not already practicing the TDD methodology, the examples provided can provide you with more proof of why it is so invaluable. If for no other reason, TDD was invaluable in developing the proxy cache because we didn't have to guess at how we should actually implement the framework.

History
At its core, the proxy cache concept is not new. The concept is borrowed from the memoization technique (meaning "to put in memory"), recognized by Donald Mitchie in his paper "Memo functions and machine learning" from a Nature magazine published in 1968.

The proxy cache is an abstraction of the memoization technique and differs from memoization by assuming that the data is likely to change, whereas memoization relies on the data not changing.

Conclusion
The design and implementation of the proxy cache approach provided in this article is simplistic. In the solution my colleagues and I eventually put together, we introduced a synchronization scenario so that all caches running in our application servers could purge themselves when necessary. There is no theoretical limit to what can be introduced into this layer.

In most instances, however, an implementation of the proxy cache that utilizes a basic replacement algorithm should be enough to satisfy any application. Remember that the goal of the proxy cache is to keep your application simple, modular, and free from responsibility creep.

References

• Portland Pattern Repository; ProxyPattern: http://c2.com/cgi/wiki?ProxyPattern; last updated 20050124
• Martin, B., et al; Singleton vs. Just Create One: http://butunclebob.com/ArticleS.UncleBob.SingletonVsJustCreateOne
• Wikipedia Users; Memoization: http://en.wikipedia.org/wiki/Memoization; last updated 20050708-22:55
• Bob Martin, et al; Single Responsibility Principle, www.objectmentor.com/resources/articles/srp

Acknowledgments
None of the information provided here would have been possible without the following people: Virgil Bistriceanu, Boris Vaysburg, Aleksey Beregov, Murali Kashaboina, and Brett Neumeier (even though he doesn't know it).