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

[Phillip Lord]

>>>>> "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
  Paul> wrong?

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 136.159.169.6  or h6.net169.ucalgary.ca. The IP number is unique
though. 



  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
agent. 


  >> 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
you. 

  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. 

Phil