Page info
title title

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.

...

Image Added

This diagram depicts direct Java-to-Java access to LexBIG functions. This is the primary deployment scenario for phase 1.

...

...

...

Image Added

This diagram depicts access through caCORE Enterprise Vocabulary Services (EVS) to a LexBIG vocabulary engine.

Image Added

The primary goal is to provide a compatible experience for existing EVS browsers and client applications.Note: this

This would be done to facilitate alternate communications with the LexBIG server (e.g. through web services as described belowin the text that follows). |

...

Image Removed

The LexBIG API is designed with web and grid-level

...

enablment in mind. This diagram depicts deployments that wrap the current API to allow the runtime to be accessed through web or grid services.

Image Added

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^{Image Removed} . 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:

...

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:

<tt>ConceptReference</tt> ConceptReference - A globally unique reference to a concept code.

<tt>ResolvedConceptReference</tt> ResolvedConceptReference - A concept reference for which additional information has been resolved, including description and relationship participation.

<tt>AssociatedConcept</tt> AssociatedConcept - A concept reference that contains full detail in participation as a source or target of an association, including indications of navigability and qualification.

...

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^{Image Removed} . 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:

...

<u>

codingSchemes</u>
A collection of one or more coding schemes.<u>

codingScheme</u>
A resource that makes assertions about a collection of terminological entities.<u>

entities</u>
A set of entity codes and their lexical descriptions<u>

relations</u>
A collection of relations that represent a particular point of view or community.<u>

versions</u>
A list of past versions of the coding scheme.<u>

mappings</u>
A list of all of the local identifiers and defining URI's that are used in the associated resource<u>

properties</u>
A collection of properties.

The following graphic shows coding schems.
Image Modified

codingSchemes

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

<u>codingScheme</u>

A resource that makes assertions about a collection of terminological entities.

<u>entities</u>

A set of entity codes and their lexical descriptions

<u>entity</u>

A set of lexical assertions about the intended meaning of a particular entity code.

<u>concept</u>

An entity that represents a class or category. The entityType for the class concept must be "concept".

<u>instance</u>

An entity that represents an instance or an individual. The entityType for the class concept must be "instance".

<u>relations</u>

A collection of relations that represent a particular point of view or community.

<u>association</u>

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".

Image ModifiedconceptsAndInstances

entities

<u>codingScheme</u>

A resource that makes assertions about a collection of terminological entities.

<u>entities</u>

A set of entity codes and their lexical descriptions

<u>entity</u>

A set of lexical assertions about the intended meaning of a particular entity code.

<u>concept</u>

An entity that represents a class or category. The entityType for the class concept must be "concept".

<u>instance</u>

An entity that represents an instance or an individual. The entityType for the class concept must be "instance".

<u>association</u>

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.".

Image Modifiedentities

entity

<u>entity</u>

A set of lexical assertions about the intended meaning of a particular entity code.

<u>comment</u>

A property that is used as an annotation or other note about the state or usage of the entity. The propertyType of comment must be "comment"

<u>definition</u>

A property that defines the entity in a particular langage or context.. The propertyType of definition must be "definition"

<u>presentation</u>

A property ths represents or designates the meaning of the entityCode. The propertyType of presentation must be "presentation"

<u>property</u>

A description, definition, annotation or other attribute that serves to further define or identify an resource.

<u>propertyLink</u>

A link between two properties for an entity.. Examples include acronymFor, abbreviationOf, spellingVariantOf, etc. Must be in supportedPropertyLink.

Image Removed

The following graphic displays an entity.

Image Addedentity

Relations

Relations are used to define and qualify associations between concepts.

association

<u>codingScheme</u>

A resource that makes assertions about a collection of terminological entities.

<u>relations</u>

A collection of relations that represent a particular point of view or community.

<u>entity</u>

A set of lexical assertions about the intended meaning of a particular entity code.

<u>association</u>

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".

<u>associationSource</u>

An entity that occurs in one or more instances of a relation on the "from" (or left hand) side of a particular relation.

Image Removed

The following figure shows an association.

Image Addedassociation

associationInstance

<u>association</u>

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".

<u>_associationSource _</u>

An entity that occurs in one or more instances of a relation on the "from" (or left hand) side of a particular relation.

<u>associationTarget</u>

An entity on the "to" (or right hand) side of a relation.

<u>associationData</u>

An instance of a target or RHS data value of an association.

<u>_associatableElement _</u>

Information common to both the entity and data form of the "to" (or right hand) side of an association.

<u>associationQualification</u>

A modifier that further qualifies the particular association instance.

Image Removed

The following figure shows associationinstance.

Image AddedassociationInstance

Naming

These elements are primarily used to define metadata for a coding scheme, mapping locally used names to global references.

...

<u>URIMap</u>

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.

<u>supportedAssociation</u>

An associationName and the URI of the defining resource.

<u>supportedAssociationQualifier</u>

An associationQualifier and the URI of the defining resource

<u>supportedCodingScheme</u>

A codingSchemeName and the URI of the defining resource

<u>supportedStatus</u>

An entryStatus and the URI of the defining resource

<u>_supportedEntityType _</u>

An entityType and the URI of the defining resource

<u>_supportedContext _</u> supportedContext

A context and the URI of the defining resource

<u>_supportedContainerName _</u>

A containerName and the URI of the defining resource

<u>_supportedDegreeOfFidelity _</u>

A degreeOfFidelity and the URI of the defining resource

<u>_supportedLanguage _</u>

A language and the URI of the defining resource

<u>_supportedProperty _</u>

A propertyName and the URI of the defining resource

<u>_supportedSortOrder _</u>

The local identifier and the URI of the defining resource

<u>_supportedHierarchy _</u>

A list of associations that can be browsed hierarchically.

<u>_supportedNamespace _</u>

A namespaceName and the corresponding URI

<u>_supportedPropertyType _</u>

A propertyType and the URI of the defining resource

<u>_supportedPropertyQualifier _</u>

A propertyQualifierName the URI of the defining resource

<u>_ supportedPropertyQualifierType _</u>

A propertyQualifierType the URI of the defining resource

<u>_supportedPropertyLink _</u>

A propertyLinkName and ththe URI of the defining resource

<u>_supportedRepresentationalForm _</u>

A representationalForm and the URI of the defining resource

<u>_supportedSource _</u>

A source and the URI of the defining resource. Source references can also carry an additional compositional rule section that describes how to combine a subpart such as a page number, section name, etc. with the core URI in order to form a meaningful URL. An optional role can also be specified.

<u>_supportedSourceRole _</u>

A source role and athe URI of the defining resource

The following figure shows naming.

Image Modified

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^{Image Removed} Mayo Clinic Informatics.

Core

LexBIG core elements provide enhanced referencing and controlled resolution of LexGrid model objects.

Image Removed

...

The following figure shows the LexBIG core elements.

Image AddedCore

Components of interest include:

<u>AbsoluteCodingSchemeVersionReference</u>

An absolute reference to a coding scheme. This form of reference is service independent, as it doesn't depend on local coding schemes names or virtual tags.

<u>AssociatedConcept</u>

A concept reference that is the source or target of an association.

<u>Association</u>

The representation of a particular association as it appears in a CodedNode.

<u>CodingSchemeSummary</u>

Abbreviated list of information about a coding scheme.

<u>CodingSchemeURNorName</u>

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.

<u>CodingSchemeVersionOrTag</u>

A named coding scheme version or a virtual tag (e.g. latest, production, etc). Note that the tagged form of identifier is only applicable in the context of a given service, as one service may identify the scheme as "production" and another as "staging".

<u>ConceptReference</u>

A reference to a coding scheme and a concept code.

<u>LogEntry</u>

A single recorded log entry.

<u>LogLevel</u>

Indicates severity of the log entry.

<u>MetadataProperty</u>

Reference to a property name and value stored in the coding scheme metadata.

<u>NameAndValue</u>

A simple name/value pair.

<u>ReferenceLink</u>

Any reference to another document element. Used by the REST architecture to embed links.

<u>ResolvedConceptReference</u>

A resolvable concept reference.

<u>ServiceURL</u>

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.

Image Modified

InterfaceElements

Components of interest include:

<u>CodingSchemeRendering</u>

Information about a coding scheme as it appears in a particular service.

<u>ExportStatus</u>

Reports the state of LexBIG export operations.

<u>ExtensionDescription</u>

Describes an add-on module registered to the LexBIG environment.

<u>LoadStatus</u>

Reports the state of LexBIG load operations.

<u>_ModuleDescription _</u>

Describes a LexBIG integrated software module.

<u>ProcessState</u>

Enumerates possible status reported for LexBIG runtime operations.

<u>ProcessStatus</u>

Reports the state of LexBIG runtime operations.

<u>RenderingDetail</u>

The details of how a coding scheme is rendered in a given service.

<u>SortContext</u>

Describes a LexBIG sort module.

<u>SortDescription</u>

A description of a LexBIG extension module.

<u>SortOption</u>

Represents a pairing of sort algorithm and order.

<u>SystemReleaseDetail</u>

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.

Image Removed

The following figure shows the NCIHistory.

Image AddedNCIHistory

Components of interest include:

<u>changeType</u>

Atomic modification actions. Currently populated from a combination of Concordia, SNOMED-CT list and NCI's action list.

<u>NCIChangeEvent</u>

...

NCIChangeEvent

This link does not work, but I'm not sure it could without an ftp application.

Link provided for historical purposes ftp://ftp1.nci.nih.gov/pub/cacore/EVS/ReadMe_history.txt

^{Image Removed}. 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.Image Removed

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

Image Added

The LexBIG Service 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:

<tt>LexBIGService</tt> LexBIGService - This interface provides centralized access to all LexBIG services.

<tt>LexBIGServiceManager</tt> 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.

Image Modified

The 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.

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.

Image AddedImage Removed

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.

This subsystem is further broken down into the following components: *

• 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.

Image Modified

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

Image Removed

This subsystem provides the functionality required to fulfill caCORE/EVS and other vocabulary requests. The Query Service is comprised of Lexical The following figure shows the Query Subsystem which comprises Lexical Set Operations, Graph Operations, Metadata, and History Operations.

Lexical Set Operations

Graph Operations sends data to LexBIG API and LexBIG Data Model (Loaders and Indexers) and LexGRID Vocabulary Model and Repository.

Image Added

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.

Lexical Set Operations

Lexical Set Operations Lexical Set Operations provides methods to return a lists or iterators of coded entries. Supported query criteria include the application of match/filter algorithms, sorting algorithms, and property restrictions. Support is also provided to resolve the union, intersection or difference of two node sets.

...

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.

...

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

Table 1 - Team MembersThe following table lists the team members for the implementation.

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 the project documentation home at: http://gforge.nci.nih.gov/docman/index.php?group_id=491&amp;selected_doc_group_id=3749&amp;language_id=1^{Image Removed} 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.

...

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^{Image Removed} Mayo Clinic Informatics.

LexEVS Grid Service is deployed in a JBoss (http://www.jboss.org/^{Image Removed}) Application Server, inside of a Globus (http://www.globus.org/^{Image Removed}) Web Application installation. LexEVS Grid Service depends on LexEVS API(http://lexevsapi.nci.nih.gov/^{Image Removed}) LexBIG APIs, which is also deployed to a JBoss container. For more information on the deployment of EVSAPI, see:

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 (http://informatics.mayo.edu^{Image Removed}). ).

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.

Image Modified

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.

Image Removed

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.

Image Added

LexEVS Grid Service Class Diagram

The LexEVS Grid Service is built on the LexGrid/LexBIG model and implementation. For more The LexEVS Grid Service is built on the LexGrid/LexBIG model and implementation.
For more information about this model, visit (LexBIG) :

Historical link
https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lexbig/lbModel/?root=lexevs

...

Historical link
LexGrid|https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lgModel/?root=lexevs

...

Also, visit http://informatics.mayo.edu^{Image Removed} Mayo Clinic Informatics 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.

LexEVS Grid Service Sequence Diagram

The sequence diagram for the operation "getSupportedCodingSchemes" is described belowin the text that follows:

Image Modified

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.:

Image Modified

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^{Image Removed} exposed by the LexEVS Grid service will be the LexBIGServiceGrid 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.

Image Modified

API Examples

For an example clients, service calls, and SOAP messages, see http://gforge.nci.nih.gov/docman/index.php?group_id=491&amp;selected_doc_group_id=3880&amp;language_id=1^{Image Removed}Example clients, service calls, and SOAP messages (sample code on the LexEVS documentation GForge archive page)

Example API usage:

Searching for concepts in NCI Thesaurus containing the string "Gene"

:

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.

Image Modified

Service Context Operations Example in Introduce

...

Info
title Important
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).

Image Modified

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. For

Refer to the following sources for more information about how :

• How caGrid uses the WS-Resource Framework (WSRF

...

• )

  Code Block
  Link provided for historical purposes http://www.cagrid.org/wiki/Metadata:WSRF

...

...

• How Resources are implemented in the LexEVS Grid Service

...

Service Context Sequence

Service Contexts API calls follow this general process:calls follow this general process:

1. The client requests a Service Context, such as CodedNodeSet.
2. The Grid Node receives the call and forwards the call to EVSAPI.
3. EVSAPI calls getCodingSchemeConcept on the local LexBIG installation.
4. The Grid Node creates a resource for the CodedNodeSetImpl object for future use.
5. The client is returned the Service Context Client for the CodedNodeSet.

Image Modified

Service Context and Resource Assignment

...

Below is a listing of the supported Service Contexts:<big>

1. CodedNodeSet

...

http://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/CodedNodeSetGrid.html^{Image Removed}CodedNodeSetGrid Interface

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:1.

1. The user requests a CodedNodeSet using getCodingSchemeConcepts.

   ...

   Include Page
   CodedNodeSet Snippet CodedNodeSet Snippet

...

1. 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.

...

1. 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.

...

1. 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.

...

1. The client may continue to make statefull calls to the CodedNodeSetClient and the assigned Resource.

...

1. These restrictions are separate calls but statefully maintained on the server via the Resource.

<big>2. CodedNodeGraph</big>

2. CodedNodeGraph

CodedNodeGraphGrid Interfacehttp://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/CodedNodeGraphGrid.html^{Image Removed}

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:1.

1. The user requests a CodedNodeGraph using getCodingSchemeConcepts.

   ...

   Include Page
   CodedNodeGraph Snippet CodedNodeGraph Snippet

...

1. 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.

...

1. 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.

...

1. 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.

...

1. 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

...

1. CodedNodeGraphRestriction Snippet CodedNodeGraphRestriction Snippet

...

1. 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.html^{Image Removed}LexBIGServiceConvenienceMethodsGrid 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:1.

1. The user requests a LexBIGServiceConvenienceMethods using getGenericExtensions.

   Include Page
   RequestLexBIGServiceConvenienceMethods Snippet

...

1. RequestLexBIGServiceConvenienceMethods

...

1. Snippet

...

1. 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.

...

1. 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.

...

1. 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.

...

1. The client may continue to make statefull calls to the LexBIGServiceConvenienceMethods Client and the assigned Resource.

...

1. These API calls are separate calls but statefully maintained on the server via the

...

1. Resource.

4. LexBIGServiceMetadata

LexBIGServiceMetadataGrid Interface

<big>4. LexBIGServiceMetadata</big>

http://informatics.mayo.edu/LexGrid/downloads/javadocGrid/org/LexGrid/LexBIG/cagrid/interfaces/LexBIGServiceMetadataGrid.html^{Image Removed}

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:1.

1. The user requests a LexBIGServiceMetadata using getServiceMetadata.

   ...

   Include Page
   RequestLexBIGServiceMetadata Snippet RequestLexBIGServiceMetadata

...

1. Snippet

...

1. The server calls the Distributed LexBIG getServiceMetadata method, returning to the server an implementation of org.LexGrid.LexBIG.LexBIGService.LexBIGServiceMetadata object.

...

1. 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.

...

1. 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.

...

1. The client may continue to make statefull calls to the LexBIGServiceMetadata and the assigned Resource.

...

1. 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.html^{Image Removed}HistoryServiceGrid 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:1.

1. The user requests a HistoryService using getHistoryService .

   Include Page
   RequestHistoryService Snippet

...

1. RequestHistoryService

...

1. Snippet

...

1. The server calls the Distributed LexBIG getHistoryService method, returning to the server an implementation of org.LexGrid.LexBIG.History.HistoryService object.

...

1. 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.

...

1. 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.

...

1. 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();

...

1. These API calls are separate calls but statefully maintained on the server via the Resource.

...

6. Sort

...

http://informatics.mayo.edu/LexGrid/downloads/javadoc/org/LexGrid/LexBIG/Extensions/Query/Sort.html^{Image Removed}Sort Interface

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:1.

1. The user requests a Sort using getSortAlgorithm .

   Include Page
   RequestSort Snippet

...

1. RequestSort

...

1. Snippet

...

1. The server calls the Distributed LexBIG getSortAlgorithm method, returning to the server an implementation of org.LexGrid.LexBIG.Extensions.Query.Sort) object.

...

1. 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.

...

1. 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.

...

1. 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

...

1. Snippet

...

1. 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^{Image Removed}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:1.

1. The user requests a Filter using getFilter

   ...

   Include Page
   RequestFilter Snippet RequestFilter

...

1. Snippet

...

1. The server calls the Distributed LexBIG getFilter method, returning to the server an implementation of org.LexGrid.LexBIG.Extensions.Query.Filter) object.

...

1. 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.

...

1. 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.

...

1. 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

...

1. RequestFilterMatch Snippet RequestFilterMatch

...

1. Snippet

...

1. These API calls are separate calls but statefully maintained on the server via the Resource.

...

8. ResolvedConceptReferencesIterator

...

http://informatics.mayo.edu/LexGrid/downloads/javadoc/org/LexGrid/LexBIG/Utility/Iterators/ResolvedConceptReferencesIterator.html^{Image Removed}ResolvedConceptReferencesIterator Interface

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:1.

1. The user gets a ResolvedConceptReferencesIterator from a Resolve.

...

1. 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.

...

1. 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.

...

1. 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.

...

1. 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

...

1. Snippet

...

1. 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.

:

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 about the Distributed LexBIG Security Implementation, see this documentation: http://gforge.nci.nih.gov/tracker/download.php/366/1462/10884/4060/Distributed_LexBIG_%20AccessTo_Licensed_Vocabulary_implemenation.doc^{Image Removed}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:

1. Step 1:Connect to the LexBIG caGrid Service

...

1. Code Block
   LexBIGServiceGrid lbs = new LexBIGServiceGridAdapter(url);

...

2. Step 3:Build an org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification to hold the Coding Scheme name.

...

1. Code Block
   CodingSchemeIdentification codingScheme = new CodingSchemeIdentification();

...

1. codingScheme.setName("codingScheme");

...

2. Step 4:Build an gov.nih.nci.evs.security.SecurityToken containing the security information for the desired Coding Scheme.

...

1. Code Block
   SecurityToken token = new SecurityToken();

...

1. token.setAccessToken("securityToken");

...

2. 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.

...

1. Code Block
   LexBIGServiceGrid lbsg = lbs.setSecurityToken(codingScheme, token);

...

1. 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.

...

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.NOTE:

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^{Image Removed} 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

See LexEVS Grid Service Testing Documentation at: http://gforge.nci.nih.gov/docman/index.php?group_id=491&amp;selected_doc_group_id=3879&amp;language_id=1^{Image Removed} (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.

...

...

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.

...

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.

...