This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The chapter on patterns in HFSJ says the service locator can optionally cache stubs. Should the service locator cache stubs or the business delegate? In my opinion, it should be the business delagate. We could have say, 10 business delegates calling a single service locator. The business delegate would pass the JNDI look-up name to the service locator, which would do the look-up and return the stub to the business delegate. The business delegate would then cast the stub to whatever specific type it needs and call the business method on the casted stub. The service locator does not know even know the exact type of the stub it is returning, it would always return the type that the look-up call returns and it is the job of the business delegate to cast it to the stub type corresponding to the remote service object it is invoking. So, I feel each business delegate, after getting the stub from the service locator (and casting to the required type) should cache the stub it uses rather than the service locator caching all the stubs used by all the business delegates. Please throw in your thoughts...
I think that the Service Locator should do the caching for several reasons. 1) Business Delegates can then be created and destroyed at will and there will be no need to do the lookup again if the object is cached i the Service Locator, remembering that the lookup is often very expensive time wise.
2) Caching is really a function of the Service Locator. The business Delegate should concentrate on the Business logic not on the lookup if it is used in conjunction with the Service Locator.
Regardless of wether the Business Delegate or the Service Locator does the lookup, you can still get the Service Locator to return a stub and have the Business Delegate cast the stub returned to whatever it expects.
This is my thoughts feel free to disagree, or correct me if you think I am wrong.
Joined: Aug 18, 2005
Mat, I think you have mis-understood what I meant. I didn't mean that the business delegate should do the look-up. The service locator will be doing the look-up and returning the stub to the delegate. The delegate should then cache the stub it has obtained, so that when the next request comes for the same stub, it need not even go to the service locator. If the service locator should do the caching, it should have a lot of instance variables because there might be a lot of delegates calling it and IT NEEDS TO KEEP TRACK OF WHICH STUB IS ASKED FOR BY WHICH DELEGATE. When the next request comes, the service locator would have the responsibility of checking whether the stub asked for by the delegate is cached and then return it to the delegate. Instead, the business delegate can cache whatever stubs it needs and need not call the service locator if the stub it needs is already cached. I think this is a better design.It would save one call (to the service locator) and also there is no need to mess up with the service locator by caching all the stubs pertaining to all the delegates. Each delegate would cache the limited number of stubs it alone needs
If the service locator should do the caching, it should have a lot of instance variables
I don't think that is the way a caching Service Locator should be implemented. It will typically have a static Map which stores the stubs with their JNDI lookup names as keys. So before performing a JNDI lookup, it will first do a lookup in the map. If there is a match it will return that match without performing a costly JNDI lookup.
IT NEEDS TO KEEP TRACK OF WHICH STUB IS ASKED FOR BY WHICH DELEGATE
A Delegate at the time of invoking the Service Locator, will pass a JNDI lookup name and the Service Locator will look up a stub for this JNDI name. So the Service Locator need not be worried about the Delegate or stub. All it has to care about are the JNDI names.
Joined: Aug 18, 2005
thanks for the reply. I think that is a neat solution. I was always thinking about instance variables and having a map just didn't occur to me
Joined: Jul 20, 2005
Maybe I didn't make myself clear sorry. I never meant to suggest that the Business Delegate does the lookup. The lookup should be done by the Servive Locator.
I agree that a Map is usually the best way to cache the object stubs when they are found.