|
What Is The Goal?
When developing an enterprise application, you may have numerous modules in one .ear file—different EJB-JARs, dozen of WARs, etc. At some point, you realize that this data you're moving back and forward between all these components needs to be cached. Or, maybe you want to have some user-related information
shared between all your WARs, because you are tired passing it different ways? And you can't use the HTTP Session, because it's not shared between WARs. This is where caching comes in.
Thus, the general goal is to take advantage of the caching advantages provided by JBoss Cache while building your EAR components. The example product in this article is deployed as an MBean service and all its modules are able to get and/or put data into an application-wide cache,
TreeCache—a tree-like structure, with nodes,
roots, and children. The app has "local propagation" which means that the "tree" data resides only inside the VM in which it was created. You can put different key-values in each node. For example:
...
cache.put ("/enterprise/webapplication1/userauthorised/john", "fullname", "John Doe");
...
cache.put ("/enterprise/webapplication77", "dataname", "Some data of Web Application
#77");
...
Of course, you can also put objects, as well as strings into cache.
Speaking of objects, remember that in this example, you do not need make your elements
serializable. The explanation for this is easy—according to official JBoss Cache documentation, local caches don't join a cluster and don't replicate changes to other nodes in a cluster. Nevertheless, the best recommendations for you is to MAKE them seriliazible, so you will be able to change cache modes anytime without any other code changes.
How can you use this in real-life applications? Here's a simple example: suppose a user logs into your Web application. You need to "share" this information with all the other Web applications in the same EAR, so the user will not have to log in again on every of them. Obviously, you could use some kind of single-sign on (SSO) implementation, but sometimes the issue isn't about authorization, it's about sharing some information about a user—their preferences, specific settings, etc.—which could be huge. Using caching, each module in your application knows this information without having to additionally retrieving it from the database or wherever it is located. Retrievement from the cache is easy:
...
// will contain 'John Doe'
String s1 = (String) cache.get ("/enterprise/webapplication1/userauthorised/john",
"fullname");
...
// will contain 'Some data of Web Application #77'
String s2 = (String) cache.get ("/enterprise/webapplication77", "dataname");
...
This sample application works the simplest of all possible ways. You've got two separated Web applications (WAR) in one EAR. They're almost the same—both of them have one servlet, which when called connects to Cache MBean and retrieves and displays the information from the /demo node and the greeting key. Each servlet also places its own sentence as a value of greeting key. Switching between the two, you see that each of them can "see" the other's sentence from the greeting key.
As mentioned previously, JBoss Cache is deployed here as a JMX MBean. MBean itself is a Java object which implements resources and their instrumentation interfaces as defined in the JMX specification. The application's modules (WARs, EJB-JARs, etc.) access the JMX MBean easily, like with any other MBean:
...
try {
MBeanServer server = MBeanServerLocator.locate();
cache = (TreeCacheMBean) MBeanProxyExt.create(TreeCacheMBean.class,
"jboss.cache:service=MyCache", server);
} catch (MalformedObjectNameException e) {
// exception handing
}
...
You can also access it by simply defining the JNDI name for this service.
While this example demonstrates some of JBoss Cache's power, remember that when you're caching and relying on this cached data, you'll need to be sure that you're getting exactly what you're supposed to. Using caching can be tricky—you need to think about all the possible situations, as well as the potential problems, of mixing different cached sessions. Caching is not a panacea, it's just additional step of application's optimization and improvement. Deciding to share information inside your application can potentially entail security vulnerabilities.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
