[Biojava-l] LSR BSA is hard
Ewan Birney
birney@ebi.ac.uk
Tue, 15 Feb 2000 07:43:38 +0000
On Mon, 14 Feb 2000, Dickson, Mike wrote:
> I want to respond to a number of comments regarding the fact that the BSA
> spec is *hard* to implement.
>
> First point was inheritence from Cos interfaces. I did some digging into
> the spec and for the biological objects we only used 2 Cos interfaces. We
> use CosPropertyService Properties which is a Corba struct and is pretty
> straightforward. We also inherit from CosLifeCycle which requires
> implementation of 3 methods all of which have simple no-op implementations.
> In short the Cos based requirements are pretty simple and default
> implementations could easily be provided.
Wait. This aint so easy Mike (at least to a dim-wit like myself). So we
have copy,move and remove. I *could* throw exceptions on these - in
particular the move() - but every use I can possibly think of will
at least require the copy() and remove() to actually work otherwise the
server is going to be groaning under objects during a single database
loop. To implement copy() properely I need to write a FactoryFinder object
which itself seems to do not alot at all, but presumably all I need to
have is a FactoryFinder saying "this is my factory" to deter people from
attempting to move it somewhere else.
Not trivial. Perhaps not as hard as it looks first time... apologies
The propertyset stuff uses "anys" which is another last-to-implement
feature of free ORBs (though most of them do it, most are buggy as well).
If it doesn't work then it just *doesn't work*.
I still think you are underestimating how tough this is on a free-orb
type environment to implement. So tough to be...impossible... (plus
you have to ship alot of IDLs onto your system and unless you are au fait
with CORBA you might feel compelled to implement all the interfaces.
stupid I know for people in know, but not so much for others).
>
> The second point that was raised was the use of valuetypes. We used
> valuetypes in the BSA as simple extensible structs. There are a number of
> complete implementations of valuetypes (including RMI-IIOP which Tim
> mentions below) in Java and they are pretty straightforward to implement and
> use. Some simple example would be easy to produce.
>
> I suspect that the real issue is concern over interoperability with Python
> and Perl, hence the simplified IDL. I do agree that this is a problem and
> that until the Python and Perl community fully implement the Corba 2.3 spec
> we'll need to deal with simplified IDL models that don't use the 2.3
> features. This alone may be a compelling argument. I don't want to lose
> access to the work being done in these languages and I very much want to
> support efforts like BioPerl and BioJava.
>
I think the time lines on the valuetypes appearing in the Perl/python orbs
are a long way off. Remember that the Perl orbs only started being usable
about 3/4 months ago to the 2.2/2.0 type specifciation (fnorb for python
has been around much longer). It is likely that the fastest route is via
binding to a C or a C++ orb. However, the nicely portable C/C++ orbs are
few on the ground (ORBit, Ominorb. Anyone who can get ILU to compile
cleanly is a genius in my view). We want to use things **now**.
At best we are talking 6 months to a year away for these orbs. The LSR
standard was deliberately far thinking in its use of valuetypes but that
does mean life is difficult *now* in particular for *academic* usage.
I can't wait a year, and I can't spend this year trying to write/alpha
test someone's orb. I want to do science now.
> Bottom line, I'll go on record as prefering to implement standardized
> approaches where possible as a way to encourage the use of the standards.
> There may be a compelling reason in this case to implement a simplified
> model but where possible I'd prefer to see people coding to the BSA spec and
> not something else. The discussion of multiple levels of interface and BSA
> being the "enterprise" one bothers me unless we can define "enterprise".
Good point.
I guess I meant "enterprise" == commerical
academic == non-enterprise/free-orbs
> When all is said and done I want to see biojava succeed because I think
> efforts like it are important. Maybe I should teach perl to do
> valuetypes.... What orbs are you using on the perl and python side of the
> equation?
>
This would be great ;) but I think you will have an uphill battle. I am
a keen advocate of the CORBA::ORBit bindings. ORBit is fast, lightweight
and portable (C based). No one on the ORBit group want to implement the
2.3 specification - everyone is very happy with the 2.2 specification.
(works for them).
COPE is still stablising, but is much close to stable. Brad mentioned that
he uses Fnorb. No idea what they think of valuetypes.
I *do* think a sensible way of getting the OMG LSR specification to work
with biocorba is a great way to easy the introductory step into CORBA for
this field, acknowledges the limitations of free orbs and gets everyone
on board. I reckon that at the end of the day, once the orbs catch up
and there is alot use of CORBA in the field (and I *am* a CORBA believer
mike. At least I am not advocating SOAP protocols...) then LSR will be the
only one left standing and biocorba will be some internal
interface/disappeared.
But for the moment, let's make this work!
> Mike
>
> > -----Original Message-----
> > From: biojava-l-admin@biojava.org [mailto:biojava-l-admin@biojava.org]
> > Sent: Monday, February 14, 2000 12:00 PM
> > To: biojava-l@biojava.org
> > Subject: Biojava-l digest, Vol 1 #25 - 2 msgs
> >
> >
> >
> > Send Biojava-l mailing list submissions to
> > biojava-l@biojava.org
> >
> > To subscribe or unsubscribe via the web, visit
> > http://biojava.org/mailman/listinfo/biojava-l
> > or, via email, send a message with subject or body 'help' to
> > biojava-l-request@biojava.org
> > You can reach the person managing the list at
> > biojava-l-admin@biojava.org
> >
> > When replying, please edit your Subject line so it is more
> > specific than
> > "Re: Contents of Biojava-l digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: RE: Biojava-l digest, Vol 1 #23 - 4 msgs
> > (timothy_w_slidel@sbphrd.com)
> > 2. SVM (Matthew Pocock)
> >
> > --__--__--
> >
> > Message: 1
> > From: Timothy_W_Slidel@sbphrd.com
> > To: birney@ebi.ac.uk
> > cc: mdickson@netgenics.com, biojava-l@biojava.org,
> > smarkel@netgenics.com
> > Date: Mon, 14 Feb 2000 12:08:36 +0000
> > Subject: Re: [Biojava-l] RE: Biojava-l digest, Vol 1 #23 - 4 msgs
> >
> > Glad to see lots of discussion and good work here. Most
> > implementations of
> > standards are based on adapters to existing code. Short of a direct
> > implementation of CORBA skeletons (which isn't always a good
> > idea if you later
> > chose to change comms model) there's always going to be some level of
> > adaptation. Obvoisuly performance degrades the more
> > adaptations you have. One
> > way to circumvent the internal IDL issue would be to use the
> > RMI over IIOP
> > model, which supports valuetypes (because RMI does
> > pass-by-value), this gives
> > IDL which is more Java-friendly. In the end of the day it
> > doesn't matter how
> > many internal interfaces you have provided the end
> > implementation works,
> > supports the IDL and isn't too slow.
> >
> > The main thing standing in the way of a free BSA IDL impl is
> > the valuetypes -
> > perhaps using RMI/IIOP would solve this problem? There are
> > free implementations
> > of events, naming - so the other services shouldn't be a problem.
> >
> > Tim
> >
> >
> >
> >
> >
> > birney@ebi.ac.uk on 13-Feb-2000 17:20
> >
> >
> >
> > To: mdickson
> > cc: biojava-l, smarkel (bcc: Timothy W Slidel/CIS/PHRD/SB_PLC)
> > Subject: Re: [Biojava-l] RE: Biojava-l digest, Vol 1 #23 - 4 msgs
> >
> >
> >
> >
> >
> >
> > >
> > > I'll be honest, I was fairly disappointed with the
> > emergence of a new
> > > IDL to express sequences. Ewan made a comment on this list
> > suggesting
> > > that an effort to provide a mapping between the LSR model
> > and the new
> > > one might be a nice thing to do. I guess I have an alternate view on
> > > this. If the community at large would like to encourage vendors to
> > > participate in OpenSource/Community Source or general
> > *open* efforts,
> > > it might be better to encourage the the use of the
> > standards work that
> > > has been done instead of continuing to invent alternatives.
> > Of course
> > > most any position can be rationalized and there might be very good
> > > reasons for doing sonmething different. NetGenics' SYNERGY is
> > > different that the LSR model. I *am* commited to migrate to it and
> > > for those things I don't like I'll continue to try to work
> > > constructively for changes. I'd like to believe that others would
> > > make a similar commitment.
> >
> >
> > Mike -
> >
> > I appreciate your concerns and directness.
> >
> > the problem about the LSR model is that it is *simply not friendly* to
> > free and open source CORBA implementations and it requires alot of
> > implementation effort by the server writers to provide something.
> > This puts a high barrier of entry to people using this.
> >
> > (let me remind you that LSR uses alot of valuetypes, which are
> > not available in most free orbs and in particular the perl and python
> > orbs, and the Cos:: definitions, which are both not available in
> > free orbs and pain to implement oneself. The specification is too
> > high, too focused on bought-in components and too focused on
> > enterprise level interoperability to make any sense for academic
> > code interoperability).
> >
> > >
> > > The problem with bridges and adaptors is that as we try to solve
> > > higher order problems that require extensions the adaptor approach
> > > becomes combanitoric. Having a solid base to build on that is
> > > consistent is pretty much a requirement if your goal is
> > > interoperability. Hence my commitment to the LSR.
> >
> >
> > >
> > > The implementation classes used in Synergy will probably
> > mostly stay the
> > > same as we move to the LSR model. That is, we hava strong
> > seperation of
> > > interface and implementation. Having *implementation*
> > centric IDL just
> > > seems silly to me. If you want implementation centric
> > interfaces with Java
> > > as the target language then use Java interfaces for that purpose.
> >
> > I disagree. It is quite sensible to have internal interfaces which
> > represent what is or is not able to do, and why not make them CORBA
> > IDL interfaces? That is what alot of other projects do (eg, GNOME).
> > CORBA does not have to be restricted to an enterprise-only, client
> > friendly interfaces, but can also be used in internal software for
> > server friendly IDLs. CORBA can be used for more than the last mile...
> >
> > I am committed to BSA-LSR, and I want to make it work. When I
> > looked at
> > providing bioperl as a BSA-LSR style set of interfaces I realised the
> > best way to do this was to have internal interfaces which I then built
> > a bridge layer in Java to BSA. *I cannot see any other way of
> > doing this*.
> > (maybe you can). I see no problem in either sharing that idea of an
> > internal interface nor encouraging other people to help write
> > the bridge.
> >
> > If you want to hit the LSR specification directly from bioperl, please
> > tell me how to do it, because I don't think it is possible.
> >
> >
> > >
> > > Sorry for being so direct. That's my style. I've been
> > following biojava
> > > for a little while now and there is some very excellent
> > work being done.
> > > I'd love to see it interoperate and leverage the very
> > excellent work we did
> > > in the LSR. I just have a different idea of how that should happen.
> > >
> > > Mike Dickson
> > > mdickson@netgenics.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
<birney@ebi.ac.uk>
-----------------------------------------------------------------