Forums

Afternoon all,

To those who are interested, the following paper may be relevant to
this discussion:

http://bioinformatics.oxfordjournals.org/cgi/content/full/24/2/287

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
England

On 23 May 2009, at 16:40, Oliver Ruebenacker wrote:

> Hello,
>
> I love the pure Java plus web service idea!
>
> (1) VCell is already based on web service, so another web service
> would add not much difficulty. Users webstart the client from
> vcell.org and connect to the VCell servers.
>
> (2) The stand-alone version of the Systems Biology Linker (SyBiL),
> which uses BioPAX to build and annotate SBML models, uses only a small
> subset of SBML, which means there is not much need for verification
> beyond what the libSBML API already provides. Also SyBiL depends on
> the Jena Semantic Web Framework, which includes already XML support
> (Xerces), which makes it unfortunate that libSBML needs to bring in
> its own XML support.
>
> (3) I expect that in a few years, most users will sit in front of
> light-weight terminals and have most of their computational needs
> served over the Internet. Applications depending on libSBML -
> regardless of which mode or variant, Java or C++ - will run almost
> exclusively on servers. Clients will do little more than translating
> between user interface, data and communication with the server.
>
> Take care
> Oliver
>
> On Thu, May 21, 2009 at 6:23 AM, Nicolas Rodriguez
> <rodrigue@ebi.ac.uk> wrote:
>> 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
>>
>>
>
>
>
> --
> Oliver Ruebenacker, Computational Cell Biologist
> BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
> Center for Cell Analysis and Modeling
> http://www.oliver.curiousworld.org
> ____________________________________________________________
> 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
>

____________________________________________________________
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