Page History

...

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:

...

Image Removed

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

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 below). |

...

The LexBIG API is designed with web and grid-level enablement 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:

...

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> - A globally unique reference to a concept code.

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

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

...

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.

Information Models

Overview

...

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:

codingScheme

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

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

...

conceptsAndInstances

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

entities

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.

The following graphic displays an entity.

entity

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.

The following figure shows an association.

association

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.

The following figure shows associationinstance.

associationInstance

Naming

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

naming

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

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.

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 .

...

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

The following figure shows the LexBIG core elements.

...

Core

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

...

Defines metadata related to model objects required by the runtime.

Image Removed

The following figure shows the interfaceelements.

Image AddedInterfaceElements

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.

...

Maintains a record of modifications made to a code system.

The following figure shows the NCIHistory.

NCIHistory

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>

A change event as documented in 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.

...

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:

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

...

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.

...

Implementation Overview

Team Members

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

...

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}

Scope

The LexEVS Grid service will provide programmatic access to the LexBIG domain objects that are available via the LexBIG information model.

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.

The LexEVS grid service The LexEVS grid service will be registered in Cancer Data Standards Repository (caDSR) under the following category:

...

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})], 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&amp;selected_doc_group_id=1914&amp;language_id=1^{Image Removed}
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.

...

The LexEVS Grid Service is built on the LexGrid/LexBIG model and implementation.
For more information about this model, visit (LexBIG) https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lexbig/lbModel/?root=lexevs^{Image Removed}
and (LexGrid) https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lgModel/?root=lexevs^{Image Removed} LexBIG
and LexGrid.

Also, visit http://informatics.mayo.edu^{Image Removed} for background information as well as Class Diagrams, examples, and other information.

For information specific to the LexEVS Grid Service, visit: https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lexbig/lbModel.cagrid/?root=lexevs^{Image Removed}
. This link contains Class Diagrams and descriptions for input/output parameters, as well as other information concerning the Silver Level Compliance submission package.

...

In General, API calls will follow this sequence:

API Examples

For an example 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 API usage:

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

:SearchingForConcepts_Snippet

...

Along with the Main Service (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.

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

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)

...

• How Resources are implemented in the LexEVS Grid Service

...

Service Context Sequence

Service Contexts API calls follow this general process:

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

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. The user requests a CodedNodeSet using getCodingSchemeConcepts.
   :RequestCodedNodeSet 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.

...

2. CodedNodeGraph

...

http://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. The user requests a CodedNodeGraph using getCodingSchemeConcepts.
   :RequestCodedNodeGraph 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:
   :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}

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. The user requests a LexBIGServiceConvenienceMethods using getGenericExtensions.
   :RequestLexBIGServiceConvenienceMethods_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 Resource.

...

4. LexBIGServiceMetadata

...

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. The user requests a LexBIGServiceMetadata using getServiceMetadata.
   :RequestLexBIGServiceMetadata_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}

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. The user requests a HistoryService using getHistoryService .
   :RequestHistoryService_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}

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. The user requests a Sort using getSortAlgorithm .
   :RequestSort_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. .
2. The client may continue to make statefull calls to the SortClient and the assigned Resource. For example, the client may call any method in
   :RequestSortCompare_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}]

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. The user requests a Filter using getFilter
   :RequestFilter_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
   :RequestFilterMatch_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}

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

...

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.

:LexGridServiceConnection_Snippet

This example shows a typical connection to the LexEVS Grid Service, with the two potential Exceptions being caught and handled as necessary.

...

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

...

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 , see 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}

LexEVS Grid Service Security

...

A client establishes access to a secured vocabulary via the following Grid Service Calls:

1. Step 1: Connect to the LexBIG caGrid Service

   Code Block

...

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

   Code Block

...

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

   ...

   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:

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

Installation / Packaging

The service will be installed and deployed as a "stand alone" service at NCICB.

...

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}

DOCUMENT APPROVAL

...

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

...

Development Manager

...

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

...

LexEVS Loader Source Mapping

...