Virtual Cell - Technology

National Resource for Cell Analysis and Modeling

Software Architecture

The Virtual Cell distributed software architecture, pictured below, has an an overall modular structure with remote clients, database servers, compute nodes, simulation data storage, etc. This facilitates the independent development of the individual services, which in turns enables the easy maintenance and growth of the architecture. The figure depicts the main software components and their interactions with each other.

(Click on Image for larger image.)

Client Architecture
The Client Application consists of the user interface to the Virtual Cell software and the backend services on the client side available on the user's computer. The Virtual Cell user is the client making requests to the Virtual Cell server via the internet.

• User Interface - graphical component which allows the user to enter the required information needed for running the Virtual Cell software and displays the information requested from the server, i.e. simulation results. The user interface includes the Physiology Editor which is used to specify and modify the physiological model; the Application Editor where the user can specify the geometry, boundary conditions, initial conditions, electrical mappings, parameters, etc for the physiological model; the Geometry Editor where the geometry can be created and/or modified; and the Simulation Editor which manages the simulation settings.
• Math Generation Service - a client-side service, generates the Math Description from an Application, and this service is invoked when the physiological model is saved or a simulation is run.
• Connection Service

These client services are can be configured either as remote services or as stand-alone applications. The currently deployed Virtual Cell software versions are deployed as a distributed client-server architecture.

Server Architecture
The server-side component protocols are based on message-oriented middleware. There is no direct communication among the different services. Instead, the services subscribe and post messages to message queues with the message execution status being recorded in a relational database. The following services comprise the server-side application of the Virtual Cell.

• Database Service - consists of multiple interface to perform simple object perisistence operations such as loading, saving, updating, deleting, querying of objects.
• Simulation Data Service - is used to retrive simulation results upon client requests. Minimization of network traffic is acheived by caching and data reduction.
• Data Export Service - service responsible for packaging user-selected simulation data into user-selected export format for use outside the Virtual Cell.
• Simulation Dispatch Service - used to schedule and enforce user quotas for simulation jobs and monitor the status of running simulations.
• Simulation Worker Services - are used to dispatch simulation jobs. There are different types of worker servers: some of the worker services handle the ODE simulation jobs, where the ODE simulation is run directly on the service or invokes a precompiled solver executable with the generated solver input files. The services that handle PDE jobs generate and compile platform-specific solver code which is submitted along with the corresponding solver input files to a batch scheduler. Some of the local and grid-based batch scheduler middleware that are supported are: PBS Professional and Condor-G. The worker service implementations are designed such that the services themselves are submitted as jobs to the batch scheduler middleware. This ensures a fully-automated load-balancing architechture.
• JMS Broker (SonicMQ) - is our Messaging Oriented Middleware. It is implementation of The Java Message Service which is a messaging standard that allows application components based on Java to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous. Our services communicate through SonicMQ instead of directly to each other to guarantee a stateless and transactional system.
• Batch Scheduler (PBS) - PBS Pro is our workload management system in which simulations are distributed across our 86 node/320 CPU cluster.
• Connection Manager - Remote Method Invocation (RMI) server authenticates the client and creates connection to the server by sending client requests (such as saving model, running simulations) to SonicMQ.
• Server Manager - monitors all the services and restart services automatically if they don't respond.
• Database (Oracle) - is the database of choice to store all the models created in the Virtual Cell.
• Storage Cluster - is the Isilon clustered storage where all the simulation results are stored.

Technology		Modeling Process
Software Architecture		Modeling Framework
Math Framework		User Interface
Testing Framework		VCML Specification