Forums Register Login

A service that hides Local/Remote EJB

+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
Thanks for sharing your thoughts...
+Pie Number of slices to send: Send
I think you should look at this..
Spring & EJB..
+Pie Number of slices to send: Send
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....
+Pie Number of slices to send: Send
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
look! it's a bird! it's a plane! It's .... a teeny tiny ad
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 847 times.
Similar Threads
Stateless bean also exposed as web service?
SLB-local, home, endpoint interface
Local session bean call from a client in a different jar
WSIF Question
Locating Local vs Remote Home interfaces
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 04:48:28.