Page History

...

Overview

In place of the existing EVS 3.2 object model, caCORE LexEVS is making a gradual transition toward a pure LexEVS back-end terminology server and exposure of This exposes the LexEVS Service object model. caCORE 3.2 and earlier required a custom API layer between external users of the system and the proprietary Apelon Terminology Server APIs. With the transition to LexEVS, caCORE LexEVS can publicly expose the open source terminology service API without requiring a custom API layermodel via a Remote Method Invocation service.

Architecture

The LexEVS API is exposed by the LexEVS caCORE System for remote , distributed access as shown in the figure below. The caCORE System's LexEVSApplicationService class implements the LexBIGService interface, effectively exposing LexEVS via caCORE.

Since in many cases the objects returned from the LexBIGService are not merely beans, but full-fledged data access objects (DAOs), the caCORE LexEVS client is configured to proxy method calls into the LexEVS objects and forward them to the caCORE server so that they execute within the LexEVS environment. The following figure shows the DLB distributed LexEVS architecture (caCORE => Application Service === Spring Remoting === caCORE Server => LexBIG Client = >LexBIG Datastore).

The Distributed The distributed LexEVS API environment will be configured on the caCORE LexEVS Server currently at (http://lexevsapi60lexevsapi6.nci.nih.gov/lexevsapi60). This will give the server access to the LexEVS database and other resources. The client must therefore go through the caCORE LexEVS server to access any LexEVS datalexevsapi64).

LexEVS Annotations

To address LexEVS DAOs, the LexEVS API integration incorporated the addition of (1) incorporates:

• Java annotation marking methods that can be safely executed on the client side

...

• classes that can be passed to the client without being wrapped by a proxy. The annotation is named @lgClientSideSafe. Every method in the LexEVS API that is accessible to the caCORE LexEVS user had to be considered and annotated if necessary.

...

...

• Spring Aspect Oriented Programming (AOP) to proxy the LexEVS classes and intercept calls to their methods.
• The

...

• LexEVS client wraps every object returned by the LexBIGService inside an AOP Proxy with advice from a LexBIGMethodInterceptor ("the interceptor").

The following graphic shows a sequence diagram showing method interception. The interceptor is responsible for intercepting all client calls on the methods in each object. If a method is marked with the @lgClientSideSafe annotation, it proceeds normally. Otherwise, the object, method name, and parameters are sent to the caCORE LexEVS server for remote execution.

...

LexEVS Installation and Configuration

The DLB distributed LexEVS API is strictly a Java interface and requires Internet access for remote connectivity to the caCORE LexEVS server. Access to the DLB API requires access to the lexevsapi-client.jar file, available for download on the NCICB Web site. The lexevsapi-client.jar file needs to be available in the classpath.for remote connectivity to the caCORE LexEVS server. 

Client configuration is represented in a client project in github:  https://github.com/lexevs/LexEVS_Distributed_Client

Example: Using the

...

distributed LexEVS API

The following code sample shows use of the DLB API how to retrieve the list of all available coding schemes in the LexEVS repository.

...