We advertise our Searches as being 'extensions', but in reality it is very difficult (or impossible) for a use to create a plug-in type Search.
Design ScopeGForge itemsPlease visit the LexEVS 5.1 Scope document found at: https://wiki.nci.nih.gov/display/EVS/LexEVS+5.1+Scope+document Solution ArchitectureProposed technical solution to satisfy the following requirements:
High Level ArchitectureThe LexEVS 5.1 infrastructure exhibits an n-tiered architecture with client interfaces, server components, domain objects, data sources, and back-end systems (Figure 1.1). This n-tiered system divides tasks or requests among different servers and data stores. This isolates the client from the details of where and how data is retrieved from different data stores.
The system also performs common tasks such as logging and provides a level of security for protected content. Clients (browsers, applications) receive information through designated application programming interfaces (APIs). Java applications communicate with back-end objects via domain objects packaged within the client.jar. Non-Java applications can communicate via SOAP (Simple Object Access Protocol) or REST (Representational State Transfer) services.
Most of the LexEVS API infrastructure is written in the Java programming language and leverages reusable, third-party components. The service infrastructure is composed of the following layers:
Application Service layer - accepts incoming requests from all public interfaces and translates them, as required, to Java calls in terms of the native LexEVS API. Non-SDK queries are invoked against the Distributed LexEVS API, which handles client authentication and acts as proxy to invoke the equivalent function against the LexEVS core Java API. The caGrid and SDK-generated services are optionally run in an application server separate from the Distributed LexEVS API.
Core API layer - underpins all LexEVS API requests. Search of pre-populated Lucene index files is used to evaluate query results before incurring cost of database access. Access to the LexGrid database is performed as required to populate returned objects using pooled connections.
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
Figure 1.1 - High Level Diagram 1.0 Query Performance Enhancements
Lucene is very fast as a search engine. Given a text string, Lucene can find matching documents in huge indexes very fast. This is the purpose and strength of Lucene. Lucene is not, however, a database. Retrieving information from the documents that the search found as 'hits' is slow. Consider this scenario: A user searches for 'heart' in the NCI MetaThesaurus. When Lucene does its search, it will return probably 50,000+ 'hits'. This search is done very fast. LexEVS previously would retrieve all of those documents to populate the ResolvedConceptReference. Retrieving this many documents from Lucene is slow. The solution is to is lazy load the documents as needed. After the Lucene search is complete, we only store the Document Id. Then, when information from the document is needed, it is retrieved from the document. This is helpful in Iterator-type scenarios, where retrieval can be done one at a time.
As we move forward, it is important to keep current with the latest Lucene API. Not only is this important for performance reasons -- it will limit our ability to upgrade our Lucene dependencies if we rely on
We advertise our Searches as being 'extensions', but in reality it is very difficult (or impossible) for a use to create a plug-in type Search. The Interface org.LexGrid.LexBIG.Extensions.Query.Search will be introduced. The purpose of this interface is to give users a plug-in type Interface to implement different search strategies. This interface will accept
As with Searching, Sort algorithms are not currently easily extended. A well defined and 'Extension-ready' interface would allow users to add additional search functionality on demand, without rebuilding or recompiling. The existing Interface org.LexGrid.LexBIG.Extensions.Query.Search will be expanded to allow for easy implementation and flexibility, allowing rapid creation of new Sort Algorithms and techniques.
Join EntityDescription when building AssociatedConcepts Furthermore, this will allow the 'EntityDescription' to be available without requiring the actual 'CodedEntry' to be resolved. For most usescases, this should enable users to resolve Graphs with 'CodedEntryDepth=0'. Avoiding any resolving of the CodedEntry will keep resolve times to a minimum. Join EntryState when building CodedEntry 2.0 Metathesauraus Content (RRF)
3.0 Value Domain SupportOverviewThe LexEVS Value Domain and Pick List service will provide ability to load Value Domain and Pick List Definitions into LexGrid repository and provides ability to apply user restrictions and dynamically resolve the definitions during run time. Both Value Domain and Pick List service are integrated part of LexEVS core API.
The LexEVS Value Domain and Pick List service will provide programmatic access to load Value Domain and Pick List Definitions using the domain objects that are available via the LexGrid logical model. The LexEVS Value Domain and Pick List service will provide ability to apply certain user restrictions (ex: pickListId, valueDomain URI etc) and dynamically resolve the Value Domain and Pick List definitions during the run time
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\\ LexEVS Value Domain and Picklist Service Class DiagramCommon Services Class DiagramThese are the classes that are used commonly across Value Domain and Pick List implementation.
Value Domain Class DiagramClasses that implements LexEVS Value Domain API
Picklist Class DiagramClasses that implements LexEVS Pick List API
LexBIG Services Class DiagramAn interface to LexEVS Value Domain and Pick List Services could be obtained using an instance of LexBigService.
4.0 Improved Loader Framework
Cross product dependenciesInclude a link to the Core Product Dependency Matrix. Changes in technologyInclude any new dependencies in the Core Product Dependency Matrix and summarize them here.
AssumptionsList any assumptions. Risks
Detailed DesignSpecify how the solution architecture will satisfy the requirements. This should include high level descriptions of program logic (for example in structured English), identifying container services to be used, and so on. Query Performance Enhancements
Metathesauraus Content (RRF)
Value Domain Support
Improved Loader Framework
Implementation PlanThis 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 environmentNo 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
Application Server
Database Server
Other Software Components
Server HardwareServer
Minimum Processor Speed
Minimum Memory
StorageExpected file server disk storage (in MB)
Expected database storage (in MB)
NetworkingApplication specific port assignments
JBoss Container Considerations There are specific requirements for JBoss containers for LexEVS 5.1. In order to support multiple versions of LexEVS (for example 5.0 and 5.1), there are JBoss considerations.
External dependenciesN/A Team/Location performing development
Procedures for DevelopmentDevelopment will follow procedures as defined by NCI. Detailed scheduleThe LexEVS 5.1 project plan is located in Gforge at: LexEVS 5.1 Project Plan and LexEVS 5.1 Project Plan (PDF) The LexEVS 5.1 BDA Project plan is located at: LexEVS 5.1 BDA Project Plan Training and documentation requirementsN/A Download center changesN/A
|