Generating an RMI Stub on a Client
Although I am binding my servers to an RMI registry so clients can then look up a service from a source which is known to everyone, I need to know a bit more about the RMI mechanism because I do not want to use the registry in the future where my clients should be able to create a UnicastRemoteObject (or a subclass thereof) for a specific server that they want to contact.
I feel this question might actually have an obvious answer, but I would indeed be thankful if someone could guide me though the steps. What does a client need to know to create a stub and use a remote service?
So, I have a server on one device, and I have a client that wants to use this service. The server object has been exported, but has not been registered on a directory at a location known by both the server and client. Can the client create a stub itself rather than having to use the one that was exported by the server? What information does it need of the server to create the stub? The server's IP? Port? What else? How do I get all this information together to create the stub?
I don't want to use the registry because using a registry is too centralised. I actually have a cluster of devices, acting both as clients and servers where these devices provide and use the same service. Each device represents its own autonomous neuron, and together they function like a nervous system.
The cluster grows when a device not a member of this cluster is engaged by a member of the cluster. Once the non-member device becomes a member, the member with which it engaged lets other members know of the now new member's stub so that other members may try to engage the new member. Using a registry doesn't bring anything of value to this cluster.
Without the registry, the first member to engage the non-member is done so "manually". I imagine this manual process would be helped when the non-member device is started and the non-member device lets the operator know (via some display) the parameters that must be used to create a stub that would allow the first member device to engage it.
'Create a UnicastRemoteObject for a specific server' is meaningless. Any time you create one, it runs on the local host. [There is an exception to that, but it doesn't apply in this case.]
Can the client create a stub itself rather than having to use the one that was exported by the server?
No. [Again there is an exception to this, as this is exactly what Registry.locateRegistry() does, but it uses classes you aren't privy to, so you can't.]
You will have to explain your aversion to using the Registry for this purpose as the RMI designers intended.
EDIT What you're really looking for is a distributed Registry. There isn't (can't be) one for RMI/JRMP, but you could investigate RMI/IIOP and suitable ORB vendors, this is meat and drink to them. Or else use a central LDAP server via JNDI instead of the Registry.
It's not fashionable to answer my own question, but I've done a little more research, and it appears that my problem lends itself to multicasting.
I have found a post here which talks about the feasibility of sending a UDP packet containing an RMI stub to multiple devices. The sender in my instance would be the non-member device, and the receivers would be the cluster of members. These member devices would then organise between themselves which one of them would try to engage the sender.
Although the link to the cited post's example code no longer appears to work, this indeed looks promising...