 |
Page History
| Scrollbar | ||
|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
...
| Page info | ||||
|---|---|---|---|---|
|
| Panel | ||||
|---|---|---|---|---|
| ||||
|
| Include Page | ||||
|---|---|---|---|---|
|
Overview
LexBIG software architecture and implementation is designed to facilitate flexibility and future expansion. The following diagrams are intended to aid the understanding of LexBIG service integration in context of the larger caBIG® universe and specific deployment scenarios:
...
| Info | ||
|---|---|---|
| ||
It is not required that the database be located on the same system as the program runtime. |
This diagram depicts access through caCORE Enterprise Vocabulary Services (EVS) to a LexBIG vocabulary engine.
The primary goal is to provide a compatible experience for existing EVS browsers and client applications.
...
This would be done to facilitate alternate communications with the LexBIG server (e.g. through web services as described belowin the text that follows).
The LexBIG API is designed with web and grid-level enablment in mind. This diagram depicts deployments that wrap the current API to allow the runtime to be accessed through web or grid services.
What is LexGrid?
...
The following graphic shows coding schems.
Concepts
Each concept represents a unique entity within the code system, which can be further described by properties and related to other concepts through relations.
...
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
codingScheme
...
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."
entity
entity
...
The following graphic displays an entity.
Relations
Relations are used to define and qualify associations between concepts.
...
The following figure shows an association.
associationInstance
...
The following figure shows associationinstance.
Naming
These elements are primarily used to define metadata for a coding scheme, mapping locally used names to global references.
...
The following figure shows naming.
LexBIG Model
...
The following figure shows the LexBIG core elements.
Components of interest include:
...
The following figure shows the interfaceelements.
Components of interest include:
...
The following figure shows the NCIHistory.
Components of interest include:
...
- Service Metadata: Coding Schema Metadata and Licensing
- Query Service: Lexical Set Operations, Graph Operations, History
- Service Manager: Loaders and Indexers
- Extensions: Plug-ins
The LexBIG Service is designed to run standalone or as part of a larger network of services. It is comprised of four primary subsystems: Service Management, Service Metadata, Query Operations, and Extensions. The Service Manager provides administration control for loading a vocabulary and activating a service. The Service Metadata provides external clients with information about the vocabulary content (e.g. NCI Thesaurus) and appropriate licensing information. The Query Operations provide numerous functions for querying and traversing vocabulary content. Finally, the Extensions component provides a mechanism to extend the specific service functions, such as Loaders, or re-wrap specific query operations into convenience methods.
...
The following figure shows how the caGrid Hosting Environment comprises the LexBIG Service. The LexBIG Service comprises Service Metadata, Query Service, Service Manager, and Extensions. Service Metadata has a link outside the Hosting environment to a Service Discovery.
The LexBIG architecture provides the underpinnings LexBIG services to be made accessible through the caGRID environment in the future, where LexBIG services 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.
...
The following figure shows the components of the Service Manager: Indexers, Loaders, Loader Administration, and Service Administration. The Loaders are extendable to LexGrid XML, OWL, RRF, OBO, and Other.
This subsystem provides administrative access to functions related to management and publication of LexBIG vocabularies. These functions are generally considered to be reserved for LexBIG administrators, with detailed instructions on how to secure and carry out related tasks described by the LexBIG Administrator's Guide.
...
The following graphic shows that the Metadata Service comprises Coding Scheme Metadata, Licensing, and Discover and Index Service.
This subsystem provides information about accessible vocabularies, related licensing/copyright information, and registration/discovery of LexBIG services.
...
The following figure shows the Query Subsystem which comprises Lexical Set Operations, Graph Operations, and History. Graph Operations sends data to LexBIG API and LexBIG Data Model (Loaders and Indexers) and LexGRID Vocabulary Model and Repository.
This subsystem provides the functionality required to fulfill caCORE/EVS and other vocabulary requests. The Query Service is comprised of Lexical Operations, Graph Operations, Metadata, and History Operations.
...
Client accesses LexEVS Grid Node Container via SOAP/HTTP. The LexEVS Grid Node accesses EVSAPI and then LexBIG via RMI. LexBIG accesses Database Servers containing vocabulary data. The database servers and loaded vocabulary configuration is a sample only.
LexEVS Grid Service and EVSAPI need not be deployed to physically separate servers, but it is recommended that if they are co-located on the same server, they should be deployed to separate JBoss containers.
...
- caGRID Service Context
- Resource Creator, Resource Home, and Resource Locator.
- Service Context which performs Service Context Grid Calls.
- Resource Instances
- Each of the three Resource Instances comprise Operations and Resource Properties.
- Each Resource Instance forwards data to LexBIG.
LexEVS Grid Service Class Diagram
The LexEVS Grid Service is built on the LexGrid/LexBIG model and implementation. For more information about this model, visit:
| Code Block |
|---|
Historical link
https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lexbig/lbModel/?root=lexevs |
| Code Block |
|---|
Historical link
LexGrid|https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lgModel/?root=lexevs |
...
For information specific to the LexEVS Grid Service, visit:
| Code Block |
|---|
Historical link
https://gforge.nci.nih.gov/plugins/scmsvn/viewcvs.php/LexBIG_Core_Services/LexBIG-2.3/lexbig/lbModel.cagrid/?root=lexevs |
...
The sequence diagram for the operation "getSupportedCodingSchemes" is described belowin the text that follows:
General Call Sequence Example
...
The client calls caGrid, 'getSupportedCodingSchemes()', caGrid Services calls Distributed LexBIG, 'getSupportedCodingSchemes()', LexBIG returns result of call to caGrid Service, and the results are returned to the client with all the appropriate caGrid security mechanisms.
Assumptions
...
- The client invokes a caGrid Service.
- caGrid Node Hosting Service uses Distributed LexBIG to implement a call.
- Distributed LexBIG returns the requested information to caGrid Service.
- caGrid Service returns a response to the client.
API Examples
Example clients, service calls, and SOAP messages (sample code on the LexEVS documentation GForge archive page)
Example API usage:
Searching for concepts in NCI Thesaurus containing the string "Gene"
| Include Page | ||||
|---|---|---|---|---|
|
Service Contexts and State
Along with the Main Service (as described above), the Server will also host the following Service Contexts. These Service Contexts are not meant to be called directly as Grid Services. The main function of these Service Contexts is to provide additional functionality to the Main Service. The following figure shows how the Service Context comprises a CodedNodeSet that have properties, such as ResolvedConceptReferenceList, Destroy, SetTermination Time, and other tasks.
...
In the figure below, two LexEVS Grid Service Calls are highlighted, 'getCodingSchemeConcepts' and 'getNodeGraph'. These two Grid Service Calls have been selected because they return to the user a "Reference" to a Service Context. For 'getCodingSchemeConcepts', the return type is CodedNodeSetReference (which references the CodedNodeSet Service Context). For 'getNodeGraph', the return type is CodedNodeGraphReference (which references the CodedNodeGraph Service Context).
Resources
LexEVS Grid Services use the WS-Resource Framework (WSRF) to allow for stateful calls to the server. When a client requests a Service Context, the client is not only issued a Reference to the Service Context that was requested, but to a unique stateful Resource on the server as well. This Resource is used in the LexEVS Grid Services as a way of statefully holding objects for further use by the client.
Refer to the following sources for more information:
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
Code Block Link provided for historical purposes http://gforge.nci.nih.gov/docman/view.php/491/13736/LexEVSGrid.ppt
Service Context Sequence
Service Context Sequence
Service Contexts API calls follow this Service Contexts API calls follow this general process:
- The client requests a Service Context, such as CodedNodeSet.
- The Grid Node receives the call and forwards the call to EVSAPI.
- EVSAPI calls getCodingSchemeConcept on the local LexBIG installation.
- The Grid Node creates a resource for the CodedNodeSetImpl object for future use.
- The client is returned the Service Context Client for the CodedNodeSet.
Service Context and Resource Assignment
...
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.
...
- The user requests a CodedNodeSet using getCodingSchemeConcepts.
Include Page RequestCodedNodeSet CodedNodeSet SnippetRequestCodedNodeSet CodedNodeSet Snippet - The server calls the Distributed LexBIG getCodingSchemeConcepts method, returning to the server an org.LexGrid.LexBIG.Impl.CodedNodeSetImpl (the implementation of org.LexGrid.LexBIG.LexBIGService.CodedNodeSet) object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeSet.service.globus.resource.CodedNodeSetResource. This Resource will be used to hold the instance of org.LexGrid.LexBIG.Impl.CodedNodeSetImpl, the implementation of org.LexGrid.LexBIG.LexBIGService.CodedNodeSet that was created above.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeSet.stubs.types.CodedNodeSetReference object to the client. This is the reference to the CodedNodeSet Service Context. This object has a direct reference to the Resource created above. The user now uses this client to make transparent Grid calls through the Service Context.
- The client may continue to make statefull calls to the CodedNodeSetClient and the assigned Resource.
- These restrictions are separate calls but statefully maintained on the server via the Resource.
...
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.
...
- The user requests a CodedNodeGraph using getCodingSchemeConcepts.
Include Page RequestCodedNodeGraph CodedNodeGraph SnippetRequestCodedNodeGraph CodedNodeGraph Snippet - The server calls the Distributed LexBIG getNodeGraph method, returning to the server an org.LexGrid.LexBIG.Impl.CodedNodeGraphImpl (the implementation of org.LexGrid.LexBIG.LexBIGService.CodedNodeGraph) object.
- The server then creates an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeGraph.service.globus.resource.CodedNodeGraphResource. This Resource will be used to hold the instance of org.LexGrid.LexBIG.Impl.CodedNodeGraphImpl, the implementation of org.LexGrid.LexBIG.LexBIGService.CodedNodeGraph that was created above.
- The server returns an org.LexGrid.LexBIG.cagrid.LexBIGCaGridServices.CodedNodeGraph.stubs.types.CodedNodeGraphReference object to the client. This is the reference to the CodedNodeGraph Service Context. This object has a direct reference to the Resource created above. The user now uses this client to make transparent Grid calls through the Service Context.
- The client may continue to make statefull calls to the CodedNodeGraphClient and the assigned Resource. For example, the client may add Restrictions to the CodedNodeGraph before a Resolve:
Include Page CodedNodeGraphRestriction Snippet CodedNodeGraphRestriction Snippet - These restrictions are separate calls but statefully maintained on the server via the Resource.
...
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.
...
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.
...
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.
...
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.
...
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.
...
If the URL is well-formed, proper connection is tested. If the connection attempt fails, a ConnectException is thrown containing the reason for the failure.
| Include Page | ||||
|---|---|---|---|---|
|
This example shows a typical connection to the LexEVS Grid Service, with the two potential Exceptions being caught and handled as necessary.
...
Security in the LexEVS Grid Service is implemented in the Distributed LexBIG layer. The information in this section explains how the LexEVS Grid Services utilize this security implementation. For more information, see Distributed LexBIG Security Implementation:
...
LexBIG Access to Licensed Vocabulary Implementation, attached to the EVS API GForge documents archive.
LexEVS Grid Service Security
...
A client establishes access to a secured vocabulary via the following Grid Service Calls:
Step 1:Connect to the LexBIG caGrid Service
Code Block LexBIGServiceGrid lbs = new LexBIGServiceGridAdapter(url);Step 3:Build an org.LexGrid.LexBIG.DataModel.cagrid.CodingSchemeIdentification to hold the Coding Scheme name.
Code Block CodingSchemeIdentification codingScheme = new CodingSchemeIdentification(); codingScheme.setName("codingScheme");Step 4:Build an gov.nih.nci.evs.security.SecurityToken containing the security information for the desired Coding Scheme.
Code Block SecurityToken token = new SecurityToken(); token.setAccessToken("securityToken");Step 5:Invoke the LexBIG caGrid service as follows: This will return a reference to a new "LexBIGServiceGrid" instance that is associated with the security properties that were passed in.
Code Block LexBIGServiceGrid lbsg = lbs.setSecurityToken(codingScheme, token);It is important to note that the Grid Service "setSecurityToken" returns an org.LexGrid.LexBIG.cagrid.LexEVSGridService.stubs.types
.LexEVSGridServiceReference.LexEVSGridServiceReference
object. This reference must be used to access the secured vocabularies.
Implementation
Each call to "setSecurityToken" sets up a secured connection to Distributed LexBIG with the access privileges included in the SecurityToken parameter. The LexEVSGridServiceReference that is returned to the client contains a unique key identifier to the secure connection that has been created on the server. All subsequent calls the client makes through this LexEVSGridServiceReference will be made securely. If additional SecurityTokens are passed in through the "setSecurityToken" Grid Service, the additional security will be added and maintained.
...
Both the current version of LexEVS grid service may be "in service" simultaneously if the corresponding underlying EVSAPI service is also "in service" to manage migration of clients.
System Testing
LexEVS Grid Service Testing Documentation (LexEVS Grid Service System Testing in the Project Documents, Development Documents section)
DOCUMENT APPROVAL
Approvers List
...
- For LexEVS v5.0, see LexEVS 5.0 Loader Source Mapping.
- For LexEVS v5.1, which includes enhancements to the loader framework, see LexEVS 5.1 Loader Source Mapping.
...
| Scrollbar | ||
|---|---|---|
|
