See below... > -----Original Message----- > From: Thomas Down [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 28, 2002 5:56 AM > To: Brian Gilman > Cc: Thomas Down; [EMAIL PROTECTED] > Subject: Re: [Biojava-l] BioJava discussion board > > Hi Brian > > On Wed, Aug 28, 2002 at 12:09:05AM -0400, Brian Gilman wrote: > > > > BioJava does not work well in a distributed environment in terms > > of RMI calls or in the "weservices" stack. Custom > > serializers/deserializers need to be made for each and every object that > > exists in the feature heirarchy. This is painful to say the least. T > > > > Where's the contructor!! There are a lot of factories that make, > > while making client side programming very easy to do, kill a middleware > > guy like myself.
The factory pattern in biojava is very straightforward in my opinion and pretty common. I don't see the connection or issue with middleware programming. In the cases where we have used BioJava it's used on both the client and server as an object model to represent biological objects. It works pretty well for the most part for this. We don't use it as the basis for remote programming and in my opinion that's not a problem since biojava isn't really optimized for that sort of access anyway. Frankly, I'm not sure any single model would be ideal for all of these cases. What I personally believe is missing is a meta-model for all this stuff that can be translated into representational models; whether that be XML, SQL, Java, Perl, what have you. So maybe what we need is a BioUML. This approach is at the heart of the OMG's model driven architecture work and its been used to good effect in at least one case (expression data) in the life sciences group (LSR) within the OMG. > Some stuff deleted... > > So what solutions do we have? > > 1. Come up with an `over-the-wire' API which is based on > data-blobs (like the example Sequence class, above) rather > than complex interfaces and factories. It'll be easy to > bridge from this back to something more like the current > BioJava client API, which remains a client-oriented API. This is my preference for marshalling data over the wire. Its not the whole problem though. See below. > > 2. Bite the bullet and write custom serializers/deserializers > to transform between BioJava and some reasonably neutral > XML representations (which could be shared with Omnigene > and other projects). I know doing this sucks, but at the > end of the day, there aren't /that/ many data types which > need to be shuffled around. It might be the easiest option > to get some really compelling web services up and working > with BioJava. This could be a simple version of #1. Having an AGAVE or BSML (or some other nifty format) serializer could be used in multiple cases one of which would be a JAXM message with an encoded XML document. Its still not clear to me though I'll always want the whole object so really what has to happen first is the remote api's need definition: i.e. what does the web service look like that uses this approach. > > 3? Come up with some scheme of metadata which allows the semantics > of BioJava (and other) interfaces to be defined in enough > detail that they can be serialized and deserialized automatically. > This is really quite similar to option 2, except with a different > language. I'd guess this is the hardest option, but much, in > the future, also be useful for other things -- e.g. auto-generating > database adaptors. This is starting to get to my BioUML comment above and as Thomas indicated if its done right it has a large impact on many other things in the future (like generating database binding from the model, for instance). Personally I think this is where the interesting work is. > > And I guess the final alternative... > > 4. Take a completely different approach, declare the `interface > oriented' BioJava 1 and interesting experiment, and design > BioJava2 in a more `data-blob' fashion. > > Personally, I think (4) would be a great shame. But it undoubtably > would make supporting distributed systems, and using fully-automatic > object persistance solutions, a whole lot easier. So I guess it's > something we should discuss. I agree that punting on the interface based approach would be bad. It's a very valid way to address accessing data and behavior. The data blob approach doesn't really adequately describe the interface contract nor does it easily lend itself to multiple implementations. Personally I'm an advocate of strongly typed, interface driven development. XML has its place but it doesn't replace the kind of programming supported by biojava now. > Thomas. > > > > PS. I think there's a lot in common between the issues discussed here, > and the question of UML class diagrams which came up on the > discussion board yesterday. UML is also more comfortable with > the `data blob' way of doing things. When I wrote the two example > classes in this message, I realized that it would have been > easier to write them in UML than Java. This is not true of most > of the BioJava interfaces. Hmm. Here I rest my case. If we start with a good model we can derive various representations from it. That would be my choice going forward. Mike > _______________________________________________ > Biojava-l mailing list - [EMAIL PROTECTED] > http://biojava.org/mailman/listinfo/biojava-l _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
