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

[Benjamin Good]

Just to add my 2c.  The idea of adding a test case to the  
registration phase did come up at the meeting, but I'm not sure how  
far its gotten?

I would suggest that this test actually be an instance of the moby  
datatype registered as the input of the service - instead of a URL.   
This would let any moby-capable client test the service whenever  
necessary using exactly the same protocol required to run the service  
in the usual case.  Having this possibility makes it feasible for  
client providers to filter out inconsistent services without relying  
entirely on the registry to do so.  This enables a runtime check on  
the service that seems impossible using only the registry.  The agent  
could then use this same check to make its decision about whether to  
keep the service listed or not..


- Ben

On Aug 16, 2005, at 9:26 AM, Eddie Kawas wrote:

> I just wanted to say that I agree with Paul.
>
> I think that when a provider registers a service, the provider enters
> a url that causes the service to return something that is commonly
> returned by all services that states that the service is running. If
> this return value is infact returned, then the service signature is
> processed. Otherwise, the offending service is recorded and the
> service is not shown to the public until the test passes. If after x
> times the test fails, then it is permanently removed.
>
> Eddie
>
>
> On 8/16/05, Paul Gordon <gordonp at ucalgary.ca> wrote:
>
>> 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
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> moby-l mailing list
>> moby-l at biomoby.org
>> http://biomoby.org/mailman/listinfo/moby-l
>>
>>
>
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>
>