I'm looking for developing a prototype that would do the following.This service by default would go and fetch the local EJB if it exists by default else it woould go for a Remote access of the bean.The client is unaware whether he calling a Local or a Remote EJB.This prototype is like a decorator.
Is this do-able/worth a shot.
What do you think?
Joined: Feb 26, 2005
At some level of the system you are architecting, that layer wouldnt know if the ejb that is eventually servicing it is being accessed locally or remotely.
However, usually, in the industry, a layer close to the ejb, knows exactly if the ejb has local and/or remote interfaces, for overall efficiency reasons.
Joined: Feb 17, 2005
The client is unaware whether he calling a Local or a Remote EJB.This prototype is like a decorator.
Is this do-able/worth a shot.
First you might take a look at the Service Locator design pattern:
There are slightly differences between the way the ServiceLocator returns local vs remote home references, as well as the way the initial context is created. In your design you can use either one ServiceLocator that can cache both local and remote interfaces, or you can use two distinct service locator instances. However the choice, in order to fully abstract the clients from your ejbs you need to provide one more layer of indirection: the business delegates.
This new layer will locate the service, invoke business methods, catch specific exceptions, etc. The business delegates will fully decouple your clients from the business services. Regards.
I think, therefore I exist -- Rene Descartes
Joined: Mar 17, 2000
I hope that you are aware of the effect of local/remote ejb invocations on the arguments passed to method calls. If your locator is assumed to return either a local or a remote ejb reference, you should also make sure that the internal states of the objects passed are consistent and predictable across the two scenarios.
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
The point still is, shouldn't the Service Locator encapsulate the invoker from the nature of the service? And how is the invoker to know which to use? Shouldn't the lookup be encapsulated, and a setting be made available, so that in a sticky situation with the service and the service requestor being local you can call the service while being unaware that a local lookup is being used, and when the application becomes distributed, equally unimpacted by that change as the Service Locator does what it says, i.e. finds the service.
From a responsibilities perspective, who should be aware if the interface is local or remote - the Business delegate or the Service Locator?
Looking for input as I am implementing this right now....
Joined: Jun 30, 2003
Also, to add to my earlier request, I noticed that IBM and I am sure other companies are recommending that we dont use caching in Service locators, after J2EE 1.3 (or is this just a WebSphere feature)...