Had some thoughts about a GlobalLooup Service, an alternative drop in
replacement to Reggie that breaks with some traditions:
The GlobalLookup Service is visible from the internet and has a public
domain name, it is discovered remotely using DNS-SD
1. Services download a Global lookup service smart proxy during
discovery.
2. Smart proxy provides a unique service ID if required and also
provides a single default group and domain from the Server.
3. Smart proxy publishes via DNS-SD each implemented interface, along
with the service ID ( utilising a txt key) and the default group.
(These may or may not be visible outside the local domain).
4. The Service might register and upload it's proxy in a number of
other domains and subgroups with GlobalLookup Services.
5. The Local Service proxy is not registered with the local network
Global Lookup Service, it is instead looked up as required by the
Global Lookup smart proxy and matched at the client.
6. Upon receiving a Lookup request, the lookup service proxy collects
a list of currently available services from DNS-SD
7. The lookup request includes the domains and groups to be queried
(this could be publicly visible services anywhere in the world).
8. A smart proxy for the Lookup service at the client downloads and
unmarshalls proxy objects and Entries to be queried locally, any
retrieved from other domains (only when not visible outside their
local network) will be retrieved directly from the local
GlobalLookup Service cache at the server. The proxy objects in
the Global server cache, have to be registered by the remote
services themselves and will appear to be registered in the local
domain and group to local clients.
9. The Global Lookup Service cache on the server utilises existing
marshalled entry comparisons to minimise the number of service
proxies returned to the client.
10. The local lookup proxy implementation queries unmarshalled Entry's
(provided that the downloaded code is trusted, with limited
permissions as specified in a bundle), enabling more complex
queries utilising the hashCode() method for greater less than
comparisons. This is done in a pre configured number of threads,
where only matching entry's are kept and all other instances
garbage collected. The bytecode and classloading is kept to a
minimum by sharing of compatible bytecode via a codebase service
that abstracts the bytecode from the origin of the marshalled objects.
11. New Entry types, will need to be made publicly available for use
and signing in a public source code staging area. Untrusted
Entries can only be utilised in Marshalled from.
12. If a service moves, it keeps a copy of the domains and groups
where it was previously registered and re-registers remotely, if
configured to do so. Leases are only kept for Globally remote
Services.
13. Local services are rediscovered every time using DNS-SD
14. If a GlobalService goes down and is replaced, it wont affect local
services, however remote registered services will eventually
re-register.
15. If a remote service goes away, it will re-register itself with the
local networks GlobalLooup Service. The local GlobalLookup
service will discard it's proxy after it's Lease expires.
16. The remote services will have registration retry's at longer time
intervals, if unsuccessful, to prevent a DOS packet storm, the
retry will only occur after a Lease expires in any case.
DNS-SD enables the use of any port, by having the remote services
register their proxy's, the packets will have the masquerading headers,
so packets find their way back to the Service, even if private.
Feel free to point out omissions and issues or make suggestions.
Just some thoughts... Cheers,
Peter.
