[MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating

Paul Gordon gordonp at ucalgary.ca
Tue Aug 16 13:51:08 UTC 2005


My CAN$0.02 :-)

>
>  Paul> A few advantages of the lease are not really advantages in
>  Paul> practice:
>
>  Paul> 1. No one will manually update their lease, they will put it
>  Paul>    in a cron
>  Paul> job.  Therefore you either need to edit your crontab, or
>  Paul> remove from the RDF file in the agent case.  Both are just as
>  Paul> likely to be ignored by an administrator when a service stops
>  Paul> working.
>
>
>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. 
>  
>
This turns into an issue with the protocol, we would need to require 
(when you register a service) test cases that return predictable, 
non-null value.  This was discussed at the last MOBY meeting, but I 
don't think anything came of it.  Or am I wrong?

>  Paul> The chief advantages of the agent are:
>
>  Paul> 1.  You can trace the registration and deregistration of a
>  Paul>     service to
>  Paul> a particular domain name.  It's not great security, but at the
>  Paul> very least people require some serious work to pose as the
>  Paul> NCBI on purpose (by hacking their Web domain), and cannot by
>  Paul> mistake (e.g. "I registered my service using the NCBI
>  Paul> authority ID because I'm using gi's").
>
>Likewise with a lease call back system. 
>
Like you said, the two approches aren't so different, because fetching 
the RDF from the server is a callback of sorts.

>Anyway, can you really not
>determine the start point of a web services call? 
>  
>
If there are proxies, multiple host names for a machine (e.g. the host 
I'm on right now is www.visualgenomics.ca, moby.ucalgary.ca, 
www.gcbioinformatics.ca, and about 6 other names), it can get complicated.

>  Paul> 2.  The RDF for the services does not have a single point of
>  Paul>     failure
>  Paul> (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. 
>  
>
True, but the mechanism to exchange a URL list could be simpler than 
mirroring the entire registry, and is less subject to error propagation 
(e.g. don't blindly copy a goof in the main mirror's database system 
because it had network connectivity issues, fetch the RDF yourself) .  
If we're lucky, people will try to outcompete each other creating the 
most robust registry :-)

>Ultimately, as two systems are doing similar things. It's just that
>one is push and the other pull. 
>
>
>  Paul> The one agent feature I would l;ike though is that I can call
>  Paul> MOBY Central to tell it that I've changed my RDF, i.e. pushing
>  Paul> a refresh. It's not critical though. If the agent runs once a
>  Paul> day, you may get some latency on bad services, but it's not
>  Paul> the end of the world.  Tim Berners-Lee got a lot of flack for
>  Paul> his Web idea because it didn't enforce that what people linked
>  Paul> to existed.  "People won't use it, they may end up at dead
>  Paul> links!" they said...
>
>
>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. 
>  
>
Would we set a maximum lease?  I'd probably give myself a 1 year lease 
so that I wouldn't be bothered again.  That doesn't make me check that 
the service works throughout the year though. IMHO, having a test case 
checked regularly is what really helps here, not the lease.  A lease is 
someone's word, a test case is action, and actions speak louder than 
words :-)

>Cheers
>
>Phil
>
>_______________________________________________
>moby-l mailing list
>moby-l at biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>  
>




More information about the moby-l mailing list