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

[Pieter Neerincx]

On 27 May, 2005, at 23:23, José María Fernández González wrote:

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

If these replicated services share the same namespace, but are served 
by different service authorities, then a client can simply bind to a 
single service by it's authority. A combination if service name, 
service authority and job ID / ticket should be enough to poll a 
service and get the result back from the same service. Or is too simple 
and am I missing something...

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

Yes! That would make life much easier. I am currently testing some 
stuff where I have an async service that has an additional help call. 
This service is a wrapper for a commandline tool. If you call the 
service with an empty Moby object it returns an object "ServiceOptions" 
which HASA String that contains the info which you would normally get 
form --help on the commandline along with some info about which 
databases are available and when they were updated. Putting this kind 
of info in the service signature would make more sense though.

Cheers,

Pieter

>
> 	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)
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>