Sesame is a versatile, freely available, multi-tier laboratory information management system (LIMS) that is in use in multiple laboratories around the world both for small-scale and large-scale applications. It supports the gathering, organization, processing, and analysis of information from a variety of sources, including databases, bench scientists, laboratory instrumentation, and software packages.
Sesame has proved its value in structural and functional proteomics investigations, in traditional protein chemistry or molecular biology laboratories, and in management of shared instrumentation facilities. It enables collaborators to participate in a research project, with equivalent access to information and the ability to enter results and process data irrespective of location (given Internet access).
The Sesame software is written in Java, uses CORBA as a middleware, and is interfaced to a relational database management system.
The Sesame dictionary is a superset (at a field level) of the most recent data dictionaries used by the NIH antibodies portal, and by the TargetTrack, the NIH structural biology database that provides information on the experimental progress of targets selected by the PSI centers and other worldwide structural biology projects. Thus, the laboratories that use Sesame are well positioned to contribute to TargetTrack and to use the information imported from it.
Typical LIMSs are workflow centric and rigid in that sense. By contrast, Sesame is built around (data) objects (e.g. primer, protein, screen, protocol, etc.), that can be linked to each other with no restriction; thus any workflow can be implemented and tracked. In addition, data objects in Sesame can be used independently from each other, so that, for example, a lab can use Sesame to track their samples and also to build up a pdf library.
Innovative projects command innovative solutions and quick development. We feel that all the effort we have put over years into the design and development of the Sesame framework has paid off, as it has allowed us to keep up with the needs of the users. The continuous development of Sesame enables us to respond to their current and future needs and assist in the discovery of new science. Contact Us!
In our analysis leading to the design of the software system, we concluded that the architecture that best fulfills the above requirements is based on the multi-tier client/server paradigm. This architecture is scalable. In a small Sesame instance, all three tiers can reside on a single computer and support a typical academic laboratory. In a large Sesame instance (such as the current installation in Madison), the second and third ties can spread across multiple high-performance computers interconnected by high-speed connections and fronted by load balancers so as to support multiple laboratories, big centers, institutes, and a large number of individual researchers worldwide.
Depending on the number of simultaneous users and the amount of data in database and file servers, Tier 2 or Tier 3 can be scaled up as needed. For example, an increasing number of simultaneous users can be handled, up to a point, by increasing the resources of the second tier servers; beyond that, it will be necessary to add new servers to run additional instances of the second tier.
By contrast, the client computers (Tier 1) don’t have to be high performance machines. The client computers load (from the network servers) and execute only the client (light) part of a distributed application, while the server part is executed on the network application servers, and the data are fetched from a database and/or files that reside on the storage servers.
Because users access Sesame through the Internet, the system is available at any time to collaborators located anywhere in the world.
Cloud LIMSs like Sesame balance flexibility and ease of use with standardization. The individual (virtual) labs can tailor their settings to best suit their needs while the users can employ different computer platforms.
Currently, the Sesame LIMS consists of nine Modules: Sheherazade is the structural and functional genomics/biology module, Sundial is the spectrometer time request and schedule module, Lamp is the metabolomics module, Jar is the target request module, Well is the Crystallization and Cryo-EM module, Camel is the NMR spectroscopy module, Rukh if for yeast two-hybrid, combinatorial, and mutant virus screens, Bazaar is the lab administration module, Jafar is the TargetTrack and 2D Crystallization Conditions browsing module.
The Sesame Modules are deployed using the Java Web Start technology (from the Sesame homepage), and they will run on any computer with an up-to-date Java Runtime installed. All Sesame Modules become available for use at the moment they are deployed at a particular installation. Whenever users access Sesame, they always are presented with the latest released version. During start-up of a Module, Java Web Start first checks to determine if the locally cached version is older than the version on the server. If yes, the new version is downloaded first; if not, the cached version is run. Hence, Sesame users never have to explicitly perform an upgrade.
Sesame was designed to support multiple, overlapping projects (multiple projects involving individual scientists or many collaborators located at the same or separate sites who may be working on more than one project).
Each user registers during their first access to the system, choosing a user name and password and supplying their full name, e-mail and organization. Every user is by default assigned to the ‘World’ lab, the parts of Sesame that are visible to anyone.
A lab in Sesame may represent a center, facility, research laboratory, or research project and may consist of from one to any number of members. Any user can create multiple labs and be a member of labs created by others.
In a typical scenario, a Principal Investigator (PI) initiates a Sesame lab by designating a member of his laboratory to be the ‘Lab Master’, who then creates the virtual lab by defining its name. Members of the PI’s physical lab are asked to register as users with Sesame and are then invited to join the lab created by the Lab Master. Individual users may accept or reject the invitation. Sesame users may leave a virtual lab or be removed by the Lab Master at any time.
The Lab Master handles the configuration of the Sesame lab, i.e. defines and maintains the membership and the lab resources. Some of the lab resources are: item status, lab protocols, plates, source organisms, barcode and label definitions, locations (room, freezer, rack, shelf), plasmid components (plasmid source, tag, cleavage, etc.), mass spectrum type, stock solutions (precipitant, salt, buffer, additive, cryoprotectant, etc.), robot racks, crystal scores, etc. The lab resources are only modifiable by the Lab Master; however, by using the ‘Can Do’ resource, the Lab Master can delegate the maintenance of different lab resources to different lab members. This imparts extraordinary flexibility to the system and enables virtual labs to adapt to changes/differences in the associated real-world labs.
Objects attributed to a given lab are visible to all lab members, and only to them. Lab data are not visible to anyone outside of a lab. While Sesame users can belong to multiple labs, at a time, they are sandboxed to the user selected ‘default lab’. Records created in a lab, the default lab, belong to the given lab, and they cannot be moved to a different lab.
Inside a lab, each record (e.g. sample) is owned by the user who created it. The editability of the fields by the other lab members depends on the lab policy, and it can be set for individual lab members or for the whole lab, for every item type. For example, the actions, info, location, and images fields in the sample view can be modified by any lab member, whereas everything else is only owner-modifiable. By default, all fields are editable by every lab member. Independently of the editability policy, lab members can always copy a non-owned record, and then modify the newly created record for their own use. Only the owner can delete a record. If a user’s membership to a lab is severed, access to the records owned in the particular lab will also be severed.