Content changes to this document from the previous to the current level are indicated by revision bars (|) unless a complete rewrite is indicated.
Date | Version | Description | Author |
---|---|---|---|
07/29/2008 | 1.0 | Initial document | Kevin Peterson |
8/30/2008 | 1.1 | Revised for Security and Exception Handling | Kevin Peterson |
If this document has been inspected, please indicate the inspection date that each version is based on in the "Change Description and Explanation" area. Entries in this log must be maintained for at least 3 years. |
This document provides the detailed design and implementation of LexBIG Enterprise Vocabulary Service (LexEVS) caGrid Service. It should be noted that the LexEVS Grid Service is no longer part of the caGrid 1.1 infrastructure and will be deployed as a separate unit. This is a change from the previous release of the LexEVS Grid Service.
The LexEVS caGrid service will allow programs to utilize the caGrid 1.2 infrastructure to access LexEVS information that is currently being produced by NCICB.
The following table lists team members.
Role | Name |
---|---|
Development Lead | Kevin Peterson |
Documentation Lead | Kevin Peterson |
Project Manager | Tom Johnson |
The LexEVS grid service will be used to obtain data accessible via the EVS API 4.2 service, specifically, the Distributed LexBIG services. Please refer to the caCORE EVS API 4.0 technical guide for details on the EVS API 4.2 EVS APIs, and the LexBIG 2.3 Technical and Admin guide for details about LexBIG 2.3.
For more Documentation, Build/Deployment instructions and examples, refer to the project documentation on the GForge archive page.
The LexEVS Grid service will provide programmatic access to the LexBIG domain objects that are available via the LexBIG information model.
The LexEVS grid service will be registered in Cancer Data Standards Repository (caDSR) under the following category:
Category | LexEVS Grid Service |
---|---|
Context | caBIG |
Classification Scheme | LexBIG |
Version | LexBIG_v2_3_rv1 |
The LexEVS Grid Service is implemented to expose the API and Model of LexBIG 2.3. For more information on LexBIG, see the Mayo Clinic website .
LexEVS Grid Service is deployed in a JBoss Application Server, inside of a Globus Web Application installation. LexEVS Grid Service depends on EVSAPI, which is also deployed to a JBoss container. For more information on the deployment of EVSAPI, see the GForge archive.
EVSAPI itself depends on an installation of LexBIG .
The diagram below shows the various components of the LexEVS Grid Service System and how they interact.
LexEVS Grid Service and EVSAPI need not be deployed to physically separate servers, but it is recommended that if they are co-located on the same server, they should be deployed to separate JBoss containers.
Below is the LexEVS Grid Service Architecture, viewed from inside of the Web Service Container. For more information on how Service Contexts and Resources are used, see the section, Service Contexts and State below.
The LexEVS Grid Service is built on the LexGrid/LexBIG model and implementation. For more information about this model, visit:
Historical link https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lexbig/lbModel/?root=lexevs |
and
Historical link https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lgModel/?root=lexevs |
Also, visit the Mayo website for background information as well as Class Diagrams, examples, and other information.
For information specific to the LexEVS Grid Service, visit:
Historical link https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lexbig/lbModel.cagrid/?root=lexevs |
This link contains Class Diagrams and descriptions for input/output parameters, as well as other information concerning the Silver Level Compliance submission package.
The sequence diagram for the operation "getSupportedCodingSchemes" is described below:
The following diagram shows a General Call Sequence from the client, through the caGrid Service, to the Distributed LexBIG and the returned results:
The LexEVS Grid Service will be deployed as a "stand alone" grid service at NCICB.
None
None
The main Service API exposed by the LexEVS Grid service will be the http://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/LexBIGServiceGrid.html Interface. All other APIs will not be directly exposed, but will be made available through Service Contexts.
In General, API calls will follow the sequence which is shown in the following diagram:
To use the LexEVS Grid Services, either org.LexGrid.LexBIG.cagrid.adapters.LexBIGServiceAdapter or org.LexGrid.LexBIG.cagrid.adapters.LexBIGServiceGridAdapter objects may be instantiated. These are two different Interfaces for accessing the Grid Services.
org.LexGrid.LexBIG.cagrid.adapters.LexBIGServiceAdapter- An Interface for interacting with the LexEVS Grid Services. This Interface is intended to mirror the existing LexBIG API as much as possible. There is no object wrapping for semantic purposes on this interface. This allows existing applications using the LexBIG API to used Grid Services without code changes. This Interface may be acquired by instantiating LexBIGServiceAdapter with the Grid Service URL as a parameter.
LexBIGService lbs = new LexBIGServiceAdapter("http://..."); |
org.LexGrid.LexBIG.cagrid.adapters.LexBIGServiceGridAdapter- An Interface for interacting with the LexEVS Grid Services. This Interfaces is the Semantically defined interface. All method parameters and return values are defined and annotated as CDEs to be loaded into CADSR. This Interface is intended to be caGrid Silver Level Compliant. This Interface may be acquired by instantiating LexBIGServiceGridAdapter with the Grid Service URL as a parameter.
LexBIGServiceGrid lbs = new LexBIGServiceGridAdapter("http://..."); |
getCodingSchemeConcepts(String, CodingSchemeVersionOrTag)
Description | Returns the set of all (or all active) concepts in the specified coding scheme. | ||
---|---|---|---|
Input | org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification, org.LexGrid.LexBIG.DataModel.Core.CodingSchemeVersionOrTag | ||
Output | org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeSet.stubs.types.CodedNodeSetReference | ||
Exception | RemoteException | ||
Implementation Details |
| ||
Sample Call: |
|
getFilter(ExtensionIdentification)
Description | Returns an instance of the filter extension registered with the given name. | |
---|---|---|
Input | org.LexGrid.LexBIG.DataModel.cagrid.ExtensionIdentification | |
Output: | org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.Filter.stubs.types.FilterReference | |
Exception | RemoteException | |
Implementation Details |
| |
Sample Call |
|
getSortAlgorithm(ExtensionIdentification)
Description | Returns an instance of the filter extension registered with the given name. | |
---|---|---|
Input | org.LexGrid.LexBIG.DataModel.cagrid.ExtensionIdentification | |
Output: | org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.Sort. | |
Exception | RemoteException | |
Implementation Details |
| |
Sample Call |
|
getFilterExtensions()
Description | Returns a description of all registered extensions used to provide additional filtering of query results. |
---|---|
Input | none |
Output | org.LexGrid.LexBIG.DataModel.Collections.ExtensionDescriptionList |
Exception | RemoteException |
Implementation Details | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. |
Sample Call |
|
getServiceMetadata()
Description | Return an interface to perform system-wide query over metadata for loaded code systems and providers. |
---|---|
Input | none |
Output | org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.LexBIGServiceMetadata. |
Exception | RemoteException |
Implementation Details |
|
Sample Call |
|
getSupportedCodingSchemes
Description | Return a list of coding schemes and versions that are supported by this service, along with their status. |
---|---|
Input | none |
Output | org.LexGrid.LexBIG.DataModel.Collections.CodingSchemeRenderingList |
Exception | RemoteException |
Implementation Details | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. |
Sample Call |
|
getLastUpdateTime()
Description | Return the last time that the content of this service was changed; null if no changes have occurred. Tag assignments do not count as service changes for this purpose. |
---|---|
Input | none |
Output | java.util.Date |
Exception | RemoteException |
Implementation Details | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. |
Sample Call: |
|
resolveCodingScheme(CodingSchemeIdentification, CodingSchemeVersionOrTag)
Description | Return detailed coding scheme information given a specific tag or version identifier. | ||
---|---|---|---|
Input | org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification, org.LexGrid.LexBIG.DataModel.Core.CodingSchemeVersionOrTag | ||
Output | org.LexGrid.codingSchemes.CodingScheme | ||
Exception | RemoteException | ||
Implementation Details | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. | ||
Sample Call |
|
getNodeGraph(CodingSchemeIdentification, CodingSchemeVersionOrTag, RelationContainerIdentification)
Description | Returns the node graph as represented in the particular relationship set in the coding scheme. | |||
---|---|---|---|---|
Input | org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification, org.LexGrid.LexBIG.DataModel.Core.CodingSchemeVersionOrTag, | |||
Output | ''org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices. | |||
Exception | RemoteException | |||
Implementation Details |
| |||
Sample Call |
|
getMatchAlgorithms()
Description: | Returns the node graph as represented in the particular relationship set in the coding scheme. |
---|---|
Input: | none |
Output: | org.LexGrid.LexBIG.DataModel.Collections.ModuleDescriptionList |
Exception: | RemoteException |
Implementation Details: | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. |
Sample Call: |
|
getGenericExtensions()
Description: | Returns a description of all registered extensions used to implement application-specific behavior that is centrally accessible from a LexBIGService. |
---|---|
Input: | none |
Output: | org.LexGrid.LexBIG.DataModel.Collections.ExtensionDescriptionList |
Exception: | RemoteException |
Implementation Details: | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. |
Sample Call: |
|
getGenericExtensions(ExtensionIdentification)
Description: | Returns an instance of the application-specific extension registered with the given name. | ||
---|---|---|---|
Input: | org.LexGrid.LexBIG.DataModel.cagrid.ExtensionIdentification | ||
Output: | org.LexGrid.LexBIG.DataModel.Collections.SortDescriptionList | ||
Exception: | RemoteException | ||
Implementation Details: | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. | ||
Sample Call: |
|
getHistoryService(CodingSchemeIdentification)
Description: | Resolve a reference to the history api servicing the given coding scheme. | |
---|---|---|
Input: | org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification | |
Output: | ''org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices. | |
Exception: | RemoteException | |
Implementation Details: |
| |
Sample Call: |
|
getSortAlgorithms(SortContext)
Description: | Returns a description of all registered extensions used to provide additional filtering of query results. |
---|---|
Input: | org.LexGrid.LexBIG.DataModel.InterfaceElements.types.SortContext |
Output: | org.LexGrid.LexBIG.DataModel.Collections.SortDescriptionList |
Exception: | RemoteException |
Implementation Details: | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. |
Sample Call: |
|
resolveCodingSchemeCopyright(CodingSchemeIdentification)
Description: | Return coding scheme copyright given a specific tag or version identifier. | ||
---|---|---|---|
Input: | org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification | ||
Output: | org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeCopyRight | ||
Exception: | RemoteException | ||
Implementation Details: | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. | ||
Sample Call: |
|
setSecurityToken(CodingSchemeIdentification, SecurityToken)
Description: | Sets the Security Token for the given Coding Scheme. | ||
---|---|---|---|
Input: | org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification, gov.nih.nci.evs.security.SecurityToken | ||
Output: | ''org.LexGrid.LexBIG.cagrid.LexEVSGridService.stubs.types | ||
Exception: | RemoteException | ||
Implementation Details: | Call this method on the associated LexBIG Service instance (or Distributed LexBIG instance) on the server, and forward the results. | ||
Sample Call: |
|
For an example clients, service calls, and SOAP messages, see the sample code on the LexEVS documentation GForge archive page.
Example API usage:
Searching for concepts in NCI Thesaurus containing the string "Gene"
//Create a Connection to the Grid Service LexBIGServiceGrid lbs = new LexBIGServiceGridAdapter(gridServiceURL); //Set up the CodingSchemeIdentification object to define the Coding Scheme CodingSchemeIdentification csid = new CodingSchemeIdentification(); csid.setName("NCI Thesaurus"); //Get the CodedNodeSet for that CodingScheme (This returns a CodedNodeSet Service Context) CodedNodeSetGrid cnsg = lbs.getCodingSchemeConcepts(csid, null); //getCodingSchemeConcepts is a Grid Service Call //Set the text to match MatchCriteria matchText = new MatchCriteria(); matchText.setText("Gene"); //Define a SearchDesignationOption, if any SearchDesignationOption searchOption = new SearchDesignationOption(); //Choose an algorithm to do the matching ExtensionIdentification matchAlgorithm = new ExtensionIdentification(); matchAlgorithm.setLexBIGExtensionName("contains"); //Chose a language LanguageIdentification language = new LanguageIdentification(); language.setIdentifier("en"); //Restrict the CodedNodeSet cnsg.restrictToMatchingDesignations(matchText, searchOption, matchAlgorithm, language); //restrictToMatchingDesignations is a Grid Service Call //Create a SetResolutionPolicy to handle the details of Resolving the CodedNodeSet //Here, we will set the Maximum number of Concepts returned to 10. SetResolutionPolicy resolvePolicy = new SetResolutionPolicy(); resolvePolicy.setMaximumToReturn(10); //Do the resolve ResolvedConceptReferenceList rcrlist = cnsg.resolveToList(resolvePolicy); //resolveToList is a Grid Service Call //Use the returned ResolvedConceptReferenceList to print some details about the concepts found ResolvedConceptReference[] rcref = rcrlist.getResolvedConceptReference(); for (int i = 0; i < rcref.length; i++) { System.out.println(rcref[i].getConceptCode()); System.out.println(rcref[i].getReferencedEntry(). getPresentation()[0].getText().getContent()); } |
Along with the Main Service (described above), the Server will also host the Service Contexts shown in the following diagram and described in the subsequent sections. These Service Contexts are not meant to be called directly as Grid Services. The main function of these Service Contexts is to provide additional functionality to the Main Service.
Service Context Operations Example in Introduce
Service Contexts are only meant to be called through the Main Service - not directly. Through the Main Service, References to these Service Contexts can be obtained. Calls are made to the Service Contexts through these References. |
In the figure below, two LexEVS Grid Service Calls are highlighted, 'getCodingSchemeConcepts' and 'getNodeGraph'. These two Grid Service Calls have been selected because they return to the user a "Reference" to a Service Context. For 'getCodingSchemeConcepts', the return type is CodedNodeSetReference (which references the CodedNodeSet Service Context). For 'getNodeGraph', the return type is CodedNodeGraphReference (which references the CodedNodeGraph Service Context).
LexEVS Grid Services use the WS-Resource Framework (WSRF) to allow for stateful calls to the server. When a client requests a Service Context, the client is not only issued a Reference to the Service Context that was requested, but to a unique stateful Resource on the server as well. This Resource is used in the LexEVS Grid Services as a way of statefully holding objects for further use by the client. For more information about how caGrid uses the WS-Resource Framework (WSRF), see http://www.cagrid.org/wiki/Metadata:WSRF
Historical link http://www.cagrid.org/wiki/Metadata:WSRF |
For more information on how Resources are implemented in the LexEVS Grid Service, refer to this LexEVSGrid presentation.
The Service Contexts API calls follow this general process:
Service Context and Resource Assignment
By default, these services are destroyed 5 minutes after creation. |
To construct a CodedNodeSet, the user calls getCodingSchemeConcepts as described above. When the user creates a CodedNodeSet through the API call getCodingSchemeConcepts, the server creates and stores the CodedNodeSet server-side as a Resource. This Resource is associated with the client and will be accessible only by the client that created it.
CodedNodeSet Call Sequence:
To construct a CodedNodeGraph, the user calls getNodeGraph as described above. When the user creates a CodedNodeGraph through the API call getNodeGraph, the server creates and stores the CodedNodeGraph server-side as a Resource. This Resource is associated with the client and will be accessible only by the client that created it.
CodedNodeGraph Call Sequence:
To construct a LexBIGServiceConvenienceMethods, the user calls getGenericExtensions as described above. When the user creates a LexBIGServiceConvenienceMethods through the API call getGenericExtensions, the server creates and stores the LexBIGServiceConvenienceMethods server-side as a Resource. This Resource is associated with the client and will be accessible only by the client that created it.
LexBIGServiceConvenienceMethods Call Sequence:
To construct a LexBIGServiceMetadata, the user calls getServiceMetadata as described above. When the user creates a LexBIGServiceMetadata through the API call getServiceMetadata , the server creates and stores the LexBIGServiceMetadata server-side as a Resource. This Resource is associated with the client and will be accessible only by the client that created it.
LexBIGServiceMetadata Call Sequence:
To construct a HistoryService, the user calls getHistoryService as described above. When the user creates a HistoryService through the API call getHistoryService, the server creates and stores the HistoryService server-side as a Resource. This Resource is associated with the client and will be accessible only by the client that created it.
HistoryService Call Sequence:
http://informatics.mayo.edu/LexGrid/downloads/javadoc/org/LexGrid/LexBIG/Extensions/Query/Sort.html
To construct a Sort, the user calls getSortAlgorithm as described above. When the user creates a Sort through the API call getSortAlgorithm, the server creates and stores the Sort server-side as a Resource. This Resource is associated with the client and will be accessible only by the client that created it.
Sort Call Sequence:
The client may continue to make statefull calls to the SortClient and the assigned Resource. For example, the client may call any method in org.LexGrid.LexBIG.Extensions.Query.Sort
http://informatics.mayo.edu/LexGrid/downloads/javadoc/org/LexGrid/LexBIG/Extensions/Query/Filter.htm
To construct a Filter, the user calls getFilter as described above. When the user creates a Filter through the API call getFilter, the server creates and stores the Sort server-side as a Resource. This Resource is associated with the client and will be accessible only by the client that created it.
Filter Call Sequence:
A ResolvedConceptReferencesIterator is created when a CodedNodeSet or CodedNodeGraph is resolved. It allows results to be returned from the server incrementally instead of all at once. When the user creates a ResolvedConceptReferencesIterator, the server creates and stores the ResolvedConceptReferencesIterator server-side as a Resource. This Resource is associated with the client and will be accessible only by the client that created it.
ResolvedConceptReferencesIterator Call Sequence:
Error Connecting to LexEVS Grid Service
When connecting through the Java Client, java.net.ConnectException and org.apache.axis.types.URI.MalformedURIException may be thrown upon an unsuccessful attempt to connect.
A MalformedURIException is thrown in the case if a poorly-formed URL string. In this case, the exception is thrown before an attempt to connect is even made.
If the URL is well-formed, proper connection is tested. If the connection attempt fails, a ConnectException is thrown containing the reason for the failure.
This example shows a typical connection to the LexEVS Grid Service, with the two potential Exceptions being caught and handled as necessary.
LexBIG Errors
LexBIG errors will be forwarded through the Distributed LexBIG layer and then on to the Grid layer. Input parameters, along with any other LexBIG (or Distributed LexBIG) errors will be detected on the server, not the client, and forwarded. All Generic LexBIG (or Distributed LexBIG) errors will be forwarded via a RemoteException, with the cause of the error and underlying LexBIG error message included.
Invalid Service Context Access
Service Context Services are not meant to be called directly. If the client attempts to do so, an org.LexGrid.LexBIG.cagrid.LexEVSGridService.CodedNodeSet.stubs.types.InvalidServiceContextAccess Exception will be thrown. This indicates a call was made to a Service Context without obtaining a Service Context Reference via the Main Service (see the above section Service Contexts and State for more information).
None
The Introduce toolkit generates a "client" class that will be provided to the users.
None
None
Security in the LexEVS Grid Service is implemented in the Distributed LexBIG layer. The information in this section explains how the LexEVS Grid Services utilize this security implementation. For more information about the Distributed LexBIG Security Implementation, refer to LexBIG Access to Licensed Vocabulary Implementation, attached to the EVS API GForge documents archive.
Certain vocabulary content accessible through the LexEVS Grid Service may require extra authorization to access. Each client is required to supply its own access credentials via Security Tokens. These Security Tokens are implemented by a SecurityToken object:
A client establishes access to a secured vocabulary via the following Grid Service Calls:
LexBIGServiceGrid lbs = new LexBIGServiceGridAdapter(url);
Build an org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification to hold the Coding Scheme name.
CodingSchemeIdentification codingScheme = new CodingSchemeIdentification(); codingScheme.setName("codingScheme"); |
Build an gov.nih.nci.evs.security.SecurityToken containing the security information for the desired Coding Scheme.
SecurityToken token = new SecurityToken(); token.setAccessToken("securityToken"); |
LexBIGServiceGrid lbsg = lbs.setSecurityToken(codingScheme, token);
It is important to note that the Grid Service "setSecurityToken" returns an org.LexGrid.LexBIG.cagrid.LexEVSGridService.stubs.types
.LexEVSGridServiceReference.LexEVSGridServiceReference
object. This reference must be used to access the secured vocabularies.
Each call to "setSecurityToken" sets up a secured connection to Distributed LexBIG with the access privileges included in the SecurityToken parameter. The LexEVSGridServiceReference that is returned to the client contains a unique key identifier to the secure connection that has been created on the server. All subsequent calls the client makes through this LexEVSGridServiceReference will be made securely. If additional SecurityTokens are passed in through the "setSecurityToken" Grid Service, the additional security will be added and maintained.
The "setSecurityToken" Grid Service is a stateful service. This means that after the client sets a SecurityToken, any subsequent call will be applied to that SecurityToken.
Secure connections are not maintained on the server indefinitely, but are based on load conditions. The server will allow 30 unique secure connections to be set up for clients without any time limitations. As additional requests for secure connections are received by the server, connections will be released by the server on an 'oldest first' basis. No connection, however, may be released prior to 5 minutes after its creation.
If no SecurityTokens are passed in by the client, a non-secure Distributed LexBIG connection will be used. The server maintains one (and only one) un-secured Distributed LexBIG connection that is shared by any client not requesting security.
All non-secured information accessed by the LexEVS Grid Service is publicly available from NCICB and users are expected to follow the licensing requirements currently in place for accessing and using NCI EVS information. |
The LexEVS service will take advantage of all improvements made to the EVSAPI services with the exception of lazy loading. LexEVS grid service, being in nature a web service is currently not taking advantage of lazy loading since objects are transferred as fully populated objects. However, future releases of LexEVS Grid Service may refractor the interface in such as way as to take advantage of some of the benefits brought about by the inclusion of lazy loading in to EVSAPI service.
LexEVS Grid Services utilize the performance enhancements of the LexBIG API.
For more information about LexBIG performance (which LexEVS Grid Services are dependent on), see the Mayo Clinic website .
Not Internationalized
The service will be installed and deployed as a "stand alone" service at NCICB.
Both the current version of LexEVS grid service and a previous version may be "in service" simultaneously if the corresponding underlying EVSAPI service is also "in service" to manage migration of clients.
See LexEVS Grid Service Testing Documentation (LexEVS Grid Service System Testing in the Project Documents, Development Documents section)