[MOBY-l] Re: MOBY client/server examples

[Mark Wilkinson]

Simon Twigger wrote:

> However, the closer I look at the code the more Im getting entwined in
> namespaces and definition files that exist on the biomoby server. My
> usual approach towards blatant code reuse is breaking down and I
> actually need to know what's going on rather than using find/replace...

heh heh heh :-)

I know what you mean, I am learning as I go as well!!

What I have tried to do to make it clear and (most importantly) easy for people to begin providing
MOBY services is to split the object definitions, port definitions, and service definitions into
three separate documents.

*EVERYONE* who is MOBY-compliant will read from the same (or mirored) object definition file -
data_type.xsd - this will be the sole repository of all 200-odd MOBY classes, and the only people who
touch it are those with CVS write acces.

*MOST* users who provide a certain common service (eg. GenbankID_2_Sequence) will also use a common
port definition for that type of service from the port_defs.wsdl document.  Only individuals who
provide "unusual" services will have to roll their own port definition, the rest will just point to
the existing document.

For the most part, the average user will simply say "yes, I can provide the service
Genbank_2_Sequence" and write a straightforward service.wsdl document pointing to their script in the
soap:address line.... in fact, the service.wsdl document I posted can, in principle, be used verbatim
with the only changes being in the address and operation name fields,  where you define the URL of
your script and the name of the subroutine to call to achieve the result.

You will, of course, have to study the data_type.wsdl document to learn the correct structure of the
incoming/returned data...


> - How can I add a new service to the biomoby defs and port_defs files,
> is this going to be a function of Moby-Central?

The data_type's and port_def's will be part of the CVS (as soon as I get off of my butt and add
them!).  That way we are all working on the same documents.  I would prefer to not have people
working on the "live" versions, however, because we are liable to have a broken MOBY most of the time
if we do that.  It is probably better to work on the versions in the CVS repository and then copy
them over at various intervals as we ensure their functionality.  (let me know if you want CVS
access...)

MOBY-Central will probably be a straight CGI interface where you indicate the class_2_class that you
are serving, and the URL of the service definition and script files (both of which will usually be
local to your own server).  It will be up to the MOBY client to read and interpret this.


> - Do I need to add to the biomoby wsdl files initially - should I try
> and develop this stuff in private (copy the appropriate wsdl files
> locally so I can hack around) with a view to adding them to the central
> repository in due course, or will this be something I can add in via the
> CVS as we develop?

I am planning to do my development on the data_type and port_def files locally, and then commit to
the relevant changes to the CVS when I have something that I am sure is working.  Your own
service.wsdl files will never be committed, as they are unique to you.


> I guess Im hoping to find a quick step-by-step intro on connecting my
> perl/CGI scripts to the outside world via SOAP and bioMOBY - what I have
> to do at my end and what info I need to provide to a centralized site to
> make things work. If someone can get me up to speed on this I can have a
> stab at writing it up for others to follow.

Unfortunately, we are all beginners struggling to find documentation  :-)  Moreover, MOBY-central
doesn't exist yet so you can't really start building services at this time.... but things are moving
forward slowly!

One of the most critical things that needs to be written up-front is a robust WSDL parser (in several
languages).  It is all well and good to provide services the way that I did in the script I sent
around, but there was no "automated" construction of the object types, or "discovery" of the service
names/parameters.  I was able to provide the service because *I* designed it, and *I* knew how to
build the object, and *I* knew what subroutine to call!  This is not the level at which we need to
work.  A good MOBY client/server will be able to construct MOBY objects by itself using the
data_type.xsd format file, without any specific coding of that object's structure...  This is
difficult, but necessary (especially at the client end).

Does anyone know of an existing OS wsdl parser?

It's the weekend!  Let's go home,

M


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

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