[MOBY-dev] correspondence between service and executable.

Pieter Neerincx pieter.neerincx at gmail.com
Thu Oct 2 13:05:47 UTC 2008


Hi Jason,

PlayMoby as advertised below looks like a good starting point to wrap  
existing tools into BioMoby web services. Looks a little like SOAPLAB,  
but in BioMoby lingua :).

But be aware that there is no such thing as *THE* BioMoby service  
definition for a certain existing binary. Take for example a look at  
BLAST. In the official public BioMoby Central registry you will find  
as many different BLAST services as there are service authorities  
providing BLAST services.
	Some groups might only provide blastp for alignment with protein  
sequences. Therefore they might have hardcoded their service to use  
blastp. Others might provide both blastp & blastn (and blastx,  
tblastx, etc.) for alignment with protein and nucleotide sequences and  
use an optional parameter (secondary article in BioMoby) to specify  
which blast program to use. Similar things you will find for many more  
BLAST parameters...
	Then there's the issue of what you align you sequences with: some  
might provide the complete INSDC (DDBJ/EMBL/Genbank) database while  
others only provide subsections like only ESTs or only certain species  
of interest. And then there dozens of other blastable databases a  
service might, might partially or might not suport. 	Some might limit  
the size of you BLAST jobs by only providing a synchronous BLAST  
service while others might have implemented an asynchronous one  
allowing for longer runtimes.
	Finally there is the issue of output formats. NCBI BLAST has 12  
different output formats. Officially a Biomoby service is registered  
with a certain output. This can not change dynamically based on a  
parameter. So one might choose to register 12 services for the 12  
different output formats. The 12 BLAST output formats are not native  
BioMoby object structures though. BioMoby allows you to wrap existing  
"legacy" data formats. In that case you might wrap your BLAST output  
and use a parameter to specify the format although it is a bit of a  
hack. You could also design a native BioMoby object structure for  
BLAST output and write a converter... For other tools similar design  
choices for different input formats will result in different service  
implementations. And then off course you might use WU-BLAST instead of  
NCBI BLAST resulting in yet another service implementation...

Personally I'm guilty of registering one of those "yet another" BLAST  
services, because at the time I wrote none of the existing services  
suited my needs. Right now your best bet is to investigate what is  
already registered in BioMoby Central and see if there is something  
that suits your needs. If so, recycle, or if not, implement yet  
another...

It would be nice if we would have a standardised way of wrapping  
existing stuff into BioMoby services and Object structures. I am  
thinking of how PostScript works. PostScript is best known as a page  
description language in the electronic and desktop publishing areas.  
Most PostScript drivers implement "everything". For a printer driver  
this means, the driver supports an unlimited high resolution on an  
unlimited large piece of paper. Off course there is no single printer  
out there that can printed on a never-ending piece of paper. Therefore  
manufactures supply PPD (PostScript Printer Definition) files that  
specify the limits a printer can handle. For example max 1200 dpi and  
A4 paper. To print you always use the unlimited driver in combination  
with a PPD for a specific device. If I convert this to our BLAST  
example all BioMoby BLAST services would be registered with the same  
input, same output and same optional parameters, but service providers  
would be albe to specify limits on those. This would require not only  
standardising on BioMoby object structures, but also on naming of  
parmeters + their values and for example on naming + version numbering  
of databases.... hence it would require some level of curation of the  
BioMoby Central ontologies.

Cheers,

Pi


On 02 Oct 2008, at 10:58, Sebastien Carrere wrote:

> Hi Jason,
>
> We developped a lightweight framework in Toulouse (France), called  
> PlayMoby.
> http://lipm-bioinfo.toulouse.inra.fr/biomoby/playmoby
>
> The aim of this framework is to deploy easily BioMoby web-services  
> for command line applications running on UNIX-like systems using a  
> Mobyle program description (http://bioweb2.pasteur.fr/projects/ 
> mobyle/).
>
> You have an exemple on how to write a perl wrapper for Blast  
> (blastp_swissprot) in the "Sample scripts" section (http://lipm-bioinfo.toulouse.inra.fr/biomoby/playmoby/#samples 
> ).
>
> We deploy and survey around 120 web-services deployed with PlayMoby  
> and if you need another exemple based on EMBOSS program, you can ask  
> me sources for one of the following program:
> http://lipm-bioinfo.toulouse.inra.fr/biomoby/analysis/external/services/mobycentral_bioworkflow.rss
>
> Hope this help,
>
> Sebastien
>
> jason a écrit :
>> Hi,
>> Any suggestion on this one?
>> Help is appreciated.
>>
>> -jason
>>
>> jason wrote:
>>> Hi, all
>>>
>>> I am trying to set up some moby services for testing. What I have  
>>> is a bunch of binaries such as blast, hmmer, and emboss program  
>>> running on my system?  One step in the service registration is  
>>> generating service meta data.  I guess others already register  
>>> some of these binaries as services. Is there a way I can find out  
>>> what binary is registered in the Moby Central? If I can, I could  
>>> fetch those service meta data from moby central, change the  
>>> authority and service URL, and register my services. Otherwise, I  
>>> need to inspect and register the binaries one by one. It is  
>>> daunting task.
>>>
>>> thanks
>>>
>>> -jason
>>>
>>>
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> 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:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------







More information about the MOBY-dev mailing list