- 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 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.
- Core API Layer - Local Java API implementation that 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.
- Clients: Local, Distributed, and caGrid clients, and SOAP, REST, QBE Clients.
- Application Service: CTS2 (LexEVS Local Runtime), Distributed LesEVS, LexEVS caCORE API's.
- Core API: LesEVS Model Objects Extended for CTS 2 = > DAO
- Indexes and Data Source: Lucene Index Files and LexGrid DB
- Optional Arangodb support for high speed graph resolution of terminology hierarchy and relationship graphs