LookupLocator transport dependence

[Sim IJskes - QCG <si...@qcg.nl>]

Gregg Wonderly wrote:
> Wow, I had not chased through all this code.  I had assumed that 
> LookupLocatorDiscovery would use LookupLocator.getRegistrar() when in 
> fact it does not, and recreates all the processing itself and uses 
> introspection to reference the getRegistrarMethod for constraints, but 
> otherwise does not call it.

The whole jini package is also what you could call, rather TCP bound. 
The upper layer of JERI is transport neutral. I saw this as an 
opportunity to create a firewall traversing jini.
But when you look at other subsystems, you will see a direct dependence 
on Socket, and the assumption that an 'transport endpoint' is identified 
by a host and port (like the LookupLocator).
The strangest thing here, is altough the LookupLocator has this 
getRegistrar() only the port and host properties are used.
LookupLocator is used a _lot_, and to me it seems like it needs to be 
changed to a more transport neutral implementation.

It is possible to implement a LookupLocator via JERI. Reggie itself 
exports itself already. The only things we need is an agreed Uuid 
(configurable ofcourse) and a default for a ServerEndpoint export.

After this we can step-wise improve all the discovery subsystems to use 
the getRegistrar() method instead of relying on the properties.

A neat thing would also be, a configurable way to silence the existing 
unicast discovery server already built in Reggie.

Any objections? :-)

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397

Re: LookupLocator transport dependence

[Sim IJskes - QCG <si...@qcg.nl>]

Patrick Wright wrote:
> This sounds like a good direction to go in. I think that having the
> code throughout rely more on lookup methods like getRegistrar() could
> make certain types of testing easier--don't need to set up the
> infrastructure for socket-based testing if you can mock or stub the
> getRegistrar() method, for example.

Indeed, that would be nice. We could also decide that a LookupLocator is 
nothing more than a specialized URI for finding a Registrar, deprecate 
all implementation details, and provide a (configurable) factory to all 
subsystems that need to bootstrap via a known Registrar.

> An important question will be how to make any such changes backwards

Indeed! Maybe including a URI based factory will provide us with more 
room to maneuver.

Gr. Sim




-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397

Re: LookupLocator transport dependence

[Patrick Wright <pd...@gmail.com>]

This sounds like a good direction to go in. I think that having the
code throughout rely more on lookup methods like getRegistrar() could
make certain types of testing easier--don't need to set up the
infrastructure for socket-based testing if you can mock or stub the
getRegistrar() method, for example.

An important question will be how to make any such changes backwards
compatible. If I understand the documentation and code correctly, both
LookupLocator and DiscoveryV1 implement version 1 of the discovery
protocol, but DV1's implementation in doUnicastDiscovery() is more
complex (and does more) than that in LookupLocator's
getRegistrarFromSocket(). Apart from the fact that both rely directly
on socket calls, it would seem good to bring these two together if it
can be done compatibly, e.g. if LookupLocator could delegate to
DiscoveryV1, for example (and extract the registrar from the
UnicastResponse).

I'm really not familiar with the code, though, so I may be reading
this incorrectly.


Patrick

Re: LookupLocator transport dependence

[Peter Firmstone <ji...@zeus.net.au>]

I like it Sim, we need more people around here who read the code, 
question implementations and come up with good ideas.

Cheers,

Peter.

Sim IJskes - QCG wrote:
> Gregg Wonderly wrote:
>> Wow, I had not chased through all this code.  I had assumed that 
>> LookupLocatorDiscovery would use LookupLocator.getRegistrar() when in 
>> fact it does not, and recreates all the processing itself and uses 
>> introspection to reference the getRegistrarMethod for constraints, 
>> but otherwise does not call it.
>
> The whole jini package is also what you could call, rather TCP bound. 
> The upper layer of JERI is transport neutral. I saw this as an 
> opportunity to create a firewall traversing jini.
> But when you look at other subsystems, you will see a direct 
> dependence on Socket, and the assumption that an 'transport endpoint' 
> is identified by a host and port (like the LookupLocator).
> The strangest thing here, is altough the LookupLocator has this 
> getRegistrar() only the port and host properties are used.
> LookupLocator is used a _lot_, and to me it seems like it needs to be 
> changed to a more transport neutral implementation.
>
> It is possible to implement a LookupLocator via JERI. Reggie itself 
> exports itself already. The only things we need is an agreed Uuid 
> (configurable ofcourse) and a default for a ServerEndpoint export.
>
> After this we can step-wise improve all the discovery subsystems to 
> use the getRegistrar() method instead of relying on the properties.
>
> A neat thing would also be, a configurable way to silence the existing 
> unicast discovery server already built in Reggie.
>
> Any objections? :-)
>
> Gr. Sim
>