aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes dynamic proxy of remote and local ejbs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "dynamic proxy of remote and local ejbs" Watch "dynamic proxy of remote and local ejbs" New topic
Author

dynamic proxy of remote and local ejbs

Mark Lybarger
Ranch Hand

Joined: Dec 19, 2003
Posts: 72
i have a bunch of stateless session ejbs that are accessed through a remote interface by a web application. i would like to provide the ability to have improved performance by allowing the sls ejbs to provide a local interface that the web apps can use. then i could deploy some of the sls ejbs in an ear with the web app, and possibly deploy other ejbs someplace else.
i'd like my webapp to be able to dynamically access the ejbs. if there's a local ejb available, use it, otherwise try to get a remote ejb. is there a pattern (example of implementation would be nice) that exists to be able to do something like this?
this functionality is briefly mentioned in the following article:
http://www.developer.com/java/ejb/print.php/3069981
here they give a way for the client to get a remote or to get a local by two distinct method calls. i'd like this to be transparent to the client if possible. i'd like to have a CustomerProxy perhaps that can be either a Customer remote or a Customer local... i don't want my client application to have to worry about where the ejb is deployed at all. just that it can get to it as effeciently as possible.
lots if "i'd like" and "i want" in there, eh?
any insights would be most appreciated.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Use the Business Delegate pattern (from Core J2EE Patterns) and have all of your clients use the Business Delegate instead of either the local or remote interface. Then your business delegate can be configured to use the one that's appropriate at configuration time or run time.
BTW, It's probably worth your while to build a little code generator for these Business Delegates.
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Mark Lybarger
Ranch Hand

Joined: Dec 19, 2003
Posts: 72
Thanks for the response. It seems that my project here just got a big "slow down cowboy". I'm unable to deploy my webapp as part of an EAR which is needed to provide local access to the ejbs. It seems that turbine doesn't like to be deployed as a war/ear on weblogic platform.
you mention to "build a little code generator...". is there a tool that already easily does this type of thing? seems that such a popular design pattern would have a commonly reusable code generation engine out there...
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
I'll admit that Business Delegate is a popular design pattern, and there probably are tools that generate code for it (in fact I know that WSAD includes such a beast). However, the variation of allowing for configurability of local/remote interfaces is enough of a difference that I don't know of any.
Kyle
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by Mark Lybarger:
you mention to "build a little code generator...". is there a tool that already easily does this type of thing? seems that such a popular design pattern would have a commonly reusable code generation engine out there...

XDoclet is one. If you're already using it you could start with one of the built-in templates and modify it to suit your needs. I have not yet done this part, but that's my next step.
For my delegates, I created a base delegate class, and a remote and local delegate classes. For each session bean, I create a delegate interface (so far they've all been the exactly like the local interface) and local and remote delegate implementations. The local one just delegates to the bean while the remote delegates but catches RemoteException and throws our own unchecked ServiceException instead (this is necessary to be able to use the same interface for both).
As for getting a delegate without the client knowing which type it's using, the delegates are Java beans, and they are loaded dynamically at runtime via a service locator that knows how to configure them (JNDI initial context factory class name and URL for remote delegates, JNDI root for both).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: dynamic proxy of remote and local ejbs