Page History
Scrollbar | ||
---|---|---|
|
Page info | ||||
---|---|---|---|---|
|
Section | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Warning | ||
---|---|---|
| ||
Data services are currently were deprecated in LexEVS 6.4.1 and will be removed in 6.5. The Java based remote method invocation will remain available for the time being. |
Introduction
...
These services are replaced by a separate CTS2 compliant web service described in the CTS2 API. |
Introduction
The The focus of documentation will be the Java based LexEVS remote method invocation service.
Info | ||
---|---|---|
| ||
See migration notes below for LexEVS Distributed 6.0, 6.1 to 6.2, 6.3 to 6.4.1, 6.5 |
caCORE LexEVS Components
The caCORE LexEVS API was a public domain, open source web service that provided access to the LexEVS Terminology Service and Data Model. LexEVS supports the CBIIT hosted NCI Thesaurus, NCI Metathesaurus, and other vocabularies. In versions up to LexEVS 6.5 Java clients accessing vocabularies can communicate their requests via the caCORE data services but beyond that only java remote LexEVS APIs will be supported. REST services are still available in a new, standard format as the CTS2 REST API.
The interfaces provided in LexEVS versions up to LexEVS 6.4.1 include a Java API, a SOAP interface, QBE style data model query methods and an HTTP REST interface. These services are separate from the CTS2 REST API.
Interfaces
Main interfaces included in the LexEVSAPI package.
LexEVSService
...
.
Info | ||
---|---|---|
| ||
See migration notes below for LexEVS Distributed 6.0, 6.1 to 6.2, 6.3 to 6.4.1, 6.5 |
LexEVSDistributed
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
...
- Example environment technology includes Java 1.7, 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
Run
Code Block language bash mvn clean install
, 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:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<dependencies> <dependency> <groupId>lexevs.dist.client</groupId> <artifactId>lexevs.dist.client</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> </dependencies> |
...
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):
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
package org.lexgrid.lexevs.remote.client; import org.LexGrid.LexBIG.DataModel.Collections.CodingSchemeRenderingList; import org.LexGrid.LexBIG.DataModel.InterfaceElements.CodingSchemeRendering; import org.LexGrid.LexBIG.Exceptions.LBInvocationException; import org.LexGrid.LexBIG.caCore.interfaces.LexEVSDistributed; import gov.nih.nci.system.client.ApplicationServiceProvider; public class MavenBasedPrototype { LexEVSDistributed lbs = null; private static String serviceUrl = "https://localhost.daplie.com:8443/lexevsapi64"; public void run() throws LBInvocationException{ try { lbs = (LexEVSDistributed)ApplicationServiceProvider.getApplicationServiceFromUrl(serviceUrl, "EvsServiceInfo"); } catch(Exception e){ System.out.println("Starting LexEVS Remote Client fails" + e); } CodingSchemeRenderingList list = lbs.getSupportedCodingSchemes(); for(CodingSchemeRendering rendering: list.getCodingSchemeRendering()){ System.out.println(rendering.getCodingSchemeSummary().getFormalName()); } } public static void main(String[] args) { try { new MavenBasedPrototype().run(); } catch (LBInvocationException e) { e.printStackTrace(); } } } |
...
Explanation of statements explains specific statements in the code by line number.
Line Number | Explanation |
---|---|
4 | Creates an instance of a class that implements the LexEVSApplicationService interface. This interface defines the service methods used to access data objects. |
7 | Construct the Query By Example Object and populate it with the desired search critieria. For this example, seach for any 'Entity' with an 'entityCode' attribute equaling 'C1234'. |
9 | Calls the search method of the LexEVSApplicationService object. |
The following example is a Query By Example with Query Options.
...
Explanation of statements explains specific statements in the code by line number.
Line Number | Explanation |
---|---|
4 | Creates an instance of a class that implements the LexEVSApplicationService interface. This interface defines the service methods used to access data objects. |
7 | Construct the QueryOptions Object. |
8 | Populate the QueryOptions with the desired Coding Scheme. |
9 | Construct a CodingSchemeVersionOrTag Object. |
10 | Populate the CodingSchemeVersionOrTag Object with the desired Version. |
11 | Populate the QueryOptions with the above CodingSchemeVersionOrTag Object. |
12 | Construct the Query By Example Object and populate it with the desired search critieria. For this example, seach for any 'Entity' with an 'entityCode' attribute equaling 'C1234'. |
14 | Calls the search method of the LexEVSApplicationService object, along with the QueryOptions. |
Warning | ||
---|---|---|
| ||
Web Services API |
...
The following table explains the syntax, indicates whether specific elements are required, and gives examples.
Element | Meaning | Required | Example | |||||
---|---|---|---|---|---|---|---|---|
| Name of the Web server on which the caCORE LexEVS 6.0 Web application is deployed. | Yes |
| |||||
| URI and name of the servlet that will accept the HTTP GET requests. | Yes |
| |||||
| Class name indicating the type of objects that this query should return. | Yes |
| |||||
| Search request criteria describing the requested objects. | Yes |
| |||||
| Starting index of the result set (Zero based). | No |
| |||||
| Restrict the query to a specific Coding Scheme Name. | No | {{codingSchemeName=NCI_Thesaurus }} | |||||
| Restrict the query to a specific Coding Scheme Version. | No
|
|
The caCORE LexEVS architecture currently provides two servlets that accept incoming requests:
...
The following table explains the syntax for criteria statements and gives examples.
Parameter | Meaning | Example |
---|---|---|
| The name of a class. |
|
| The name of an attribute of the return class or an associated class |
|
| The value of an attribute. |
|
Examples of Use
The examples in the following table demonstrate the usage of the XML-HTTP interface. In actual usage, these queries would either be submitted by a block of code or entered in the address bar of a Web browser.
Info | ||
---|---|---|
| ||
The servlet name GetHTML in the examples is used for placement into a browser address bar. It would be replaced with GetXML for use in an application. |
Query |
| ||
---|---|---|---|
Semantic Meaning | Find all objects of type Entity that contain an 'entityCode' matching the pattern 'C123*'. |
Working with Result Sets
Because HTTP is a stateless protocol, the caCORE LexEVS server cannot detect the context of any incoming request. Consequently, each invocation of GetXML or GetHTML must contain all of the information necessary to retrieve the request, regardless of previous requests. Developers should consider this when working with the XML-HTTP interface.
...
Info | ||
---|---|---|
| ||
When specifying attribute values in the query string, note that use of the following characters generates an error: |
Scrollbar | ||
---|---|---|
|