VCell Architecture Notes

vcell architecture is evolving. Here are some of our goals.

• VCell RESTful API (module vcell-api) has completely replaced our RMI service for all client-server communication (coarse-grained, versioned API). However, many calls still depend on Java Serialization; coupling client-server software versions.
  • refactor all client-server communication according to RESTful principles and API versioning.
  • completely document API using Open API.
  • spawn off module vcell-apiclient as a lightweight client-side library (eventually generated using Open API tools).
  • support multiple clients (vcell-client, vcell-imagej, web applications, third-party tools and scripts).
  • use standard reverse proxy for HTTP/TLS and JSON/XML for load balancing and caching.
  • use an API Gateway / API Management tool such as WSO2 (with a reverse proxy) for reporting, quality of service, filter invalid requests, and provide an on-boarding platform and OpenAPI-based service discovery.
• Simplify simulation job reporting and job management (for scalability and flexibility). Current solution of jobs reporting status via messaging (ActiveMQ) provides very good job management but is difficult to scale. Introduced separate ActiveMQ instance for Simulation Messages as first step in migration to new solution.
• All VCell services are packaged as microservices using Docker and orchestrated with Docker swarm mode. Planned migration to Kubernetes orchestration).
• Redesign data access framework (resurrect prior next generation design) - with support for local and cloud storage.