[MOBY-dev] correspondence between service and executable.

Fri Oct 3 16:55:13 UTC 2008

Hi, Pieter, Sebastien
I pull all the services information from Moby Registery using 
"worker.getServices().".  Then I checked the cached services directory.  
The xml files are very useful for me to find out what service is 
available for which application.
For example, I want to know whether someone wrapped hmmsearch before.
I use this command
"grep -i hmmsearch *"

thanks for the help

-jason

Pieter Neerincx wrote:
> 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
> -------------------------------------------------------------
>
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev