# Presentation: 648824

## Silver Level Compatibility

***Part B:  Grid Enabling your Silver System Panel Discussion***

- Tahsin Kurc1, Scott Oster1, Shannon Hastings1, Patrick McConnell2, Baris E. Suzek3, Kiran Keshav4, Michael Keller5
- 1 The Ohio State University
- 2 Duke University Comprehensive Cancer Center
- 3 Protein Information Resource, Georgetown University Medical Center
- 4 Columbia University
- 5 Booz Allen Hamilton

## Agenda

- Overview of Silver-Level Compliance
- caGrid Background
- Silver to Grid:  Migrating Silver Applications to Data and Analytical Grid Services
- Grid-enabled Data Service:  gridPIR
- Grid-enabled Analytical Service:  geWorkbench
- Summary

## Agenda

- Overview of Silver-Level Compliance
- caGrid Background
- Silver to Grid:  Migrating Silver Applications to Data and Analytical Grid Services
- Grid-enabled Data Service:  gridPIR
- Grid-enabled Analytical Service:  geWorkbench
- Summary

## Overview of Silver Level Compliance

**Compatibility Guidelines: ****.**
- Interoperability can be defined as the ability of a system to _access_ and _use_ the parts of another system. The caBIG program has made interoperability between data and software components a primary strategic goal.
- Compatibility is promoted by a rigorous set of requirements that, when met, significantly reduce the barrier to use of a resource by a remote party who was not involved in the development of that resource.

## Overview of caBIG compliance

**Syntactic**

**Semantic**

**Semantic & **
**Syntactic**

## Overview of caBIG Compliance

- Is there an ***object model*** of input and output data?  Can parts of the object model be re-used?
- Are the concepts ***(vocabulary)*** used to describe the objects available for others to re-use? (EVS)
- Are the ***common data elements*** (CDEs - data descriptors) that describe the object model (objects and attributes) available to others for re-use? (caDSR)
- Is there a public ***Application Programmers Interface*** (API) that describes the data descriptors (CDEs)?

**Notes:**
For silver level reviews, There will be a very in depth talk about silver level reviews by Lewis Frey, previosly at Vanderbilt and who wil lsooon be joining Huntsman CC in Utah, and Bob Friemuth form Wash U at 415 tomorrow (Monday).  the cross cutting workspaces have in place a review process and have reviewed a half dozen developer projects with an additional dozen in process. And another half dozen that will come in soon.
In  anutshell, these are the questions asked:

## Vocabularies/Terminologies

-                                      ***TM***

**Examples**

- GeneOntology
- NCI Thesaurus

- GeneOntology registered in EVS
- NCI Thesaurus

**Notes:**
Vocabularies, also called Terminologies, or Ontologies, or concepts, are a central piece of semantic compatibility:  we need to be working from the same definitions.  These are now provided by EVS (the Enterprise Vocabulary Services) from NCI, eg NCI Thesaurus and associated ontologies that are hosted there:  eg, the Gene Ontology
At the Gold level, the VCDE WS and caBIG will have proposed and adopted and made standards a number of ontologies/vocabulary services that are caBIG standards

## Common Data Elements (CDEs)

-                                      ***TM***

**Examples**

**Notes:**
Common data elements are sometimes the hardest things to understand for caBIG newcomers, and I hope I don’t make a hash of this.  A CDE is a description of a piece of structured  data (“data about data, or metadata”) that is stored in a repository (in caBIGs case, in the caDSR).  Now because the data is describe so well (as metadata), this allows a developer to chose to reuse data structures if she chooses WITHOUT having to speak to the developer who created the metadata or code where it is used already.
Metadata in computer science is not a new idea, and there is an ISO (International Standards Organization ) 11179 standard whichc specifies how this is done.  The caDSR (cancer Data Standards Repository) is an implementation of the ISO 11179 standard and is the repository that caBIG has chosen to use.  The CDEs from a developer project must register the CDEs in the caDSR.
At the Gold level, developers should use standards that have been adopted by caBIG.  The CDE standards are in fact a good thing to adopt at the silver level, too, since they can alos function of a menu of CDEs that developers can choose from.

## Information Models (UML Models)

-                                      ***TM***

**Examples**

**Notes:**
IM:
For the VCDE it all starts with  the Information model. This is what will define the structure and semantics of the data.  For Normal people, thinking in terms of objects in actually more intelligible than thinking about how procedural computer programs work.  The caBIG participants have adopted a method of constructing Information Models in the UML (Unified Modeling Language).   So the first step is to use or build upon or create an object model for your system as a class diagram as a UML diagram.  At the Gold level of compliance, caBIG will have harmonized the Information models within caBIG and the developer will have adopted any of those suggested changes in her system.

## Programming and Messaging Interfaces

-                                      ***TM***

**Examples**

- JavaDocs
- XML, ASN.1
- SOAP, CORBA

- Globus
- caGrid-based services

**Notes:**
I will tell you at the outset that Programming and Messaging Interfaces are the province of my Colleagues in the Architecture WS, and I still have not estalished a complete syntactic or semantic compatibility when I talk with them.  1)  they have a different VOCABULARY and they communicate differently (Jut look at the code”)  So I will defer to my architecture colleague Patrick wh will discuss APIs in more detail.  Programming and messaging interfaces:  that is how the messages are understood to be emitted, transferred and received.   We have chosen to rely on APIs (Application Programmers Interfaces) for description.  An example for this is a javadocs description of the API
For transmission, we require an electronic format (standard) and we have decided upon XML.
Finally, for emission and reception, we require some standard messaging protocal, such as SOAP (Some other ??? Protocal)
At the Gold, level,m there are specific requirements for ???

## Types of APIs and Systems

**Data service (Data oriented system)**
- Exposes a published Information Model
- Provides query method
- Query is an object
- Associations of objects returned should be “traversable” (from the returned objects or via further queries)
**Analytical services**
- Algorithmic manipulation of input
- All needed associations of the input/output objects should be materialized
**Analytical tools**
- Consume data registered in the caDSR via silver API or data source (e.g. file)
- Don’t need to produce data (that is, may produce on-screen visualizations etc.)
**Command-line programs**
- Should be wrapped into a client API

## Overview caBIG Compliance

**Overview caBIG Compliance**

- Info Model

- Messaging
- Interfaces/
- API

- Common
- Data
- Elements

- Vocabularies

**Notes:**
Very briefly, the UML model of class objects is built and the descriptions are described by terms in EVS, the vocabulary repository (SIW).
When the ANNOTATED UML model is ready the UML Loader Soiftware can convert those objects into CDEs and find CDEs in the caDSR that can be re-used.  There is also a piece of software that can generate the public API. Using these tools and processes, helps to build a silver level compliant system, tho these tools are not nessasary to build one.

I’ll now turn it over to my Colleague, Patrick McCOnnell from Duke.

## Agenda

- Overview of Silver-Level Compliance
- caGrid Background
- Silver to Grid:  Migrating Silver Applications to Data and Analytical Grid Services
- Grid-enabled Data Service:  gridPIR
- Grid-enabled Analytical Service:  geWorkbench
- Summary

## What is caGrid?

- Development project of Architecture Workspace, aimed at helping define and implement Gold Compliance
- No requirements on *implementation* technology will be necessary for Gold compliance
- Specifications will be created defining requirements for interoperability
- caGrid provides core infrastructure, and tooling to provide “a way” to achieve Gold compliance
- Leverages the “Grid” concept (and implementation) to enable data and analysis sharing for caBIG

## caGrid Community Involvement

- caGrid itself provides no real “data” or “analysis” to caBIGTM; its the enabling infrastructure which allows the community to do so
- Community members add value to the grid as applications, services, and processes *(for example: shared workflows)*
- caGrid provides the necessary core services, APIs, and tooling
- The real “value” of the grid comes from bringing this information to the “end user”
- Community members develop end user applications which consume of the resources provided by the grid

## What is a Community Provided caGrid Service?

- Silver compatible systems are exposed to the Grid as caGrid Services
- caDSR models are used for all data types, and transported over the grid in a common fashion
- Standardized, common pattern and mechanism for remote access
- Language and implementation technology independent
- Common security infrastructure for authentication and authorization
- Standardized service metadata models and metadata advertisement mechanisms
- Community provided service types:
- Data Services
- Expose data to the grid in a unified way
- Analytical Services
- Expose analytical operations to the grid

## caGrid exposing caDSR data

- In caDSR, nearly all items can be individually versioned, but a specific Project version represents a curated collection of Packages, Classes, and Attributes with consistent semantics
- Data is exposed in caGrid as instances defined in a specific Project
- Data Services expose instance data as a subset of Classes from a given Project
- Analytical Services operate over instances of Classes from potentially numerous Projects

## caGrid exposing Silver Systems

- Object Oriented APIs and data resources are developed using Object types and information models registered in the caDSR
- These “silver systems” are grid-enabled by defining a grid service interface that defines the functionality to be exposed to the grid
- The ***grid service interface***** **uses the same Object types as the existing system, but leverages a platform- and language-neutral representation (XML) of them
- The ***grid service implementation***** **maps service invocations to API calls or queries into the existing system

## caGrid Data Description Infrastructure

***Client and service APIs are object oriented***, and operate over well-defined and ***curated data types***
***Objects are defined in UML*** and converted into ISO/IEC 11179 Administered Components, which are in turn registered in the Cancer Data Standards Repository (caDSR)
***Object definitions draw from controlled terminology and vocabulary*** registered in the Enterprise Vocabulary Services (EVS), and their relationships are thus semantically described
***XML serialization of objects*** adhere to XML schemas registered in the Global Model Exchange (GME)

## Advertisement and Discovery Process

- All services register their service location and metadata information to an Index Service
- The Index Service subscribes to the standardized metadata and aggregates their contents

- Clients can discover services using a discovery API which facilitates inspection of data types
- Leveraging semantic information in EVS (from which service metadata is drawn), services can be discovered by the semantics of their data types

## Introduce Graphical Development Environment (GDE)  -- Going Silver to Gold

**GUI for creating and manipulating a grid service**
- Provides means of simple creation of service skeleton that a developer can then implement, build, and deploy
- Automatic code generation of complete WSRF compliant grid service which is configured to provide:
- Security
- Advertisement
- Discovery
- Complete UnBoxed Client API
- Provides a set of tools which enable the developer to add/remove/modify/import methods of the service as well create sub-services/resources.
- Automatic code generation of all the required code, Globus grid service code/configuration, service configuration, implementation of the client, and stubbed implementation of the service

## Inside the Introduce created service

**Inside the Introduce created service**

- Services have many moving and configurable parts which support features such as:
- Advertisement
- Discovery
- Invocation
- Security (Authentication/Authorization)
- Stateful Resources
- The Introduce Toolkit can keep all these features in sync as the developer creates and modifies the grid service

## Managing the Complexities of a Grid Service

**Managing the Complexities of a Grid Service**

- = introduce managed

- = globus/axis managed

- = developer implements

## Generating a User Friendly Service Interface

**Providing Client Side Object API**
- The Globus/Axis build process will automatically generate a client side object oriented API
- Introduce generates a wrapper for this API which matches the service designers interface to make a clean mapping from client to service.
- This wrapper will handle auto boxing/unboxing of the parameters into and out of document literal form.

## Enabling Security

**Enabling Security**

**Security:**
- Enable configuration for each service and for each method in a service.
- Support complete GSI security configuration for authentication and support for an authorization plug-in framework.
- Require service security metadata to be available anonymously via the grid service interface (*getServiceSecurityMetadata())* or the grid service’s resource properties.

## caGrid Production Environment

## Agenda

- Overview of Silver-Level Compliance
- caGrid Background
- Silver to Grid:  Migrating Silver Applications to Data and Analytical Grid Services
- Grid-enabled Data Service:  gridPIR
- Grid-enabled Analytical Service:  geWorkbench
- Summary

## Silver to gridSilver versus grid

**APIs**
- Silver APIs are typically programming language APIs
- Grid APIs are messaging APIs, though are typically wrapped with programming language APIs
**CDEs and Vocabularies**
- Silver systems require CDEs to be registered with corresponding concepts
- Grid services advertise this semantics
**Information Model**
- Silver data-oriented systems require the information model to be queriable and traversable
- Grid services provide a common interface and language (CQL) for querying

## Silver to gridAnalytical versus data services

- A data service is a specialized analytical service
- Similarities
- Created using Introduce
- Strongly typed, object-oriented inputs/outputs
- Metadata includes domain model extract (CDEs) that correspond to inputs/outputs
- Same grid (WSRF) protocols used for messaging
- Differences
- Data services have consistent query method
- CQLProcessor controls logic of handling queries and accessing the backend datastore
- Analytical services can have any method with any parameters
- A data service can also be an analytical service

## Silver to gridTaking silver to grid 

- Generate an XML Schema
- Create a Schema based upon UML and CDEs
- Upload to GME
- Create a service skeleton
- Add service extensions (data, metadata, etc.)
- Add datatypes (XML Schema) and metadata (CDEs)
- Analytical services
- Add methods, parameters, method-level security
- Data services
- Select model(s), CQLProcessor
- Add service-level security
- Set service properties
- Implement the service
- Business logic should be abstracted from service implementation
- Implement each service method, hooking in logic and transformations

## Silver to gridThe grid provides added functionality

**Silver to grid**The grid provides added functionality

## Agenda

- Overview of Silver-Level Compliance
- caGrid Background
- Silver to Grid:  Migrating Silver Applications to Data and Analytical Grid Services
- Grid-enabled Data Service:  gridPIR
- Grid-enabled Analytical Service:  geWorkbench
- Summary

## Protein Information Resource (PIR)

- Integrated Protein Informatics Resource for Genomic/Proteomic Research

- UniProt Universal Protein Resource: Central Resource of Protein Sequence and Function
- PIRSF Family Classification System: Protein Classification and Functional Annotation
- iProClass Integrated Protein Knowledgebase: Data Integration and Functional Analysis
- iProLINK: Source for Protein Literature Mining and Ontology Development

**http://pir.georgetown.edu**

## Universal Protein Resource (UniProt)

- UniProt: Universal Protein Resource - Central Resource of Protein Sequence and Function

- International Consortium
- PIR at GUMC
- European Bioinformatics Institute (EBI)
- Swiss Institute of Bioinformatics (SIB)
- Unifies PIR-PSD, Swiss-Prot, TrEMBL Protein Sequence Databases

**http://www.uniprot.org**

## UniProt Databases

- Primary Resource for gridPIR

## Grid-enablement of PIR (gridPIR)

- Goal provide comprehensive and fully annotated protein related information for genomic and proteomic cancer research
- A data service exposing protein related information from UniProt databases on the caGrid
- Available on caGrid since August 1, 2005
- Developed using model driven approach and caCORE SDK 3.1
- Adopted by Biomedical Informatics Facility for the Abramson Cancer Center at U.Penn.
- All data is public so no security layer implemented

## gridPIR Development

## Grid-enabled example applicationsgridPIR  - Creating a caGrid 1.0 data service

** ****Step 1: Run Introduce Grid Service Authoring Toolkit**

## Grid-enabled example applicationsgridPIR  - Creating a caGrid 1.0 data service

**Step 2: Select data service configuration**
- GridPIR API is migrated from caCORE SDK 3.0 to 3.1

**Step 3: Create caCORE SDK Backended caGrid Data Service**

## Grid-enabled example applicationsgridPIR  - Creating a caGrid 1.0 data service

**Step 4: Add GridPIR API’s client to data service configuration**

## Grid-enabled example applicationsgridPIR  - Creating a caGrid 1.0 data service

**Step 5: Link to GridPIR API**
- All UniProt and PIR data are public so no security is layer is needed

## Grid-enabled example applicationsgridPIR - Creating a caGrid 1.0 data service

**Step 6: Configure domain model to be exposed/advertised on caGrid   **

## Grid-enabled example applicationsgridPIR  - Creating a caGrid 1.0 data service

**Step 7: Configure schema describing objects **

- Schema generated by caCORE SDK is manually loaded

## Grid-enabled example applicationsgridPIR  - Creating a caGrid 1.0 data service

**Step 8: Add service hosting center information to service metadata file**

- <com:ResearchCenter displayName="**Protein Information Resource**" shortName="**PIR**“ xmlns:com="gme://caGrid.caBIG/1.0/
- gov.nih.nci.cagrid.metadata.common">
-          <com:ResearchCenterDescription description="**The Protein Information Resource (PIR), located at Georgetown University Medical Center (GUMC), is an integrated public bioinformatics resource to support genomic and proteomic research, and scientific studies****.**“ homepageURL="**http://pir.georgetown.edu**"/>
-          <com:Address country="**US**" postalCode="**20007**" locality="Washington" stateProvince="**DC**" street1="**3300 Whitehaven Street, NW, Suite 1200**"/>
-          <com:pointOfContactCollection>
-              <com:PointOfContact affiliation="**Lombardi Comprehensive Cancer Center, Georgetown University Medical Center**" email="**bes23@georgetown.edu**" firstName="**Baris**" lastName="**Suzek**" role="participant"/>
-          </com:pointOfContactCollection>
-      </com:ResearchCenter>
- </md:hostingResearchCenter>

**serviceMetadata.xml: **

**Index service/caGrid Portal: **

## Grid-enabled example applicationsgridPIR  - Creating a caGrid 1.0 data service

**Step 9: Deploy GridPIR  data service**
-  Service metadata is registered to index service for discovery

## Grid-enabled example applicationsgridPIR  - Discovery

** ****Discover the data services that provide protein related information**
- Background:
- Classes and attributes are semantically annotated using concepts from Enterprise Vocabulary Service (EVS)
-  Step 1: Find the concept for Protein using EVS service/API
- EVSGridServiceClient client = new EVSGridServiceClient(**"http://cagrid-service.nci.nih.gov:8080/wsrf/services/cagrid/EVSGridService”**);
- EVSDescLogicConceptSearchParams  evsSearchParams = new EVSDescLogicConceptSearchParams();
- evsSearchParams.setVocabularyName("**NCI_Thesaurus**");
- evsSearchParams.setSearchTerm("**Protein**");
- evsSearchParams.setLimit(10);
**DescLogicConcept[]** descLogicConcepts = client.searchDescLogicConcept(evsSearchParams);

**Concept Code**

**Concept Name**

## Grid-enabled example applicationsgirdPIR  - Discovery

** ****Discover the data services that provide protein related information**
-  Step 2: Discover the data service using the “Protein” concept and discovery API
- DiscoveryClient client = new DiscoveryClient(**“http://cagrid-index.nci.nih.gov:8080/wsrf/services/DefaultIndexService”**
- proteinExposingServices = client.discoverDataServicesByModelConceptCode("**C17021**");
-      if (proteinExposingServices != null) {
-    	for (int i = 0; i < proteinExposingServices.length; i++) {
-             **EndpointReferenceType** service = proteinExposingServices[i];
-       ...
-     }
- }

**http://141.161.54.149:8080/wsrf/services/cagrid/GridPIR**

- http://cagrid-portal.nci.nih.gov:8080/wsrf/services/cagrid/CaBIOSvc

- http://128.252.178.222:9092/wsrf/services/cagrid/GeneConnect

## Grid-enabled example applicationsgridPIR  - Query 

**  ****Query GridPIR service **
- Step 1: Retrieve the annotated domain model from GridPIR service
- EndpointReference service = new EndpointReference(“**http://141.161.54.149:8080/wsrf/services/cagrid/GridPIR**
- “);
**DomainModel** model=MetadataUtils.getDomainModel(service);

## Grid-enabled example applicationsgridPIR  - Query

**Grid-enabled example applications****gridPIR  - Query**

**  ****Query GridPIR service**

- Step 2: CQL query to retrieve the proteins  for gene “BRCA2” (Breast Cancer Gene 2)
- <CQLQuery xmlns="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQLQuery">
- 	<Target name=" **edu.georgetown.pir.domain.Protein**">
- 	   <Association roleName=“**geneCollection**"
- 		      name=" **edu.georgetown.pir.domain.Gene** ">
- 	        <Attribute name=“**name**" value=“**BRCA2**" predicate="**EQUAL_TO**"/>
- 	   </Association>
- 	</Target>
- </CQLQuery>** **

## Grid-enabled example applicationsgridPIR  - Query 

**  ****Query GridPIR service **
- Step 3: Get results

**GridPIR**

- BRCA2_RAT

- BRCA2_MOUSE

- BRCA2_HUMAN

- From multiple organisms

## Grid-enabled example applicationsgridPIR  - Query 

**  ****Query GridPIR service **
- Step 4: Refine results
- <CQLQuery xmlns="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQLQuery">
-         <Target name="edu.georgetown.pir.domain.Protein">
-            <Group logicRelation="**AND**">
-                 <Association roleName="**organismCollection**"
- 				 name="**edu.georgetown.pir.domain.Organism**">
-                         <Attribute name="**scientificName**" value="**Homo sapiens**" 					predicate="**EQUAL_TO**"/>
-                 </Association>
-                 <Association roleName="geneCollection" name="edu.georgetown.pir.domain.Gene">
-                         <Attribute name="name" value="BRCA2" predicate="EQUAL_TO"/>
-                 </Association>
-            </Group>
-         </Target>
- </CQLQuery>

## Grid-enabled example applicationsgridPIR  - Query 

**  ****Query GridPIR service **
- Step 5: Get results

**GridPIR**

**BRCA2_HUMAN**

- Only human proteins

## Grid-enabled example applicationsgridPIR  - Interoperability 

**  ****Using metadata for interoperability**
- Background:
- Index service returned GridPIR and GeneConnect as protein related information providers
- Step 1: Retrieve the annotated domain model from GeneConnect service
- EndpointReference service = new EndpointReference(“**http://128.252.178.222:9092/wsrf/services/cagrid/GeneConnect**
- “);
**DomainModel** model=MetadataUtils.getDomainModel(service);

## Grid-enabled example applicationsgridPIR  - Interoperability 

**  ****Using metadata for interoperability**
- Step 2: Compare semantic annotations for GridPIR and GeneConnect domain models

- GeneConnect

- GridPIR

- Value domain = String

- Value domain = String

- Common Data Elements

## Agenda

- Overview of Silver-Level Compliance
- caGrid Background
- Silver to Grid:  Migrating Silver Applications to Data and Analytical Grid Services
- Grid-enabled Data Service:  gridPIR
- Grid-enabled Analytical Service:  geWorkbench
- Summary

## Grid-enabled example applicationsAnalytical Service-geWorkbench

**Platform for Integrated Genomics Research**
**Center for Computational Biology and Bioinformatics****Columbia University**_[https://www.c2b2.columbia.edu](https://www.c2b2.columbia.edu/)_

## geWorkbenchApplication Background

- geWorkbench - Java based integrative genomics platform
- Component-based architecture allows for complex applications to be added as individual components.
- caGrid as a geWorkbench component
- A component that can discover and invoke grid services, retrieve the results, and use other components of the framework for tasks such as visualization.

## Grid-enablement of geWorkbench

- Three algorithms from geWorkbench were grid-enabled using the caGrid infrastructure, and exposed as Analytical Services:
- Hierarchical Clustering
- Som Clustering
- Aracne

## How Do You Grid Enable an Algorithm?

- Model data types to be used in UML
- Register data types in caDSR
- Create Service
- Deploy to a web server/container.

## Registered Data types

## Creating a Service

**Step 1:  Run the Introduce Toolkit**

## Creating a Service

**Step 2:  Add your code to the Introduce-created stub (YourServiceImpl)**

## UML – API Link

**UML diagram**

**API Realization**

## Deploying a Service

**Step 3:  Deploy Your Service**
- Deploy to a Tomcat web container
- Can deploy with ant, or use Introduce.
- Example: _[http://cagridnode.c2b2.columbia.edu:8080/wsrf/services/cagrid/HierarchicalClustering](http://cagridnode.c2b2.columbia.edu:8080/wsrf/services/cagrid/HierarchicalClustering)_

## Analytical Service Discovery

- Discovery API
- Before you can invoke a service, it must be discovered.

**Core Services**
- Index Service

## Analytical Service Discovery

**Service discovery in geWorkench**

## Analytical Service Invocation

**Invoking Services**

**geWorkbench – **
**caGrid **
**Data Type**
**Converter**

**Analytical Services**
- HierarchicalClustering
- SomClustering
- Aracne

## Analytical Service Invocation

## caGrid Request

**XML representation of a microarray dataset**

## caGrid Response

**XML from grid node representing clustering results**

## Agenda

- Overview of Silver-Level Compliance
- caGrid Background
- Silver to Grid:  Migrating Silver Applications to Data and Analytical Grid Services
- Grid-enabled Data Service:  gridPIR
- Grid-enabled Analytical Service:  geWorkbench
- Summary

## Summary

**Syntactic and semantic interoperability is desired and required **
- Programmatic access, correct parsing and interpretation of information
- Integration across applications, data sources, application domains
**Metadata and interfaces are important**
- Common data elements, controlled vocabulary
- Well defined interfaces, object-oriented view
- Model Driven Architecture
**Layered approach to compatibility and interoperability**
- Silver level: making your application accessible through community accepted standards/mechanisms
- Grid/Gold level: Integration of your application in a multi-institutional, distributed environment
**Tools**
- caDSR, EVS, caCORE SDK
- caGrid, Introduce, GME
- They can be used in tandem
- Security support at each level; CSM and GAARDS