Forums

Michael Hucka wrote:
> Let me throw out another idea about this.
>
> Suppose (hypothetically speaking :-)) that we were to
> introduce a web service for libSBML [+], and produce a pure
> Java version that is *not* a *complete* reimplementation,
> but instead called on the web service version for certain
> complex operations such as model validation, unit analysis,
> etc. My thinking is that this would address multiple
> problems:
>
> 1) It would permit a pure java implementation
>
> 2) It would do it without incurring the implementation and
> maintenance cost of reproducing the entire libsbml code
> base. There would still be only one code base for some
> of the really hairy bits that are also the most worrisome
> from the standpoint of ensuring identical behavior.
>
> 3) It would also make the pure java deployable smaller in
> size than a full libsbml java implementation would be.
>
> Downsides:
>
> 1) Some of the libsbml functionality in the pure java
> version would require a network connection to use.
> We'd be careful to make them only things that have to be
> deliberately called, not common operations.
>
Great idea to have a web-service, I was about to propose that as well
but was thinking also to have few native call for these complex operations.
In fact, we could have both, with some configuration options to use
either webservice, native or nothing (with some lost of functionalities).

Looking at some JNI documentations, I think there is room for
improvement if we do few native call but it will still be difficult to
have something rock solid.
http://en.wikipedia.org/wiki/Java_Native_Interface#Pitfalls "subtle
errors in the use of JNI can destabilize the entire JVM in ways that are
very difficult to reproduce and debug"
http://java.sun.com/docs/books/jni/html/pitfalls.html#25706

> 2) It wouldn't solve the problem of having to implement
> Level 3 packages twice. (You wouldn't want to implement
> them only in the libsbml core and then make all of it
> accessible over the web service; the point of the
> approach being proposed here is that *most* of the
> libsbml functionality would be in the pure java client.
> I don't see that L3 packages would not be sufficiently
> heavy to qualify.)
>
> We would have to figure out which operations are most
> worthwhile doing via the web, balancing the size of data
> transfer involved versus the complexity of the code in
> libsbml that would be saved from reimplementation. I also
> have ideas for how to provide a high-availability facility
> for the web service, so that people wouldn't all have to hit
> a single server sitting under my desk at Caltech :-).
>
> This seems like a workable compromise, no?
>
>
Yes, having the SBML objects as pure java objects, manipulate the
objects and the functionalities to read and write SBML files with a
small jar would be perfect.

> Can people try to think about the weaknesses and shot holes
> into this scheme? Likewise, if there are some additional
> clever hacks we could do, please mention them. If we're
> going to write a grant proposal to get more developers to do
> this, we'd better know about possible counter-arguments now.
>
An obvious weakness is having to pass big SBML files trough the network
that is why, it would be important I think,
to have a web-service that can be installed locally and/or the
possibility to call an equivalent interface using native call.

Nico

> Footnotes:
> [+] Frank Bergmann already provides a web service system
> exposing much of the libSBML API. The web service proposed
> here would admittedly replicate a significant chunk of that.
> However, it would do it in different ways, so it would not
> be an identical system.
>
>

____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu