[MOBY-dev] Notes from working group 'B'

[Mark Wilkinson]

Hi all, 

Unfortunately, all of my notes from my working group at the MOBY meeting
were stolen along with my laptop just a few days after the meeting
ended.  I have tried to recall everything that we decided, and I compile
it below.

If I have made any errors, or forgotten anything, please post to the
list.

Report from Working Group B

Issues:  Registry mirrors, Service mirrors, Async services, Service
testing metadata, standardized LSID provision

Decisions:
Registry Mirrors  registry mirroring will be accomplished by
synchronizing the SignatureURL’s among a set of registries.  Each
registry will have an agent that can (at its discretion) visit any or
all of the signature URL’s to retrieve the service signatures and update
its own registry.  Someone ____________ is going to look into the
various ways of synchronizing this list (LDAP, DNS, other?)


Service Mirrors  Mark will change the MOBY Central API such that
multiple endponts can be registered/returned in a service search.  This
will affect the registerService and findService API calls.  The
implication of registering multiple endpoints is that the *identical*
service is running in all indicated locations, with the same database
and same software version.  These endpoints all share the same Service
Signature metadata, so they had better be identical!

Async services  a few details have to be worked out (I think the Spanish
contingent took on the task of fleshing this out completely), but the
upshot is that, when a service is registered, it will be assumed to have
four “method” calls:
1)	The name of the service (e.g. doBlastAnalysis)
2)	The name with _async appended (e.g. doBlastAnalysis_async)
3)	The name with _poll appended (e.g. doBlastAnalysis_poll)
4)	The name with _result appended (e.g. doBlastAnalyis_result)

The service registration is identical to what it is now, methods 2,3,4
are optional and are not explicitly registered.  (the ability of a
service to run asynchronously can be determined by querying the RDF
metadata through LSID resolution  predicates TBD).   Calling the service
by name executes the service synchronously exactly as it does currently.
If a service refuses to run synchronously, it returns an empty response
(this is a valid behaviour, and will not break “old” clients).  Calling
the xxx_async method will return a MOBY Object representing a “ticket”-
the namespace should be unique to your async service.  The ticket can be
used to poll the service using the xxx_poll method (API TBD) , and the
same ticket can be used to retrieve the result using the xxx_result
method.


Service Testing Metadata  it was generally agreed that it is desirable
to have a sample input such that a service can be tested.  This will be
made available by the service providers as a string literal in their
Service Signature (this is retrieved by LSID resolution).  The string
should be a complete MOBY message (<MOBY>…..</MOBY>) representing a
sample input to that service that will ALWAYS work; where “work” means
generate an output of the Object type registered in the Service
Signature and in MOBY Central.  This input is to be used for testing
that a service is running, but not for validating the output.


Standardized LSID provision  I have updated the online API documents to
show how LSID’s will be derived from MOBY Central messages.  Generally
speaking, in the response message from MOBY Central, any XML tag whose
content represents an entry in one of the ontologies, or a service
instance, will have an attribute lsid=’nnn’, where nnn can be resolved
to metadata describing that entity.  For the MOBY Ontologies, this
metadata is the RDF describing the ontology node.  For service
signatures, this metadata is the RDF of the service signature (taken as
a GET directly from the service providers machine through the usual LSID
resolution process using their registered SignatureURL as the GET URL).
As soon as I get a few minutes free I will implement this new part of
the API.

I’m sure there are things I have missed… please make your additions and
comments to the list.