 |
Page History
...
| Panel | ||
|---|---|---|
| ||
Author: Traci St.Martin/Craig Stancl/Kevin Peterson/Scott Bauer/Sridhar Dwarkanath/Mike Turk |
Sign off | Date | Role | CBIIT or Stakeholder Organization | Reviewer's Comments (If disapproved indicate specific areas for improvement.) |
|---|---|---|---|---|
— | — | — | — | — |
The purpose of this document is to collect, analyze, and define high-level needs for and designed features of the National Cancer Institute Center for Biomedical Informatics and Information Technology (NCI CBIIT) caCORE LexEVS Release 5.1. The focus is on the functionalities proposed by the stakeholders and target users to make a better product. The use case documents show in detail how the features meet these needs.
...
Data Source layer--- is responsible for storage and access to all data required to represent the objects returned through API invocation.
High Level Design Diagram
...
The LexEVS Value Domain and Pick List Service meant to expose the API particularly for the Value Domain and Pick List elements of the LexGrid Logical Model. For more information on LexGrid model see http://informatics.mayo.edu\\
Improved Loader Framework
...
For example, an index of People may be indexed in Lucene as:
| No Format |
|---|
Document: id 1
First Name: John
Last Name: Doe
Sex: Male
Age: 45
Document: id 2
First Name: Jane
Last Name: Doe
Sex: Female
Age: 40
... etc.
|
LexEVS stores information about Entities in this way. Property names and values, as well as Qualifiers, Language, and various other information about the Entity are held in Lucene indexes.
Backgroud Backgronud - Querying Lucene
Lucene provides a Query mechanism to search through the indexed documents. Given a search query, Lucene will provide the Document id and the score of the match (Lucene assigns every match a 'score', depending on the strength of the match given the query).
...
- Lazy Retrieval
We can leverage this to increase performance in LexEVS. Consider this simplified LexEVS Entity index:
| No Format |
|---|
Document: id 1
Code: C12345
Name: Heart
Document: id 2
Code: C67890
Name: Foot
Document: id 3
Code: C98765
Name: Heart Attack
|
...
Class: | org.LexGrid.LexBIG.Extensions.Extendable.Search |
|---|---|
Method: | public org.apache.lucene.search.Query buildQuery(String searchText) |
Description: | Given a String search string, build a Query object to match indexed Lucene Documents |
...
WeightedDoubleMetaphoneQuery
This algorithm does not automatically assume that the user has spelled the terms incorrectly. Searches are also based on the actual text that the user has input, along with the Metaphone value.
Again, if the user input "Breast", the query will still match "Breast" and "Prostrate", but "Breast" will have a higher match score, because the actual user text is considered. This will add a greater precision to this fuzzy-type query.
Algorithm:
| No Format |
|---|
get: user text input
2: total score = 0
3: metaphone score = 0
4: actual score = 0
5: metaphone value = lucene.computeMetaphoneValue(user text input)
6: metaphone score = lucene.scoreMetaphoneValue(metaphone value)
7: actual score = lucene.score(user text input)
8: total score = metaphone score + actual score
9: halt
|
...
Also, a leading and trailing wildcard will be added, so
"th a heart atta"
Will also match:
"The patient with a heart attack was seen today".
Algorithm:
| No Format |
|---|
get: user text input
2: user text input = '*' + user text input + '*'
3: score = lucene.score(user text input)
4: halt
|
...
- Sorting on Different Class types
- A single Sort may be applicable for a variety of Class types. For instance, both an 'Association' and an 'Entity' may be sorted by 'Code', but the actual implementation of retrieving the Code and comparing it may be different between the two. It is the job of the Sort to implement a Comparator for each potential Class that it is eligible to sort.
- Default Sorting
- All result sets are sorted by default by Lucene Score, meaning that the best match according to Lucene will always be returned first by default. Note that if two or more result sets are being Unioned, Intersected, or Differenced, the user must explicitly call a 'matchToQuery' sort on the result set as a whole to order all of the results.
- Sort Contexts
- Sorts may be applicable in one or more 'Contexts' (see: org.LexGrid.LexBIG.DataModel.InterfaceElements.types.SortContext)
This means that a Sort may apply only to a CodedNodeSet, or only to a CodedNodeGraph, or some combination. Sorts will only be employed by the API if they match the Context in which the results are being sorted.
- Sorts may be applicable in one or more 'Contexts' (see: org.LexGrid.LexBIG.DataModel.InterfaceElements.types.SortContext)
- Performance Issues
- Sorting is generally computationally expensive, because in order to correctly sort, the field to be sorted has to be fully retrieved for the entire result set. For very specific or refined queries, this may not be a problem, but for large ontologies or very general queries, performance may be a concern. To alleviate this, 'Post sort' has been introduced.
- Post Sorting
In order to minimize the performance impact of sorting, users are encouraged to use a 'Post sort' where possible. A Post sort is done after the result set has been restricted, thus limiting the amount of information that must be retrieved in order to perform the sort. For instance, a query may match a set of Entities:
No Format {"Heart", "Heart Failure", "Heart Attack", "Arm", "Finger", ...}
As described earlier, all results are by default sorted by Lucene score, so if we limit the result set to the top 3, the result is:
| No Format |
|---|
{"Heart", "Heart Failure", "Heart Attack"}
|
The restricted set can then be 'Post' sorted - and because the result set has be limited to a reasonable number of matches, sorting and retrieval time can be minimized.
Algorithm:
| No Format |
|---|
1: get: Sort requested by user
2: get: Context sort is being applied to
3: if: sort is not valid for Context
halt
4: else:
5: get: Class to be sorted on
6: if: sort is not valid for Class
halt
7: get: Comparator for Sort - given (Class to be sorted on)
8: sort results using Comparator for Sort
9: halt
|
...
Code | Qualifier |
|---|---|
C01234 | isAnOrgan |
C98765 | isADisease |
| No Format |
|---|
SELECT * FROM Codes
|
Results in:
...
To get the Qualifiers, separate SELECTs must be used for each.
| No Format |
|---|
SELECT * FROM Qualifiers where Code = C01234
And
SELECT * FROM Qualifiers where Code = C98765
|
...
Code | Qualifier |
|---|---|
C01234 | isAnOrgan |
C98765 | isADisease |
| No Format |
|---|
SELECT * FROM Codes JOIN Qualifiers ON Code
|
...
Most data elements will be loaded as either properties or property qualifiers:
A few will be loaded as qualifiers to associations.
...
Here is a UML representation of Value Domain within LexGrid 200901 model.!value_domain_VDModel.jpg,alt="UML representation of Value Domain wihtin LexGrid 200901 model"!
Value Domain Definition
...
Here is a UML representation of Pick List within LexGrid 200901 model:!value_domain_PLModel.jpg,alt="UML representation of Pick List within LexGrid 200901 model"!
Pick List Definition
...
Class Name | Description |
|---|---|
VDEntryTypeServices | Class to handle Entry Type objects to and fro database . |
VDEntryStateServices | Class to handle Entry State objects to and fro database. |
VDPropertyServices | Class to handle Property objects to and fro database. |
VDMappingServices | Class to handle supported Mappings objects to and fro database. |
VDServiceHelper | Helper class containing methods that are commonly used. |
VDBaseSQLServices | Class to handle SQL Services. |
VDBaseService | Base service class to handle all Value Domain and Pick List related objects to and fro from database. |
!value_domain_CommonClassDiagram.jpg.alt\"value domain CommonClassDiagram"!
Value Domain Class Diagram
...
Class Name | Description |
|---|---|
VDSServices | Class to handle list of Value Domain Definitions Object to and fro database |
VDServices | Class to handle individual Value Domain Definition objects to and fro database. |
VDEntryServices | Class to handle Value Domain Entry objects to and fro database. |
LexEVSValueDomainServices | Primary interface for LexEVS Value Domain API |
LexEVSValueDomainServicesImpl | Implementation of LexEVSValueDomainServices which is primary interface for LexEVS Value Domain API. |
LoadValueDomain | Imports the value Domain Definitions in the source file, provided in LexGrid canonical format, to the LexBIG repository. |
ResolvedValueDomainCodedNodeSet | Contains coding scheme version reference list that was used to resolve the value domain and the coded node set. |
ResolvedValueDomainDefinition | A resolved Value Domain definition containing the coding scheme version reference list that was used to resolve the value domain and an iterator for resolved concepts. |
!value_domain_VDClassDiagram.jpg,alt="value domain VDClassDiagram"!
Pick List Class Diagram
Classes that implements LexEVS Pick List API
Class Name | Description |
|---|---|
PickListsServices | Class to handle list of Pick List Definitions. |
PickListServices | Class to handle individual Pick List Definition objects to and fro database. |
PLEntryServices | Class to handle Pick List Entry objects to and fro database. |
LexEVSPickListServices | Primary interface for LexEVS Pick List API. |
LexEVSPickListServicesImpl | Implementation of LexEVSPickListServices which is primary interface for LexEVS Pick List API. |
LoadPickList | Imports the Pick List Definitions in the source file, provided in LexGrid canonical format, to the LexBIG repository. |
ResolvedPickListEntyList | Class to hold list of resolved pick list entries. |
ResolvedPickListEntry | Bean for resolved pick list entries. |
...
Method Name | Description |
|---|---|
getValueDomainService() | Returns an interface to LexEVS Value Domain API |
getPickListService() | Returns an interface to LexEVS Pick List API. |
!value_domain_LexBIGServiceClassDiagram.jpg,alt="value domain LexBIGServiceClassDiagram"!
Main Service API
...
An interface to LexEVS Value Domain and Pick List Services could be obtained using an instance of LexBigService.
Information | getValueDomainService() |
|---|---|
Description: | Returns an interface to LexEVS Value Domain API. |
Input: | none |
Output: | org.lexgrid.valuedomain.LexEVSValueDomainServices |
Exception: | LBException |
Implementation Details: | Implementation: |
Information | getPickListService() |
|---|---|
Description: | Returns an interface to LexEVS Pick List API. |
Input: | none |
Output: | org.lexgrid valuedomain.LexEVSPickListServices |
Exception: | LBException |
Implementation Details: | Implementation: |
LexEVS Value Domain Service API - Loading Value Domain
...
Information | loadValueDomain(ValueDomainDefinition vddef, String systemReleaseURI) |
|---|---|
Description: | Loads supplied valueDomainDefinition object |
Input: | org.LexGrid.emf.valueDomains.ValueDomainDefinition, |
Output: | none |
Exception: | LBException |
Implementation Details: | Implementation: |
Information | loadValueDomain(InputStream inputStream,boolean failOnAllErrors)) |
|---|---|
Description: | Loads valueDomainDefinitions found in inputStream |
Input: | java.io.InputStream |
Output: | none |
Exception: | Exception |
Implementation Details: | Implementation: |
Information | loadValueDomain(String xmlFileLocation, boolean failOnAllErrors) | |
|---|---|---|
Description: | Loads valueDomainDefinitions found in input xml file | |
Input: | java.lang.String | |
Output: | none | |
Exception: | Exception | |
Implementation Details: | Implementation: |
|
Validate XML resources
Information | validate(URI uri, int valicationLevel) throws LBParameterException |
|---|---|
Description: | Perform validation of the candidate resource without loading data. |
Input: | java.net.URI |
Output: | none |
Exception: | Org.LexGrid.LexBIG.Exceptions.LBParameterException |
Implementation Details: | Implementation: |
Query Value Domain
Information | isConceptInDomain(String entityCode, URI valueDomainURI) |
|---|---|
Description: | Determine if the supplied entity code is a valid result for the supplied value domain and, if it is, return the particular codingSchemeVersion that was used. |
Input: | java.lang.String, |
Output: | org.LexGrid.LexBIG.DataModel.Core. AbsoluteCodingSchemeVersionReference |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | isConceptInDomain(String entityCode, URI entityCodeNamespace, CodingSchemeVersionOrTag csvt, URI valueDomainURI) |
|---|---|
Description: | Similar to previous method, this method determine if the supplied entity code and entity namespace is a valid result for the supplied value domain when resolved against supplied Coding Scheme Version or Tag. |
Input: | java.lang.String, |
Output: | org.LexGrid.LexBIG.DataModel.Core. AbsoluteCodingSchemeVersionReference |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | resolveValueDomain(URI valueDomainURI, AbsoluteCodingSchemeVersionReferenceList csVersionList) |
|---|---|
Description: | Resolve a value domain using the supplied set of coding scheme versions. |
Input: | java.net.URI, |
Output: | org.lexgrid.valuedomain.dto.ResolvedValueDomainDefinition |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | isSubDomain(URI childValueDomainURI, URI parentValueDomainURI) |
|---|---|
Description: | Check whether childValueDomainURI is a child of parentValueDomainURI. |
Input: | java.net.URI, |
Output: | boolean |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | getValueDomainDefinition(URI valueDomainURI) |
|---|---|
Description: | Returns value domain definition for supplied value domain URI. |
Input: | java.net.URI |
Output: | org.LexGrid.emf.valueDomains.ValueDomainDefinition |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | listValueDomains(String valueDomainName) | ||
|---|---|---|---|
Description: | Return the URI's for the value domain definition(s) for the supplied domain name. If the name is null, returns everything. If the name is not null, returns the value domain(s) that have the assigned name. | ||
Input: | java.lang.String | ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f41bfa27-4ce3-462a-a78d-f3d1ef50b0ec"><ac:plain-text-body><![CDATA[ | Output: | java.net.URI[] | ]]></ac:plain-text-body></ac:structured-macro> |
Output: | java.net.URI[] | ||
Exception: | org.LexGrid.LexBIG.Exceptions.LBException | Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | getAllValueDomainsWithNoNames() | |
|---|---|---|
Description: | Return the URI's of all unnamed value domain definition(s). | |
Input: | none | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="142dbe25-2fe1-48f7-a9cc-b3661c1cd595"><ac:plain-text-body><![CDATA[ | Output: | java.net.URI[] |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException | |
Implementation Details: | Implementation: |
Information | getValueDomainEntitiesForTerm(String term, URI valueDomainURI, String matchAlgorithm) |
|---|---|
Description: | Resolves the value domain supplied and restricts to the term and matchAlgorith supplied. Return object ResolvedValueDomainCodedNodeSet contains the codingScheme URI and Version that was used to resolve and the CodedNodeSet. |
Input: | java.lang.String, |
Output: | org.lexgrid.valuedomain.dto.ResolvedValueDomainCodedNodeSet |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | getCodingSchemesInValueDomain(URI valueDomainURI) |
|---|---|
Description: | Returns list of coding scheme summary that is referenced by the supplied value domain. |
Input: | java.net.URI |
Output: | org.LexGrid.LexBIG.DataModel.Collections. AbsoluteCodingSchemeVersionReferenceList |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | isDomain(String entityCode, String codingSchemeName, CodingSchemeVersionOrTag csvt) |
|---|---|
Description: | Determine if the supplied entity code is of type valueDomain in supplied coding scheme and, if it is, return the true, otherwise return false. |
Input: | java.lang.String, |
Output: | boolean |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Remove Value Domain Definition
Information | removeValueDomain(URI valueDomainURI) |
|---|---|
Description: | Removes supplied value domain definition from the system. |
Input: | java.net.URI |
Output: | none |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException, |
Implementation Details: | Implementation: |
Information | removeAllValueDomains() |
|---|---|
Description: | Removes all value domain definitions from the system. |
Input: | none |
Output: | none |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException, |
Implementation Details: | Implementation: |
Drop Value Domain tables
Information | dropValueDomainTables() |
|---|---|
Description: | Drops value domain tables only if there are no value domain and pick list entries. |
Input: | none |
Output: | none |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException, |
Implementation Details: | Implementation: |
LexEVS Pick List Service API
...
There are three methods that could be used to load Pick List Definitions :
Information | loadPickList(PickListDefinition pldef, String systemReleaseURI) |
|---|---|
Description: | Loads supplied Pick List Definition object |
Input: | org.LexGrid.emf.valueDomains.PickListDefinition, |
Output: | none |
Exception: | LBException |
Implementation Details: | Implementation: |
...
Information |
| loadPickList(InputStream inputStream, boolean failOnAllErrors) |
|---|---|---|
Description: | Loads Pick List Definitions found in inputStream | |
Input: | java.io.InputStream | |
Output: | none | |
Exception: | Exception | |
Implementation Details: | Implementation: |
Information | loadPickList (String xmlFileLocation, boolean failOnAllErrors) |
|---|---|
Description: | Loads Pick List Definitions found in input xml file |
Input: | java.lang.String |
Output: | none |
Exception: | Exception |
Implementation Details: | Implementation: |
Validate XML resources
Information | validate(URI uri, int valicationLevel) throws LBParameterException |
|---|---|
Description: | Perform validation of the candidate resource without loading data. |
Input: | java.net.URI |
Output: | none |
Exception: | Org.LexGrid.LexBIG.Exceptions.LBParameterException |
Implementation Details: | Implementation: |
Query Pick List
Information | getPickListDefinitionById(String pickListId) |
|---|---|
Description: | Returns pickList definition for supplied pickListId. |
Input: | java.lang.String |
Output: | org.LexGrid.emf.valueDomains.PickListDefinition |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
Information | getPickListDefinitionsForDomain(URI valueDomainURI) | ||
|---|---|---|---|
Description: | Returns all the pickList definitions that represents supplied valueDomain URI. | ||
Input: | java.net.URI | ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a30994cc-41da-4660-bf75-bcfe31e9b40f"><ac:plain-text-body><![CDATA[ | Output: | org.LexGrid.emf.valueDomains.PickListDefinition[] | ]]></ac:plain-text-body></ac:structured-macro> |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException | ||
Implementation Details: | Implementation: | ]]></ac:plain-text-body></ac:structured-macro> |
Information |
| getPickListValueDomain(String pickListId) |
|---|---|---|
Description: | Returns an URI of the represented valueDomain of the pickList. | |
Input: | java.lang.String | |
Output: | java.net.URI | |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException | |
Implementation Details: | Implementation: |
Information | listPickListIds() |
|---|---|
Description: | Returns a list of pickListIds that are available in the system. |
Input: | none |
Output: | java.util.List<java.lang.String> |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException |
Implementation Details: | Implementation: |
...
Information |
| resolvePickList(String pickListId, boolean sortByText) |
|---|---|---|
Description: | Resolves pickList definition for supplied pickListId. | |
Input: | java.langString, | |
Output: | org.lexgrid.valuedomain.dto.ResolvedPickListEntryList | |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException | |
Implementation Details: | Implementation: |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="0f73f091-8a1c-44b2-ba38-1e4e0c5ba230"><ac:plain-text-body><![CDATA[ | Information | resolvePickListForTerm(String pickListId, String term, String matchAlgorithm, String language, String[] context, boolean sortByText) | ]]></ac:plain-text-body></ac:structured-macro> |
|---|---|---|---|
Description: | Resolves pickList definition by applying supplied arguments. | ||
Input: | java.lang.String, | ||
Output: | org.lexgrid.valuedomain.dto.ResolvedPickListEntryList | ||
Exception: | org.LexGrid.LexBIG.Exceptions.LBException | ||
Implementation Details: | Implementation: |
Remove Pick List Definition
Information | removePickList(String pickListId) |
|---|---|
Description: | Removes supplied Pick List Definition from the system. |
Input: | java.lang.String |
Output: | none |
Exception: | org.LexGrid.LexBIG.Exceptions.LBException, |
Implementation Details: | Implementation: |
Resolved Value Domain Objects
ResolvedValueDomainCodedNodeSet
Contains Coding Scheme Version reference list that was used to resolve the Value Domain and the CodedNodeSet.
The CodedNodeSet is not resolved.
ResolvedValueDomainDefinition
A resolved Value Domain Definition containing the Coding Scheme Version reference list that was used to resolve the Value Domain and an iterator for resolved concepts.
Resolved Pick List Objects
ResolvedPickListEntry
Contains resolved Pick List Entry Nodes
ResolvedPickListEntryList
Contains the list of resolved Pick List Entries. Also provides helpful features to add, remove, enumerate Pick List Entries.
Error Handling
Both LexEVS Value Domain and Pick List services uses org.LexGrid.LexBIG.Impl.loaders.MessageDirector to direct all fatal, error, warning, info messages with appropriate messages to the LexBIG log files in the 'log' folder of LexEVS install directory.
Along with MessageDirector, the services will also make use of org.LexGrid.LexBIG.exception.LBException to throw any fatal and error messages to the log file as well as to console.
Load Scripts
Scripts to load Value Domain and Pick List Definitions into LexEVS system will be located under 'Admin' folder of LexEVS install directory. This loader scripts will only load data in XML file that is in LexGrid format.
Value Domain Loader
LoadValueDomain.bat for Windows environment and LoadValueDomain.sh for Unix environment.
Both these scripts takes take in following parameters :
Parameter | Function |
|---|---|
-in | Input <uri> URI or path specifying location of the source file. |
-v | Validate <int> Perform validation of the candidate resource without loading data. |
Example:
| No Format |
|---|
sh LoadValueDomain.sh \-in "file:///path/to/file.xml"
|
Pick List Loader
LoadPickList.bat for Windows environment and LoadPickList.sh for Unix environment.
Both these scripts takes take in following parameters:
Parameter | Function |
|---|---|
-in | Input <uri> URI or path specifying location of the source file. |
-v | Validate <int> Perform validation of the candidate resource without loading data. |
Example:
| No Format |
|---|
sh LoadPickList.sh \-in "file:///path/to/file.xml"
|
Sample XML files
Value Domain Definitions
Below is a sample XML file containing Value Domain Definitions in LexGrid format that can be loaded using LexEVS Value Domain Service.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<?xml version="1.0" encoding="UTF-8"?>
<systemRelease xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://LexGrid.org/schema/2009/01/LexGrid/versions http://LexGrid.org/schema/2009/01/LexGrid/versions.xsd"
xmlns="http://LexGrid.org/schema/2009/01/LexGrid/versions" xmlns:lgVer="http://LexGrid.org/schema/2009/01/LexGrid/versions"
xmlns:lgCommon="http://LexGrid.org/schema/2009/01/LexGrid/commonTypes" xmlns:data="data"
xmlns:lgVD="http://LexGrid.org/schema/2009/01/LexGrid/valueDomains" xmlns:lgNaming="http://LexGrid.org/schema/2009/01/LexGrid/naming"
releaseURI="http://testRelease/04" releaseDate="2008-11-07T14:55:51.615-06:00">
<lgCommon:entityDescription>Sample value domains</lgCommon:entityDescription>
<lgVer:valueDomains>
<lgVD:mappings>
<lgNaming:supportedAssociation localId="hasSubtype" uri="urn:oid:1.3.6.1.4.1.2114.108.1.8.1">hasSubtype</lgNaming:supportedAssociation>
<lgNaming:supportedCodingScheme localId="Automobiles" uri="urn:oid:11.11.0.1">Automobiles</lgNaming:supportedCodingScheme>
<lgNaming:supportedDataType localId="testhtml">test/html</lgNaming:supportedDataType>
<lgNaming:supportedDataType localId="textplain">text/plain</lgNaming:supportedDataType>
<lgNaming:supportedHierarchy localId="is_a" associationNames="hasSubtype" isForwardNavigable="true" rootCode="@">hasSubtype</lgNaming:supportedHierarchy>
<lgNaming:supportedLanguage localId="en" uri="www.en.org/orsomething">en</lgNaming:supportedLanguage>
<lgNaming:supportedNamespace localId="Automobiles" uri="urn:oid:11.11.0.1" equivalentCodingScheme="Automobiles">Automobiles</lgNaming:supportedNamespace>
<lgNaming:supportedProperty localId="textualPresentation">textualPresentation</lgNaming:supportedProperty>
<lgNaming:supportedSource localId="lexgrid.org">lexgrid.org</lgNaming:supportedSource>
<lgNaming:supportedSource localId="_111101">11.11.0.1</lgNaming:supportedSource>
</lgVD:mappings>
<lgVD:valueDomainDefinition valueDomainURI="SRITEST:AUTO:DomesticAutoMakers" valueDomainName="Domestic Auto Makers" defaultCodingScheme="Automobiles" effectiveDate="2009-01-01T11:00:00Z" isActive="true" status="ACTIVE">
<lgVD:properties>
<lgCommon:property propertyName="textualPresentation">
<lgCommon:value> Domestic Auto Makers</lgCommon:value>
</lgCommon:property>
</lgVD:properties>
<lgVD:definitionEntry ruleOrder="1" operator="OR">
<lgVD:entityReference entityCode="005" referenceAssociation="hasSubtype" transitiveClosure="true" targetToSource="false" leafOnly="false"/>
</lgVD:definitionEntry>
</lgVD:valueDomainDefinition>
<lgVD:valueDomainDefinition valueDomainURI="SRITEST:AUTO:AllDomesticButGM" valueDomainName="All Domestic Autos But GM" defaultCodingScheme="Automobiles" effectiveDate="2009-01-01T11:00:00Z" isActive="true" status="ACTIVE">
<lgVD:properties>
<lgCommon:property propertyName="textualPresentation">
<lgCommon:value> Domestic Auto Makers</lgCommon:value>
</lgCommon:property>
</lgVD:properties>
<lgVD:definitionEntry ruleOrder="1" operator="OR">
<lgVD:entityReference entityCode="005" referenceAssociation="hasSubtype" transitiveClosure="true" targetToSource="false" leafOnly="false"/>
</lgVD:definitionEntry>
<lgVD:definitionEntry ruleOrder="2" operator="SUBTRACT">
<lgVD:entityReference entityCode="GM" referenceAssociation="hasSubtype" transitiveClosure="true" targetToSource="false" leafOnly="false"/>
</lgVD:definitionEntry>
</lgVD:valueDomainDefinition>
<lgVD:valueDomainDefinition valueDomainURI="SRITEST:AUTO:AllDomesticANDGM" valueDomainName="All Domestic Autos AND GM" defaultCodingScheme="Automobiles" effectiveDate="2009-01-01T11:00:00Z" isActive="true" status="ACTIVE">
<lgVD:properties>
<lgCommon:property propertyName="textualPresentation">
<lgCommon:value> Domestic Auto Makers AND GM</lgCommon:value>
</lgCommon:property>
</lgVD:properties>
<lgVD:definitionEntry ruleOrder="1" operator="OR">
<lgVD:entityReference entityCode="005" referenceAssociation="hasSubtype" transitiveClosure="true" targetToSource="false" leafOnly="false"/>
</lgVD:definitionEntry>
<lgVD:definitionEntry ruleOrder="2" operator="AND">
<lgVD:entityReference entityCode="GM" referenceAssociation="hasSubtype" transitiveClosure="true" targetToSource="false" leafOnly="false"/>
</lgVD:definitionEntry>
</lgVD:valueDomainDefinition>
<lgVD:valueDomainDefinition valueDomainURI="SRITEST:AUTO:DomasticLeafOnly" valueDomainName="Domestic Leaf Only" defaultCodingScheme="Automobiles" effectiveDate="2009-01-01T11:00:00Z" isActive="true" status="ACTIVE">
<lgVD:properties>
<lgCommon:property propertyName="textualPresentation">
<lgCommon:value>Domestic Leaf Only</lgCommon:value>
</lgCommon:property>
</lgVD:properties>
<lgVD:definitionEntry ruleOrder="1" operator="OR">
<lgVD:entityReference entityCode="005" referenceAssociation="hasSubtype" transitiveClosure="true" targetToSource="false" leafOnly="true"/>
</lgVD:definitionEntry>
</lgVD:valueDomainDefinition>
</lgVer:valueDomains>
</systemRelease>
|
Pick List Definitions
Below is a sample XML file containing Pick List Definitions in LexGrid format that can be loaded using LexEVS Pick List Service.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<?xml version="1.0" encoding="UTF-8"?>
<systemRelease xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://LexGrid.org/schema/2009/01/LexGrid/versions http://LexGrid.org/schema/2009/01/LexGrid/versions.xsd"
xmlns="http://LexGrid.org/schema/2009/01/LexGrid/versions" xmlns:lgVer="http://LexGrid.org/schema/2009/01/LexGrid/versions"
xmlns:lgCommon="http://LexGrid.org/schema/2009/01/LexGrid/commonTypes" xmlns:data="data"
xmlns:lgVD="http://LexGrid.org/schema/2009/01/LexGrid/valueDomains" xmlns:lgNaming="http://LexGrid.org/schema/2009/01/LexGrid/naming"
releaseURI="http://testRelease/04" releaseDate="2008-11-07T14:55:51.615-06:00">
<lgCommon:entityDescription>Sample value domains</lgCommon:entityDescription>
<pickLists>
<lgVD:mappings>
<lgNaming:supportedCodingScheme localId="Automobiles" uri="urn:oid:11.11.0.1">Automobiles</lgNaming:supportedCodingScheme>
<lgNaming:supportedLanguage localId="en" uri="www.en.org/orsomething">en</lgNaming:supportedLanguage>
<lgNaming:supportedNamespace localId="Automobiles" uri="urn:oid:11.11.0.1" equivalentCodingScheme="Automobiles">Automobiles</lgNaming:supportedNamespace>
<lgNaming:supportedProperty localId="textualPresentation">textualPresentation</lgNaming:supportedProperty>
<lgNaming:supportedSource localId="lexgrid.org">lexgrid.org</lgNaming:supportedSource>
<lgNaming:supportedSource localId="_111101">11.11.0.1</lgNaming:supportedSource>
</lgVD:mappings>
<lgVD:pickListDefinition pickListId="SRITEST:AUTO:DomesticAutoMakers" representsValueDomain="SRITEST:AUTO:DomesticAutoMakers" isActive="true" defaultEntityCodeNamespace="Automobiles" defaultLanguage="en" completeDomain="false">
<lgCommon:owner>Owner for Domestic Auto Makers</lgCommon:owner>
<lgCommon:entityDescription>DomesticAutoMakers</lgCommon:entityDescription>
<lgVD:mappings>
<lgNaming:supportedCodingScheme localId="Automobiles" uri="urn:oid:11.11.0.1">Automobiles</lgNaming:supportedCodingScheme>
<lgNaming:supportedDataType localId="texthtml">text/html</lgNaming:supportedDataType>
<lgNaming:supportedDataType localId="textplain">text/plain</lgNaming:supportedDataType>
<lgNaming:supportedLanguage localId="en" uri="www.en.org/orsomething">en</lgNaming:supportedLanguage>
<lgNaming:supportedNamespace localId="Automobiles" uri="urn:oid:11.11.0.1" equivalentCodingScheme="Automobiles">Automobiles</lgNaming:supportedNamespace>
<lgNaming:supportedProperty localId="textualPresentation">textualPresentation</lgNaming:supportedProperty>
<lgNaming:supportedSource assemblyRule="rule1" uri="http://informatics.mayo.edu" localId="lexgrid.org">lexgrid.org</lgNaming:supportedSource>
<lgNaming:supportedSource localId="_111101">11.11.0.1</lgNaming:supportedSource>
</lgVD:mappings>
<lgVD:pickListEntryNode pickListEntryId="PLGMp1" isActive="true">
<lgCommon:owner>Owner for PLGMp1</lgCommon:owner>
<lgCommon:entryState containingRevision="R001" relativeOrder="1" changeType="NEW" prevRevision="R00A"/>
<lgVD:inclusionEntry entityCode="GM" entityCodeNamespace="Automobiles" propertyId="p1">
<lgVD:pickText>General Motors</lgVD:pickText>
</lgVD:inclusionEntry>
<lgVD:properties>
<lgCommon:property propertyName="textualPresentation" isActive="true" language="en" propertyId="p1" propertyType="presentation" status="active" effectiveDate="2001-12-17T09:30:47Z" expirationDate="2011-12-17T09:30:47Z">
<lgCommon:owner role="role" subRef="subref">General Motors</lgCommon:owner>
<lgCommon:entryState containingRevision="R001" relativeOrder="1" changeType="NEW" prevRevision="R00A"/>
<lgCommon:source subRef="subref1" role="role1">General Motors</lgCommon:source>
<lgCommon:value dataType="textplain">Property for General Motors</lgCommon:value>
</lgCommon:property>
</lgVD:properties>
</lgVD:pickListEntryNode>
<lgVD:pickListEntryNode pickListEntryId="PLGMp2" isActive="true">
<lgCommon:owner>Owner for PLGMp2</lgCommon:owner>
<lgCommon:entryState containingRevision="R001" relativeOrder="1" changeType="NEW" prevRevision="R00A"/>
<lgVD:inclusionEntry entityCode="GM" entityCodeNamespace="Automobiles" propertyId="p2">
<lgVD:pickText>GM</lgVD:pickText>
</lgVD:inclusionEntry>
</lgVD:pickListEntryNode>
<lgVD:pickListEntryNode pickListEntryId="PLJaguarp1" isActive="true">
<lgCommon:owner>Owner for PLJaguarp1</lgCommon:owner>
<lgCommon:entryState containingRevision="R001" relativeOrder="1" changeType="NEW" prevRevision="R00A"/>
<lgVD:inclusionEntry entityCode="Jaguar" entityCodeNamespace="Automobiles" propertyId="p1">
<lgVD:pickText>Jaguar</lgVD:pickText>
</lgVD:inclusionEntry>
</lgVD:pickListEntryNode>
<lgVD:pickListEntryNode pickListEntryId="PLChevroletp1" isActive="true">
<lgCommon:owner>Owner for PLChevroletp1</lgCommon:owner>
<lgCommon:entryState containingRevision="R001" relativeOrder="1" changeType="NEW" prevRevision="R00A"/>
<lgVD:inclusionEntry entityCode="Chevy" entityCodeNamespace="Automobiles" propertyId="p1">
<lgVD:pickText>Chevrolet</lgVD:pickText>
</lgVD:inclusionEntry>
</lgVD:pickListEntryNode>
</lgVD:pickListDefinition>
<lgVD:pickListDefinition pickListId="SRITEST:AUTO:DomasticLeafOnly" representsValueDomain="SRITEST:AUTO:DomasticLeafOnly" completeDomain="true" defaultEntityCodeNamespace="Automobiles" defaultLanguage="en" isActive="true">
<lgCommon:entityDescription>Leaf Only Nodes of Domastic AutoMakers</lgCommon:entityDescription>
</lgVD:pickListDefinition>
</pickLists>
</systemRelease>
|
Database structure
Value Domain Tables
Table Name | Description |
|---|---|
valueDomain | Will contain Value Domain Definition information |
vdEntry | Contains Value Domain Entries information and its rules |
entryState | Contains entry state details of every entry |
mappings | Contains supported mapping information for a Value Domain Definition |
property | Contains Property informations for Value Domain Definition |
Pick List Tables
Table Name | Description |
|---|---|
pickList | Will contain Pick List Definition information |
plEntry | Contains Pick List Entry Nodes information |
entryState | Contains entry state details of every entry |
mappings | Contains supported mapping information for a Pick List Definition |
property | Contains Property informations for Pick List Definition and its Nodes |
Installation / Packaging
Both LexEVS Value Domain and Pick List services are integrated part of core LexEVS API and will be packaged and installed with other LexEVS services.
System Testing
Value Domain Service
The System test case for the LexEVS Value Domain service is performed using the JUnit test suite:
...
This test suite will be run as part of regular LexEVS test suites AllTestsAllConfigs and AllTestsNormalConfigs.
Pick List Service
The System test case for the LexEVS Value Domain service is performed using the JUnit test suite:
...
This test suite will be run as part of regular LexEVS test suites AllTestsAllConfigs and AllTestsNormalConfigs.
Improved Loader Framework Detailed Design
Document Purpose
This document provides the detailed design and implementation of LexBIG Enterprise Vocabulary Service (LexEVS) Loader Framework Extension. It is also the goal of this document to provide enough information to allow those persons wishing to create their own loaders can do so. This document will also assume the reader is already familiar with the LexEVS software.
Implementation Overview
Description
The LexEVS software already provides a set of loaders within an existing legacy framework which served LexEVS developers well over many years. But as LexEVS has gained users, and requests for new loaders has grown , it was decided that a new loader framework should be developed that would: (1) be easier to extend (2) provide improved performance (3) dynamic loading of new loaders (4) take advantage of proven open source components such as Spring Batch and Hibernate.
...
Also, this Framework is completely independent of the current loader code so there is no impact to current loaders.
Scope
The LexEVS Loader Framework will provide a way for LexEVS developers to write new loaders and have them recognized dynamically by the LexEVS code. Also the framework will provide help to loader developers in the form of utility classes and interfaces.
Architecture
The LexEVS Loaders Framework extend the functionality of LexBIG 5.0 . For more information on LexBIG, see https://cabig-kc.nci.nih.gov/Vocab/KC/index.php/LexEVS_Version_refer to LexEVS 5.0.
High Level Overview
Figure 1 (below) The following figure shows the major components of the Loader Framework (A) in relation to a hypothetical new loader and what expected API usage would be. Ideally, the new loader can find make most if its API calls through the utilities provided by the Loader Framework API (B). Some work will need to be done with Spring (C) such as configuration of a Spring config file. Also it may or may not be necessary for a loader to use Hibernate (D) or use the LexBIG API (E). However, again, the hope is that much of the work a new loader may need to do can be accomplished by the Loader Framework API.
The Loader Framework utilizes Spring Batch for managing its Java objects to improve performance and Hibernate provides the mapping to the LexGrid database.
Figure 1
Assumptions
- None
Dependencies
- This Loader Framework requires LexEVS release 5.0 or above.
- Development system are required to install the Sun Java Development Kit (SDK) or Java Runtime Environment (JRE) version 1.5.0_11 or above.
- Maven 2.1 or greater.For software and hardware dependencies for the system hosting the LexEVS runtime, refer to greater.
- For software and hardware dependencies for the system hosting the LexEVS runtime, refer to the LexEVS 5.0 https://cabig-kc.nci.nih.gov/Vocab/KC/index.php/LexEVS_5.0_ Documentation.
Issues
- None
Third Party Tools
- Spring: A lightweight open-source application framework.
- Spring see http://www.springsource.com/
- Spring Batch see http://static.springsource.org/spring-batch/
- Sprint Batch Reference see http://static.springsource.org/spring-batch/reference/html/index.html
- Hibernate: An open source Java persistence framework. See https://www.hibernate.org/
- Maven: Apache build manager for Java projects. See http://maven.apache.org/
- Eclipse: An Open Source IDE. See http://www.eclipse.org/
Implementation Contents
Development and Build Environment
The Loader Framework code is available in the NCI Subversion (SVN) repository. It is comprised of three Framework projects. Also at the time of this writing there are three projects in the repository that utilize the Loader Framework. These projects utilize Maven for build and dependency management.
...
The above projects are built and managed by Maven.
Maven plugin for Eclipse: http://m2eclipse.codehaus.org/
How to Use the Loader Framework: A Roadmap
So you want to write a loader and use the Loader Framework. What are the key considerations?
In general the process can be described as:
...
An example may help in understanding the Framework. Our discussion will refer to the following figure 2 below. Lets say we are writing a loader to load the ICD-9-CM codes and their description which are contained in a text file. We know we'll need a data structure to hold the data after we've read it so we have a class:
| No Format |
|---|
ICD9SourceObject {
String id;
String descr;
String getId() { return id; }
}
|
Enter Spring. The Loader Framework uses Spring Batch to manage the reading, processing and writing of data. Spring provides classes and interfaces to help do this work and the Loader Framework also provides utilities to help loader developers. In our example, we will write a class that will use the Spring ItemReader interface. It will take a line of text and return an ICD9SourceObject (1 and 2). Next we'll want to process that data into a LexEVS object such as an Entity object. So we'll write class that implements Spring's ItemProcessor interface. It will take our ICD9SourceObject and output a LexEVS Entity object (3,4). Finally, we'll want to write the data to the database (5). Note that the LexEVS model objects provided in the Loader Framework are generated by Hibernate and utilize Hibernate to write the data to the database. This will free us from having to write SQL.
Figure 2
Spring
You will need to configure Spring to be aware of your objects and how to manage them. This is done via a XML configuration file. More details on the Spring config file below.
...
From the Maven documentation:
For more information on the Maven project see:
http://maven.refer to the documentation on apache.org/guides/getting-started/maven-in-five-minutes.html
Configure your Spring Config (myLoader.xml)
Spring is a lightweight bean management container and among other things it contains a batch function which is utilized by the Loader Framework. A loader using the framework will need to work closely with Spring Batch and the way it does that is through Spring's configuration file where you configure beans (your loader code) and how the loader code should be utilized by Spring Batch (by configuring a Job, Step and other Spring Batch stuff in the spring config file). What follows is a brief overview of those tags related to the LoaderFramework. For more detail please see refer to the Spring documentation: http://static.springsource.org/spring-batch/reference/html/index.html.
Figure 3
Beans
The 'beans:beans' tag is the all-encompassing tag. You define all your other tags in here. You can also define an import within this tag to import an external Spring config file. Not shown in figure 3.
...
Use these tags, 'beans:bean', to define the beans to be managed by the Spring container by specifying the packaged qualified class name. You can also specify inititialization values and set bean properties within these tags.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<beans:bean id="umlsCuiPropertyProcessor" parent="umlsDefaultPropertyProcessor" class="org.lexgrid.loader.processor.EntityPropertyProcessor">
<beans:property name="propertyResolver" ref="umlsCuiPropertyResolver" />
</beans:bean>
|
...
The 'job' tag is the main unit of work. The job is comprised of one or more steps that define the work to be done. Other advanced and interesting things can be done within the Job such as using 'split' and 'flow' tags to indicate work that can be done in parellel steps to improve performance.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<job id="umlsJob" restartable="true">
<step id="populateStagingTable" next="loadHardcodedValues" parent="stagingTablePopulatorStepFactory"/>
...
|
...
You can do anything you want within a Tasklet such as sending an email or a LexBIG function such as indexing. You're not limited to just database operations. The Spring documentation also has this to say about Tasklets:
| Info |
|---|
The Tasklet is a simple interface that has one method, execute, which will be a called repeatedly by the TaskletStep until it either returns RepeatStatus.FINISHED or throws an exception to signal a failure. Each call to the Tasklet is wrapped in a transaction |
Chunk
Spring documentation says it best:
| Info |
|---|
Spring Batch uses a 'Chunk Oriented' processing style within its most common implementation. Chunk oriented processing refers to reading the data one at a time, and creating 'chunks' that will be written out, within a transaction boundary. One item is read in from an ItemReader, handed to an ItemWriter, and aggregated. Once the number of items read equals the commit interval, the entire chunk is written out via the ItemWriter, and then the transaction is committed. |
Reader
An attribute of the chunk tag. Here is the class that you defined implementing the Spring ItemReader interface to read data from your data file and create domain-specific objects.
...
Attribute of the chunk tag. This class will implement the Spring interface ItemWriter. In the case of the Loader Framework these classes have been written for you. They are the LexGrid model objects that use Hibernate to write to the database.
Key Directories
Below is an image of the loader-framework-core project in Eclipse which shows the key directories of the Loader Framework. The following is a summary of the contents of those directories.
Figure 4
Directory | Summary |
|---|---|
connection | Connect to LexBIG and do LexBIG tasks such as register and activate. |
constants | Assorted constants. |
dao | Access to the LexBIG database. |
data | Directly related to data going into the LexBIG database tables. |
database | Database specific tasks not related to data, such as finding out the database type (MySQL, Oracle) |
fieldsetter | Spring related classes for helping to write to the database. |
lexbigadmin | Common tasks you want LexBIG to do for you such as indexing. |
listener | You can attach listeners to a load so that the code will execute and certain points in the load such as a cleanup listener that runs when the load is finished or a setup listener etc... |
logging | Gives you access to the LexBIG logger. |
processor | Important directory. Contains classes that you can pass your domain specific object to and will return a LexBIG object. |
properties | Code used internally by the Loader Framework. |
reader | Readers and reader-related tools for loader developers. |
rowmapper | Classes for reading from a database. Currently experimental code. |
setup | Classes such as JobRepositoryManager that help Spring do its work. As Spring hums along it keeps tables of its internal workings. Loader developers should not need to dive into this directory. |
staging | If your loader needs to load data to the database temporarlily you can find helper classes in this directory. |
wrappers | Helper classes and data strucutres such as a Code/CodingScheme class. |
writer | Miscellanous Miscellaneous classes that write to the database. These are not the same ones you'd use in your loader, i.e the LexBIG model objects that use Hibernate. Those classes are contained in the PersistanceLayer PersistenceLayer project (next figure 5, below). Its It is by using those classes in the PersistenceLayer that you let the Loader Framework do some of the heavy lifting for you. |
Figure 5
Algorithms
None
Batch Processes
None
Error Handling
Spring Batch gives the Loader Framework some degree of recovery from errors. Like the other features of Spring it is something the Loader developer would need to configure in their Spring config file. Basically, Spring will keep track of the steps it has executed and make note of any step that has failed. Those failed steps can be re-run at a later time. The Spring documentation provides additional information on this function. See http://static.springsource.org/spring-batch/reference/html/configureJob.html and http://static.springsource.org/spring-batch/reference/html/configureStep.htmlfunction. Refer to the configure job documentation and configure step documentation.
Database Changes
None
Client
Currently, the LexBIG GUI does not provide a framework to dynamically load extendable GUI components. While not impossible to extend the GUI functionality especially for those working closely with the LexBIG code, loaders written to use the new framework should expect that their loader will be called via the command line or script.
JSP/HTML
None
Servlet
None.
Security Issues
None.
Performance
Spring can accommodate parallel processing to enhance performance. The Spring documentation provides a good discussion of this topic. See http://static.Refer to scalability on springsource.org/spring-batch/reference/html/scalability.html.
Internationalization
Not internationalized.
Installation / Packaging
The Loader Framework is packaged as a LexBIG extension and thus is not included in the LexBIG jar.
Migration
None.
Documentation Considerations
The Loader Framework will also be described in the knowledge centerKnowledge Center.
Testing
Automated test tests are run via Maven. As mentioned earlier the projects containing the Loader Framework code are configured to work with Maven. Figure 6 (below), shows how The following figure shows the PersistenceLayer project and its standard Maven layout. Notice the structure of the test code mirrors the structure of the application code. To run the automated test in our Eclipse environment we select the project, right click, select 'Run As' and select 'Maven test'. Maven will do the rest.
Figure 6
Test Guidelines
The test cases are also integrated into the LexBIG 5.1 build environment and are run with each build.
Test Cases
See System Testing.
Test Results
See System Testing.
Custom Loader Feasibility Report and Recommendation
Persistence Layer Feasibility
...
- Group Readers
- Group Writers
- Writers configurable to skip certain records
- Partitionable readers to break up large source files
- Error checking Readers and Writers
- A Validating framework for inspecting content before it is inserted into the database.
- etc.
BDA Support Detailed Design
LexEVS uses the BDA (Build and Deployment Automation) system to build and deploy artifacts. This build script that produces these artifacts and deploys them is kicked off via a build server (an instance of Anthill pro).
...
Each of these is produced as a separate artifact via a single build call. The local java Java application is built and integrated into the web application. The data service is also integrated into the web application. Separate analytical and data grid services are also created.
...
In this case two separate JBoss server instances are required. In one instance the web enabled application (lexevsapi) is copied to the remote server as a war file, it is accompanied by a grid data service zip file that is unzipped into a typical war file directory structure. In the other instance the LexEVS grid analytical service is deployed. In every case the server is stopped, configured as necessary, receives the new war file or directory and is started again. The BDA process is considered to be successful when all project builds are complete, all artifacts are deployed, and each public interface of these services is verified.
Implementation Plan
This will include the technical environment (HW,OS, Middleware), external dependencies, teams/locations performing development and procedures for development (e.g. lifecycle model,CM), and a detailed schedule.
Technical environment
No new environment requirements exist for the the LexEVS 5.1, with the exception of additional storage to accommodate larger content loads.
Software (Technology Stack)
Operating System
- Linux (though no operating system dependencies currently exist)
...
- caGrid 1.3 / Globus 4.0.3
Server Hardware
Server
- NCI standard hardware.
...
- Minimum required by JBoss.
Storage
Expected file server disk storage (in MB)
...
- 100GB (May increase due to additional RRF content load)
Networking
Application specific port assignments
...
- Grid services can NOT be in the same JBoss container because of naming - they both need to be named /wsrf in the container. This results in the use of 1 JBoss container for LexEVS 5.0 and 1 JBoss container for LexEVS 5.1.
External dependencies
N/A
Team/Location performing development
- Traci St. Martin / Mayo Clinic
- Craig Stancl / Mayo Clinic
- Scott Bauer / Mayo Clinic
- Kevin Peterson / Mayo Clinic
- Sridhar Dwarkanath / Mayo Clinic
- Michael Turk / Mayo Clinic
Procedures for Development
Development will follow procedures as defined by NCI.
Detailed schedule
The LexEVS 5.1 project plan is located in Gforge at: LexEVS 5.1 Project Plan and LexEVS 5.1 Project Plan (PDF)on the Gforge archive in MS Project format and PDF format
The LexEVS 5.1 BDA Project plan is located at : LexEVS 5.1 BDA Project Plan (login required).
Training and documentation requirements
Documentation for LexEVS 5.1 will be located on provided by the Vocabulary Knowledge Center Wiki https://cabig-kc.nci.nih.gov/Vocab/KC/index.php/LexBig_and_LexEVS: LexEVS Guides and Training.
Download center changes
Downloads for LexEVS 5.1 will be located on the Vocabulary Knowledge Center Wiki https://cabig-kc.nci.nih.gov/Vocab/KC/index.php/LexBig_and_LexEVS LexEVS wiki.
| Scrollbar | ||
|---|---|---|
|