A service that hides Local/Remote EJB

[SU Lingam]

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?

Thanks

[Jesus Angeles]

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.

[Valentin Tanase]

Hi SU,

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:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

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.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html

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.

[Ajith Kallambella]

Su,

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.

[SU Lingam]

Thanks for sharing your thoughts...

[Karthik Guru]

I think you should look at this..
Spring & EJB..

[NikhilN Kumar]

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....

[NikhilN Kumar]

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)...

http://www-128.ibm.com/developerworks/websphere/techjournal/0410_woolf/0410_woolf.html