[Biojava-l] AGAVE usage
Brian Gilman
gilmanb@genome.wi.mit.edu
Fri, 30 Aug 2002 11:08:08 -0400
On 8/30/02 9:35 AM, "Patrick McConnell" <MCCon012@mc.duke.edu> wrote:
>
> When developing web services, the general procedure is to return Java
> objects in web service methods, and let the service engine build the WSDL
> and serialize the XML. For most applications (especially business
> processes), this makes sense. However, this does not translate to BioJava
> perfectly since the data is extremely complex and BioJava has an internal
> representation quite different from the XML.
>
> So, we have two options (as I see it):
> (1) Build Java objects for each complexType. This is fine, but alot
> of work since we will have to map complexType -> Java class -> BioJava
> class.
> (2) Go through the painstaking process of writing WSDL, and use the
> Agave IO package. This will be extremely painstaking because we will have
> to interface with the SOAP level.
>
I see another choice of producing proxy classes in bio-java that can
take in AGAVE XML/other and producing bio-java objects. This is probably the
most straight forward method in my opinion. Thomas, Matthew?? What so you
think?
> Does anyone have an opinion on this subject? This is actually a design
> decision that we should probably make across the board for BioJava web
> service implementations.
>
> I have done (1) for blast (with the exception of Java class -> BioJava
> class), and it was pretty straight forward to implement. I started to do
> this for Agave, but I ran into some compatibility problems. Among these
> are:
> (1) At least one type extends string, which you cannot do in Java (it
> is a final class).
> (2) The web services package I use does not (at this moment) support
> choice. So, I will have to find some workaround. Does anyone know if this
> is a limitation on other web service packages (I am using GLUE).
GLUE works well. I'm using apache's SOAP. Don't know the difference...
-B
>
> -Patrick
>
>
>
>
>
> Brian King <kingb_98@yahoo.com>@biojava.org on 08/30/2002 12:29:48 AM
>
> Please respond to brian.king@animorphics.net
>
> Sent by: biojava-l-admin@biojava.org
>
>
> To: MCCon012@mc.duke.edu
> cc: biojava-l@biojava.org
>
> Subject: [Biojava-l] AGAVE usage
>
>
> Patrick,
>
> Yes, I think the intention of having the FeatureSet at
> the top level was to allow you to pass around
> annotations without the associated sequence. This can
> be useful when you need to separate different
> annotation types into different files. If you are
> validating using the XML Schema definition of AGAVE
> (agave.xsd), XML Schema doesn't require a root
> element, so you can have any globally scoped element
> as the document root. Most of the elements have
> global scope, so a document with a single seq_feature
> should be valid.
>
> I'm working on a version of the AGAVE IO package that
> spits out AGAVE 3, so I have a chance to reduce some
> of the flakiness that was mentioned.
>
> Brian
>
>
> -------------------------------------------------
> Looking at the schema, I believe that you can push
> around annotations
> without the sequence.
>
> The root element, sciobj, can have zero or more of any
> of the
> following:
> bio_sequence
> contig
> FeatureSet
> chromosome.
>
> So, I think what you are looking for is the
> FeatureSet, which contains
> an
> annotations element, distinct from the bio_sequence
> elements.
>
> Please, an Agave expert correct me if I am wrong.
>
> -Patrick
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
> _______________________________________________
> Biojava-l mailing list - Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
>
>
>
> _______________________________________________
> 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