[Biojava-l] GO web service

Dickson, Mike mdickson@netgenics.com
Sat, 31 Aug 2002 09:58:30 -0400


Once more into the breach...

> > >WooHa!  I think I learned my lesson from the last go round like Ewan.
> > >I'm not touching this with a ten foot pole.
> >
> > Could you explain a bit about why so that we can get an idea about what
> > we are getting into?  I'd hate to start down a path that led nowhere.

> Endless discussions about the pros and cons of a "standard" that everyone
> wants to fit their use case/prejuidice.

I'd also add that we got bogged down in details of the implementation
technology (we want to use Corba valuetypes; wait, Orbit (insert your
favorite ORB here) doesn't do valuetypes) and lost sight of a valid
biological model.  Oh yeah, and since I've already used the dreaded "model"
word I suppose that's an indication that there was some disagreement about
how to approach building systems in the first place.  More on that below.

In the SOAP/XML world I'd expect you'd get bogged down in similar places.
If I was doing it I'd stick with the model described in the JAX-RPC specs
(for Java of course).  There are a number of good soap implementations
already that implement this.  Of course if your favorite is one that doesn't
you might not like this approach...  There is also the issue of how to
represent objects being transmitted. As has been indicated, if you follow
some basic rules you can let the JAX-RPC layer do the marshalling. If you're
really into technology you can write your own marshalling layer (bad idead
IMO). Alternatively you can use more of a document oriented messaging
approach and send back XML "documents" (as in Agave).  Lastly of course
there is the stateless nature of web services vs. stateful behavior in
BioJava (and CORBA).  What does a good stateless interface to the stuff in
BioJava look like?

> Far better to do these things bottom up - build things which work, perhaps
> using SOAP/CORBA/Yadda/ASN/WibblyStufff - show that it works, and abstract
> out anything that looks protcoly/technology based behind interfaces so
> that if WhizzyBangBang stuff in 2003 looks better, it is easy to drop in
> (ie, don't make the technology drive the data model)

Personally I prefer to build in both directions.  Pick an area and define
and architectural "spike" (borrowing from XP).  Have a clear abstract model
for that piece in mind.  And then build some code (and the test cases).  And
yes, keep away from exposing too much of the distribution technology in the
language level interfaces.  

> The "official" OMG way to do this is via UML and some buzz word about
> technology free modelling, but there is still a massive tendancy for
> top-down-design-by-committee, which I think just doesn't work, and frankly
> the Biojava/BioPerl data model (which are reasonably in sync, give or take
> the odd split location thang) is a fine way to start, and the usual
> "propose idea on list, and whoever codes it wins the argument" is a far
> better resolving procedure than committees

I'm not going to get into this one other than to say that this is clearly an
opinion and it doesn't represent everyone's position (not mine at least).
For the record, I'm on the board of directors of the OMG. 

Personally I think spending some time on the model is a good idea.  There
are some places where proposals are starting to get into discussions about
the validity of one approach or another (interfaces and objects vs. data
blobs).  Modeling helps you sort out the impact of such things.  And BTW,
I'm by no means a UML freak.  My personal preference is to do a little
modeling, a little testing and coding, and iterate.  One of the things that
I think has been missing from the BioJava/BioPerl projects is a clear
definition of its architectural direction.  There may be one and it may be
openly discussed over beers when a group gets together but that doesn't help
someone new who is trying to understand how to apply or extend it.

> anyway - build systems which work now is my motto ;)

I'd certainly agree with this.  

> BTW - I recently implemented something in CORBA (C) and it was a pleasure
> though getting your head around the C CORBA mapping does require drugs.

> Talk is cheap. Code is what counts.

No, they both count.  Ultimately people build code. 

If I had advice to give from past experiences it would be to bite of small
problems, develop a shared understanding of them through an abstract model
and then make them real.  Keep iterating until you're done.  And if there
are ways to stay away from defining the problem relative to a technology, do
so.  In the web services vs. CORBA war the key difference is stateless
behavior (IMO).  You can implement a stateless interface in either approach
so if we decide we want to develop a services based stateless interface in
biojava focus on the service definition and not on what your favorite web
services implementation enables.

And as Ewan says, talk is cheap.  It isn't real unless it's written down.
That will help others come up to speed and contribute.

Mike
> 
> 
> 
> 
> >
> > Thanks : - )
> >
> > -Patrick
> >
> >
> >
> >
> >
> > "Dickson, Mike" <mdickson@netgenics.com> on 08/30/2002 04:10:32 PM
> >
> > To:    "'Patrick McConnell'" <MCCon012@mc.duke.edu>, Simon Brocklehurst
> >        <simon.brocklehurst@cambridgeantibody.com>
> > cc:    Ewan Birney <birney@ebi.ac.uk>, Brian Gilman
> >        <gilmanb@genome.wi.mit.edu>, biojava-l@biojava.org
> >
> > Subject:    RE: [Biojava-l] GO web service
> >
> >
> > WooHa!  I think I learned my lesson from the last go round like Ewan.
> I'm
> > not touching this with a ten foot pole.
> >
> > BTW, I have experience building commercial systems with both CORBA and
> Web
> > Services.  I will simply say that arguing about protocols is a waste of
> > time.  They're both just tools.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Patrick McConnell [mailto:MCCon012@mc.duke.edu]
> > > Sent: Friday, August 30, 2002 3:30 PM
> > > To: Simon Brocklehurst
> > > Cc: Ewan Birney; Brian Gilman; biojava-l@biojava.org
> > > Subject: Re: [Biojava-l] GO web service
> > >
> > >
> > > Web services are not good for object-oriented distributed systems
> because
> > > web services do not describe behavior well, they describe data well.
> > > CORBA
> > > is terrible with data because it doesn't interoperate with other
> systems.
> > > You can build the most beatiful, elegent RMI based system in Java, and
> I
> > > will never be able to access that functionality from my .NET client,
> or
> > my
> > > perl client, or my LISP client, or my whatever.  For many, this is
> fine
> > > because they are working within a single business and have control
> over
> > > both the client and the server.  This isn't the case in
> bioinformatics,
> > > were cross-organizational collaboration is a necessity.
> > >
> > > I think very few bioinformaticians are interested in sophisticated
> > > distributed systems.  Instead, they just want to be able to get at
> data
> > > and
> > > tools easily.  I think Web services will do that for them better than
> any
> > > CORBA based technology.  Am I wrong here?
> > >
> > > I have heard the argument before, and I still don't buy that web
> services
> > > is just CGI done a tiny bit better.  CGI and web services have quite
> > > similar qualities and uses, but the ability to strongly type data in
> XML
> > > and to dynamically discover operations/data types makes web services
> > quite
> > > a bit better.  Both of these are keys to successfully building flows
> of
> > > services, which is were I think web services really transcend all
> > previous
> > > technologies.  Now, if we could just get a flow implementation from a
> > > major
> > > vendor, we could start building complex tools from simple web services
> > and
> > > really start using the power of web services : - )
> > >
> > > -Patrick
> > >
> > >
> > >
> > >
> > >
> > > Simon Brocklehurst
> <simon.brocklehurst@CambridgeAntibody.com>@biojava.org
> > > on 08/30/2002 03:57:29 PM
> > >
> > > Sent by:    biojava-l-admin@biojava.org
> > >
> > >
> > > To:    Ewan Birney <birney@ebi.ac.uk>
> > > cc:    Brian Gilman <gilmanb@genome.wi.mit.edu>, Patrick McConnell
> > >        <MCCon012@mc.duke.edu>, biojava-l@biojava.org
> > >
> > > Subject:    Re: [Biojava-l] GO web service
> > >
> > >
> > > Ewan Birney wrote:
> > >
> > > > I remember all these discussions from those great CORBA days. Boy am
> I
> > > > staying away from this for the moment... (too scared frankly!)
> > > >
> > >
> > > I don't blame ya...
> > >
> > > I don't want to be negative (it's not useful), but I suspect not
> > > everyone out there is too experienced at building distributed computer
> > > systems.  My concern is that this (and other) talk about Web Services
> > > may leave lots of people with the impression that Web Services are
> > > something they're not.
> > >
> > > Two things people need to know:
> > >
> > > 1) Building great distributed computer systems is hard.
> > >
> > > 2) If you're gonna do it, CORBA/J2EE over IIOP/RMI/RMI over IIOP are
> > > orders of magnitude more useful than Web Services over http - assuming
> > > you want to build a distributet, object-orientated (and possible
> > > Enterprise-class) computer systems.
> > >
> > > Right now, Web Services is nothing more than CGI done a tiny bit
> > > better.  That's fine if all you want to do is run Blast (in fact, Web
> > > Services is really good things like that).  But they're not good if
> you
> > > want to build an even slightly sophisticated distributed computer
> > > system.
> > >
> > > I truly don't understand the excitement about Web Services -
> > > pleeeaaaasssee no-one say they're really good for tunelling through
> > > firewalls, I can't be doin' with that old chestnut ;-)
> > >
> > > Ho hum... just my two cents etc...
> > >
> > > Simon
> > > --
> > > Simon M. Brocklehurst, Ph.D.
> > > Director of Informatics & Robotics
> > > Cambridge Antibody Technology
> > > The Science Park, Melbourn, Cambridgeshire, UK
> > > http://www.CambridgeAntibody.com/
> > > mailto:simon.brocklehurst@CambridgeAntibody.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
> >
> >
> >
> >
> >
> 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> <birney@ebi.ac.uk>.
> -----------------------------------------------------------------