[Biojava-l] LSR BSA is hard
Dickson, Mike
mdickson@netgenics.com
Mon, 14 Feb 2000 18:10:03 -0500
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.
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.
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".
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?
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
> >