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

[José María Fernández González]

Hi Mark & the MOBYfiers 8-),

<snip>

> 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!
> 

Also, I can remember we talked about storing updated QoS information,
doesn't it? Thinking on replicated services, each one should have its
own QoS information.

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

I have been reading the above description about asynchronous services,
and there is at least one loose points. You can imagine an scenario
where we have a replicated service, and that service is asynchronous. A
client would choose one of them, but it would be technically difficult
to assure the obtained ticked is useable in *each* one of the replicated
services. INB guys have at least two huge computer facilities, and they
are geographically disperse, which makes difficult to share the same job
identifier namespace. Therefore, either each replicated service should
have its unique namespace or clients should tie to the chosen services
at the beginning.

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

Please, don't forget detailed textual descriptions of the services (long
description, input & output parameters, examples, external & internal
links), objects (long description, what it means each HAS and HASA
element, examples, links), and perhaps namespaces, as they should have
their place in RDF. Providers are the only responsible to fill these
optional, but useful, information fields/tags.

	Have a nice weekend,
		José María

-- 
José María Fernández González		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Diseño de Proteinas		Protein Design Group
Centro Nacional de Biotecnología	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin nº 3 (Campus Cantoblanco, U. Autónoma), Madrid (Spain)