The tricky part is how to enumerate multiple domains?
Perhaps this could be done by finding other lookup services globally via
a DNS-SD directly by two new methods in LookupDiscovery?
public void addDomains(String[] domains) throws IOException {...}
public void removeDomains(String[] domains) throws IOException {...}
We might then have another class that enumerates the domains for us.
Then we have to figure out how to retrieve the remote ServiceItem's for
each result for ServiceAttribute Entry comparisons.
This could require an array of smart proxies that each process their
domain results? Putting the load and the risk back onto the client.
Perhaps it would be best to perform most entry matches on the lookup
server to reduce remote network bandwidth requirements.
Anyway I don't think I've got the interactions conceptualised properly,
I doesn't feel right. Feel free to come up with ideas.
Cheers,
Peter.
Peter Firmstone wrote:
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.
