Data Services are Deprecated in 6.4
Data services were deprecated in LexEVS 6.4.1 and removed in 6.5. The Java based remote method invocation will remain available for the time being.
These services are replaced by a separate CTS2 compliant web service described in the CTS2 API.
The focus of documentation will be the Java based LexEVS remote method invocation service.
See migration notes below for LexEVS Distributed 6.0, 6.1 to 6.2, 6.3 to 6.4.1, 6.5
The Distributed LexEVS Portion of LexEVSAPI extends a subclass of, or in 6.5 and later, implements LexEVSService. This interface is a framework for calling LexEVS API methods remotely, while enforcing restrictions on proprietary content. JavaDoc
This is the only caCore API available in 6.5
This exposes the LexEVS Service model via a Remote Method Invocation service.
LexEVS Installation and Configuration
The distributed LexEVS API is strictly a Java interface and requires Internet access 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
Using the distributed LexEVS API
Example code can be found at the above client project link for a number of use cases.
For versions 6.4.1 and above the distributed java client features a mavenized project. This client has a large dependency set. Maven simplifies dependency resolution. Cloning and building the Client project provides a local maven repository version of the client jar and pom.
Step by step instructions for integration into a maven project in an eclipse environment:
- Example environment technology includes Java 1.8, Maven 3.2.3, Git, and Eclipse Neon or some other maven enabled Eclipse IDE.
- This example assumes some familiarity with Eclipse and Maven.
- Run git clone https://github.com/lexevs/LexEVS_Distributed_Client.git
- Change working directory to LexEVS_Distributed_Client
, if tests fail you may add -DskipTests
- Create a new Java Project in Eclipse
- Configure as a Maven project
- Add as dependency to the pom file:
Users should be able to access a remote service with code similar to the following (Service URL should be adjusted to a valid LexEVS API service such as the one hosted at NCI):
The LexEVS API is exposed by the LexEVS caCORE System for remote access through the caCORE System's
LexEVSApplicationService class which implements the
The distributed LexEVS API environment will be configured on the LexEVS Server currently at (https://lexevsapi6.nci.nih.gov/lexevsapi64/).
To address LexEVS DAOs, the LexEVS API integration incorporates:
- Java annotation marking methods that can be safely executed on the client side
- This includes classes that can be passed to the client without being wrapped by a proxy
- 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) used to proxy the LexEVS classes and intercept calls to methods based on annotations.
- The LexEVS client wraps every object returned by the LexBIGService inside an AOP Proxy with advice from a LexBIGMethodInterceptor ("the interceptor").
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.