 |
Page History
...
LexEVS software architecture and implementation is designed to facilitate flexibility and future expansion in the terminology services research community. The purpose of LexEVS is to enable individual Cancer Centers and others to use the provided EVS services and if desired, install local instances of vocabularies.
The figure that follows shows the following components, initially designed to use the caBIG Grid:
- caBIG Nodes
- Partial Online Replica
- Local Replica
- NCI
History and Definition
...
LexBIG is the set of services that EVS adapters use to store/retrieve terminology metadata. LexBIG is a more specific project that applied LexGrid vision and technologies to requirements of the caBIG® research community. The goal of the project is to build a vocabulary server accessed through a well-structured application programming interface (API) capable of accessing and distributing vocabularies as commodity resources. The server is to be built using standards-based and commodity technologies. Primary objectives for the project include:
...
The LexEVS 6.x infrastructure exhibits an n-tiered architecture with client interfaces, server components, domain objects, data sources, and back-end systems (Figure 1.1). This n-tiered system divides tasks or requests among different servers and data stores. This isolates the client from the details of where and how data is retrieved from different data stores.
...
- 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 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.
...
Additional specifications related to the registration and discovery of LexBIG services in the caGRID environment will be included later phases of work in concordance accordance with caGRID 1.0.
Service Management Subsystem
...
