QCG - Sim IJskes wrote:
Peter Firmstone wrote:
Sim IJskes - QCG wrote:
When we have several reggies running on the internet, it would be
handy to find them via DNS SRV records. It would only create an
extra layer of indirection. With DDNS zone updates one could build
some kind of super registry, but i would prefer just to code it in
java.
Sim, I hear you when you say you'd just prefer to code it in Java,
has anyone any experience with dnsjava? Their website is so simple, I
Sorry, i was unclear. I think i was expressing that i prefer to code
it in Jini services, instead of DDNS etc. This is only for the
prototyping phase. I've noticed that i can work much faster when
everything is java and nothing is unmodifiable. When it works, and
behaves like expected then we can refactor it to fit the DDNS service,
and put in a factory for the implementation to enable to switch
between DDNS and the Java Ref Implementation. Much easier for testing
and other bench activities. As we can code the ref. impl. in any form
we want, we can also detect mismatches between the DDNS and what we
need, early during development.
Gr. Sim
Ok , that's a good idea, I'm just trying to imagine the way it might
work, the GlobalLookupService should be a smart proxy service that
allows current jini services to be registered to DNS without requiring
any changes to those services , perhaps my semantics are poor, a better
name might be DNSLookupService that also implements ServiceRegistrar.
This could be discovered by the usual Jini Multicast Request,
Announcement or Unicast Discovery methods currently utilised by jini
services. We could also have some kind of boot strap utility that finds
DNSLookupService's using DNS-SD returning the URL's to LookupLocator
instances when we need to avoid Jini Multicast Discovery or just use the
exiting LookupLocator with a public URL (we might do this if we're
roaming outside a Jini network). Later our DNSLookupService smart proxy
implementations (after prototyping) are free to be re implemented or
compared for improvement. The Marshalled Entry instances will have to
be cached at the DNSLookupService Server at Registration as DNS-SD
cannot support Entry's. I had in mind that the client do most of the
compute work for comparing entry's rather than the server.
The Sequence might work like this:
1. Jini Service discovers a LookupService registrar obtained through
discovery.
2. Jini Service uses the ServiceRegistrar to register its service.
3. The LookupService registrar accepts the ServiceItem and caches it
at the Server and updates the DNS-SD (one dns service record for
each ServiceType interface)
4. A client utilises a LookupService smart proxy to find the DNS-SD
from the ServiceTemplate object passed in, we can utilise DNS-SD
to retrieve a service based on a ServiceID or the ServiceType.
5. Any entry matches are performed for the LookupService server by
its smart proxy after first filtering the results aginst
ServiceType and ServiceID, processed at the client. Althernately
they could be matched at the server using marshalled object
comparisons as Reggie currently does.
Initially, as you point out, we don't need to actually utilise DNS-SD to
start with, we could prototype with a simple file behind the
DNSLookupService registrar with similar semantics to DNS-SD until we've
got a partial implementation working.
Cheers,
Peter.
