Imagine a central registry that knows of other registries:
You can have a central Registry X with 0..n bound remote objects. These objects live in the JVM of Registry X.
Then there can be 0..n registries (let's say Registry A, B and C) which have 1..n bound remote objects.
Registry A..C can now "publish" their remote objects on Registry X.
Therefore Registry A..C (if run on same host) cannot use the same port as Registry X. There could be a mechanism for Registry A..C to query Registry X for a "free port", or just search on it's own for a free port.
When Registry A..C publish their remote objects on Registry X, Registry X has to prepare a dummy registry entry that holds
- remote object name
So if one queries Registry X for remote objects (or a specific remote object), Registry C can return a special lookup-result, telling the queriying host that the queried remote object can be found on "host:port#remoteobject".
#1 Updated by achristian over 2 years ago
- Status changed from New to Assigned
Totally unnecessary, as the already existing publication searcher provides this functionality:
just do a Simon.searchRemoteObjects() and find all published remote objects of all registries on the local network.
But one could think of a realy registry-binding, to that one can do a lookup on a central registry and gets redirected to the "real" registry. Question is: Is this realldy needed? The only advantage of this would be, that it would work over the internet, becase it's TCP only and no multicast (for finding the remtoe objects) is required.
On the other side: There could also be a publication-service running, where all the registries publish their remote objects --> kind of index-server for remote-objects...
Have to think about it... More ideas and thoughts are welcome.