Discussions

There are two classes in the petstore provided by Sun, implementing the Service Locator design pattern. The com.sun.j2ee.blueprints.servicelocator.web.ServiceLocator and com.sun.j2ee.blueprints.servicelocator.ejb.ServiceLocator. In the web service locator, the JavaDoc says that this implementation is intented only for the web tier, not EJB tier.

I compared the ejb.ServiceLocator and web.ServiceLocator. The only difference is that the web.ServiceLocator uses Synchronized HashMap as a cache, while ejb.ServiceLocator does not any caching mechanism. It does the JNDI lookup for every request. Why is that?

I guess one possible reason might be the EJB spec prohibits the use of thread and Synchronized HashMap voilates this rule. But I am not sure. Even so, as far as I know, the servlet spec also does not recommend developers manipulate threads by themselves. Why synchronized map can be use in the web tier service locator?

In the end, how am I going to implement the caching machanism in the service locator for ejb tier? Doing the JNDI lookup every time seems quite redundand and inefficient to me.

The concept of Service Locator pertains to providing a service which can be cached for performance.The basic objective remains the same on the both web and ejb tier however implementation is different.
On ejb layer, this pattern maintains a simple hashmap cache of EJBHomes for a production implementations.This works as a factory for cached ejb homes,thus avoiding redudant lookup codes and actual lookups for every home lookup calls from different clients.
Also exceptions such as NamingException etc can be wrapped with a factory exception to futher simplify the client.
On Web tier common cleint services like web controller classes need to be referenced using expensinve JNDI calls.
Using a cached object in the session will avoid lookups for the same client using the service again.
I hope this answers your question.
-Jyot
Dataconcepts,LLC

The concept of Service Locator pertains to providing a service which can be cached for performance.The basic objective remains the same on the both web and ejb tier however implementation is different.
On ejb layer, this pattern maintains a simple hashmap cache of EJBHomes for a production implementations.This works as a factory for cached ejb homes,thus avoiding redudant lookup codes and actual lookups for every home lookup calls from different clients.
Also exceptions such as NamingException etc can be wrapped with a factory exception to futher simplify the client.
On Web tier common cleint services like web controller classes need to be referenced using expensinve JNDI calls.
Using a cached object in the session will avoid lookups for the same client using the service again.
I hope this answers your question.
-Jyot
Dataconcepts,LLC

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.