One of the primary issues with the current lookup server design and the
ServiceRegistrar interface in particular is the fact that one can only receive
unmarshalled services. My work on providing marshalled results, visible in the
http://reef.dev.java.net project, allows the opportunity to find stuff without
getting a JVM memory explosion. However, there is a further issue, and that is
in order to "see into" the marshalled object you need to either resolve it or
dive into the stream of bytes. My further work on the PreferredClassLoader
mechanism for establishing "never preferred" classes helps to make it possible
to do resolution of remote objects using locally defined class instances, so
that you can, for example, look at Entry objects.
Also, in my reef work, I investigated adding the names of all classes that are
visible in the type hierarchy of the objects so that you could ask "instanceof"
kinds of questions without unmarshalling.
There are just all kinds of issues related to this that come into play.
Performing a Jini lookup, on the internet today, would be like asking your web
browers to open a tab for every page on the net, and then waiting for that to
finish so that you could click through the tabs to find what you are looking for.
Clearly, lookup needs to be a completely different concept to exist in a large
world such as is visible "on the internet."
Gregg Wonderly
Peter Firmstone wrote:
Anyone got any opinions about Lookup Service Discovery?
How could lookup service discovery be extended to encompass the
internet? Could we utilise DNS to return locations of Lookup Services?
For world wide lookup services, our current lookup service might return
a massive array with too many service matches. Queries present the
opportunity to reduce the size of returned results, however security
issues from code execution on the lookup service present problems.
If we did allow queries on a Lookup Service, could we do so with a
restricted set of available Types utilising only trusted signed
bytecodes? If bytecode becomes divorced from the origin of a Marshalled
Object, and instead obtained from a trusted codebase service, then
perhaps we could have a system of vetting source code submitted for the
purpose of becoming trusted authorised query types? Any query utilising
untrusted bytecode might return an UntrustedByteCodeException?
Perhaps we could make service match results available as a bytestream,
clients that couldn't handle large amounts of data could inspect the
bytestream, continually discarding what isn't required?
Check out this link on DNS service discovery:
http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
Cheers,
Peter.
