[MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community
Paul Gordon
gordonp at ucalgary.ca
Tue Aug 8 15:25:38 UTC 2006
Hi all,
I think both RDF and ping are necessary:
1. The RDF is a contract of sorts. If you are not committed enough to
keep the RDF available for download, your service should be
deregistered. It also makes people aware that if they modify their
service, they really should be updating the RDF (at least the service
instance version number). There definitely needs to be a grace period
though, as yousay, while the agent is in testing mode.
2. I think the ping should be mandatory, with a valid input test case.
I think this is REALLY important: If we want users to really adopt MOBY,
we MUST make it difficult to have dead services show up as service
options in clients. There is NO good reason to allow lazy service
provision. If our focus is on providers rather than users, to use an
English idiom, we are putting the cart before the horse. If a service
provider cannot easily provide a sample of valid input, they obviously
have not even really tested their service! In MobyServlet
(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html),
you MUST provide one or more test "mobyData" blocks of the correct input
type, and receive answers of the correct data type, THEN it register
your service. I could very easily, and very happily, add the test data
automatically to the registration data or RDF...
Sorry for all of the capitalization, but I show no mercy to broken
services! (Including some registered by people in my own lab :-)) The
robustness of the individual services is (as Mark's has learned)
interpreted as the robustness of the clients and the protocol itself,
let's not give people any reason to doubt...
Paul
> Summarising, using SignatureURLs and the RDF Agent makes (de-)
> registration more secure, but it doesn't solve the issue of pollution
> of registries due to dead or mis-registered services.
>
> Registry pollution seriously hampers service discovery and spoils the
> fun. The recently discussed BioMOBY "ping" would be a good candidate
> to check whether a service is up. I think we already agreed that the
> ping request will be an empty request. Hence, a ping request has no
> query alias mobyData tag and there is an empty mobyContent tag:
>
> <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'
> xmlns='http://www.biomoby.org/moby'>
> <moby:mobyContent moby:authority='www.myauthority.org' />
> </moby:MOBY>
>
> There was still some discussion though about what the ping response
> should look like. We suggest this will be the same as the input with
> the option to append serviceNotes. In the serviceNotes section we
> could optionally use exceptionCode 700 to signal everything is Ok,
> but just as with normal service invocation serviceNotes remain
> optional. So a minimal ping response would be something like this:
>
> <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'
> xmlns='http://www.biomoby.org/moby'>
> <moby:mobyContent moby:authority='www.myauthority.org' />
> </moby:MOBY>
>
> With serviceNotes it would look like this:
>
> <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'
> xmlns='http://www.biomoby.org/moby'>
> <moby:mobyContent moby:authority='www.myauthority.org'>
> <moby:serviceNotes>
> <moby:Notes>
> Some human readable information about this service...
> </moby:Notes>
> <moby:mobyException severity ="information">
> <moby:exceptionCode>700</moby:exceptionCode>
> <moby:exceptionMessage>Service is up</moby:exceptionMessage>
> <moby:/mobyException>
> </moby:serviceNotes>
> </moby:mobyContent>
> </moby:MOBY>
>
> The question that remains is who will use the ping? We think both a
> registry and the clients could take advantage of the ping. The
> registry could have a Ping Agent in addition to the RDF Agent to
> check whether services are up. And it would be fine if this Ping
> Agent removes dead services after a certain amount of unsuccessful
> attempts. Furthermore to get the most up-to-date information a client
> could use a ping to check whether services are up. Having an option
> to hide services which are down would make more sense to us compared
> to hiding services without a SignatureURL as a SignatureURL doesn't
> tell us anything about service availability nor about service
> quality. The SignatureURL only tells you something about registration
> security, which is probably not very useful for most clients.
>
> Would this make everybody happy?
>
> Cheers from Fortaleza,
>
> Martin and Pieter
>
>
> On 4-Aug-2006, at 1:50 PM, Mark Wilkinson wrote:
>
>
>> Issue #1:
>> -------------
>> Well, along with the rest of you, I got an inbox full of threatening
>> emails from the agent yesterday. Ugh! Sorry about that!
>>
>> So, the first-try of the agent was possibly a bit of a disaster w.r.t.
>> public relations, but we did learn from it, and we're re-coding it now
>> to have a less annoying behaviour!
>>
>> History: The primary purpose of the agent is to enable a distributed
>> and safe way to add/update/remove your services from the registry. At
>> present, services registered without a SignatureURL can be removed by
>> anyone, which is quite a dangerous situation. For this reason, we
>> encourage people to now download their Service Signature RDF from the
>> page that Eddie has set up at
>> http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm and
>> save the output to whatever URL you enter in the Signature URL box.
>> This will protect your service from deregistration by third-
>> parties. If
>> you need to deregister your service, simply remove its description
>> from
>> the RDF document, and the agent will remove it from the registry the
>> next time it crawls. [[More about this in Issue #2 below...]]
>>
>> Another behaviour of the agent is its (configurable) ability to
>> "cleanse" the registry of any service that do not have a SignatureURL.
>> The assumption was that "dead" services would likely not have
>> SignatureURLs, and that any service that was intended to be
>> production-
>> quality would have been registered with a SignatureURL so those
>> without
>> could/should be removed. This became a part of the draft policy
>> statement for my instance of MOBY Central
>> (http://mobycentral.icapture.ubc.ca/MOBYCentral_Policy.html).
>>
>> I've had complaints about this policy from several of the key MOBY
>> partners, and they have convinced me to loosen this policy to be less
>> "tyrannical", and in the process we have come up with an alternative
>> proposal that I wish to put forward to the community.
>>
>> My concern with the way people use the main public registry has been
>> that people tend to leave their "trash" lying around in there for, in
>> some cases, years! This clutters-up the search results of other
>> people
>> and is generally quite a nuisance. However, if we agree that services
>> with a SignatureURL are "production quality" and that services
>> without a
>> SignatureURL are "test", then it is still possible to filter-out these
>> "test" services at the client-level, while allowing them to persist in
>> the registry for people to use and experiment with until they are
>> ready
>> to re-register them with a SignatureURL.
>>
>> i.e. the new policy proposal is that services without a
>> SignatureURL can
>> remain in the main public registry; however it is up to the client
>> whether or not these services are displayed in the search results.
>>
>> Does this sound more reasonable to everyone?
>>
>> If so, I will update the policy statement, and we can make a note of
>> this "convention" in the API documentation as well.
>>
>> ===============
>>
>> Issue #2: Immediate Deregistration/Updating
>>
>> The MOBY Central code does not allow you to deregister a service
>> with a
>> Signature URL, nor can you update it. This can be very annoying, I
>> know!! It's not sufficient to just wait for the agent to visit during
>> the night... there must be a better way!
>>
>> It is undocumented because we're still experimenting to see if
>> there are
>> any obvious down-sides, but MOBY Central is currently configured to
>> trigger an Agent visit if you call the registerService method with
>> your
>> SignatureURL as the only parameter. This allows you to *immediately*
>> deregister or update a service (based on a local edit of your
>> Signature
>> RDF document) rather than waiting for the next agent crawl.
>>
>> I invite all developers to try this and let us know if this seems
>> like a
>> sensible behaviour. There may be better ways to accomplish this,
>> so if
>> you have other ideas, or if you see any potential security-holes in
>> this
>> approach, please let us know.
>>
>> ============
>>
>> Cheers all!
>>
>> Mark
>>
>> --
>> Mark Wilkinson
>> Asst. Professor, Dept. of Medical Genetics
>> University of British Columbia
>> PI in Bioinformatics, iCAPTURE Centre
>> St. Paul's Hospital, Rm. 166, 1081 Burrard St.
>> Vancouver, BC, V6Z 1Y6
>> tel: 604 682 2344 x62129
>> fax: 604 806 9274
>>
>> "Since the point of a definition is to explain the meaning of a
>> term to
>> someone who is unfamiliar with its proper application, the use of
>> language that doesn't help such a person learn how to apply the
>> term is
>> pointless. Thus, "happiness is a warm puppy" may be a lovely thought,
>> but it is a lousy definition."
>>
>> Köhler et al, 2006
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>
>
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
>
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
More information about the MOBY-dev
mailing list