{scrollbar:icons=false}

Page info
title title

LexEVS 6.1 Specific Architecture Overview

Refer to LexEVS 6.1 Design Document.

caBIG LexEVS Architecture Overview

LexEVS software architecture and implementation is designed to facilitate flexibility and future expansion in the caBIG community. The purpose of LexEVS is to enable individual Cancer Centers to use the provided caCORE EVS services and if desired, install local instances of vocabularies.

The figure below that follows shows the following components pointing to the caBIG Grid:

...

• Application Service Layer - accepts incoming requests from all public interfaces and translates them, as required, to Java calls in terms of the native LexEVS API. Non-SDK queries are invoked against the Distributed LexEVS API, which handles client authentication and acts as proxy to invoke the equivalent function against the LexEVS core Java API. The caGrid and SDK-generated services are optionally run in an application server separate from the Distributed LexEVS API.
  The LexEVS caCORE SDK services work directly against the database, via Hibernate bindings, to resolve stored objects without intermediate translation of calls in terms of the LexEVS API. However, the LexEVS SDK services do still require access to metadata and security information stored by the Distributed and Core LexEVS API environment to resolve the specific database location for requested objects and to verify access to protected resources, respectively.
  From the client prospective, the LexEVS services will function as "ports" accessible through the caGrid 1.3 service architectural model. LexEVS services will follow the caGrid architecture for analytical and data services. See the caGrid 1.3 documentation for architectural details.
• Core API Layer - underpins all LexEVS API requests. Search of pre-populated Lucene index files is used to evaluate query results before incurring cost of database access. Access to the LexGrid database is performed as required to populate returned objects using pooled connections.
• Data Source Layer - is responsible for storage and access to all data required to represent the objects returned through API invocation.

LexEVS 6.x High-level Design Diagram

The figure below that follows shows the following components of the Architecture Diagram:

...

The LexEVS CTS 2 API provides programmatic access to LexEVS 6.x implementation of the preliminary CTS 2 features and services. (For LexEVS 6.1 Query mechanisms have been implemented in REST based architecture and are fully compatible with the CTS2 Normative specification.  This deprecates the work against the preliminary CTS2 SFM, but useful features for authoring and versioning have been left in place.)

Documentation can be found here Refer to LexEVS 6.0 CTS2 API for the documentation.

LexEVS API/Grid Service Interaction

...