 |
Page History
| Scrollbar | ||
|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Page info | ||||
|---|---|---|---|---|
|
| Panel | ||||
|---|---|---|---|---|
| ||||
|
| Include Page | ||||
|---|---|---|---|---|
|
Overview
LexBIG software architecture and implementation is designed to facilitate flexibility and future expansion. The following diagrams are intended to aid the understanding of LexBIG service integration in context of the larger caBIG® universe and specific deployment scenarios:
This diagram depicts the LexBIG vision. Individual Cancer Centers will be able to use the existing set of caCORE EVS services. If desired, local instances of vocabularies can be installed.
This diagram depicts direct Java-to-Java access to LexBIG functions. This is the primary deployment scenario for phase 1.
| Info | ||
|---|---|---|
| ||
It is not required that the database be located on the same system as the program runtime. |
This diagram depicts access through caCORE Enterprise Vocabulary Services (EVS) to a LexBIG vocabulary engine.
The primary goal is to provide a compatible experience for existing EVS browsers and client applications.
...
This would be done to facilitate alternate communications with the LexBIG server (e.g. through web services as described belowin the text that follows).
The LexBIG API is designed with web and grid-level enablement enablment in mind. This diagram depicts deployments that wrap the current API to allow the runtime to be accessed through web or grid services.
What is LexGrid?
LexGrid is an initiative of the Mayo Clinic Division of Biomedical Informatics that focuses on the representation, storage, and dissemination of vocabularies. This effort centers on, but is not limited to, the domain of medical vocabularies and nomenclatures. Focal points of the LexGrid project include the development and promotion of standards, tools, and content that:
...
Additional information for LexGrid is available at http://informatics.mayo.edu
Mayo Clinic Informatics.
What is LexBIG?
LexBIG is a more specific project that applies LexGrid vision and technologies to requirements of the caBIG® community. The goal of the project is to build a vocabulary server accessed through a well-structured application programming interface (API) capable of accessing and distributing vocabularies as commodity resources. The server is to be built using standards-based and commodity technologies. Primary objectives for the project include:
...
The goal for the initial year of development was to achieve the Bronze level of compatibility with regard to the caBIG® requirements. Silver-level compatibility is being pursued.
LexGrid Model
The LexGrid Model is Mayo Clinic's proposal for standard storage of controlled vocabularies and ontologies. The LexGrid Model defines how vocabularies should be formatted and represented programmatically, and is intended to be flexible enough to accurately represent a wide variety of vocabularies and other lexically-based resources. The model also defines several different server storage mechanisms and an XML format. This model provides the core representation for all data managed and retrieved through the LexBIG system, and is now rich enough to represent vocabularies provided in numerous source formats such as OWL (NCI Thesaurus) and RRF (NCI MetaThesaurus).
Once the vocabulary information is represented in a standardized format, it becomes possible to build common repositories to store vocabulary content and common programming interfaces and tools to access and manipulate that content. The LexBIG API developed for caBIG® is one such interface, and is described in additional detail in LexBIG APIs.
Following are some of the higher-level objects incorporated into the model definition:
Code Systems
Each service defined to the LexGrid model can encapsulate the definition of one or more vocabularies. Each vocabulary is modeled as an individual code system, known as a codingScheme. Each scheme tracks information used to uniquely identify the code system, along with relevant metadata. The collection of all code systems defined to a service is encapsulated by a single codingSchemes container.
Concepts
A code system may define zero or more coded concepts, encapsulated within a single container. A concept represents a coded entity (identified in the model as a concept) within a particular domain of discourse. Each concept is unique within the code system that defines it. To be valid, a concept must be qualified by at least one designation, represented in the model as a property. Each property is an attribute, facet, or some other characteristic that may represent or help define the intended meaning of the encapsulating concept. A concept may be the source for and/or the target of zero or more relationships. Relationships are described in more detail in a following section.
Relations
Each code system may define one or more containers to encapsulate relationships between concepts. Each named relationship (e.g. "hasSubtype" or "hasPart") is represented as an association within the LexGrid model. Each relations container must define one or more association. The association definition may also further define the nature of the relationship in terms of transitivity, symmetry, reflexivity, forward and inverse names, etc. Multiple instances of each association can be defined, each of which provide a directed relationship between one source and one or more target concepts.
Source and target concepts may be contained in the same code system as the association or another if explicitly identified. By default, all source and target concepts are resolved from the code system defining the association. The code system can be overridden by each specific association, relation source (associationInstance), or relation target (associationTarget).
LexBIG Extensions
The LexBIG vocabulary model extends the LexGrid model to provide unique constructs or granularity required by caBIG® that are not present in the core model. While many extensions exist, this document will focus on some of direct relevance to the high-level architecture.
Concept Resolution
LexBIG allows the service runtime to provide managed resolution of code-based objects that are referenced through LexBIG-specific lists and iterators (mechanism that allow streaming of list content). These lists and iterators are typically returned when requesting sets or graphs of vocabulary terms through the LexBIG API (described in LexBIG APIs). Some model components involved in the resolution process include:
...
ConceptReference
...
-
...
A
...
globally
...
unique
...
reference
...
to
...
a
...
concept
...
code.
...
ResolvedConceptReference
...
-
...
A
...
concept
...
reference
...
for
...
which
...
additional
...
information
...
has
...
been
...
resolved,
...
including
...
description
...
and
...
relationship
...
participation.
...
AssociatedConcept
...
-
...
A
...
concept
...
reference
...
that
...
contains
...
full
...
detail
...
in
...
participation
...
as
...
a
...
source
...
or
...
target
...
of
...
an
...
association,
...
including
...
indications
...
of
...
navigability
...
and
...
qualification.
...
| Info | ||
|---|---|---|
| ||
Formal representation of the LexGrid and LexBIG models are discussed in VKC:Information Models. |
Information Models
...
Scope of Information Provided
The information below is provided for introductory purposes. A full description of all available model components is also available in the javadoc distributed with the LexEVS installation package (see file breakdown in the LexEVS 5.0 x Installation Guide). Since the javadoc is automatically generated and synchronized during the build process, it is recommended as the primary reference for use by LexEVS developers.
LexGrid Model
The LexGrid model is mastered in XML schema. The LexBIG project currently builds on the 2008 version of the LexGrid schema. A formal representation, showing portions of this structure that are of primary interest to the LexBIG project, is presented below. A complete version of the model is available at http://informatics.mayo.edu?page=lgm . Mayo Clinic Informatics.
CodingSchemes
The CodingSchemes branch of the model defines high level containers for concepts and relations. Each CodingScheme represents a unique code system or version in the LexBIG service. Components of interest include:
...
codingSchemes
A collection of one or more coding schemes.
...
The following graphic shows coding schems.
Concepts
Each concept represents a unique entity within the code system, which can be further described by properties and related to other concepts through relations.
conceptsAndInstances
codingScheme
A resource that makes assertions about a collection of terminological entities.
...
A binary relation from a set of entities to a set of entities and/or data. The entityType for the class concept must be "association".
conceptsAndInstances
entities
codingScheme
A resource that makes assertions about a collection of terminological entities.
...
A binary relation from a set of entities to a set of entities and/or data. The entityType for the class concept must be "association."
entities
entity
entity
A set of lexical assertions about the intended meaning of a particular entity code.
...
The following graphic displays an entity.
Relations
Relations are used to define and qualify associations between concepts.
association
codingScheme
A resource that makes assertions about a collection of terminological entities.
...
The following figure shows an association.
associationInstance
association
A binary relation from a set of entities to a set of entities and/or data. The entityType for the class concept must be "association".
...
The following figure shows associationinstance.
Naming
These elements are primarily used to define metadata for a coding scheme, mapping locally used names to global references.
...
URIMap
A local identifier that is used in a specific context (e.g. language, property name, data type, etc) and an optional URI that can be used to find the exact definition and meaning of the local id. Note: the string portion of this entry can be used to provide additional documentation or information, especially when a URI is not supplied.
...
The following figure shows naming.
LexBIG Model
The following extensions to the LexGrid model were introduced in support of caBIG® requirements. As with the LexGrid model, this document provides a summary of the most significant elements for consideration by LexBIG programmers. The complete and current version of the model is available online at http://informatics.mayo.edu?page=lexex . Mayo Clinic Informatics.
Core
LexBIG core elements provide enhanced referencing and controlled resolution of LexGrid model objects.
The following figure shows the LexBIG core elements.
Components of interest include:
...
Either a local name or the URN of a coding scheme. These two are differentiated syntactically - if the entity includes a colon (
":" or a hash "#" it is assumed to be a URN. Otherwise it is assumed to be a local name.
...
References a service in the Globus environment, this will be a global service handle (GSH).
InterfaceElements
Defines metadata related to model objects required by the runtime.
The following figure shows the interfaceelements.
Components of interest include:
...
The combination of a system release and all of the entityVersions
that accompanied that release.
NCIHistory
Maintains a record of modifications made to a code system.
The following figure shows the NCIHistory.
Components of interest include:
...
Atomic modification actions. Currently populated from a combination of Concordia, SNOMED-CT list and NCI's action list.
NCIChangeEvent A change event as documented in ftp
This link does not work, but I'm not sure it could without an ftp application.
| Code Block |
|---|
Link provided for historical purposes ftp://ftp1.nci.nih.gov/pub/cacore/EVS/ReadMe_history.txt |
. Note that date and time of the change event is recorded in the containing version. All change events for the same/date and time a recorded in the same version.
Architecture
LexBIG
LexBIG Services
This section describes architectural detail for services provided by the LexBIG system. These services are geared toward the administration, management, and serving of vocabularies defined to the LexGrid/LexBIG information model. A system overview is provided, followed by a description of key subsystems and components. Each subsystem is described in terms of its overall structure, formal model, and specification of key public interfaces.
The following figure shows the LexBIG service components.
- Service Metadata: Coding Schema Metadata and Licensing
- Query Service: Lexical Set Operations, Graph Operations, History
- Service Manager: Loaders and Indexers
- Extensions: Plug-ins
The LexBIG Service is designed to run standalone or as part of a larger network of services. It is comprised of four primary subsystems: Service Management, Service Metadata, Query Operations, and Extensions. The Service Manager provides administration control for loading a vocabulary and activating a service. The Service Metadata provides external clients with information about the vocabulary content (e.g. NCI Thesaurus) and appropriate licensing information. The Query Operations provide numerous functions for querying and traversing vocabulary content. Finally, the Extensions component provides a mechanism to extend the specific service functions, such as Loaders, or re-wrap specific query operations into convenience methods.
Primary points of interaction for programming include the following classes:
LexBIGService - This interface provides centralized access to all LexBIG services.
LexBIGServiceManager - The service manager provides a centralized access point for administrative functions, including write and update access for a service's content. For example, the service manager allows new coding schemes to be validated and loaded, existing coding schemes to be retired and removed, and the status of various coding schemes to be updated and changed.
caGRID Hosting
...
The following figure shows how the caGrid Hosting Environment comprises the LexBIG Service. The LexBIG Service comprises Service Metadata, Query Service, Service Manager, and Extensions. Service Metadata has a link outside the Hosting environment to a Service Discovery.
The LexBIG architecture provides the underpinnings LexBIG services to be made accessible through the caGRID environment in the future, where LexBIG services LexBIG architecture provides the underpinnings LexBIG services to be made accessible through the caGRID environment in the future, where LexBIG services might optionally be deployed in a caGRID Globus container. caGrid provides a Globus service for service registration and discovery. LexBIG services deployed to the grid would be registered in the NCICB registry and be searchable through the NCICB index service.
| Info | ||
|---|---|---|
| ||
Additional specifications related to the registration and discovery of LexBIG services in the caGRID environment will be included later phases of work in concordance with caGRID 1.0. This is will be coordinated with caBIG® Architecture workspace designees. |
Service Management Subsystem
The following figure shows the components of the Service Manager: Indexers, Loaders, Loader Administration, and Service Administration. The Loaders are extendable to LexGrid XML, OWL, RRF, OBO, and Other.
This subsystem provides administrative access to functions related to management and publication of LexBIG vocabularies. These functions are generally considered to be reserved for LexBIG administrators, with detailed instructions on how to secure and carry out related tasks described by the LexBIG Administrator's Guide.
...
- Indexers
Vocabularies may be indexed to provide enhanced performance or query capabilities. Types of indexes incorporated into the LexBIG system include but are not limited to the following:- Lexical Match - for example, "begins-with" and "contains"
- Phonetic - allows for the ability to query based on "sounds-like" entry of search criteria.
- Stemming - allows for the ability to find lexical variations of search terms.
Index creation is typically bundled into the load process. Architecturally speaking, however, this capability is decoupled and extensible.
- Loaders
Vocabularies may be imported to the system from a variety of accepted formats, including but not limited to:- LexGrid XML (LexBIG canonical format)
- NCI Thesaurus, provided in Web Ontology Language format (OWL)
- UMLS Rich Release format (RRF)
- Open Biomedical Ontologies format (OBO)
As with indexers, the load mechanism is designed to be extensible from an architectural standpoint. Additional loaders can be supported by the introduction of pluggable modules. Each module is implemented in the Java programming language according to a LexBIG-provided interface, and registered to the loader runtime environment.
Metadata and Discovery Subsystem
The following graphic shows that the Metadata Service comprises Coding Scheme Metadata, Licensing, and Discover and Index Service.
This subsystem provides information about accessible vocabularies, related licensing/copyright information, and registration/discovery of LexBIG services.
...
Finally, the LexBIG architecture provides the underpinnings for LexBIG services to be made accessible through the caGRID environment in the future, where vocabulary services might be deployed and discovered within a caGRID Globus container. However, this portion of the API is preliminary and awaits coordination with caBIG® Architecture WS designees to determine exact recommendations and nature of LexBIG services on the grid.
Query Subsystem
The following figure shows the Query Subsystem which comprises Lexical Set Operations, Graph Operations, and History. Graph Operations sends data to LexBIG API and LexBIG Data Model (Loaders and Indexers) and LexGRID Vocabulary Model and Repository.
This subsystem provides the functionality required to fulfill caCORE/EVS and other vocabulary requests. The Query Service is comprised of Lexical Operations, Graph Operations, Metadata, and History Operations.
...
History provides vocabulary-specific information about concept insertions, modifications, splits, merges, and retirements when supplied by the content provider.
LexEVS API/Grid Service Interaction
(DESIGN DOC IMPORT START)
Revision History
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 |
| Info | ||
|---|---|---|
|
...
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. |
Document Purpose
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.
Implementation Overview
Team Members
The following table lists the team members for the implementation.
Role | Name |
|---|---|
Development Lead | Kevin Peterson |
Documentation Lead | Kevin Peterson |
Project Manager | Tom Johnson |
Description
The LexEVS grid service will be used to obtain data accessible via the LexEVS service, specifically, the Distributed LexEVS services. Please refer to the LexEVS 5.0 Programmer's Guide for more information.
For more Documentation, Build/Deployment instructions and examples, visit LexEVS 5.0 Documentation and Training.
Scope
The LexEVS Grid service will provide programmatic access to the LexBIG domain objects that are available via the LexBIG information model.
...
Context | caBIG |
Classification Scheme | LexBIG |
Version | LexBIG_v2_3_rv1 |
Architecture
The LexEVS Grid Service is implemented to expose the API and Model of LexBIG 2.3. For more information on LexBIG, see http://informatics.mayo.edu Mayo Clinic Informatics.
LexEVS Grid Service is deployed in a JBoss Application Server, inside of a Globus Web Application installation. LexEVS Grid Service depends on [ LexEVS API|http://lexevsapi.nci.nih.gov/], which is also deployed to a LexBIG APIs, which is also deployed to a JBoss container. For more information on the deployment of EVSAPI, see:
| Code Block |
|---|
http://gforge.nci.nih.gov/docman/index.php?group_id=366&selected_doc_group_id=1914&language_id=1] |
LexEVS API itself depends on an installation of LexBIG).
The diagram below shows the various components of the LexEVS Grid Service System and how they interact.
Client accesses LexEVS Grid Node Container via SOAP/HTTP. The LexEVS Grid Node accesses EVSAPI and then LexBIG via RMI. LexBIG accesses Database Servers containing vocabulary data. The database servers and loaded vocabulary configuration is a sample only.
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 "Service #Service Contexts and State" section below.
In the following figure, there is an LexEVS Grid Service
...
Client (Operations) contacting the Web Service Container, which communicates with the Globus/Axis WebApp. Within the Globus/Axis WebApp, a Grid Service communicates with the Service Context that distributes data to LexBIG. The Globus/Axis WebApp comprises Grid Service (LexEVS Grid Service which performs Grid Service Context Calls) and the Service Context. The Service Context comprises:
- caGRID Service Context
- Resource Creator, Resource Home, and Resource Locator.
- Service Context which performs Service Context Grid Calls.
- Resource Instances
- Each of the three Resource Instances comprise Operations and Resource Properties.
- Each Resource Instance forwards data to LexBIG.
LexEVS Grid Service Class Diagram
The LexEVS Grid Service is built on the LexGrid/LexBIG model and implementation. For more information about this model, visit:
| Code Block |
|---|
Historical link
https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lexbig/lbModel/?root=lexevs |
| Code Block |
|---|
Historical link
LexGrid|https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lgModel/?root=lexevs |
Also, visit Mayo Clinic Informatics
The LexEVS Grid Service is built on the LexGrid/LexBIG model and implementation.
For more information about this model, visit LexBIG
and LexGrid.
Also, visit http://informatics.mayo.edu for background information as well as Class Diagrams, examples, and other information.
For information specific to the LexEVS Grid Service, visit:
| Code Block |
|---|
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.
LexEVS Grid Service Sequence Diagram
The sequence diagram for the operation "getSupportedCodingSchemes" is described belowin the text that follows:
General Call Sequence Example
The client calls caGrid, 'getSupportedCodingSchemes()', caGrid Services calls Distributed LexBIG, 'getSupportedCodingSchemes()', LexBIG returns result of call to caGrid Service, and the results are returned to the client with all the appropriate caGrid security mechanisms.:
Assumptions
- The LexEVS service will be based on the latest LexEVS 5.0 release.
- The LexEVS Grid Service will not have any method level security. All security requirements will be handled by the actual deployment of the underlying LexEVS 5.0 service. Please see the "Security" section below for more information on how the LexEVS Grid Service utilizes this security.
- The LexEVS Grid Service will not be deployed as a "core" service by caGrid at NCICB as was previously done, but rather will now be deployed as a standalone service.
- The LexEVS Grid Service release schedule will no longer be coupled to the caGrid deployment schedule as previously done.
- Multiple version of LexEVS Grid Service may be active at the same instance in time depending solely on the availability of the underlining EVSAPI service.
Dependencies
- LexEVS 5.0 service needs to be available and running correctly.
- The LexEVS service and operations will use the Introduce toolkit to generate the appropriate structure for registering the service into caDSR.
Third Party Tools
- Introduce Toolkit
- Globus Toolkit (4.0.3) or appropriate version supported by caGrid 1.2
- caGrid 1.2 core infrastructure
Server
The LexEVS Grid Service will be deployed as a "stand alone" grid service at NCICB.
APIs
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 Generalgeneral, API calls will follow this sequence:
- The client invokes a caGrid Service.
- caGrid Node Hosting Service uses Distributed LexBIG to implement a call.
- Distributed LexBIG returns the requested information to caGrid Service.
- caGrid Service returns a response to the client.
API Examples
Example clients, service calls, and SOAP messages|http://gforge.nci.nih.gov/docman/index.php?group_id=491&selected_doc_group_id=3880&language_id=1] SOAP messages (sample code on the LexEVS documentation GForge archive page)
Example API usage:
Searching for concepts in NCI Thesaurus containing the string "Gene"
| Include Page |
|---|
|
|
Service Contexts and State
Along with the Main Service (as described above), the Server will also host the following Service Contexts. 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. The following figure shows how the Service Context comprises a CodedNodeSet that have properties, such as ResolvedConceptReferenceList, Destroy, SetTermination Time, and other tasks.
Service Context Operations Example in Introduce
| Info | ||
|---|---|---|
| ||
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. |
Obtaining a Service Context Reference
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).
Resources
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.
Refer to the following sources for more information:information:
How caGrid uses the WS-Resource Framework (WSRF)
How caGrid uses the WS-Resource Framework (WSRF)Code Block Link provided for historical purposes http://www.cagrid.org/wiki/Metadata:WSRF
Service Context Sequence
Service Contexts API calls follow this general process:
- The client requests a Service Context, such as CodedNodeSet.
- The Grid Node receives the call and forwards the call to EVSAPI.
- EVSAPI calls getCodingSchemeConcept on the local LexBIG installation.
- The Grid Node creates a resource for the CodedNodeSetImpl object for future use.
- The client is returned the Service Context Client for the CodedNodeSet.
Service Context and Resource Assignment
| Info | ||
|---|---|---|
| ||
By default, these services are destroyed 5 minutes after creation. |
Below is a listing of the supported Service Contexts:
1. CodedNodeSet
:
1. CodedNodeSet
CodedNodeSetGrid Interfacehttp://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/CodedNodeSetGrid.html
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:
- The user requests a CodedNodeSet using getCodingSchemeConcepts.
:RequestCodedNodeSet
Include Page CodedNodeSet Snippet CodedNodeSet Snippet - The server calls the Distributed LexBIG getCodingSchemeConcepts method, returning to the server an org.LexGrid.LexBIG.Impl.CodedNodeSetImpl (the implementation of org.LexGrid.LexBIG.LexBIGService.CodedNodeSet) object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeSet.service.globus.resource.CodedNodeSetResource. This Resource will be used to hold the instance of org.LexGrid.LexBIG.Impl.CodedNodeSetImpl, the implementation of org.LexGrid.LexBIG.LexBIGService.CodedNodeSet that was created above.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeSet.stubs.types.CodedNodeSetReference object to the client. This is the reference to the CodedNodeSet Service Context. This object has a direct reference to the Resource created above. The user now uses this client to make transparent Grid calls through the Service Context.
- The client may continue to make statefull calls to the CodedNodeSetClient and the assigned Resource.
- These restrictions are separate calls but statefully maintained on the server via the Resource.
2. CodedNodeGraph
http://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/CodedNodeGraphGrid.htmlCodedNodeGraphGrid Interface
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:
- The user requests a CodedNodeGraph using getCodingSchemeConcepts.
:RequestCodedNodeGraphInclude Page CodedNodeGraph Snippet CodedNodeGraph Snippet - The server calls the Distributed LexBIG getNodeGraph method, returning to the server an org.LexGrid.LexBIG.Impl.CodedNodeGraphImpl (the implementation of org.LexGrid.LexBIG.LexBIGService.CodedNodeGraph) object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeGraph.service.globus.resource.CodedNodeGraphResource. This Resource will be used to hold the instance of org.LexGrid.LexBIG.Impl.CodedNodeGraphImpl, the implementation of org.LexGrid.LexBIG.LexBIGService.CodedNodeGraph that was created above.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeGraph.stubs.types.CodedNodeGraphReference object to the client. This is the reference to the CodedNodeGraph Service Context. This object has a direct reference to the Resource created above. The user now uses this client to make transparent Grid calls through the Service Context.
- The client may continue to make statefull calls to the CodedNodeGraphClient and the assigned Resource. For example, the client may add Restrictions to the CodedNodeGraph before a Resolve:
:Include Page CodedNodeGraphRestriction Snippet CodedNodeGraphRestriction Snippet - These restrictions are separate calls but statefully maintained on the server via the Resource.
3. LexBIGServiceConvenienceMethods
http://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/LexBIGServiceConvenienceMethodsGrid.htmlLexBIGServiceConvenienceMethodsGrid Interface
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:
- The user requests a LexBIGServiceConvenienceMethods using getGenericExtensions.
:RequestLexBIGServiceConvenienceMethods_.Include Page RequestLexBIGServiceConvenienceMethods Snippet RequestLexBIGServiceConvenienceMethods Snippet - The server calls the Distributed LexBIG getGenericExtensions method, returning to the server an org.LexGrid.LexBIG.Impl.Extensions.GenericExtensions.LexBIGServiceConvenienceMethodsImpl (the implementation of org.LexGrid.LexBIG.Extensions.Generic.LexBIGServiceConvenienceMethods) object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.LexBIGServiceConvenienceMethods.service.globus.resource.LexBIGServiceConvenienceMethodsResource. This Resource will be used to hold the instance of org.LexGrid.LexBIG.Impl.Extensions.GenericExtensions.LexBIGServiceConvenienceMethodsImpl, the implementation of org.LexGrid.LexBIG.Extensions.Generic.LexBIGServiceConvenienceMethods that was created above.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServicesLexBIGServiceConvenienceMethods.stubs.types.LexBIGServiceConvenienceMethodsReference object to the client. This is the reference to the LexBIGServiceConvenienceMethods Service Context. This object has a direct reference to the Resource created above. This LexBIGServiceConvenienceMethodsClient implements org.LexGrid.LexBIG.Extensions.Generic.LexBIGServiceConvenienceMethods. The user now uses this client to make transparent Grid calls through the Service Context. Because this LexBIGServiceConvenienceMethods implements org.LexGrid.LexBIG.Extensions.Generic.LexBIGServiceConvenienceMethods, API calls will look to the user as being identical to direct LexBIG API calls.
- The client may continue to make statefull calls to the LexBIGServiceConvenienceMethods Client and the assigned Resource.
- These API calls are separate calls but statefully maintained on the server via the Resource.
4. LexBIGServiceMetadata
http://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/LexBIGServiceMetadataGrid.htmlLexBIGServiceMetadataGrid Interface
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:
- The user requests a LexBIGServiceMetadata using getServiceMetadata.
:
_Include Page RequestLexBIGServiceMetadata Snippet RequestLexBIGServiceMetadata Snippet - The server calls the Distributed LexBIG getServiceMetadata method, returning to the server an implementation of org.LexGrid.LexBIG.LexBIGService.LexBIGServiceMetadata object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.LexBIGServiceMetadata.service.globus.resource.LexBIGServiceMetadataResource. This Resource will be used to hold the instance of an implementation of org.LexGrid.LexBIG.LexBIGService.LexBIGServiceMetadata.
- org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.LexBIGServiceMetadata.stubs.types.LexBIGServiceMetadata object to the client. This is the reference to the LexBIGServiceMetadata Service Context. This object has a direct reference to the Resource created above. The user now uses this client to make transparent Grid calls through the Service Context.
- The client may continue to make statefull calls to the LexBIGServiceMetadata and the assigned Resource.
- These API calls are separate calls but statefully maintained on the server via the Resource.
5. HistoryService
http://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/HistoryServiceGrid.htmlHistoryServiceGrid Interface
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:
- The user requests a HistoryService using getHistoryService .
:
_Include Page RequestHistoryService Snippet RequestHistoryService Snippet - The server calls the Distributed LexBIG getHistoryService method, returning to the server an implementation of org.LexGrid.LexBIG.History.HistoryService object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.HistoryService.service.globus.resource.HistoryServiceResource. This Resource will be used to hold the instance of an implementation of org.LexGrid.LexBIG.History.HistoryService.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.LexBIGServiceMetadata.stubs.types.LexBIGServiceMetadata object to the client. This is the reference to the HistoryService Service Context. This object has a direct reference to the Resource created above. The user now uses this client to make transparent Grid calls through the Service Context.
- The client may continue to make statefull calls to the HistoryServiceClient and the assigned Resource. For example, the client may call any method in org.LexGrid.LexBIG.History.HistoryService
Example: history.getLatestBaseline(); - These API calls are separate calls but statefully maintained on the server via the Resource.
6. Sort
- Resource.
6. Sort
Sort Interfacehttp://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 user requests a Sort using getSortAlgorithm .
:
_Include Page RequestSort Snippet RequestSort Snippet - The server calls the Distributed LexBIG getSortAlgorithm method, returning to the server an implementation of org.LexGrid.LexBIG.Extensions.Query.Sort) object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.Sort .service.globus.resource.Sort Resource. This Resource will be used to hold the instance of an implementation of org.LexGrid.LexBIG.Extensions.Query.Sort.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.service.SortClient object to the client. This is the client to the Sort Service Context. This object has a direct reference to the Resource created above. This SortClient implements org.LexGrid.LexBIG.Extensions.Query.Sort. The user now uses this client to make transparent Grid calls through the Service Context. Because this Sort implements org.LexGrid.LexBIG.Extensions.Query.Sort, API calls will look to the user as being identical to direct LexBIG API calls.
- The client may continue to make statefull calls to the SortClient and the assigned Resource. For example, the client may call any method in
:Include Page RequestSortCompare Snippet
_RequestSortCompare Snippet - These API calls are separate calls but statefully maintained on the server via the Resource.
7. Filter
[http://informatics.mayo.edu/LexGrid/downloads/javadoc/org/LexGrid/LexBIG/Extensions/Query/Filter.htm]Filter Interface
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:
- The user requests a Filter using getFilter
:Include Page RequestFilter Snippet
_RequestFilter Snippet - The server calls the Distributed LexBIG getFilter method, returning to the server an implementation of org.LexGrid.LexBIG.Extensions.Query.Filter) object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.Filter.service.globus.resource.FilterResource. This Resource will be used to hold the instance of an implementation of org.LexGrid.LexBIG.Extensions.Query.Filter.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.service.FilterClient object to the client. This is the client to the Filter Service Context. This object has a direct reference to the Resource created above. This FilterClient implements org.LexGrid.LexBIG.Extensions.Query.Filter. The user now uses this client to make transparent Grid calls through the Service Context. Because this Filter implements org.LexGrid.LexBIG.Extensions.Query.Filter, API calls will look to the user as being identical to direct LexBIG API calls.
- The client may continue to make statefull calls to the FilterClient and the assigned Resource. For example, the client may call any method in org.LexGrid.LexBIG.Extensions.Query.Filter
:
_Include Page RequestFilterMatch Snippet RequestFilterMatch Snippet - These API calls are separate calls but statefully maintained on the server via the Resource.
8. ResolvedConceptReferencesIterator
- the server via the Resource.
8. ResolvedConceptReferencesIterator
ResolvedConceptReferencesIterator Interfacehttp://informatics.mayo.edu/LexGrid/downloads/javadoc/org/LexGrid/LexBIG/Utility/Iterators/ResolvedConceptReferencesIterator.html
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:
- The user gets a ResolvedConceptReferencesIterator from a Resolve.
- The server calls the Distributed LexBIG resolve method on the CodedNodeSet, returning to the server an implementation of org.LexGrid.LexBIG.Utility.Iterators.ResolvedConceptReferencesIterator object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.ResolvedConceptReferencesIterator.service.globus.resource.ResolvedConceptReferencesIteratorResource. This Resource will be used to hold the instance of an implementation of org.LexGrid.LexBIG.Utility.Iterators.ResolvedConceptReferencesIterator.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.service.ResolvedConceptReferencesIteratorClient object to the client. This is the client to the ResolvedConceptReferencesIterator Service Context. This object has a direct reference to the Resource created above. This ResolvedConceptReferencesIteratorClient implements org.LexGrid.LexBIG.Utility.Iterators.ResolvedConceptReferencesIterator. The user now uses this client to make transparent Grid calls through the Service Context. Because this ResolvedConceptReferencesIterator implements org.LexGrid.LexBIG.Utility.Iterators.ResolvedConceptReferencesIterator, API calls will look to the user as being identical to direct LexEVS API calls.
- The client may continue to make statefull calls to the ResolvedConceptReferencesIteratorClient and the assigned Resource. For example, the client may call any method in org.LexGrid.LexBIG.Utility.Iterators.ResolvedConceptReferencesIterator
:Include Page ResolvedConceptReferencesIterator Snippet
_ResolvedConceptReferencesIterator Snippet - These API calls are separate calls but statefully maintained on the server via the Resource.
Error Handling
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.
...
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.
:
| Include Page | |||
|---|---|---|---|
|
|
|
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 LexEVS 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 LexEVS (or Distributed LexEVS) errors will be forwarded via a RemoteException, with the cause of the error and underlying LexEVS 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).
Client
The Introduce toolkit generates a "client" class that will be provided to the users.
Security Issues
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, see Distributed LexBIG Security Implementation: LexBIG Access to Licensed Vocabulary Implementation, attached to the EVS API GForge documents archive.
LexEVS Grid Service Security
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:
<font color="000FFF">Name Name: SecurityToken
Namespace: gme://caCORE.caCORE/3.2/gov.nih.nci.evs.security
Package: gov.nih.nci.evs.security</font>
Accessing Secure Content
A client establishes access to a secured vocabulary via the following Grid Service Calls:
Step 1:Connect to the LexBIG caGrid Service
Code Block LexBIGServiceGrid lbs = new LexBIGServiceGridAdapter(url);Step 3:Build an org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification to hold the Coding Scheme name.
Code Block CodingSchemeIdentification codingScheme = new CodingSchemeIdentification(); codingScheme.setName("codingScheme");Step 4:Build an gov.nih.nci.evs.security.SecurityToken containing the security information for the desired Coding Scheme.
Code Block SecurityToken token = new SecurityToken(); token.setAccessToken("securityToken");Step 5:Invoke the LexBIG caGrid service as follows: This will return a reference to a new "LexBIGServiceGrid" instance that is associated with the security properties that were passed in.
Code Block 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.
Implementation
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.
...
| Info | ||
|---|---|---|
| ||
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. |
Performance
The LexEVS service will take advantage of all improvements made to the LexEVS API 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 LexEVS API 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 http://informatics.mayo.edu Mayo Clinic Informatics.
Installation
...
and Packaging
The service will be installed and deployed as a "stand alone" service at NCICB.
Migration
Both the current version of LexEVS grid service may be "in service" simultaneously if the corresponding underlying EVSAPI service is also "in service" to manage migration of clients.
System Testing
LexEVS Grid Service Testing Documentation (LexEVS Grid Service System Testing in the Project Documents, Development Documents section)
DOCUMENT APPROVAL
Approvers List
The individuals listed in this section constitute the approvers list for the Integration Test Plan document. Formal approval must be received from all approvers prior to the initiation of the next steps in the process.
TITLE | NAME |
|---|---|
Project Manager | Name |
Development Manager | Name |
Reviewers List
The individuals listed in this section constitute the reviewers list for the Master Test Plan document. Formal approval is not required from the reviewers, however, it is desirable to have all reviewers review and comment on the document. Reviewers may choose to concentrate on reviewing only those sections that are in their area of responsibility, rather than the entire document.
TITLE | NAME |
|---|---|
Technical Writer | Name |
LexEVS Loader Source Mapping
This section is now moved to separate pages to provide details on how different formats are loaded into the LexEVS model.
- For LexEVS v5.0, see LexEVS v55.0 Loader Source Mapping.
- For LexEVS v5.1, which includes enhancements to the loader framework, see LexEVS 5.0 1 Loader Source Mapping.
| Scrollbar | ||
|---|---|---|
|