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

Fri Feb 24 18:24:36 UTC 2006

sorry, as usual.. here the attach for the previous email
O.

----- Original Message -----
From: "Oswaldo Trelles" <ots at ac.uma.es>
To: "Core developer announcements" <moby-dev at biomoby.org>
Cc: <Pieter.Neerincx at wur.nl>
Sent: Friday, February 24, 2006 7:04 PM
Subject: Re: [MOBY-dev] [moby] Suggestion for new tag in
Parameter(SecondaryInput specification)

> 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
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asynchMOBY.pdf
Type: application/pdf
Size: 56693 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20060224/adf252cb/attachment-0002.pdf>