NCBO-OOR Architecture

From NCBO Wiki
Revision as of 15:01, 9 February 2009 by Benjamindai (talk | contribs) (Write-up of BioPortal layered architecture)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The NCBO-OOR architecture (essentially the NCBO BioPortal architecture) uses a classic architecture layered approach, which decouples the logic and domain object models between each layer. This approach decouples the versioning and changes in one layer from another. Thus, as software modules evolve (which they always do), the impact on the rest of the software sub-systems is significantly reduced. Furthermore, the BioPortal enforces de-coupling through web services (e.g., REST and SOAP) and the enterprise pattern of “Dependency Injection.” Note that Protégé 3.x has been incorporated into business logic layer (in addition to pre-existing LexGrid) to enable full support of OWL ontologies and the capability to store ontology based meta data, mappings, and marginal notes.

The Presentation Tier delivers the BioPortal user-interface which currently uses the Ruby on Rails technology. Ruby on Rails is a leading mature UI framework supported by large software development communities. It enables rapid prototyping as well as solid integration with web services.

The Interface Tier consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc). The Presentation Tier will be solely driven by the REST services (currently implemented with RESTlet libraries and possible migration to NetKernel). The subsequent “Service-Oriented Architecture” section delves further in the value and goals for NCBO web services.

The Business Logic Tier uses the Spring technology which enables a partner to insert any software implementation that abides to the NCBO-defined interfaces. This is achieved through the “Dependency Injection” enterprise pattern which is core to the Spring framework. For example, if NCI requires use of a different flavor of LexGrid, a module could be easily implemented by NCI using the NCBO interfaces and deployed without having to modify the core BioPortal software. This architectural approach enables incorporation of new capability into the BioPortal through packaging and configuration. The need to do a major BioPortal software release to support a customized implementation is significantly reduced.