File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Distributed Java and the fly likes Jini and Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Jini and "Placeholder/Proxy" Classes" Watch "Jini and "Placeholder/Proxy" Classes" New topic

Jini and "Placeholder/Proxy" Classes

Tim Patton

Joined: Oct 17, 2006
Posts: 7
I just got started with Jini and I'm converting an app over that used a bit of RMI. The switch is pretty straitforward however one thing is bugging me. I've found that for every Jini "service" I write I also have to write a set of placeholder classes on the client.

For instance say I wrote an interface for adding numbers, Adder. When the client app starts up with RMI I'd find the registry then get the Adder and then continue start. With Jini, it could take a few seconds to find everything and get an Adder object, plus the adder could appear or disappear on the network. No problem, thats what I use Jini for. However, I can't just let my client app use the Adder interface directly, since the object it points to could change or even end up null. So I wrap the Adder I get from Jini with my own local proxy that receives updates if the adder changes or goes away and I can design it to return null or to wait for a new Adder in the latter case. However, if I make a new service, Multiplier, I have to create a new local proxy and other related classes (Usually a ServiceDiscoveryListener). Is there a shortcut around this or does everyone write wrappers like this for Jini code? I was able to use 1.5 Generics to generalize most of this, but I still have to write 1 or 2 client side classes per interface.
I agree. Here's the link:
subject: Jini and "Placeholder/Proxy" Classes
It's not a secret anymore!