Gregg Wonderly wrote:
I too use static locator configuration because I am usually one of the
administrators across a VPN connection, and my other users are remote users,
not local to the multicast TTL.
I wonder if we shouldn't think about a pluggable system something like
URLStreamHandler. That is, an abstract class that has pluggable protocol
handlers which could be added to the system via configuration, or
programmatically via a security based authorization. Then, we can use
LookupLocator, but just move to a multi-protocol lookup facility.
Currently we're restricted to jini://host:port URI syntax in
LookupLocator, although we have various options for discovery, these are
goverened by constraints, but then you have the problem of the client
and server being configured with different constraints and unicast
discovery protocols.
We already have a number of different discovery protocol options, it
would be nice if LookupLocator reflected this.
LookupLocator is often generated by way of a URI string found during
multicast discovery or from configuration, a string would also make
sense for DNS-SRV.
A handler sounds like a good idea, Sim and I were discussing something
like that recently for RiverClassLoader. Perhaps something using an SPI
interface might be appropriate, the URI scheme used to lookup up a
suitable provider.
Cheers,
Peter.
The idea of "multicast" is interesting, but its a local network segment technology, at most, to be
dependable. I've not been able to ever "count" on it working. So, looking at DNS-SRV would allow
us to "find" URLs. We might think about a different/refined multicast or rendezvous kind of
thing, but I am not sure we can make multicast-discovery be and more dependable with just software. It's a
network infrastructure issue.
Gregg
On Jan 2, 2013, at 4:49 AM, Peter Firmstone <[email protected]> wrote:
Dan Creswell wrote:
On 1 January 2013 09:48, Peter Firmstone <[email protected]> wrote:
You might remember an earlier discussion on the list about
StreamServiceRegistrar:
public interface StreamServiceRegistrar extends ServiceRegistrar{
ResultStream lookup(ServiceTemplate tmpl, Class[] entryClasses,
int maxBatchSize, int limit) throws IOException;
}
ResultStream is similar to MatchSet from JavaSpace05, it allows local
filtering of ServiceItems (with only Entry's unmarshalled), delayed
unmarshalling and stream like retrieval of ServiceItems.
Well, I've been considering how LookupLocator is restricted to
jini://host:port based URI and figured that in future it may be preferable /
desireable to perform Unicast Discovery using other methods.
I'm considering another method for StreamServiceRegistrar:
namely something like:
/**
* Returns an array of URI that can be used if necessary
* for unicast discovery of the lookup service.
*/
public URI[] getUniversalLocators() throws IOException;
or:
/**
* Returns a space separated list of URI strings that
* can be used if necessary for unicast discovery of the
* lookup service.
*/
public String getURI() throws IOException;
These methods could easily return jini://host:port for standard Jini unicast
discovery, this allows a lot more freedom for future expansion of discovery
methods, for very little effort.
How would you see these being used in a real system? Would I want
these URL's on the Registrar? See, to get them, I need to have got
hold of the Registrar in the first place. Dunno, this feels like
something that needs to be on an Admin interface somewhere.
Got time for an example?
I would certainly say StreamServiceRegistrar is the wrong place to put
them. They have nothing to do with Streaming at all. That's okay,
StreamRegistrar is becoming a next-gen ServiceRegistrar interface but,
if it is, we need a different name.
Sounds like you've a better name in mind?
Cheers,
Peter.
