cacore case study lexbig api integration n.
Skip this Video
Loading SlideShow in 5 Seconds..
caCORE Case Study: LexBIG API integration PowerPoint Presentation
Download Presentation
caCORE Case Study: LexBIG API integration

Loading in 2 Seconds...

play fullscreen
1 / 17

caCORE Case Study: LexBIG API integration - PowerPoint PPT Presentation

  • Uploaded on

caCORE Case Study: LexBIG API integration. Characteristics of caCORE. Components. Model Driven Architecture All caCORE components designed in UML and appropriate APIs generated from this information model n -tier Architecture and Open APIs

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

caCORE Case Study: LexBIG API integration

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
characteristics of cacore
Characteristics of caCORE


  • Model Driven Architecture
    • All caCORE components designed in UML and appropriate APIs generated from this information model
  • n-tier Architecture and Open APIs
    • All caCORE components publish a series of well-described APIs (Java Beans, Web Services, HTTP interface (REST)) that provide open read access to data
    • APIs implemented in an n-tier architecture that allows for flexibility in the persistence layer and shields end users from implementation details
  • Registered Metadata
    • All caCORE components register detailed descriptions of their object APIs in a repository - this ‘data about data’ is called metadata
  • Controlled Terminology
    • All caCORE components use controlled terminology to describe metadata and (where appropriate) data
cacore system architecture
caCORE System Architecture
  • caCORE is based on an n-tier architecture
  • Provides middleware between data and presentation
    • Data Access Objects
    • Domain objects (Java Beans)
    • Application Service
    • API Interfaces (JavaAPI, Web services, XML-HTTP)
non orm system
Non-ORM system
  • LexBIG is a Non-”Object Relational Mapping” (ORM) system
  • caCORE EVS domain object mapped to LexBIG objects. Mapping is Object To Object Mapping (OTOM)

Current vs LexBIG integrated System


Web App






LexBIG integrated System:

Web App





how was lexbig integrated
How was LexBIG integrated?
  • New LexAdapter – “wrapper” around LexBIG
    • Provides:
      • “wrapper” for OTOM (facilitate seamless integration of down-stream applications)
      • LexBIG API configurations
  • New Data Access layer -- EVSLexBigDAOImpl
    • DAO used by the caCORE system. Accesses data via LexAdapter
why incorporate lexbig in cacore
Why Incorporate LexBIG in caCORE?
  • Current terminology components are proprietary, Metaphrase is frozen
    • Requires complex architecture in caCORE
    • Difficult to enhance functionality
      • Lacks support for open data formats
      • Performance, lexical processing, graphs
      • Foreign language, DL support limitations
demo html interface rest
Demo – HTML Interface (REST)



demo xml interface rest
Demo – XML Interface (REST)



demo java api
Demo – Java API

/************* Java API Test ***********************************************/

// 1. Search a DescLogicConcept


System.out.println("--------------------Java API Test-----------------------");

System.out.println("1. Search for DescLogicConcepts where concept name ‘blood*'");


ApplicationService appService = ApplicationService.getRemoteInstance("");

EVSQuery evsQuery = new EVSQueryImpl();

String vocabularyName = "NCI_Thesaurus";

String searchTerm = “blood*";

evsQuery.searchDescLogicConcepts(vocabularyName , searchTerm, 100);

List resultList = appService.evsSearch(evsQuery);

for(int i=0; i< resultList.size(); i++){

gov.nih.nci.evs.domain.DescLogicConcept dlc= (gov.nih.nci.evs.domain.DescLogicConcept) resultList.get(i);

System.out.println("Code: "+ dlc.getCode() +"\t"+ dlc.getName());


demo cacore perl
Demo - CaCORE Perl

#!/usr/bin/perl -w

use strict;

use LWP::UserAgent;

use HTTP::Request::Common;

use CaCORE::ApplicationService;

use CaCORE::EVS;

my $appsvc = CaCORE::ApplicationService->instance("");

# Search DescLogicConcept by code


# This test searches for all DescLogicConcepts with a given code


print "Search DescLogicConcept by code.\n";

my $dlConcept = new CaCORE::EVS::DescLogicConcept;



@dlcSet = $appsvc->queryObject("CaCORE::EVS::DescLogicConcept", $dlConcept);


foreach my $dlc (@dlcSet) {

print "DescLogicConcept: code=" . $dlc->getCode . ", name=" . $dlc->getName . "\n";


project resources and communication
Project Resources and Communication
  • EVS / LexBIG install

  • EVS Homepage:

  • EVS 3.2 Release:
    • Release Notes

    • Java API download:
    • Technical Guide

  • EVS Users Mailing List


Sequence Diagram

  • Use case: user searching for an EVS object.

(Note: ApplicationService layers removed for brevity.)