[MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating
p.lord at cs.man.ac.uk
Tue Aug 16 13:15:29 EDT 2005
>>>>> "Paul" == Paul Gordon <gordonp at ucalgary.ca> writes:
>> This is a necessary problem with neither the agent nor the
>> lease. It is a current problem with the implementation of the
>> agent. All you do is add a call back to the service.
Paul> This turns into an issue with the protocol, we would need to
Paul> require (when you register a service) test cases that return
Paul> predictable, non-null value. This was discussed at the last
Paul> MOBY meeting, but I don't think anything came of it. Or am I
I can't comment on this really, because I wasn't there!
Paul> 1. You can trace the registration and deregistration of a
Paul> service to a particular domain name. It's not great security,
Paul> but at the very least people require some serious work to pose
Paul> as the NCBI on purpose (by hacking their Web domain), and
Paul> cannot by mistake (e.g. "I registered my service using the
Paul> NCBI authority ID because I'm using gi's").
>> Likewise with a lease call back system.
Paul> Like you said, the two approches aren't so different, because
Paul> fetching the RDF from the server is a callback of sorts.
In a sense. It's just that you don't know when it is going to
happen. This is the point with a lease. The client requests from the
server a time limited registration. Is it possible for the client to
query MOBY-Central and ask how often the RDF agent will call? Is it
possible to request that it happens more frequently or less?
>> Anyway, can you really not determine the start point of a web
>> services call?
Paul> If there are proxies, multiple host names for a machine
Paul> (e.g. the host I'm on right now is www.visualgenomics.ca,
Paul> moby.ucalgary.ca, www.gcbioinformatics.ca, and about 6 other
Paul> names), it can get complicated.
Or 18.104.22.168 or h6.net169.ucalgary.ca. The IP number is unique
Paul> 2. The RDF for the services does not have a single point of
Paul> failure (i.e. the central registry).
>> This is also untrue. There is nothing to stop a lease percolating
>> through a set of federated registries. With the agent, you have
>> to percolate the registered URL's (or the RDF) in the same way.
Paul> True, but the mechanism to exchange a URL list could be
Paul> simpler than mirroring the entire registry, and is less
Paul> subject to error propagation (e.g. don't blindly copy a goof
Paul> in the main mirror's database system because it had network
Paul> connectivity issues, fetch the RDF yourself) . If we're
Paul> lucky, people will try to outcompete each other creating the
Paul> most robust registry :-)
Who says that the lease is not encoded as a URL? Besides which, the
lease mechanism might federate by passing around data. Or the client
might explicitly register in more than one registry. Again, I don't
think that this is a necessary advantage of either a lease or the
>> You still want people to be able to search on the freshness of
>> information though. With a lease, you can add queries to
>> moby-central to say "give me only services with a current
>> lease"--after all the registry is not required to deregister a
>> service when it's lease runs out.
Paul> Would we set a maximum lease? I'd probably give myself a 1
Paul> year lease so that I wouldn't be bothered again.
Yes, this is part of the basic idea behind a lease. The registry overs
a specific contract which describes what it is prepared to do for
Paul> That doesn't make me check that the service works throughout
Paul> the year though. IMHO, having a test case checked regularly is
Paul> what really helps here, not the lease. A lease is someone's
Paul> word, a test case is action, and actions speak louder than
Paul> words :-)
As Tom says, service liveness or quality data is not the same thing as
registration, but an orthogonal issue to it. Having service quality
data would be a nice addition to moby-central.
More information about the moby-l