# Presentation: 518917

## caGrid Version 0.5 Architecture OverviewAdvertisement & DiscoverycaBIG Architecture Workspace Face to FaceGeorgetown UniversityAugust 16, 2005

- Scott Oster
- Ohio State University
- oster@bmi.osu.edu

- Manav Kher
- SAIC
- kherm@mail.nih.gov

## Outline

- Overview
- Service Metadata
- Core Services Involved
- Advertisement Process
- Discovery Process
- Discovery Tools

## Definitions of terms

**Advertisement**
- The **caGrid Grid Service Owner** composes service metadata describing the service to the grid and publishes it to grid.  The service metadata describes properties of the grid services that caGrid users and other grid services may query.
**Discovery**
- A **caGrid Researcher** specifies search criteria describing a service.  The research submits the discovery request to a discovery service, which identifies a list of services matching the criteria, and returns the list to the researcher.

## Service Metadata

- Service Data Elements (SDEs) represent a service’s dynamic state or metadata.
- They represent the entry point for clients to introspect services to discover what they do
- SDEs are described by XML Schemas and represented to clients and services as Objects or XML documents
- Can be statically defined in a service’s GWSDL or dynamically created

## Object view of Service Data Elements

- By describing our service metadata in XML Schema, Globus provides the tooling to create corresponding Java Beans to facilitate client and service use
- Service Data is defined under a unique name, and its value can be viewed as an XML document conforming to the schema, or an appropriately populated Java Bean

- Image Source: http://gdp.globus.org/gt3-tutorial/singlehtml/images/schema.png

## Service Data Attributes

**minOccurs** : The minimum number of values that this SDE can have.
**maxOccurs** : The maximum number of values that this SDE can have. The value of this attribute can be unbounded, which indicates an array with no size limit.
**modifiable** : True or false. Specifies if the value of this SDE can be changed by a client.
**nillable** : True or false. Specifies if the value of this SDE can be NULL.
**mutability** : This attribute can have the following values:
- static: The value of the SDE is provided in the GWSDL description.
- constant: The value of the SDE is set when the Grid Service is created, but remains constant after that.
- extendable: New elements can be added to the SDE, but not removed.
- mutable: New elements can be added and removed.

## caGrid Standard Service Metadata

**caGrid Standard Service Metadata**

- Common Metadata describes generic information about service providing Cancer Center
- Data Service Metadata describes the data exposed using terminology and objects from caDSR/EVS
- Analytical Service Metadata describes the supported operations and their inputs and outputs using terminology and objects from caDSR/EVS

*Common*
*Service*
*Metadata*

*Analytical*
*Service*
*Metadata*

*Data*
*Service*
*Metadata*

## Overview of Service Metadata Registration and Discovery

- All services register their GSH and SDE subscription information to an Index Service
- The Index Service subscribes to the standardized SDEs 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 SDEs are drawn), services can be discovered by the semantics of their data types

## Services related to Service Metadata

**Cancer Data Standards Repository (caDSR)**
- caBIG projects register their data models as Common Data Elements (CDEs) which are semantically harmonized and then centrally stored and managed the caDSR
**Enterprise Vocabulary Services (EVS)**
- EVS is set of services and resources that address the need for controlled vocabulary
- caDSR data models are defined by terminology in the EVS
**Thesaurus**: a biomedical thesaurus
**Metathesaurus**: based on NLM's Unified Medical Language System Metathesaurus supplemented with additional cancer-centric vocabulary
**Global Model Exchange (GME)**
- GME is a DNS-like data definition registry and exchange service that is responsible for storing and linking together data models in the form of XML schema.
- caDSR data objects which travel the grid as XML do so in the format described in GME-registered schemas
**Globus Information Services (Index Service)**
- The Globus Information Services infrastructure provides a generic framework for aggregation of service data, a registry of Grid services, and a dynamic data-generating and indexing node, suitable for use in a hierarchy or federation of services

## caGrid Advertisement

**caGrid Advertisement**

- All caBIG services are expected to provide caGrid standard Common Service Metadata
- All caBIG Analytical services are expected to provide caGrid standard Analytical Service Metadata
- All caBIG Data services are expected to provide caGrid standard Data service Metadata
- Services are also permitted to provide their own more specialized metadata
- All caBIG services are expected to register their service “address” to the caGrid Index Service which will aggregate their standard metadata

## caGrid Deployer

- caGrid provides a graphical deployer that facilitates the deployment of caBIG services
- Facilitates the creation of caGrid standard metadata for the type of service being deployed
- Automatically configures the service to maintain registration with the caGrid Index Service

## caGrid Deployer – Common Service Metadata

- The deployer prompts the developer to enter the information needed to populate the Common Service Metadata
- The deployer uses this information to populate a template of the metadata
- The appropriate service configuration files are then configured to create and publish this metadata

## caGrid Deployer – caDSR Metadata

- The deployer displays a tree view of the caDSR domain model selected for the service (for data services)
- The developer can select a subset of the model
- The deployer uses this information to populate a template of the metadata
- The appropriate service configuration files are then configured to create and publish this metadata

## caGrid Deployer – Advertisement

- The deployer allows the developer to select the Index Service to register to, defaults to the caGrid registry
- The appropriate service configuration files are then configured to register to the specified Index Service and specify the previously configured service metadata

## caGrid Advertisement

- caGrid deployer configures underlying components through the use of configuration files
- Later talks will detail the specifics
- Registry Publish Provider
- Service Data Provider Manager
- Notification Source Provider

## Discovery Process

- Clients formulate a query over the caGrid standard metadata
- Examples:
- “Find me all the services from Cancer Center X”
- “Which Analytical services take Genes as input?”
- “Find me all the services with some metadata mentioning the string *‘macromolecules’*”
- This query is sent to the caGrid Index Service which returns the Grid Service Handle (address) of the services satisfying the query.
- The client can then further interrogate the satisfying services by asking for all of their metadata or service descriptions
- Finally the client invokes the desired services as appropriate

## Discovery and Metadata API

- Globus provides the basic APIs necessary to query the Index Service and ask services for their metadata.
- caGrid provides a Discovery and Metadata API to make this easier to use and to specialize it for caGrid standard metadata
- Provides Java Bean representation of service metadata and higher level discovery methods such as *discoverServicesByConceptCode(String code)*
- Details are provided in a later talk

## Future Structures from the Building Blocks

- The semantic data registration, data type registration, standard service metadata aggregation and registration, and service interface description provide the building blocks for interesting higher level applications and services
- Workflow/Data Pathway Discovery
- Create a graph of potential data flow scenarios from one service to another from a starting data type (type matching)
- Identify Semantically compatible Services
- Identify services which work with the same EVS concepts, but use different data models (create a data mapping, prompt for harmonization)
- Dynamic Graphical Invocation
- Starting with an EVS concept, find Data Services providing data types based on that concept, query for data from one, find Analytical Services operating on that data type, request the WSDL/XSD of the operation, create a GUI dynamically from that information to fill out the additional parameters, invoke the service

## EVS Based Discovery on the Grid	

- EVS (NCI Thesaurus) can be queried through caCORE API
- Component Interaction Diagram

## Discovery Tools

- Graphical User Interfaces built on discovery API facilitate end user discovery
- Result in a list of services which can be used externally or invoked directly from the tools
- Discovery Web Application (no client download necessary)
- Part of the caGrid Browser
- Discovery Client Application
- Part of Grid Portal client application

## Discovery Web Portal

- Web application provides user interface for Discovery API methods, and provides ability to search multiple fields
- Provides EVS concept discovery
- Discovered services can be collected in a “Service Cart” for future use
- Standard caGrid metadata can be viewed
- Data Services can be queried
- Integrated with Security

## Discovery Client Application

- Java Swing Application provides user interface for all Discovery API methods
- Discovered services are presented in a list
- Service data can be browsed with custom renderers for standard caGrid metadata
- Data Services can be queried
- Integrated with security