[MOBY-dev] [moby] Suggestion for new tag in Parameter(Secondary Input specification)

Fri Feb 24 18:04:33 UTC 2006

Hi all and Pieter in particular:

This is Oswaldo from the gnv5 -University of Malaga- group at the INB.
Perhaps Pieter's mail needs some additional information from our group to
better understand some aspects of the INB architecture.

The INB project was started in March'04, a major decision was make to use
BioMOBY as the underlying integration protocol. However, several of the
desirable functionalities were not available in the protocol, specially
important from the INB perspective were the ability to launch large-CPU
tasks using asynchronous messaging; a protocol for error handling (and, in
the way, some specific rules for dealing with collections; help information,
DB optimization, etc etc. we expect to propose extensions in these fields.
soon).

However, we design the architecture keeping in mind to maintain full
compatibility with moby. A good example is our current async implementation
(see the attached document for a longer description). What can we learn from
this document? that we extend the protocol -async- even with the double cost
of maintain moby compatibility: Even more, our current proposal for async
was born during the INB meeting (July'05) and discussed with Martin and
Eddie. This proposal is completely new and -if approved- we will need to
re-write our async code (well, not at all). Thus, once we are part of the
moby group and our ideas can be taken into account, we will move closer in
the moby direction to avoid double work from our side (as you can imagine,
this is what we want).

On the other hand, our registration procedure -in my opinion- does not break
our moby compatibility. In fact you can use directly all the services we
have developed. If you see the new fields, most of them are used to allow
(user-friendly and self explicative) automatic interface building. SO they
don't have any influence in the services call protocol.

We of course will be happy to propose a documentation system and other
extensions, but at this moment there are other priorities.

In sumary; in fact we have our own ideas about a full protocol. For
strategic reasons we develeop at our own cost, some moby extension (from a
practical point of view, we took our own decisions because we needed a fast
development -you know that error handling have spent more than 4 months in
discussion!!!!). But we dont want to break moby (and we are not going to do
that).

sorry for this long (and boring) dissertation.

Oswaldo

PS with repect to the registration procedure, it can be done using moby
functionality, but we request additional information to be used by our
client (if you want addictional information on our protocol dont hesitate to
request)

> I read the INB paper "Intelligent client for integrating
> bioinformatics services" published in Bioinformatics. The things
> mentioned above were described there and it made me wonder... For
> asynchronous service calls the INB leads an initiative to extend the
> BioMOBY standard, which is great! This may take a bit longer to get
> accepted and implemented as compared to hacking together some custom
> extension, but it makes sure that your BioMOBY services are
> compatible with the rest of the BioMOBY world. The INB did the same
> for error handling. But for the things mentioned above the INB people
> chose to go their own way. The "extended service registration"
> procedure is INB specific and the additional (help) info is available
> form a "fourth party" server (not the BioMOBY client, nor the service
> provider, nor the INB BioMOBY Central). I think this is bad. The INB
> BioMOBY Central is out of sync with the official BioMOBY Central and
> no longer compatible, because of the modified registration procedure :
> (. Personally I think this is even worse...
>
> Anyway the things mentioned above would definitely be useful! The
> secondary parameter description was just added to the service
> registration call. So that's solved. When I retrieve a service I get
> the BioMOBY WSDL that contains amongst others all the description
> fields. If I have a typical BLAST service that supports all 40+
> parameters it also means that this WSDL will hold the description for
> 40+ params. It's getting big...:). So adding additional help in XML
> format and example input and output there (during registration) would
> make the WSDL we send around even longer. Not my favourite solution.
>
> I would rather like to see a solution where this additional
> information is provided by the service (provider) and only when the
> client requests it explicitly. This way it doesn't need to be stored
> in a BioMOBY Central. This could be done for example using an
> additional method [ServiceName]_help. If this would be standardised
> the new RDF agent, might be extended and use this method to get the
> example input, excute the service with this example input and
> validate the results. It can than check:
> * whether the service works
> * if the input and output are valid as compared to how the service
> was registered.
> If these checks fail it might send an automated e-mail to the
> maintainer of that service and eventually if the issues are not
> resolved remove the service from BioMOBY Central. In the "cleaning
> out the registry" thread Mark mentioned that he would contact service
> providers whose services work perfectly well, but were registered
> incorrectly. No matter how efficient Mark might work, sooner or later
> BioMOBY will be so popular and BioMOBY Central so big, that doing
> this manually won't be feasible anymore. So this needs to be
> automated sooner or later anyway. Having example input and output
> might be used for that. So what do the others think...
>
> Just my 2c,
>
> Pi
>
> >
> > Kind regards,
> > Johan Karlsson
> >
> > Mark Wilkinson wrote:
> >> Absolutely - I believe the INB had also requested this a while
> >> ago, too.
> >>
> >> Do we need to go through an RFC for this?  I hope not...
> >>
> >> If nobody objects, I'll add it to the API right away.  It should only
> >> take a couple of minutes to code.
> >>
> >> M
> >>
> >>
> >>
> >> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote:
> >>
> >>> Can we add an optional description field to the secondary article
> >>> tag?
> >>> It might help people fill it out if they have a hint *what* they're
> >>> filling out besides the articleName. i.e.:
> >>>
> >>> <Parameter articleName="NameOfArticle">
> >>> <desc>This field sets the frameshift penalty in the alignment.
> >>> The higher it is set, the less likely frameshifts will be
> >>> detected and corrected.</desc>
> >>>         <datatype>Integer|Float|String|DateTime</datatype>
> >>>         <default>...</default> <!-- any/all of these -->
> >>>         <max>...</max>         <!-- ... -->
> >>>         <min>...</min>         <!-- ... -->
> >>>         <enum>...</enum>        <!-- ... -->
> >>>         <enum>...</enum>        <!-- ... -->
> >>>   </Parameter>
> >>>
> >>> Sound reasonable?  Does this require a RFC?
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev at biomoby.org
> >>> http://biomoby.org/mailman/listinfo/moby-dev
> >>>
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://biomoby.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: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
>
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-dev