OpenTox

Architecture overview
in-silico toxicology gmbh blog

The IST OpenTox architecture consists of 3 main layers. OpenTox compliant webservices are the core layer, that provide the functionality for OpenTox classes. Clients (e.g. libraries for various programming languages and command line/graphical user interfaces) interact with webservices and provide interfaces for end users. Webservices may depend on backends for special purposes (e.g. databases, A+A servers, number crunching). Clients should never interact directly with backends.

OpenTox services can run on separate servers (cloud configuration) or on a single machine (standalone configuration) even without internet connection.

Clients:

  • use the OpenTox/ToxBank REST API to communicate with webservices

Examples:

 GUIs: ToxCreate, ToxPredict, lazar, toxbank protocol and investigation GUIs, Bioclipse, …
 CLIs and scripts: validation scripts for algorithm model development, irb using opentox-client, curl, opentox-test, …
 Libraries: e.g. the opentox-client Ruby library

Webservices:

  • use the OpenTox/ToxBank REST API to communicate with other webservices
  • use application specific protocols to communicate with backends (implementation specific and optional)

Examples:

 IST: compound, feature, dataset, algorithm, model, validation, investigation, task)  IDEA: dataset (AMBIT), algorithm, protocol
 TUM: algorithm, model
 NTUA: algorithm, model

Backends:

  • optimized for particular purposes (data storage and retrieval, number crunching, …)
  • never addressed directly from clients or 3rd party webservices
  • one backend may be used for multiple services

Examples:

 IST: {Redis}, 4store, [Rserve], OpenSSO
 External: CACTVS, PubChem
{} IST services that may be removed in the future
[] IST services that may be added in the future

Implementation

IST OpenTox services and applications are implemented in predominately Ruby and distributed as RubyGems. The opentox-client library is a wrapper for the OpenTox API which is used in client applications and webservices. The opentox-server library depends on opentox-client and provides a basic web server infrastructure for web applications and webservices based on the Sinatra framework. It implements common functionality like

  • content negotiation
  • authentication and authorisation
  • configuration handling
  • basic CRUD operations

OpenTox webservices (e.g. compound, feature, dataset, algorithm, model, validation, investigation, task) extend opentox-server.

Tests

OpenTox tests are maintained in a separate package called opentox-test which includes

  • client tests
  • webservice tests
  • integration tests
  • cloud configuration tests
  • standalone configuration tests

The complete test suite in opentox-test is executed once a day for the master and development branch of all webservices.

Configuration

URIs and credentials for webservices and backends are configured in ~/.opentox/config/:

  • default.rb: default configuration for opentox-server
  • {service_name}.rb: overwrite/extends default.rb
  • test.rb: test configuration

Configuration details can be found here.

blog comments powered by Disqus

Published

07 February 2013

Tags