This is especially the case for simple types such as integers and doubles. Array access can be optimized at the module if it is known that the data type has a fixed size. The header is therefore (2 + 4 + 4d) bytes long, where d equals the number of dimensions of the array. Arrays start with a header made up of one byte indicating the data type stored in the array, and an integer indicating the number of dimensions, followed by a sequence of integers, one for each dimension, denoting the number of elements in each dimension.
The remainder of the data consists of the sequence of characters that make up the string which is also null terminated.Īrrays are multi-dimensional objects of arbitrary size containing homogeneous data. The string itself is made up of an unsigned 32-bit integer denoting the number of bytes in the string. The string data type has the following structure. Integer and double data types have the following structures. Boolean types are represented in exactly the same way as a byte type, the value of the byte when set to zero represents false and a value of one true. For example the data type byte, actually comprises of two bytes, one byte to indicate that the following type is a byte and the data byte itself. SBW supports seven basic data types: byte, boolean, integer (32-bit), double (64 bit), string, array and listĮach data type is proceeded by a type type to indicate the type of data that follows. This work is and was supported through the generous support of NIH, DARPA and the DOE The workload for the second developer is greatly reduced, and they can instead concentrate on novel functionality. Thus, a particular tool may expose a time-dependent simulation interface from a simulation tool, another tool developer-rather than invent another simulation tool-can exploit this capability and develop a new tool that can carry out additional functions. All a developer need know is the interface that the tool exposes. This means that a developer can now build on previous work without having to understand in detail the often intricate internal workings of other tools. The workbench allows different tools to expose programmatic functionality to other tools.
Our attempt to resolve this has been to develop a software framework called the System Biology Workbench.
This standard is called Systems Biology Markup Language (SBML) Along with CellML (the introduction of a standard format is beginning to make a significant impact on tools writers, and the majority of the most widely used tools now employ SBML as a means to exchange models.Ĭode Reuse The second issue is more difficult to address, that is how to encourage code reuse in the community. Model Interchange The first problem, that of model exchange, has been addressed by introducing a standard format for all tool writers to employ. As a result, the community has seen much duplicated effort. Unlike other software development communities, there is little tradition of code reuse in the system biology community. As a result, many of the tools provide similar functionality. Writing simulation tools takes time, and many of the projects are short-lived, which means that the authors are unable to develop the tools very far. The second problem is that many of the tools duplicate each other's capabilities. This obviously hinders the free exchange of models from one tool to another.Ģ. The result is that a model saved in one tool cannot be loaded into another. Each tool uses its own format, often undocumented, to store models. Though welcome in many respects, this proliferation has resulted in two unwelcome side effects:ġ. This proliferation of tools has resulted in a variety of capabilities and interfaces. The interfaces to the system are encapsulated in client-side libraries that we provide for different programming languages.Īt the last count, there were over 250 different packages for simulating cellular networks (see ).
SBW enables applications (potentially running on separate, distributed computers) to communicate via a simple network protocol. Our goal was to create a simple, high performance, open-source software infrastructure which is easy to implement and understand. The Systems Biology Workbench (SBW), is a software framework that allows heterogeneous application components-written in diverse programming languages and running on different platforms-to communicate and use each others' capabilities via a fast binary encoded-message system. Researchers in quantitative systems biology make use of a large number of different software packages for modeling, analysis, visualization, and general data manipulation.