Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: domain of greggwon@gmail.com designates
 209.85.161.177 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: LookupLocator and ServiceRegistrar
From: Gregg Wonderly <greggwon@gmail.com>
In-Reply-To: <50E58072.10704@zeus.net.au>
Date: Thu, 3 Jan 2013 12:45:33 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <97EC6EA3-496A-4B99-8DD4-463297E7E13F@gmail.com>
References: <50E2B0D1.7060408@zeus.net.au>
 <CAMPUXz9asuh4aZBL9ccejb0t5PZQyV=d_8ueWUgpkb+7Bn1DLg@mail.gmail.com>
 <50E410CC.2050400@zeus.net.au>
 <976859AA-E15F-4A61-9C75-820221F2F6EC@gmail.com> <50E58072.10704@zeus.net.au>
To: dev@river.apache.org


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.
>>=20
>> 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.
>> =20
>=20
> 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(=85) 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.

>=20
> 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?

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

>=20
> 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

>=20
> Cheers,
>=20
> Peter.
>=20
>> 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.
>>=20
>> Gregg
>>=20
>> On Jan 2, 2013, at 4:49 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>>=20
>> =20
>>> Dan Creswell wrote:
>>>   =20
>>>> On 1 January 2013 09:48, Peter Firmstone <jini@zeus.net.au> wrote:
>>>>      =20
>>>>> You might remember an earlier discussion on the list about
>>>>> StreamServiceRegistrar:
>>>>>=20
>>>>> public interface StreamServiceRegistrar extends ServiceRegistrar{
>>>>>  ResultStream lookup(ServiceTemplate tmpl, Class[] entryClasses,
>>>>>          int maxBatchSize, int limit)  throws IOException;
>>>>> }
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> I'm considering another method for StreamServiceRegistrar:
>>>>>=20
>>>>> 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;
>>>>>=20
>>>>> 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;
>>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>          =20
>>>> 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.
>>>>      =20
>>> Got time for an example?
>>>   =20
>>>> 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.
>>>>=20
>>>>      =20
>>> Sounds like you've a better name in mind?
>>>=20
>>> Cheers,
>>>=20
>>> Peter.
>>>=20
>>>   =20
>>=20
>>=20
>> =20
>=20