[MOBY-l] A simple MOBY service up and running

[Mark Wilkinson]

Hi all,

I've been playing around with getting service definitions and servers to
work properly.  It's a bit fiddly, but on the upside it looks as if
*most* of the fiddly-bits will only need to be done once, with each
individual service simply referring to a set of standard
object/port-definition documents held at BioMOBY.org (or some other
predictable location).

As I went through the process I got a better idea of how I think things
should look, and have come to the following initial conclusions w.r.t.
standardization of names/methods:

(1)  A service *must* output a defined MOBY class, even if that means
defining a new one just for that service.  For example, if we eventually
create a service which parses the straight HTML of a Blast report into
MOBY alignment classes, then the output of Blast should be defined as
"BlastHTML", and described in the data_types.xsd document, even though
BlastHTML is just straight text with no real MOBY strucutre.  Once that
is agreed upon, then...

(2)  A service-name should take the form ClassA_2_ClassB, or
Namespace_2_ClassB, indicating that this service translates
ClassA/Namespace objects into ClassB objects.
        eg.  PrimarySeq_2_aaSeq,  or GenbankID_2_PrimarySeq

(3)  The method call to evoke a service is the same as the Class which
will be returned.  This is in keeping with the idea that a piece of data
is retrieved using the triple <Class, Namespace, ID>.  For example, a
Perl SOAP::Lite call to evoke the service in (2) will look as follows:
        $service->ClassB(Namespace => $id)

These are just initial thoughts, and are certainly not fixed in stone.
However, I do think it is worth thinking about these things sooner
rather than later...

Below is the client code for a simple service I have set up to translate
Genbank ID's into MOBY PrimarySeq objects after retrieving them from
SRS.  The service definition, and script are held on my local machine.
The data/port definitions are located on BioMOBY.org, and can be used by
everyone (I will set up the CVS to include these files so that we can
work on them directly).  This means that you need only write  a .wsdl
service definition (possibly using this one as a template) and write a
short script in order to create a MOBY service.  Easy!

All documents, except for the script itself, are viewable on-line by
following the addresses in the service definition file.  Please confirm
that this script works for you too.  It should be run as follows:

        perl moby_remote_client.pl AB456747

where AB456747 is the Genbank ID you are interested in retrieving.
Leave this blank for a default genbank entry.

Now on to the hard bit:  MOBY-Central!

Cheers all, and MOBY-on!!

Mark

P.S.  anyone interested in seeing the server script code drop me a
line...  The object definitions need to be tightened up a bit, but that
can happen over time.  I just wanted to get something working to have a
foundation to start from. :-)

--
--------------------------------
"Speed is subsittute fo accurancy."
________________________________

Dr. Mark Wilkinson
Bioinformatics Group
National Research Council of Canada
Plant Biotechnology Institute
110 Gymnasium Place
Saskatoon, SK
Canada


-------------- next part --------------
A non-text attachment was scrubbed...
Name: moby_remote_client.pl
Type: application/x-perl
Size: 807 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-l/attachments/20011031/021745da/attachment.pl>