 |
Page History
...
The caCORE LexEVS API was a public domain, open source wrapper web service that provides full access to the LexEVS Terminology ServerService and Data Model. LexEVS supports the CBIIT hosted NCI Thesaurus, NCI Metathesaurus, and several other vocabularies. In versions up to LexEVS 6.5 Java clients accessing vocabularies can communicate their requests via the open source caCORE data and services but beyond that only java remote LexEVS APIs .will be support
The open source interfaces provided as part of caCORE in LexEVS versions up to LexEVS 6.0 4 include a Java APIsAPI, a SOAP interface, QBE style data model query methods and an HTTP REST interface. The Java APIs are based on the EVS 3.2 object model and the LexEVS Service object model.
The EVS 3.2 model, exposed as part of caCORE 3.2, has been re-released with LexEVS as the back-end terminology service in place of the proprietary Apelon DTS back end. The SOAP and HTTP REST interfaces are also based on the 3.2 object model. The SDK 4.0 was used to generate the EVS 3.2 Java API, as well as the SOAP and HTTP REST interfaces.
The only difference between the EVS 3.2 API exposed as part of the caCORE LexEVS 6.0 and the API exposed as part of caCORE 3.2 is the back-end terminology server used to retrieve the vocabulary data. The interface (API calls) are the same and should only require minor adjustments to user applications.
| Info | ||
|---|---|---|
| ||
You cannot integrate caCORE 3.2 components with caCORE LexEVS 6.x. If you used multiple components of caCORE 3.2 (for example, EVS with caDSR), you need to continue to work with the caCORE 3.2 release until the other caCORE 4.0 components are available. |
With caCORE LexEVS 6.x, a proxy layer called Distributed LexEVS API enables Distributed API clients to access the LexEVS API from anywhere.
Interfaces
Main interfaces included in the LexEVSAPI package.
LexEVSService
The Main LexEVSAPI Interface. JavaDoc
LexEVSDistributed
The Distributed LexEVS Portion of LexEVSAPI. This interface is a framework for calling LexEVS API methods remotely, along with enforcing security measures. JavaDoc
| Add Page | ||||||
|---|---|---|---|---|---|---|
|
LexEVSDataService
| Warning | ||
|---|---|---|
| ||
See the CTS2 API for REST Services |
The caCORE-SDK Data Service Portion of LexEVSAPI. This extends the caCORE ApplicationService to provide additional direct to database query options. JavaDoc
Search Paradigm
The caCORE LexEVS architecture includes a service layer that provides a single, common access paradigm to clients that use any of the provided interfaces. As an object-oriented middleware layer designed for flexible data access, caCORE LexEVS relies heavily on strongly typed objects and an object-in/object-out mechanism.
Accessing and using a caCORE LexEVS system requires the following steps:
- Ensure that the client application has access to the objects in the domain space.
- Formulate the query criteria using the domain objects.
- Establish a connection to the server.
- Submit the query objects and specify the desired class of objects to be returned.
- Use and manipulate the result set as desired.
caCORE LexEVS systems use four native application programming interfaces (APIs). Each interface uses the same paradigm to provide access to the caCORE LexEVS domain model, with minor changes specific to the syntax and structure of the clients. The following sections describe each API, identify installation and configuration requirements, and provide code examples.
The sequence diagram in Sequence diagram - caCORE 4.0 LexEVS API search mechanism illustrates the caCORE LexEVS API search mechanism implemented to access the NCI EVS vocabularies.
Querying the System
LexEVS conforms to the caCORE SDK API - for more information see caCORE SDK 4.1 Programmer's Guide.
QueryOptions
QueryOptions are designed to give the user extra control over the query before it is sent to the system. QueryOptions may be used to modify a query in these ways:
These services are separate from the CTS2 REST API.
Interfaces
Main interfaces included in the LexEVSAPI package.
LexEVSService
Legacy caCORE Interface. Interface methods are deprecated after LexEVS 6.4. JavaDoc
LexEVSDistributed
The Distributed LexEVS Portion of LexEVSAPI. This interface is a framework for calling LexEVS API methods remotely, along with enforcing security measures. JavaDoc
| Add Page | ||||||
|---|---|---|---|---|---|---|
|
LexEVSDataService
| Warning | ||
|---|---|---|
| ||
See the CTS2 API for REST Services |
The caCORE-SDK Data Service Portion of LexEVSAPI. This extends the caCORE ApplicationService to provide additional direct to database query options. JavaDoc
Search Paradigm
The caCORE LexEVS architecture includes a service layer that provides a single, common access paradigm to clients that use any of the provided interfaces. As an object-oriented middleware layer designed for flexible data access, caCORE LexEVS relies heavily on strongly typed objects and an object-in/object-out mechanism.
Accessing and using a caCORE LexEVS system requires the following steps:
- Ensure that the client application has access to the objects in the domain space.
- Formulate the query criteria using the domain objects.
- Establish a connection to the server.
- Submit the query objects and specify the desired class of objects to be returned.
- Use and manipulate the result set as desired.
caCORE LexEVS systems use four native application programming interfaces (APIs). Each interface uses the same paradigm to provide access to the caCORE LexEVS domain model, with minor changes specific to the syntax and structure of the clients. The following sections describe each API, identify installation and configuration requirements, and provide code examples.
The sequence diagram in Sequence diagram - caCORE 4.0 LexEVS API search mechanism illustrates the caCORE LexEVS API search mechanism implemented to access the NCI EVS vocabularies.
Querying the System
LexEVS conforms to the caCORE SDK API - for more information see caCORE SDK 4.1 Programmer's Guide.
QueryOptions
QueryOptions are designed to give the user extra control over the query before it is sent to the system. QueryOptions may be used to modify a query in these ways:
- 'CodingScheme' - Restricts the query to the specified Coding Scheme, instead of querying every available Coding Scheme.
CodingSchemeVersionOrTag' - Restricts the query to the specified Version of the Coding Scheme.
Info - 'CodingScheme' - Restricts the query to the specified Coding Scheme, instead of querying every available Coding Scheme.
CodingSchemeVersionOrTag' - Restricts the query to the specified Version of the Coding Scheme.
Info title Note This may NOT be specified without also specifying the 'CodingScheme' attribute.
If left unset, it will default to the version of the Coding Scheme tagged as "PRODUCTION" in the system.- 'SecurityTokens' - Security Tokens to use with the specified query. These Security Tokens are scoped to the current query ONLY. An subsequent queries will also need to specify the necessary Query Options.
'LazyLoad' - Some high use-case model Objects have bee 'lazy-load' enabled. This means that some attributes and associations of a model Object may not be fully populated when returned to the user. This allows for faster query times. This defaults to false, meaning that all attributes and associations will be eagerly fetched by the server and model Objects will always be fully populated. To enable this on applicable Objects, set to true.
Info title Note Lazy Loading may only be used in conjunction with specifying a Coding Scheme and Version with the 'CodingScheme' and 'CodingSchemeVersionOrTag' attributes above.
- 'ResultPageSize' - the page size of results to return. The higher the number, the more results the system will return to the user at once. The client will request the next group of query results transparenly. This parameter is useful for performance tuning. For example, if a query returns a result of10,000 Objects, a 'ResultPageSize' of '1000' would make 10 calls to the server returning a page of 1000 results each time. If left unset, this value will default to the default set Page Size
...
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.
Controlling the Start Index
To specify a specific start position in the result set, specify the &startIndex parameter. This will scroll to the desired position within the set of results.
Internal-Use Parameters
A number of parameters, such as &resultCounter, &pageSize, and &page, are used internally by the system and are not designed to be set by the user.
| Info | ||
|---|---|---|
| ||
When specifying attribute values in the query string, note that use of the following characters generates an error: |
Distributed LexEVS API
| Info | ||
|---|---|---|
| ||
Overview
This exposes the LexEVS Service model via a Remote Method Invocation service.
Architecture
The LexEVS API is exposed by the LexEVS caCORE System for remote access as shown in the figure below. The caCORE System's LexEVSApplicationService class implements the LexBIGService interface.
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 distributed LexEVS architecture (caCORE => Application Service === Spring Remoting === caCORE Server => LexBIG Client = >LexBIG Datastore).
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.
Controlling the Start Index
To specify a specific start position in the result set, specify the &startIndex parameter. This will scroll to the desired position within the set of results.
Internal-Use Parameters
A number of parameters, such as &resultCounter, &pageSize, and &page, are used internally by the system and are not designed to be set by the user.
| Info | ||
|---|---|---|
| ||
When specifying attribute values in the query string, note that use of the following characters generates an error: |
Distributed LexEVS API
| Info | ||
|---|---|---|
| ||
Overview
This exposes the LexEVS Service model via a Remote Method Invocation service.
Architecture
The LexEVS API is exposed by the LexEVS caCORE System for remote access as shown in the figure below. The caCORE System's LexEVSApplicationService class implements the LexBIGService interface.
The distributed LexEVS API environment will be configured on the LexEVS Server currently at (http://lexevsapi6.nci.nih.gov/lexevsapi64).
...
