[MISC] [MOBY-l] Time-to-live as service metadata

[Mark Wilkinson]

To be honest, I have racked my brains on this, and can't come up with a
better solution that what you & Martin are suggesting either - I was
hoping to bring it up at the MOBY meeting in CSHL in a couple of weeks,
but it looks like the cat's out of the bag again now :-)  It's all a
part of the larger issue of security (in general) and quality of
service.  My understanding of UDDI is that UDDI registrations don't
time-out, but rather are governed by (a) quite small and domain specific
registries, that (b) have password authentication for the
register/deregister process if necessary.  As such, they might not
experience the problem of wanton random (useless) service registration
since only a select few can register services, nor of services becoming
obsolete given the peer-pressure of the smaller social-domain the
registry caters to.  Conversely, if you look at the services currently
available in MOBY Central you will already see quite a bit of garbage -
services and objects called "TEST", for example - people not cleaning up
after themselves... in fact, I noticed this morning that someone has
registered an object called "LSID" that is specific to a particular
domain of LSID's!  EEEK! Granted, this is my fault for not getting off
my arse and setting up a test-instance of the registry, but it does
emphasize the need for some sort of automated maintenance!

My inner voice tells me that the more barriers we put at the
service-provision side of the equation, the fewer people will play the
game, and the less useful MOBY will be.  It's easy enough for people
with a good knowledge of systems to set up a cron that will re-register
their services on a weekly basis, but this does raise the bar higher
than I had hoped to w.r.t. service-provider buy-in, and will be quite
foreign to someone on e.g. MS Windows.  The flip-side of the coin is, as
you say, that the less reliable/useful the system is as a whole the less
it will be used - a deadly downwards spiral toward uselessness!  Damned
if you do, damned if you don't!  

Personally, I'm all for the time-to-live solution, if the person who
decides to build it *promises* to build the tools to make it easy to
implement! 

...notice that we first need someone to raise their hand and volunteer
to build it ;-)  I'm trying to get more money to pay coders in my lab,
but that will take time, so... anyone with idle hands is welcome to do
the devils work!

M




On Wed, 2004-03-17 at 13:14, Frank Gibbons wrote:
> At 03:41 PM 3/17/2004, Martin Senger wrote:
> > > Or have a Time To Live associated with a service.  The policy would be
> > > central.  By default, a service stays listed for, lets say, 7 days...
> > >
> >    I like it, and I like that somebody brought it here again. I was trying
> >a year ago, but nobody listened to me. This "leasing" is a concept that
> >has been discussed a lot within myGrid project and is very appealling. It
> >is part of a broader question of "quality of service" (or "metadata"
> >attached to a service).
> 
> Sounds like a good idea to me (not that I have any experience in this 
> stuff). I think, if MOBY takes off in a big way, this might turn out to be 
> an Achilles' heel if not tackled early. What will happen if, five years 
> from now, there are 1000 services registered, but only 250 of them actually 
> work as advertised? You're going to have some pretty unhappy service 
> consumers on your hands, and it's going to become harder for others to 
> justify adding services.
> 
> Imagine MOBY as one of those maps you get a holiday fair, showing what each 
> booth is and what they're selling. If most of the booths are empty, or are 
> selling something different from what the little map says, pretty soon 
> people start to say "oh, MOBY used to be great when it started out, but you 
> don't want to go there now unless you really have a lot of time on your 
> hands - most of the booths are empty, and those that aren't empty are 
> selling something different from what you expect."
> 
> "Time to live" sounds like a fairly low-maintenance way to go.
> 
> -Frank
> 
> 
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
> Tel: 617-432-3555       Fax: 
> 617-432-3557       http://llama.med.harvard.edu/~fgibbons
> 
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre