Skip to main page content
Access keys NCBI Homepage MyNCBI Homepage Main Content Main Navigation
. 2008 Feb;41(1):106-23.
doi: 10.1016/j.jbi.2007.03.009. Epub 2007 Apr 2.

caCORE Version 3: Implementation of a Model Driven, Service-Oriented Architecture for Semantic Interoperability

Affiliations
Free PMC article

caCORE Version 3: Implementation of a Model Driven, Service-Oriented Architecture for Semantic Interoperability

George A Komatsoulis et al. J Biomed Inform. .
Free PMC article

Abstract

One of the requirements for a federated information system is interoperability, the ability of one computer system to access and use the resources of another system. This feature is particularly important in biomedical research systems, which need to coordinate a variety of disparate types of data. In order to meet this need, the National Cancer Institute Center for Bioinformatics (NCICB) has created the cancer Common Ontologic Representation Environment (caCORE), an interoperability infrastructure based on Model Driven Architecture. The caCORE infrastructure provides a mechanism to create interoperable biomedical information systems. Systems built using the caCORE paradigm address both aspects of interoperability: the ability to access data (syntactic interoperability) and understand the data once retrieved (semantic interoperability). This infrastructure consists of an integrated set of three major components: a controlled terminology service (Enterprise Vocabulary Services), a standards-based metadata repository (the cancer Data Standards Repository) and an information system with an Application Programming Interface (API) based on Domain Model Driven Architecture. This infrastructure is being leveraged to create a Semantic Service-Oriented Architecture (SSOA) for cancer research by the National Cancer Institute's cancer Biomedical Informatics Grid (caBIG).

Figures

Figure 1
Figure 1
The major components of caCORE version 3. The primary technology stack contains a model driven, object oriented data system (caBIO in this example) and the metadata and controlled terminology services required to achieve semantic interoperability. Supporting this stack is a set of enabling technologies that simplifies the process of creating a ‘caCORE-like’ system and a supporting technology stack that includes a Common Security Module (CSM) that can be readily implemented through the caCORE SDK.
Figure 2
Figure 2
An example of a Unified Modeling Language (UML) model used in the generation of caCORE-like data systems. This particular example is a portion of the caBIO system.
Figure 3
Figure 3
High level view of the architecture of the caCORE architecture. The architecture is split into three tiers: a client tier that a consuming application would use, a persistence or data tier that contains the data persisted in a relational database management system (RDBMS) and a middle tier that converts queries created in the form of domain objects into queries that can be understood by the persistence tier.
Figure 4
Figure 4
Simplified view of a Common Data Element (CDE) in the caDSR implementation of the ISO 11179 metamodel. This example is for a CDE that describes the name of an agent (i.e. a drug compound) that is constrained to an enumerated list of values provided by the Cancer Therapeutics Evaluation Program (CTEP) of the NCI.
Figure 5
Figure 5
Binding of controlled terminology to the classes and attributes of a class derived from a domain model in UML. This binding is then used to derive the components of an ISO 11179 Common Data Element in the caDSR (bottom).
Figure 6
Figure 6
Hierarchical Provenance Model implemented in caCORE version 3. The central class is the Provenance class that has associations to a SourceReference (a means to retrieve the information that was used to create a particular instance of a class) and three Source objects that describe the supplying source (the entity supplying the data to the user of the API), the immediate source (the source that was used by the supplying source) and the original source (the original creators or publishers of the data).
Figure 7
Figure 7
A Query By Example (QBE) query into the caBIO service utilizing the Java Bean API. A QBE service, wherein a prototype of the query object is created and appropriate attributes have values set to incorporate the boundaries of the query. This code sample is not complete, certain setup components have been removed for clarity. See the caCORE Technical Guide [3] for complete details.
Figure 8
Figure 8
Architecture of the Common Security Module (CSM). The CSM is designed to work with pluggable credential providers so that it can be incorporated into applications that will operate in diverse environments.
Figure 9
Figure 9
Two caGrid use cases: The top panel describes a set of workflows in which objects retrieved from one system are used as inputs into another system. The bottom panel describes aggregation of data from two distinct resources based on common CDEs in each system. The resulting aggregate using a Grid key is functionally equivalent to a Cartesian join using foreign keys in a relational database management system.

Similar articles

See all similar articles

Cited by 38 articles

See all "Cited by" articles

Publication types

LinkOut - more resources

Feedback