# Presentation: 232707

## caBIGTM ReportingGrid Publication and Parser DemoThe Robert H. Lurie Comprehensive    Cancer  Center of Northwestern UniversityVanderbilt Ingrams Cancer Center

**caBIGTM Reporting****Grid Publication and Parser Demo****The Robert H. Lurie Comprehensive ****   Cancer  Center of Northwestern University****Vanderbilt Ingrams Cancer Center**

- Sorena Nadaf, Vanderbilt
- Warren Kibbe, Northwestern

## Inter-institutional Reporting

- Building Blocks
- CDEs
- Web services
- SSL for encryption
- Authentication using Kerberos/SAML
- Authorization, identity management using LDAP
- All of these pieces are used in Shibboleth
- _[http://shibboleth.internet2.edu/](http://shibboleth.internet2.edu/)_
- Grid services
- GridShib will provide security/identity management for the grid
- Demo

## Schematic of a caBIGTM Reporting grid layer

**legacy**

***caBIG grid infrastructure***

**caBIG**
**Compatible**
**Object**
**Model**
**Adapter**

**caBIG **
**Compatible**
**System**

**Registration**
**Subscription/publication**
**Federation**
**Security**

## Parser, Data model and  grid layer

- Grid layer
- Authentication
- Authorization/identity management
- Registration
- Advertising/Discovery
- Web services layer
- Data service
- Data model adaptor
- Validator service
- Syntactic interoperability announced through webservice
- Semantic validator available through the data model

## Grid Methods

*Each institution maintains control of their data*
- AnnounceService
- RegisterService
- Heartbeat (periodic announcement)
- DiscoverKnownServices

## Service Data Methods

*Each institution maintains control of their data!*
*Each service transaction is between a client and a provider*
- GetCDElist (CDEs used at  institution)
- GetCDEInfo (CDE info for items used at local institutions)
- GetData (For AEs - get current AEs the requester is allowed to see from the provider)
- Can be limited by protocol, institution, date range
- SendData (For AEs - submit the AE to the provider)

## Service is currently running at Vanderbilt and NU

**http://critr.mc.vanderbilt.edu/cfusion/AE_webservice/AEs/ae.cfc?WSDL**
**https://secure.lurie.northwestern.edu/AE_webservice/Aes/AE.cfc?WSDL**

## View of the site selector from my laptop

## View of the data grid from Vanderbilt

## View of the data grid from laptop

## Web service definitions for the parser

## Now the demo

## Background

- Advantages of “transparent” data sharing
- Speed of transfer
- Acknowledgement of receipt
- Compliance
- Statistical power (larger populations can be studied)

## Background

- Example
- Sharing adverse event information
-  This is only one of many examples of areas where sharing of data will have an immediate benefit for cancer patients
- Targeted groups
- Cancer center to cancer center
- Cancer center to cooperative group
- Cooperative group to cancer center
- Cancer center to NCI
- Cancer center to FDA

## Building Blocks

- CDEs
- Web services
- SSL for encryption
- Authentication using Kerberos/SAML
- Authorization, identity management using LDAP
- All but CDEs are part of Shibboleth
- _[http://shibboleth.internet2.](http://shibboleth.internet2.edu/)__[edu](http://shibboleth.internet2.edu/)__[/](http://shibboleth.internet2.edu/)_

## What we built

- Simple AE schema in Oracle
- Data dictionary in Oracle (we would like to use the CDEs for this!)
- Used the published CTC for AE definitions
- Used the existing NU AE entry module
- Web services servlet
- Web services browser
- WDSL file

## Schema(ERD)

**Schema****(ERD)**

## Data Dictionary

**Data Dictionary**

## Common Toxicity Criteria Browser

**Common Toxicity Criteria Browser**

## Adverse Event Entry Form

**Adverse Event Entry Form**

## Adverse Event Tablespace

**Adverse Event Tablespace**

## Webservice WSDL file

**Webservice WSDL file**

## Webservice ‘consumer’view

**Webservice ‘consumer’view**

## Data from the Webservice

## The Following slides are from the caGRID presentation at the Architecture face-to-face in Seatller March 2005

## Functions

- Grid Communication Protocol

- Service Description

- Service

- Business Process

**Service Registry**

- Security / Policy

**Semantic** **service**

- Resource Management

**Functions**

**Quality of Service**

- ID Resolution

**OGSA Compliant - Service Oriented Architecture**

**caGrid OGSA SOA**

**Transport**

## Functions

**Service Registry**

- Security / Policy

**Semantic** **service**

**Resource Management**

**Functions**

**Quality of Service**

- ID Resolution

- HTTP

- SMTP

- RMI/IIOP

**OGSA Compliant Service Oriented Architecture**

- JMS

**Map System Components vs. Requirements**

- XML

- SOAP

**WS-Addressing**

**WS-Renewable**
** ****References**

- Service Description

- XSD

- WSDL

**WS-Policy/**
**WS-metaexch.**

**WS-Resourc.Pr**
** ****WS-BaseFault**

**Advertise**

**Discovery**

**Service**

- Query

- Invocation

- Grid
- Cache

**Business Process**

- Workflow

- Federated
- Query

**Administration**

**Security**
**VO**

## Map System Components vs. Technologies

- Grid Communication Protocol

- Service Description

- Service

- Business Process

**Service Registry**

- Security

**Semantic** **service**

- Resource Management

**Functions**

**Quality of Service**

- ID Resolution

**OGSA Compliant - Service Oriented Architecture**

**Transport**

**Map System Components vs. Technologies**

- GSI

- CAS

- myProxy

- GT3

- DQP

- Workflow

- OGSA-DAI

- GT3 Core

- GRAM

- GLOBUS Toolkit

- caDSR

- EVS

- Mobius

- GT3

## Semantic Grid View

- Semantic services build on top of grid services
- Service interoperability
- Metadata identifies relationships among grid services. Which one is related to others. When to use one instead of the other
- Support advertisement, discovery, federated query, invocation and workflow

- Grid services – Data & Computational services

**Semantic Information services**

- Semantic
- Metadata

- Service
- identifiers

**caBIG Environment**

- Portal / API

- Grid Service
- Metadata

## Components in Globus Toolkit

## OGSA-DAI Architecture

- Previously heavily dependant upon OGSI implementation provided by GT3
- Currently has a three layer architecture:
**Presentation layer **- OGSI, WS-RF or WS-I-compliant services
**Business logic layer** - the core OGSA-DAI functionality
**Data layer **- the data resources (for example relational or XML databases) which can be exposed by OGSA-DAI services

- * Diagram from OGSA-DAI

## Security Layers

**Security Layers**

- * From Globus presentation