this message intends to promote the idea of method-based cachingas a means to elegantly and effectively improve the efficiency ofEJB-systems. In order to explain what this is about I haveimplemented a related API that uses javassist. My suggestedapproach helps to easily and transparently separate the aspect ofclient side caching from other system aspects.

PART 1: WHAT IS THIS THING GOOD FOR?------------------------------------

This API demonstrates a cache that dynamically, transparently andconsistently caches results of method invocations. It intends topromote the idea of method-based caching as an excellent optionfor improving the efficiency of modern information systems.

Method-based caching can be useful in the context of layeredarchitectures where a layer is abstracted by a set of Javainterfaces. A good example is a servlet-based web server whoseservlets invoke EJB methods (all EJBs are abstracted by Javainterfaces). Method results are cached at the client side (whichhappens to be a web server for the example) and so at a cache hit,a costly and potentially remote EJB method call can be avoided. Inthis context the approach is ALWAYS A BETTER OPTION THAN DYNAMICWEB CACHING. The reasons for this exciting statement are explainedbelow. An important example of a dynamic web caching approach isJESI (see http://www.esi.org/jesit_tag_lib_1-0.html).

Note that method-based caching can be applied in such a way thatit maintains 100% cache consistency (also called strong cacheconsistency). In order to do so, an application developer has toannotate the respective methods of a service interface. Theannotations form a so called "cache model". Apart from theseannotations, a respective cache remains 100% transparent(invisible) to the client AND to the server code and so it can bedeployed in very late project cycles without harming existing codeand system functionality. In terms of aspect-oriented programming,method-based caching may be considered a way to separate a cachingaspect from other system aspects.

For detailed information on the general idea of method-basedcaching, please read the paper available athttp://www.ipd.uka.de/~pfeifer/publications/doa03.pdfBy means of an experiment and a benchmark application, the papershows that method-based caching can considerably increase theoverall system efficiency of a real world EJB-based webapplication.

As apposed to the implementation presented in the referencedpaper, DMCache (this API) is fully dynamic. In particular, allcache classes that implement a layer's Java interfaces (e.g. a setof EJB interfaces) are generated at system RUNTIME using a dynamicproxy approach. Further, cache models are not specified viaXML-files but by means of method annotations. (Annotations are anew feature of JDK 1.5.)

The API is in an early state but functional and tested. The sourcecode in the package "ord.ipd.dmcache.model.test" gives an idea onhow to use it and what it can do.

In practice, this kind of caching is meant to entirely REPLACEDYNAMIC WEB CACHING FOR ARCHITECTURES WITH AN EJB-LIKE APPLICATIONLAYER. A good example is a servlet-based web server with servletsinvoking EJBs. Since EJB calls are expensive it may be useful tocache the respective calls' results for read-only calls. In such acase, EJB calls are usually expensive and form the system'sbottleneck - however servlet computations are cheap (apart fromthe included EJB calls).

The following considerations reveal that under thesecircumstances, method-based caching is A LOT SMARTER than dynamicweb caching, because the former1) leads to better hit rates than dynamic web caching (or at least the same hit rates),2) makes page fragmentation approaches such as ESI obsolete,3) is very likely to consume less memory dynamic web caching,4) potentially provides strong cache consistency,5) does not pollute the server or client code with nasty cache-related code-snippets or tags.

The following paragraphs explain why this is true:

1) A servlet-based web page computation my be considered as afunction page(m_1(a_1_1),...,m_k(a_1_k)) with m_1(a_1_1) tom_k(a_1_k) being respective EJB calls and a_1_1 to a_1_k beingrespective method arguments. (The argument values a_1_1,...,a_1_kare derived from the parameters of a corresponding HTTP pagerequest.) If m_1(a_1_1) to m_k(a_1_k) are read-only method calls,then page(...) quite likely may be cached (as a dynamic web page).

One gets a hit for page(...) only if the respective page requestparameters correspond to the arguments for the underlyingEJB-method calls, namely a_1_1,...,a_1_k. Obviously this case alsoleads to corresponding hits in the case of method-based caching.Thus, the hit rates of method-based caching are at least as goodas for dynamic web caching.

Now consider a second page computation page_2(m_1(a_2_1),...,m_k(a_2_k)) which is based on other request parameters thanpage(...). If a_2_i = a_1_i holds for some i in {1,...,k} then onewill get a hit for the method-based cache but not for a respectivedynamic web cache (since the request parameters between page(...)and page_2(...) differ). Thus method-based caching can cause evenbetter hit rates than dynamic web caching!

2) Method-based caching makes page fragmentation approaches. Thisfollows straight from 1): At best, page fragmentation can onlyproduce fragments so tiny that at least zero to one EJB methodcalls m_i(a) will be contained in a fragment computation. If thefragment computation contains zero EJB-calls, then its computationis very efficient and so caching the fragment is useless (rememberthat servlet executions are usually efficient apart from theirembedded EJB-calls). If the fragment computation contains one EJBmethod call then the method-based cache has the same potential ofproducing a cache hit in respect to m_i(a).

3) Web page code is usually highly redundant because it contains alot of rendering information. Therefore cached web pages areusually stored on disk and must be read from disk at a cache hit.In contrast, method results are usually a lot less redundant andcome in a compact binary format. Thus cached method results can bekept in memory - no disk access is necessary at a cache hit.

5) Using dynamic web caching, JESI tags or other code for cacheconsistency usually must be embedded in servlets. It make theservlet code error prone and less readable. In contrast,annotations for method-based caching are compact and wellseparated from other system code. They are located in front ofmethod declarations as JDK 1.5 annotations.

PART 2: BUILDING----------------

The API requires the JDK 1.5 and ANT. (It works with ANT 1.6 orhigher - lower version are not tested.) In order to build it,please set the environment variables "JAVA_HOME" and "ANT_HOME"appropriately and go to the directory "dmcache/bin".

Run "build.bat" on Windows or "build.sh" on Unix and find theresults in "dmcache/build/jar":dmcache.jar - the API's library.dmcachetest.jar - the test code."build.bat" also runs the JUnit test whose result can be foundin "dmcache/log/DMCacheTestResult.txt".

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.