[Biojava-l] GO web service

Patrick McConnell MCCon012@mc.duke.edu
Fri, 30 Aug 2002 13:02:49 -0400


Please see
http://mendel.mc.duke.edu:1755/libraries/biojava/webservices/overview1.gif
for a general overview of how things are hooked together.  It is the
generic web services architecture with BioJava objects on one end and
tools/databases on the other.  Please comment at will!

What do you mean by network 'chatter'?

I like your idea to breakdown the services.  However, what advantage is
there to parsing/translation as web services instead of client-side?  I
suppose we could expose those as services to non-BioJava apps.

-Patrick





Brian Gilman <gilmanb@genome.wi.mit.edu> on 08/30/2002 11:23:37 AM

To:    Patrick McConnell <MCCon012@mc.duke.edu>
cc:

Subject:    Re: [Biojava-l] GO web service


On 8/30/02 11:13 AM, "Patrick McConnell" <MCCon012@mc.duke.edu> wrote:

>
> None of that has been discussed.  In fact, much of that is still up in
the
> air in the web services community.  For instance, there has yet to be a
> standard security protocol adopted for web services technology.
>

    Check out SAML it looks like it's going to win the security war.

> Actually, much of what you you say can (should?) be handled by the web
> services engine.  I think we should be interested in developing
interfaces
> and implementations that are not concerned with how the service is
hosted.
> If we accept this abstraction, we can develop classes that simple run
> processes/access data, parse results, and return well structure objects.
> The rest, we leave up to the service engine.

    I agree that the engine should take care of most of these issues. But,
we probably want to address network "chatter" up front. I'd like to put up
big boxes of how a web service based on bio-java might work to get people
thinking about things before coding up a storm.

    I think a breakdown of service types based on bio-java might be helpful
for all of us. Something like:

    Data services --> bio-java modules (org.biojava.bio.blah)
    Analysis services --> org.biojava.bio.foo
    Translation services -->
    Parsing services -->

    This would give us a nice breakdown of what people want and what exists
in the bio-java packages. From there we could come up with an architecture
document or XML-Schema docs that map to the services that the community is
interested in.

    I hope I'm making sense here...What do others think??

                                    -B

>
> Is this reasonable, or do you think we need to address these issues?
>
> -Patrick
>
>
>
>
>
> Brian Gilman <gilmanb@genome.wi.mit.edu> on 08/30/2002 10:57:16 AM
>
> To:    Patrick McConnell <MCCon012@mc.duke.edu>, <biojava-l@biojava.org>
> cc:
>
> Subject:    Re: [Biojava-l] GO web service
>
>
> On 8/30/02 9:50 AM, "Patrick McConnell" <MCCon012@mc.duke.edu> wrote:
>
> Hello all,
>
>   I'm just wondering if anyone has a design document or a sketch of how
> the web service package of biojava?? I'd like to know exactly what I'd be
> writing to/with?
>
>   Have there been design discussions about all these services on another
> list?? Have people thought about security, reliability, scalability,
object
> persistence, round trip reduction etc??
>
>                           Best,
>
>                                   -B
>>
>> I am thinking of developing a Gene Ontology web service for the web
>> services module for BioJava.  I believe this is a good candidate for a
>> 'domain-specific' web service because a well developed and tested SQL
>> schema exists.
>>
>> Does anyone have any thoughts on this?  Specifically, what sort of
> methods
>> should be included?
>>
>> For the GO web service we built on site here, I included methods such
as:
>>     String getTerm(int goAcc)
>>     String[][] getPathsToRoot(int goAcc)
>>     boolean isAncestor(int goAcc, int ancestorGoAcc)
>>     String getDescription(int goAcc)
>>     int getRoot()
>>     int[] getChildren(int goAcc)
>>     int[] getParents(int goAcc)
>>
>> and so on...
>>
>> And, the most useful part:
>>     int[] getGoAccsByLocus(String locusLinkId)
>>
>> but, that brings in non-standard data from NCBI.
>>
>> We have also integrated Tigr's data:
>>     int getGoAccsByTigrId(String tigrId)
>>
>> but again, who knows how this data is set up in other peoples systems.
> So,
>> we will not be able to integrate that.
>>
>> Does this seem like a useful tool?  Does anyone have any suggestions on
>> what web services should be used for the webservices module?  So far, I
> am
>> planning on blast and go to show the utility of a tool-oriented web
> service
>> and a data-oriented web service.
>>
>> Thanks for any input,
>>
>> -Patrick
>>
>>
>> _______________________________________________
>> Biojava-l mailing list  -  Biojava-l@biojava.org
>> http://biojava.org/mailman/listinfo/biojava-l
>>
>
> --
> Brian Gilman <gilmanb@genome.wi.mit.edu>
> Group Leader Medical & Population Genetics Dept.
> MIT/Whitehead Inst. Center for Genome Research
> One Kendall Square, Bldg. 300 / Cambridge, MA 02139-1561 USA
> phone +1 617  252 1069 / fax +1 617 252 1902
>
>
>
>
>
>

--
Brian Gilman <gilmanb@genome.wi.mit.edu>
Group Leader Medical & Population Genetics Dept.
MIT/Whitehead Inst. Center for Genome Research
One Kendall Square, Bldg. 300 / Cambridge, MA 02139-1561 USA
phone +1 617  252 1069 / fax +1 617 252 1902