river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gregg...@gmail.com>
Subject Re: LookupLocator and ServiceRegistrar
Date Thu, 03 Jan 2013 18:45:33 GMT

On Jan 3, 2013, at 6:58 AM, Peter Firmstone <jini@zeus.net.au> wrote:

> 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.

I don't see such a restriction since there is a LookupLocator(String) constructor.  That string
can convey anything, and the history of "jini:" is just history, not a requirement.  People
using the other constructors get "jini:" behaviors.  The getRegistrar(…) methods just need
to use a pluggable protocol discovery/lookup function, and then return a ServiceRegistrar
implementation.   Whether or not that is a "remote" reference or a "proxy service" is a detail
for the protocol provider.

> 
> We already have a number of different discovery protocol options, it would be nice if
LookupLocator reflected this.

What are you imagining to be different?

> 
> 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.

I generate lookup locator from/in configuration.  Even through I do enable multicast discovery,
unicast is also happening, and I've always managed multiple discoveries using a ServiceID->ServiceItem
(well with my deferred unmarshalling, it might not be ServiceItem) map.

> 
> 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.

Yes, this is what I am thinking along the lines of.

Gregg

> 
> 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 <jini@zeus.net.au> wrote:
>> 
>>  
>>> Dan Creswell wrote:
>>>    
>>>> On 1 January 2013 09:48, Peter Firmstone <jini@zeus.net.au> 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.
>>> 
>>>    
>> 
>> 
>>  
> 


Mime
View raw message