# Presentation: 296438

## caGrid Phase II

**caGrid Phase II**
**System architecture**

_***caGrid Team Mission:***_* ****”Define the caBIG system architecture that satisfies the requirements of the caBIG Community”***

## caBIG requirements – Use case view
System components – Design view
Implementation strategy – Use case prioritization
Technology testing & Proof of concept
Evaluation and recommendations
Significant architecture views
Deployment and Grid service view
Risk analysis
Summary

- System components – Design view
- Implementation strategy – Use case prioritization
- Technology testing & Proof of concept
- Evaluation and recommendations
- Significant architecture views
- Deployment and Grid service view
- Risk analysis
- Summary

## caGrid System Architecture Process

- _For each workspace (ICR,C-CDE, TBPT, CTMS):_
- Identify Software feature list
- Identify actors and use case
- Develop Use case diagrams

- _Integrated analysis:_
- Create integrated high level use case view
- Develop integrated use case diagram
- Develop use case specifications
- Testing and feedback from caBIG

- _caGrid Architecture:_
- Identify architecture views
- Develop caGrid architecture
- Prioritized use case to define implementation phases

- _SIG Recommendations_
- Identifiers
- Workflows
- Query languages
- Identity

- _Non-functional requirements_
- caBIG standards
- Categories

- _Technology:_
- Evaluation
- Map models with technologies
- Develop technology view

- _Design and development:_
- Design and develop framework
- Reference implementation
- Documentation

- caBIG

**NCICB**

**Research**
**Center**

***Other Data Source***

***Small Center ***

***Other Domain Object ***

***Resource Center***

***Resource Center***

***Portal***

**Research**
**Center**

## Integrated Use Case Model

***Advertisement: ***By providing rich semantic information, a grid service can be advertised on the caBIG grid This allows members of the community to locate (discover) this service based on the semantic metadata
***Administration:*** Administration use case outlines how resources can be managed on the grid
***Discovery: ***Discovery is the act of searching for (based on filtering criteria) and identifying caBIG resources*** ***
*** ******Invocation: ***This use case describes how a researcher would execute a tool or application on the grid
-  ***Query: ***Query use case outlines how a researcher can use one or more data services on the grid to retrieve relevant data
*** ******Workflow: ***Workflow is connecting of multiple grid services in trying to solve a problem that an individual service could not solve

## Non Functional Requirements

| 1. Security |
| --- |
| Support community of communities (Virtual Organizations): Enable disparate groups of Cancer Research Centers and / or individuals (researchers / clinicians) to share resources in a controlled fashion, so that members may collaborate to achieve a share goal |
| Enables integration and interoperability: Enable integration and interoperability between Cancer Research Center security and caGrid security. Do not replace Cancer Research center security mechanism and infrastructure. Interoperability between parties should happen in all layers as follows: transport, message, service, and policy layer |
| Enables creation and management of dynamic trust domain:  Trust among resources and users. These trust can span multiple research centers. Research communities that perform collaborative work within caGrid may form quickly, evolve overtime, and span organizations. Their effective operation depend critically on trust, the extend on which one participant can relay on others to behave as expected |
| Support dynamic creation of services: Users must be able to create new services (like data service) dynamically without administrator intervention. These services need to be coordinated and must interact securely with other services. Thus, we must be able to name the service with an assertable identity and grant access right to that identity without contradicting the governing local policy |

- * The Grid 2 book

## Non Functional Requirements  (Cont.) 

| 4. Connectivity |
| --- |
| Traversing firewalls, Dynamic IP addresses and Network Address Translations (NATs), Network characteristics are different, Temporal disconnects, Ad-hoc networks (APPAGG-RG) |
| 5. Decentralization |
| Fault tolerance might be related and self-healing are related (auto reconfiguration) |
| 6. Even servers crash |
| Decentralized infrastructure service, Dynamic entry/exit |
| 7. Quality of Services |
| Data quality and corruption |
| 8. Industry / NCI standards: |
| Must be grid computing compliant, Leverage existing solutions where appropriate
Standard interface protocols, Service oriented architecture pattern, Use HTTP as a transport protocol, Have easily-understandable programming model, Perform parallel programming, The system is JMS compliant, Web services, Open source, J2EE Complaint, Java source code, Expose object not data source, Standard query language instead of standard API., EVS as standard vocabulary, caDSR provides Ontology mapping, Local Data source is JDBC compliant  |
| 9. Semantic: |
| Well defined API, Ability to use relational backend, Ability to read/write/modify OWL/RDF/DAML-OIL ontology language, Ability to read/write/modify RDFS/XML representation of semantic objects, Ability to define ontologies on the fly, Ability to map ontologies to one another, Reification ready, Inference engine capability, RDQL aware/ready/plug-in, Ability to find intersection/union of two related ontologies |

## Considerations to define the system architecture

- Functional requirements:
- Use cases from caBIG community
- Non-functional requirements:
- Security, reliability, performance, open source, etc.
- Compatibility documents:
- Expose objects no data source (like RDBMS or XML)
- NCICB:
- Leverage caDSR and EVS
- Others: caCORE Toolkit
- caBIG technologies
- Mobius
- Architecture workspace:
- Probably other requirements from SIGs (Identifiers, security, etc)
- Principles:
- SOA
- Standards and community acceptance
- Solve a business problem no a technology problem
- Leverage OGSA / OGSI / WS-RF Standards - Specifications

**Architectural Considerations**

## 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 Components - SOA**

**Transport**

## System Components (Cont.)

**Transport** is the mechanism used to move service requests from the Service consumer to the service provider, and service responses from the service provider to the service consumer
**Service Communication Protocol** is an agreed mechanism that the service provider and the service consumer use to communicate what is being requested and what is being returned
**Service Description** is an agreed schema for describing what the service is, how it should be invoked, and what data is required to invoke the service successfully
**Service** describes an actual service that is made available for use
**Business Process** is a collection of services, invoked in a particular sequence with a particular set of rules, to meet a business requirement. Note that a business process could be considered a service in its own right, which leads to the idea that business processes may be composed of services of different granularities
**The Service Registry** is a repository of service and data descriptions, which may be used by service providers to publish their services, and service consumers to discover or find available services. The service registry may provide other functions to services that require a centralized repository
**Policy:** is a set of conditions or rules under which a service provider makes the service available to consumers. There are aspects of policy which are functional, and aspects which relate to quality of service; therefore we have the policy function in both functional and quality of service areas
**Security **is the set of rules that might be applied to the identification, authorization, and access control of service consumers invoking services
**Management** is the set of attributes that might be applied to managing the services provided or consumed

## 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**

## Use case prioritization – caGrid Phase II

| Use case package | Scope of Implementation – GT3 |
| --- | --- |
| Advertisement | API (Extend Globus / OGSA-DAI client API)
Develop caGrid GUI (Web based)
Define service metadata based on caBIG object model metadata Define data service level metadata
Plug-in caDSR as metadata provider
XML Schema management |
| Discovery | API (Extend Globus / OGSA-DAI client API)
Develop caGrid GUI (Web based)
Globus Registry based discovery. Initial identifier testing |
| Query | Single data source query
Implement OGSA-DAI functionality for transformation and delivery
Abstract it extending API and developing GUI (Web based) 
Test Query federation independently
Evaluate query languages |
| Invocation | Create services with Globus core / Index
Initial testing implementing GRAM |
| Security | Secure communication, limited access control 
GSI – myProxy. Testing data and tools services |

## Use case prioritization – caGrid Future Version

| Use case | Scope of Implementation – GT4 |
| --- | --- |
| Advertisement | Semantic metadata for applications / tools
GUI client and Desktop client
Identifiers for service description |
| Discovery | Free text and advance discovery
Semantic interoperability between data and applications |
| Query | Federated query
Query languages decisions |
| Invocation | GRAM fully implemented
gridFTP and RFT for  |
| Workflow | Review of SIG recommendation
Technology testing in grid environment |
| Security | Credential management, Single sign-on, more robust access control
CAS, GSI, myProxy |
| Administration | API and GUI tools
Best practices SIG recommendation regarding deployment of caGrid services
 |

## Technology evaluation:caCORE and caARRAY integration into OGSA-DAI framework

**Globus**

- OGSA-DAI

**caBIO**

**caARRAY**

**caDSR / EVS**

- Built on top of Globus toolkit. Thus inherits all characteristics of a generic Globus grid service - advertisement and discovery through Globus index service and security authentication and authorization  framework.
- OGSA-DAI extension to expose objects as data sources.
- Same implementation patterns for both data sources
- Same query languages
- Code migrated from OGSA-DAI 3.1 to 4 and 5.0.
- Local caDSR instance to qualify data grid service
- Local caDSR fulfill advertisement, discovery and query requirements
- Leverage Globus/OGSA-DAI functionality

## Technology evaluation: Mobius Integration

**Globus**

- OGSA-DAI

**MAKO**

**caBIO**

**caBIO**

**MAKO**

- Three steps test: caBIO as MAKO, MAKO as OGSA-DAI and MAKO as Globus service
- OGSA-DAI client API can query into caBIO using XPath and return XML views of caBIO objects
- Mobius Services can now leverage the Grid Security Infrastructure (GSI)
- More overhead in being a grid services
- Severe degradation in performance of MAKO binary attachments.  Binaries must be base 64 encoded on the sending side and decoded on the receiving side

## Technology evaluation:DQP

**Globus**

- OGSA-DQP

**caBIO**
**mySQL**

**GO**
**mySQL**

**EVS**
**mySQL**

- OGSA-DAI extension
- Query language OQL
- Each data source expose mySQL database
- Serialization provided by the datasource / DQP
- mySQL provides the schema
- Query, transformation and delivery using OGSA-DAI framework
- Cached query results using delivery activity from OGSA-DAI
- You can cache in xmldb or RDBMS
- Query cache results using datasource language
- Federation: DQP core capability
- Extensible framework to query objects

## Technology evaluation:Globus Security 	

- Used SimpleCA to create a caBIG certificate authority (caBIG-CA)
- Installed and Configured Globus3.2.1 (using caBIG-CA ) on the OSU dc cluster
- Created host certificates using caBIG-CA for each node on the cluster
- Create user certificates for both Linux and windows users using caBIG-CA
- Set up MAKO services and GME services on all nodes, and provided access control via a centralized grid map file
- Proxy certificate generation for the both Linux and windows users to test credential delegation
- Invoked the MAKO secure grid services from both windows and Linux using the MAKO GUI, passing the proxy certificate for user of the GUI
- Setup MyProxy on one of the dc cluster nodes
- Deployed MyProxy client to the globus installation on each node of the cluster
- Tested storing and retrieving proxies from MyProxy in both windows and Linux environments and invoked MAKO secure grid service using those proxies
**In progress**
- Cross institutional secure communication between NCICB and OSU
- Installation, Configuring and Setup of Purse on the OSU DC Cluster

## Technology evaluation: Analytical tools as Grid service

- A service wrapper around Jim Kent’s Blat Alignment tool
- Binary distribution of the tool with a java implementation wrapper built to execute it.  The tool was hard-configured to run DNA alignments against the yeast genome
- The service was built using the bottom-up Globus build tools (the WSDL interface definition was automatically generated from the java source)
- Service implementation used delegation (operational providers) to make the service independent from grid container classes
- The Globus core provides the basic building blocks for invocation services in a grid environment
- Only synchronous application invocation is supported
- No Job /Task management functionality is provided, this would have to build upon the Globus Core (Like WS Gram / COG)
- Service data and Meta-data should be used to make these examples richer
- Notification services should be investigated for use as an implementation of asynchronous invocation using the Globus Core
- Cog-Toolkit and other more sophisticated (Globus Core based) invocation frameworks should be evaluated as an extension of this exercise

**Globus (GT3)**

**Blat Service**

## Related projects

- Architecture of GDMS modules integrated in OGSA-DAI

- Distribute Mediation

- BRIDGESBiomedical Research Informatics Delivery by Grid Enabled Services

**Notes:**

BRIDGES will incrementally develop and explore database integration over six geographically distributed research sites within the framework of the large Welcome Trust biomedical research project Cardiovascular Functional Genomics. Three classes of integration will be developed to support a sophisticated bioinformatics infrastructure supporting: data sources (both public and project generated), bioinformatics analysis and visualization tools, and research activities combining shared and private data. The inclusion of patient records and animal experiment data means that privacy and access control are particular concerns. An exploration of index factories accelerating sequence processing will test the hypothesis that the Grid makes a new class of e-Science indexes feasible. Both OGSA-DAI and IBM DiscoveryLink technology will be employed and a report will identify how each performed in this context. 

Entrez—direct and fast access to key Pubmed, Nucleotide and Genbank data sources 
Blast—more power for gene and protein similarity searches 
HMMER—an SQL-based front end to the HMMER application 
XML—SQL-based access to XML-based data sources 
BioRS—access to a broad array of public bioinformatics data sources 
ODBC—access to additional relational data sources 
Extended search—integrates information from unstructured data sources 
Teradata—accesses information residing in a teradata data warehouse 
DB2 control center—fast configuration of any data source within DiscoveryLink 

The solution: 
Provides single-query access to data residing in multiple heterogeneous data sources, both locally and remotely. 
Permits queries across several data sources and optimizes performance, reducing the time needed to get back results difficult or impossible to obtain in a conventional way. 
Eliminates many database currency and synchronization issues—DiscoveryLink queries the original distributed data sources without modifying or copying the data. 

## Significant use cases vs. Candidates technologies

|  | Advertise | Discovery | Query | Invocation |
| --- | --- | --- | --- | --- |
| 1. Globus | User defines attribute to qualify services
Standard API for advertisement | Standards API to search for services
Search based on metadata defined by users | - Not available out of the box. However could be implemented | - Standard process to virtualize applications
Standard API
Notification and status |
| 2. Globus + OGSA-DAI | Extended framework to expose data sources
Provides static (Service description) and dynamic (model definition) metadata
Process and API to advertise data services | - Since OGSA-DAI services are Globus services. Discovery leverage Globus APIs. This is done by querying the dynamic and static metadata |  Does not force to use a specific query language You use the one that the data source provides
Provides a standard way to submit queries with perform documents
Query single data sources or federation by using integration process | - Same as option 1
- OGSA-DAI does not provide additional functionality for invocation |
| 3 Globus + OGSA-DAI + DQP | - Same as option 2 | Same as option 2
Select data source participants for query, create a one schema and query against that schema | Federated query
Need to extend framework to query objects
Flexible to create federated environments
Cached federated environments / queries  | - Same as option 1.
- OGSA-DAI does not provide additional functionality for invocation. |

- * Security: All options includes GLOBUS security and Index services

## Significant use cases vs. Candidates technologies (Cont.)

|  | Advertise | Discovery | Query | Invocation |
| --- | --- | --- | --- | --- |
| 4. Globus + Mobius | Same as option 1
All data services expose as XML data sources
Need to extend metadata framework to describe data services in vmako
Need to define a process to use caDSR as metadata providers Need to translate caDSR to XML schema
Need to define scope between caDSR and GME | Same as option 1
Need to extend Globus metadata API to discovery resources exposed as VMAKO | Only support XPATH as query language
With VMAKO, the user see data sources as single data source
Integration tool more than grid framework
Does not provide federated queries | - No supported |
| 5 Globus + OGSA-DAI + Mobius | Similar to option 2
All Service expose as XML data service
Need to extend framework for metadata Similar to option 4
Need to define how to integrate GME | - Need to extend framework to use metadata | Same as option 4
Extra layers no provide added value | - No supported |
| 6 Globus Core / Index services / GRAM | - Same as option 1 | - Same as option 1 | - No supported | Remote submission of jobs
Common user interface |

- * Security: All options includes GLOBUS security and Index services

## Security evaluation summary

- * Security: All options includes GLOBUS security and Index services

|  | Secure Communication   | Single Sign On | User/Organization Management | Delegation | Access Control on caBIG Services | User/Organizational Attribute Management |
| --- | --- | --- | --- | --- | --- | --- |
| GSI | Yes, via public/private keys | Yes via X509 Certificate
No efficient way of managing certificates | Limited | Yes – but with security ramifications | Access control at the service level, not sufficient (management nightmare) NO access control at the data layer | No |
| myProxy | N/A | N/A | Helps manage proxies for users but that is all  Not sufficient | Can be used as a tool to help delegate proxies | N/A | N/A |
| Shib | N/A | Yes, but not but the heuristics does no apply to the gird | Yes, but not but the heuristics does no apply to the gird | No | No | Yes, but not but the heuristics does no apply to the gird |
| GridShib | Yes via Globus | Yes via Globus | Partially via Globus, probably wont be sufficient. | Yes via Globus | Will be able to be used as a tool to help provide access control | Yes |

## caGrid Technologies – Summary & Recommendations

- Globus Tool kit 3/4 Grid framework
- Registry and index service  (Advertisement, Discovery, virtual organizations)
- Globus security (GSI-CAS, myProxy)
- Authentication, Authorization, Delegation, Encryption
- Mobius
- MAKO as grid cached service
- GME as metadata repository framework
- Globus Core, Index services, COG and GRAM as Invocation
- OGSA-DAI as Grid Data layer
- Exposing data service
- Query language that represents the objects.
- Metadata (Object description) as caDSR Instances
- Additional metadata as GLOBUS metadata
- DQP 2.0 / 3.x
- Query plan
- architecture for federation
- caDSR/EVS service as semantic layer
- Provides information for federation
- Helps to advertise and discover services
- Semantic resolution on the grid

## 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

## Grid View

- Admin

**Grid View**

- Security

- caBIO

- caDSR
- EVS

- caBIG
- Dataresource

- ...

- caARRAY

- Other caBIG
- DataResource

- Data source expose as objects
- caDSR / EVS qualify services
- caDSR / EVS semantic interoperability among dataservices
- Standard grid interface
- Standard query language
- Standard query interface
- Standard discovery interface
- Globus / OGSA-DAI Security
- Data integration using mediation pattern
- Federated query with DQP
- Leverage OGSA-DQP functionality like transformation and delivery (e.g. gridFTP)
- Same Globus framework to virtualize data and applications
- Index services
- Resource monitoring
- Invocation / Schedule
- Execution / coordination

- Identifiers

- caBIG Analysis
- tool

- rProteomics

- Other caBIG
- Analysis tool

- Grid client API

- Globus

- Resource API

- OGSA-DAI / DQP

- GRAM

- Registry

- Query

- Invocation

## 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

## caGrid Deployment Diagram / Services

- caBIG Grid node
- (Replica)

- caBIG Registry Service

- Research center grid node

- Federated query service

- Data services:
- caARRAY service
- caBIO service

- Registry / Grid nodes: Globus 3/4 (component: Core, Index Services, Security, Information services, GRAM (Optional))
- Cached services: Mobius (MAKO) for XML, mySQL for RDB, Files
- Federation service DQP Data service: OGSA-DAI

- CA Authority
- Service

- ID Resolution
- Service
- (replica)

- Project /
- Research Center
- Registry (1 or more)
- VO

- Vocabulary Service - EVS
- Semantic Service - caDSR

- NCICB Grid node

- Cached service

- Application / data service

- Expose services
- GT3: Java API from Object model
- GT4: Web service from Object model

**caGrid Deployment Diagram / Services**

- Semantic service map data and tools

- caGrid Portal

- caBIG Grid node
- (Replica)

- Metadata extractor service: caDSR instance of services from each data/application service Implemented either in Mobius (GME / caDSR)

- Metadata extractor service

- Grid Client

- Portal / grid client / grid client apps

- CAS

**caBIG**

- Scenario 1:
- Install caGRID
- In Research center

- Scenario 2:
- Advertise a
- Service.

- Scenario 3:
- Discover
- service.

- Scenario 4:
- Discover
- Service portal.

- Scenario 6:
- Query integration
- Two Data sources.

- Scenario 7:
- Federated
- Query.

- Scenario 5:
- Query single
- Data sources.

## caGrid Services

- Data services
- Analytical services
- Portal service
- Client API service
- Registry services
- Administration services
- Security services

## 6. Risk analysis

- Technology evolution
- Changing versions of the toolkits
- Community adoptions for grid standards
- Usability / Complexity
- Requirement evolution
- Changing / evolving community needs
- caBIG Community adoption
- Late introduction of requirements
- Support / knowledge / Training
- Learning curve
- Administration needed to support distributed infrastructure
- Availability / Monitoring / Performance
- Training
- Technology
- Quality of service

## High-Level – Time Line

|   |   | Oct | Nov | Dec | Jan | Feb |  | Mar | Apr | May | Jun |   |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|   |  |   |   |   |   |   |  |   |   |   |  |   |
| Requirement analysis |  |   |   |   |   |   |  |   |   |   |  |   |
|   |  |   |   |   |   |   |  |   |   |   |  |   |
| System architecture |  |   |   |   |   |  |   |   |   |   |  |   |
|   |  |   |   |   |   |   |  |   |   |   |  |   |
| Reference implementation |  |   |   |   |   |   |  |   |   |   |   |   |
|   |  |   |   |   |   |   |  |   |   |   |  |   |
| Technology evaluation |  |   |   |   |   |   |  |   |   |   |  |   |
|   |   |   |   |   |   |   |  |   |   |   |   |   |

**High-Level – Time Line**

## Main deliverables for phase II – Prototype GRID

- _caGrid requirements: _First version and_ _Use cases and non functional requirements
- _Grid infrastructure_: GT3, OGSA-DAI 5: Implement Advertisement, Discovery, Query, Invocation and security as described in use case prioritization
- _Service description and semantics_: caDSR and EVS as caGrid components Mobius to support semantics as well
- _GUI and API: _Web interface to use the grid and API to build applications
- _Reference implementation_: Implement ~3 data services and ~2 analytical services to test the grid infrastructure
- _Documentation and lesson learned:_ Document the process to implement the system and how to expose services
- _Potential Technologies_: Evaluate migration to GT4 and Security frameworks. DQP.
- _Have fun_ 

- _[Cagrid_developers@list.nih.gov](mailto:Cagrid_developers@list.nih.gov)_
**caGrid Team:**
- NCICB: Peter, Avinash
- OSU: Joel, Scott, Tahsin, Stephen, Shannon
- Panther Informatics.: Steve, Brian
- BAH: Arumani, Michael
- SAIC: Tara, Manav, Jijin, Ruowei, William

## Appendix

## OGSA and Globus Toolkit 3

_**OGSA:**_ Open standard architecture for next generation grid-services to enable the creation, maintenance, and integration of grid services maintained by virtual organizations
_**OGSI:**_ A core component of OGSA, which provides a uniform way to describe grid services and defines a common pattern of behavior for all grid services. In short, this architecture defines grid service behaviors, service description mechanism, and protocol binding information by using web services as the technology enabler
_**Virtual organizations:**_ coordinated resource sharing and problem solving in dynamic, multi-institutional organizations. sharing is with direct access to computers, software, data, and other resources by a range of collaborative problem solving and resource brokering strategies. The sharing is controlled with resource providers and consumers defining what is shared, who is allowed to share and the conditions under which sharing occurs. The set of individuals and/or institutions defined by the sharing rules from the virtual organization
_**GT3:**_ The Globus software technology toolkit version 3 is the major reference implementation of the OGSI standard

## Components in Globus Toolkit

## OGSA-DAI

- The OGSA-DAI project is concerned with constructing middleware to assist with access and integration of data from separate data sources via the grid. It is engaged in identifying the requirements, designing solutions and delivering software that will meet this purpose. The project was conceived by the _**UK Database Task Force**_ and is working closely with the Global Grid Forum _**DAIS-WG**_ and the _**Globus Team**_
- OGSA-DAI is a UK _**DTI Funded**_ e-Science Grid Core Project involving the following partners:

- * From OGSA-DAI

## 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

## GT3 and Grid Security infrastructure (GSI)

- Casts security functionality as OGSA services to allow them to be located and used as needed by applications
- Uses sophisticated hosting environments to handle security for applications and allow security to adapt without having to change the application
- Publishes service security policy so that clients can discover dynamically what credentials and mechanisms are needed to establish trust with the service
- Specifies standards for the exchange of security tokens to allow for interoperability

- GT3s security model seeks to allow applications and users to operate on the Grid in as seamless and automated a manner as possible. Security mechanisms should not have to be instantiated in an application but instead should be supplied by the surrounding Grid infrastructure, allowing the infrastructure to adapt on behalf of the application to meet the application's requirements. The application should need to deal with only application specific policy. GT3 uses the following powerful features of OGSA and Web services security to work toward this goal:

- * From Security for grid services paper

## Security Layers

**Security Layers**

- * From Globus presentation

## GT3 Security Model in action

- The client’s hosting environment retrieves and inspects the security policy of the target service to determine what mechanisms and credentials are required to submit a request
- If the client’s hosting environment determines that the needed credentials are not already present, it contacts a credential conversion service to convert existing credentials to the needed format, mechanism, and/or trust root. Two examples of such services are CAS, for translating the user’s personal credential to a VO credential, and KCA, for converting between Kerberos and PKI mechanisms
- The client’s hosting environment uses a token processing and validation service (e.g., XKMS) to handle the formatting and processing of authentication tokens for exchange with the target service. This service relieves the application and its hosting environment from having to understand the details of any particular mechanism
- On the server side, the hosting environment likewise uses a token processing service to process the authentication tokens presented by the client. (In the example, both use the  same service, but each could use a separate service.)
- After authentication and the determination of client identity and attributes, the target service’s hosting environment presents the details of the request and client information to an authorization service (e.g., PERMIS or Akenti) for a policy decision

- *  From Security for grid services paper