# Presentation: 398646

## Open Grid Services Architecture:A Tutorial

- Ian Foster
- Argonne National Laboratory
- University of Chicago
- Globus Alliance
- www.mcs.anl.gov/~foster

## Thanks

- For slides and/or comments: Malcolm Atkinson, David Foster, Carl Kesselman, Lisa Childers, Lee Liming, Steve Tuecke

## Overview

- Grid background
- Open Grid Services Architecture
- Open Grid Services Infrastructure
- Beyond OGSI: other OGSA services
- Globus Toolkit v3 implementation
- Early GT3 performance measurements
- Scientific and commercial perspectives
- Summary

## The Grid

- Infrastructure (“middleware” & “services”) for establishing, managing, and evolving multi-organizational federations
- Dynamic, autonomous, domain independent
- On-demand, ubiquitous access to computing, data, and services
- Mechanisms for creating and managing workflow within such federations
- New capabilities constructed dynamically and transparently from distributed services
- Service-oriented, virtualization

## What is a Grid?

- Three key criteria
- Coordinates distributed resources ...
- using standard, open, general-purpose protocols and interfaces ...
- to deliver non-trivial qualities of service.
- What is not a Grid?
- A cluster, a network attached storage device, a scientific instrument, a network, etc.
- Each may be an important component of a Grid, but by itself does not constitute a Grid

**Notes:**
TBD: Perhaps split this into multiple slides, with more elaboration about what is and is not a Grid.  Can draw material from Ian’s article.

## eScience is the Initial Motivator ...

- New approaches to enquiry based on
- Deep analysis of huge quantities of data
- Interdisciplinary collaboration
- Large-scale simulation
- Smart instrumentation
- Enabled by an infrastructure that enables access to, and integration of, resources & services without regard for location

*... **but eBusiness is catching up rapidly*

## Resource Integrationas a Fundamental Challenge

## Distributed Computing

- The concept of sharing distributed resources is not new
- In 1965, MIT's Fernando Corbató and the other Multics OS designers envisioned a computer facility operating “like a power company or water company”
- In their 1968 article “the computer as a communications device,” J. C. R. Licklider and Robert W. Taylor anticipated Grid-like scenarios
- Since the late 1960s, much work has been devoted to developing distributed systems, with mixed success

## Overview

- Grid background
**Open Grid Services Architecture**
- Open Grid Services Infrastructure
- Beyond OGSI: other OGSA services
- Globus Toolkit v3 implementation
- Early GT3 performance results
- Scientific and commercial perspectives
- Summary

## Why Open Standards Matter

- Ubiquitous adoption demands open, standard protocols
- Standard protocols enable *interoperability*
- Avoid product/vendor lock-in
- Enables innovation/competition on end points
- Further aided by open, standard APIs
- Standard APIs enable *portability*
- Allow implementations to port to different vendor platforms
- Internet and Web as exemplars

## The Emergence ofOpen Grid Standards

- Increased functionality,
- standardization

- Custom
- solutions

- 1990

- 1995

- 2000

- 2005

- The Emergence ofOpen Grid Standards

- 2010

## Open Grid Services Architecture

- Service orientation to virtualize resources
- Everything is a service
- From Web services
- Standard interface definition mechanisms
- Evolving set of other standards: security, etc.
- From Grids (Globus Toolkit)
- Service semantics, reliability & security models
- Lifecycle management, discovery, other services
- A framework for the definition & management of composable, interoperable services

- “The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration”, Foster, Kesselman, Nick, Tuecke, 2002

## Web Services 

- XML-based distributed computing technology
- Web service = a server process that exposes typed ports to the network
- Described by the Web Services Description Language, an XML document that contains
- Type of message(s) the service understands & types of responses & exceptions it returns
- “Methods” bound together as “port types”
- Port types bound to protocols as “ports”
- A WSDL document completely defines a service and how to access it

## WSDL Example

- <**wsdl:definitions** targetNamespace=“...”>
-    <**wsdl:types**>
-       <schema>
-          <xsd:element name=“fooInput” .../>
-          <xsd:element name=“fooOutput” .../>
-       </schema>
-    </wsdl:types>
-    <**wsdl:message** name=“fooInputMessage”>
-       <part name=“parameters” element=“fooInput”/>
-    </wsdl:message>
-    <**wsdl:message** name=“fooOutputMessage”>
-       <part name=“parameters” element=“fooOutput”/>
-    </wsdl:message>
-    <**wsdl:portType** name=“fooInterface”>
-       <**wsdl:operation** name=“foo”>
-          <**input** message=“fooInput”/>
-          <**output** message = “fooOutput”/>
-       </wsdl:operation>
-    </wsdl:portType>
- </wsdl:definitions>

## Transient Service Instances

- “Web services” address discovery & invocation of persistent services
- Interface to persistent state of entire enterprise
- In Grids, must also support transient services, created/destroyed dynamically
- Interfaces to the states of distributed activities
- E.g. workflow, video conf., dist. data analysis
- Significant implications for how services are managed, named, discovered, and used
- In fact, much of our work is concerned with the management of services

## OGSA Structure

- A standard substrate: the Grid service
- Standard interfaces and behaviors that address key distributed system issues: naming, service state, lifetime, notification
- A Grid service is a Web service
- ... supports standard service specifications
- Agreement, data access & integration, workflow, security, policy, diagnostics, etc.
- Target of current & planned GGF efforts
- ... and arbitrary application-specific services based on these & other definitions

## Overview

- Grid background
- Open Grid Services Architecture
**Open Grid Services Infrastructure**
- Beyond OGSI: other OGSA services
- Globus Toolkit v3 implementation
- Early GT3 performance results
- Scientific and commercial perspectives
- Summary

## OGSI Specification

- Defines WSDL conventions and extensions
- For describing and naming services
- Working with W3C WSDL working group to drive OGSI extensions into WSDL 1.2
- Defines fundamental interfaces (using extended WSDL) and behaviors that define a Grid Service
- A unifying framework for interoperability & establishment of total system properties
- http://www.ggf.org/ogsi-wg

## FundamentalInterfaces & Behaviors

- OGSI defines basic patterns of interaction, which can be combined with each other and with custom patterns in a myriad of ways
- OGSI Specification focuses on:
- Atomic, composable patterns in the form of portTypes/interfaces
- Define operations & associated service data elements
- A model for how these are composed
- Compatible with WSDL 1.2
- Complete service descriptions are left to other groups that are defining real services

## OGSI: Standard Web Services Interfaces & Behaviors

- Naming and bindings (basis for virtualization)
- Every service instance has a _unique name_, from which can discover _supported bindings_
- Lifecycle (basis for fault resilient state management)
- Service instances created by _factories_
- Destroyed _explicitly_ or via _soft state_
- Information model (basis for monitoring & discovery)
- _Service data_ (attributes) associated with GS instances
- Operations for _querying_ and _setting_ this info
- Asynchronous _notification_ of changes to service date
- Service Groups (basis for registries & collective svcs)
- Group membership rules & membership management
- Base Fault type

## OGSI Service Data

- Attributes: Publicly visible state of the service
- Want to bring full power of XML to attributes
- getXXX/setXXX is too limiting
- How to get/set multiple?
- Want richer queries across attributes (e.g., join)
- Use XML Schema, XPath, XQuery, XSLT, etc.
- OGSI service data:
- Attributes defined using XML Schema
- Attributes combined into a single (logical) document within the service
- Rich pull/push/set operations against service data document
- Should declare attributes in WSDL interface

## Open Grid Services Infrastructure

- Implementation

- Hosting environment/runtime
- (“C”, J2EE, .NET, ...)

- Data
- access

- Lifetime management
-  Explicit destruction
-  Soft-state lifetime

## Open Grid ServicesInfrastructure (OGSI)

**Service requestor (e.g. user application)**

**Service factory**

- Interactions standardized using WSDL

- Authentication & authorization are applied to all requests

- Open Grid Services_Infrastructure_ (OGSI)

## GWSDL

- OGSI requires interface extension/composition
- We worked within W3C WSDL working group to define standard interface extension in WSDL 1.2 that meets OGSI requirements
- But could not wait for WSDL 1.2
- So defined gwsdl:portType that extends WSDL 1.1 portType with:
- WSDL 1.2 portType extension
- WSDL 1.2 open content model
- Define GWSDL  WSDL 1.1 & 1.2 mappings

## GWSDL Example

- <wsdl:definitions>
-    <wsdl:types>...</wsdl:types>
-    <wsdl:message>...</wsdl:message>
-    ...
-    <**gwsdl:portType** name=“foo”                              **extends=“ns:bar ogsi:GridService”**>
-       <wsdl:operation name=“op1”>...</wsdl:operation>
-       <wsdl:operation name=“op2”>...</wsdl:operation>
-       **<ogsi:serviceData ... />**
-    </gwsdl:portType>
-    ...
- </wsdl:definitions>

## Example:Reliable File Transfer Service

- File
- Transfer

*Internal*
*State*

*Data transfer operations*

## OGSI Implementations

- Globus Toolkit version 3.0 (Java, C client)
- U Virginia OGSI.NET (.NET)
- LBNL pyGlobus (Python)
- U Edinburgh (.NET)
- U Manchester (PERL)
- Fujitsu Unicore (Java)

## Overview

- Grid background
- Open Grid Services Architecture
- Open Grid Services Infrastructure
**Beyond OGSI: other OGSA services**
- Globus Toolkit v3 implementation
- Early GT3 performance results
- Scientific and commercial perspectives
- Summary

## Open Grid Services Architecture

- OGSA

- OGSI: Interface to Grid Infrastructure

- Applications in Problem Domain X

- Compute, Data & Storage Resources

- Distributed

- Application & Integration Technology for Problem Domain X

- Users in Problem Domain X

**Virtual Integration Architecture**

- Generic Virtual Service Access and Integration Layer

** **

** **

**-**

** **

## OGSA Standardization & Implementation

- OGSI defines core interfaces and behaviors for manageable services
- Supported by strong open source technology & major commercial vendors
- Efforts are underway within GGF, OASIS, and other bodies to define standards for
- Agreement negotiation
- Common management model
- Data access and integration
- Security and policy
- Etc., etc., etc.

## Transactions & Contexts

- WS-Coordination & WS-Transaction
- IBM/MS (not in standards org)
- WS-CAF (Coordinated Application Framework)
- Sun/Oracle/Arjuna/Fujitsu (not in standards org)
- WS-CTX (Context)
- WS-CF (Coordination Framework)
- WS-TXM (Transaction Management)
- Both take a “contextualization” approach
- Context (id) threaded through SOAP header
- OGSI for context creation, naming & lifecycle???

## Security Standards

- Many core security standards are from IETF
- X.509, Kerberos, etc.
- X.509 Proxy Certificates (RFC soon hopefully)
- Used by Globus Toolkit GSI
- OASIS appears to be leader in Web services security standards
- WS-Security: SOAP message security
- SAML: signed assertions using XML
- XACML: access control lists using XML
- GGF OGSA Security WG evaluating security specifications for applicability to OGSA

## IBM/MicrosoftWS Security Architecture

- Large set of specifications for doing Web services security, most of which should be appropriate for OGSA
- Announced April 2002
- Initial spec in July 2002 (WS-Security)
- Submitted to OASIS
- New crops of specs arrive periodically
- WS-Policy*, WS-Trust, WS-Federation, etc.
- But... Not yet in any standards organization

## WS SecurityCurrent/Proposed WSS-specs 

- proposed

- SOAP Foundation

- WS-Security

- WS-Policy

- WS-Trust

- WS-Privacy

- WS-Secure
- Conversation

- WS-Federation

- WS-Authorization

- In progress

- promised

## OASIS SAML & XACML

- SAML: Security Assertion Markup Language
- Good for asserting properties such as group membership, etc
- XACML: eXtensible Access Control Markup Language
- For defining access control policies
- These are gaining considerable momentum, but WS-Policy* leaves them in question

## Project Liberty Alliance

- V1.x specifications for identity federation
- Allows cross-organization identification
- Privacy preserving model
- Based on SAML

## WS-Agreement

- Recall key criteria of a Grid:
*Coordinates resources that are not subject to centralized control* ...
- using standard, open, general-purpose protocols and interfaces ...
*to deliver non-trivial qualities of service*.
- Implies need to express and negotiate agreements that govern the delivery of services to clients
- Agreement = what will be done, QoS, billing, compliance monitoring

**Notes:**
TBD: Perhaps split this into multiple slides, with more elaboration about what is and is not a Grid.  Can draw material from Ian’s article.

## WS-Agreement Contents

- Standard agreement *language*
- A composition of a set of terms that govern a service’s behavior with respect to clients
- Agreement language uses WS-Policy (currently)
- Standard attributes for terms that express current state of negotiation
- Other groups define specific terms
- Standard agreement negotiation *protocol*
- Establish, monitor, re-negotiate agreement
- Expressed using OGSI GWSDL interfaces
- Each agreement represented by a service

## WS-Agreement Applicability

- All interesting Web/Grid services interactions will be governed by agreements!
- WS-Agreement (language and interfaces) should be used by specifications that define domain-specific services
- Data services
- Job submission
- Specialized services
- Etc.

## Platform’s Community Scheduling Framework & WS-Agreement  

- Reservation Agreement Exchange

**Internet**

**Queuing **
**Service**

**GT3.0**

**Job **
**Service**

**Reservation **
**Service**

**RM Adapter**

**GT3.0**

**LSF**

**Site A**

**Site B**

**RM Adapter**

**GT3.0**

**PBS**

**Site C**

**GT3.0**

**SGE**

**RM**
**Adaptor**

## WSDM / WSMF / CMM

- OASIS Web Services Distributed Management (WSDM) technical committee
- Management using/of Web Services
- HP submitted its Web Services Management Framework (WSMF) to WSDM in July 2003
- WS-Events: event schema, subscription, message queues
- WSMF-Foundation: management *using* Web services
- WSM: management *of* Web services
- GGF Common Management Model (CMM) WG
- IBM submission overlaps WSMF-Foundation
- Working to bring WSDM & CMM together, based on OGSI foundation

## Data as Service:OGSA Data Access & Integration

- Service-oriented treatment of data appears to have significant advantages
- Leverage OGSI introspection, lifetime, etc.
- Compatibility with Web services
- Standard service interfaces being defined
- Service data: e.g., schema
- Derive new data services from old (views)
- Externalize to e.g. file/database format
- Perform queries or other operations

## Data Services

- GGF Data Access and Integration Svcs (DAIS)
- OGSI-compliant interfaces to access relational and XML databases
- Needs to be generalized to encompass other data sources (see next slide...)
- Generalized DAIS becomes the foundation for:
- Replication: Data located in multiple locations
- Federation: Composition of multiple sources
- Provenance: How was data generated?

## “OGSA Data Services”(Foster, Tuecke, Unger, eds.)

- Describes conceptual model for representing all manner of data sources as Web services
- Database, filesystems, devices, programs, ...
- Integrates WS-Agreement
- Data service is an OGSI-compliant Web service that implements one or more of base data interfaces:
- DataDescription, DataAccess, DataFactory, DataManagement
- These would be extended and combined for specific domains (including DAIS)

## Data Access & Integration Services

-                         Slide Courtesy Malcolm Atkinson, UK eScience Center

## Overview

- Grid background
- Open Grid Services Architecture
- Open Grid Services Infrastructure
- Beyond OGSI: other OGSA services
**Globus Toolkit v3 implementation**
- Early GT3 performance results
- Scientific and commercial perspectives
- Summary

## The Globus Alliance

- A group of people with a common mission:
*“**Make Grid computing an everyday reality.”*
- Argonne/U.Chicago, USC-ISI, EPCC, & KTH-PDC
- Led by Ian Foster (Argonne), Carl Kesselman (ISI), Malcolm Atkinson (EPCC), Lennart Johnsson (PDC)
- Includes researchers, software developers, software architects & designers, systems engineers, & others
- Collaborations (or at least acquaintances) with most Grid activities in the world
- All activities contribute to our common mission
- Research
- Software development (prototypes, reference implns)
- Application consulting
- Infrastructure consulting

## Globus Toolkit:A Story of Evolution

- Definition of Grid problem has been stable since original Globus Project proposal in 1995
- Though we’ve gotten better at articulating it
- But our approach to its solution has evolved:
- From APIs and custom protocols...
- to standard protocols...
- to Grid services (OGSA)
- Driven by experience implementing and deploying the Globus Toolkit, and building real applications with it

## Globus Toolkit® v3.0

- All of the GT v2.4 services and clients
- Complete Java implementation of OGSI v1.0
- Rich, container-based implementation
- Built on Apache Axis
- Globus “proprietary” services built on OGSI
- Managed Jobs (akin to GT2 GRAM)
- Reliable File Transfer (RFT)
- Index Services (akin to GT2 GIIS)
- Some services not yet OGSI-fied:
- GridFTP, Replica Location Services (RLS)

## GT3 Distribution

- GT2
- Components

- RLS

- GT-OGSA
- Grid Service
- Infrastructure

- The focus of this presentation

## GT-OGSA Grid Service Infrastructure

- Security Infrastructure

- System-Level Services

- Base Services

- User-Defined Services

- Grid Service Container

- Hosting Environment

- Web Service Engine

- OGSI Spec Implementation

## GT-OGSA Grid Service Infrastructure

- Security Infrastructure

- System-Level Services

- Base Services

- User-Defined Services

- Grid Service Container

- Hosting Environment

- Web Service Engine

- OGSI Spec Implementation

## OGSI Implementation

- GT3 includes a set of primitives that fully implement the interfaces and behaviors defined in the OGSI Specification
- Defines how entities can create, discover and interact with a Grid service
- The OGSI Specification defines a protocol:  GT3 provides a programming model for that protocol

## Implementation of the GridService portType: GridServiceImpl and PersistentGridServiceImpl

- Implementation of the GridService portType: GridServiceImpl and PersistentGridServiceImpl

- destroy()
- setServiceData()
- findServiceData()
- requestTerminationAfter()
- requestTerminationBefore()
- addOperationProvider()
- (See docs for complete set of methods)

- <parameter name=“operationProviders” value=“<className>”>

- Additional
- functionality can be
- added to a
- Grid Service using
- OperationProviders

- Deployment descriptor

## Building an OGSI-Compliant Grid Service using GT3

**Write service-specific**
**logic that also**
**implements the GT3 **
**OperationProvider **
**interface**

## Building an OGSI-Compliant Grid Service using GT3

**Write service-specific**
**logic that also**
**implements the GT3 **
**OperationProvider **
**interface**

**Combine with one of the**
**two GT3 implementations**
**of base GridService**
**functionality:**
**GridServiceImpl or**
**PersistentGridServiceImpl**

- Building an OGSI-Compliant Grid Service using GT3

## Building an OGSI-Compliant Grid Service using GT3

**Write service-specific**
**logic that also**
**implements the GT3 **
**OperationProvider **
**interface**

**Combine with one of the**
**two GT3 implementations**
**of base GridService**
**functionality:**
**GridServiceImpl or**
**PersistentGridServiceImpl**

**An **
**OGSI-Compliant**
**grid service**

- Building an OGSI-Compliant Grid Service using GT3

## Building an OGSI-Compliant Grid Service using GT3

**An **
**OGSI-Compliant**
**grid service**

**OperationProviders are **
**configured at deployment time **
**or added at runtime**

**Write service-specific**
**logic that also**
**implements the GT3 **
**OperationProvider **
**interface**

**Combine with one of the**
**two GT3 implementations**
**of base GridService**
**functionality:**
**GridServiceImpl or**
**PersistentGridServiceImpl**

- Building an OGSI-Compliant Grid Service using GT3

## A Grid Service Can be Composed of Multiple OperationProviders

- OPs can be designed as atomic bits of functionality to facilitate reuse
- OP approach eases the task of bringing legacy code into OGSI-compliance
- OPs allow Grid Services to be formed dynamically (in contrast to the inheritance approach)

## Several OperationProviders are Included in the GT3 Distribution

**NotificationSourceProvider**

**HandleResolverProvider**

**ServiceGroupRegistrationProvider**

**ServiceGroupProvider**

**FactoryProvider**

## OGSI Specification: Notifications

- Our NotificationSourceProvider implementation allows any Grid Service to become a sender of notification messages
- A subscribe request on a NotificationSource triggers the creation of a NotificationSubscription service
- A NotificationSink can receive notification msgs from NotificationSources
- Sinks are not required to implement the GridService portType
- Notifications can be set on SDEs

## OGSI Specification: Factory

- Factory portType
- Factories create services
- Factories are typically persistent services
- Factory is an optional OGSI interface
- (Grid Services can also be instantiated by other mechanisms)

## OGSI Specification: Service Groups

- Service group portTypes
- A ServiceGroup is a grid service that maintains information about a group of other grid services
- The classic registry model can be implemented with the ServiceGroup portTypes
- A grid service can belong to more than one ServiceGroup
- Members of a ServiceGroup can be heterogeneous or homogenous
- Each entry in a service group can be represented as its own service
- Service group portTypes are optional OGSI interfaces

## OGSI Specification: Handle Resolver

- HandleResolver portType
- Defines a means for resolving a GSH (Grid Service Handle) to a GSR (Grid Service Reference)
- A GSH points to a Grid Service
- (GT3 uses a hostname-based GSH scheme)
- A GSR specifies how to communicate with the Grid Service
- (GT3 currently supports SOAP over HTTP, so GSRs are in WSDL format)

## A Service Creation Scenario*

- Registry

- * All scenarios are offered as examples and are not prescriptive

**1. From a**
**known registry,**
**the client**
**discovers a**
**factory by**
**querying the**
**service data **
**of the**
**registry**

- Client

## A Service Creation Scenario

- Client

- Registry

**2. The client calls**
**the createService**
**operation on the**
**factory**

- Factory

**1. From a**
**known registry,**
**the client**
**discovers a**
**factory by**
**querying the**
**service data **
**of the**
**registry**

## A Service Creation Scenario

- Client

- Registry

- Factory

- Service

**3. The factory**
**creates a**
**service**

**1. From a**
**known registry,**
**the client**
**discovers a**
**factory by**
**querying the**
**service data **
**of the**
**registry**

**2. The client calls**
**the createService**
**operation on the**
**factory**

## A Service Creation Scenario

- Client

- Registry

- Factory

- Service

**4. The factory**
**returns a locator to**
**the newly created**
**service**

**1. From a**
**known registry,**
**the client**
**discovers a**
**factory by**
**querying the**
**service data **
**of the**
**registry**

**2. The client calls**
**the createService**
**operation on the**
**factory**

**3. The factory**
**creates a**
**service**

## A Service Creation Scenario

- Client

- Registry

- Factory

- Service

**5. The client and **
**service interact**

**1. From a**
**known registry,**
**the client**
**discovers a**
**factory by**
**querying the**
**service data **
**of the**
**registry**

**2. The client calls**
**the createService**
**operation on the**
**factory**

**3. The factory**
**creates a**
**service**

**4. The factory**
**returns a locator to**
**the newly created**
**service**

## A Notification Scenario

**1. NotificationSink calls**
**the subscribe operation**
**on NotificationSource**

- NotificationSource

## A Notification Scenario

**2.NotificationSource creates a subscription**
** ****service**

**1. NotificationSink calls**
**the subscribe operation**
**on NotificationSource**

- NotificationSink

- NotificationSource

- NotificationSubscription

## A Notification Scenario

-                         **3. Notification**
**               ****Source returns a**
**        ****locator to the **
** ****subscription service**

**1. NotificationSink calls**
**the subscribe operation**
**on NotificationSource**

**2.NotificationSource creates a subscription**
** ****service**

- NotificationSink

- NotificationSource

- NotificationSubscription

## A Notification Scenario

- NotificationSubscription

**4.b The NotificationSink and **
**Subscription service interact**
**to perform lifetime**
**management**

**4.a deliverNotification**
**stream continues**
**for the lifetime of**
**NotificationSubscription**

**1. NotificationSink calls**
**the subscribe operation**
**on NotificationSource**

**2.NotificationSource creates a subscription**
** ****service**

-                         **3. Notification**
**               ****Source returns a**
**        ****locator to the **
** ****subscription service**

- NotificationSink

- NotificationSource

## A Notification Scenario

- NotificationSource

- NotificationSubscription

**1. NotificationSink calls**
**the subscribe operation**
**on NotificationSource**

**subscribe**

**2.NotificationSource creates a subscription**
** ****service**

-                         **3. Notification**
**               ****Source returns a**
**        ****locator to the **
** ****subscription service**

**4.b The NotificationSink and **
**Subscription service interact**
**to perform lifetime**
**management**

**4.a deliverNotification**
**stream continues**
**for the lifetime of**
**NotificationSubscription**

**The sole mandated**
**cardinality: 1 to 1**

## GT-OGSA Grid Service Infrastructure

**Security Infrastructure**

- System-Level Services

- Base Services

- User-Defined Services

- Grid Service Container

- Hosting Environment

- Web Service Engine

- OGSI Spec Implementation

## Transport Layer Security/Secure Socket Layer (TLS/SSL)
To be deprecated
SOAP Layer Security
Based on WS-Security, XML Encryption, XML Signature
GT3 uses X.509 identity certificates for authentication
It also uses X.509 Proxy certificates to support delegation and single sign-on, updated to conform to latest IETF/GGF draft

- To be deprecated
- SOAP Layer Security
- Based on WS-Security, XML Encryption, XML Signature
- GT3 uses X.509 identity certificates for authentication
- It also uses X.509 Proxy certificates to support delegation and single sign-on, updated to conform to latest IETF/GGF draft

- Security Infrastructure

## GT-OGSA Grid Service Infrastructure

- Security Infrastructure

**System-Level Services**

- Base Services

- User-Defined Services

- Grid Service Container

- Hosting Environment

- Web Service Engine

- OGSI Spec Implementation

## System-Level Services

- General-purpose services that facilitate the use of Grid services in production environments
- The 3.0 distribution includes three system-level services
- An administration service
- A logging service
- A management service

## GT-OGSA Grid Service Infrastructure

- Security Infrastructure

- System-Level Services

- Base Services

- User-Defined Services

**Grid Service Container**

- Hosting Environment

- Web Service Engine

- OGSI Spec Implementation

## Grid Service Container

-    Includes the OGSI Implementation, security infrastructure and system-level services, plus:
- Service activation, deactivation, construction, destruction, etc.
- Service data element placeholders that allow you to fetch service data values dynamically, at query time
- Evaluator framework (supporting ByXPath and ByName notifications and queries)
- Interceptor/callback framework (allows one to intercept certain service lifecycle events)

## Grid Service Container (cont.)

- Interface Layer

- Transport Layer

- Implementation Layer

- Layers in the Web Services Model

- OGSI Spec is here

- Transport/binding
- layer (e.g., GT3: SOAP over HTTP)

- Container is here

## GT-OGSA Grid Service Infrastructure

- Security Infrastructure

- System-Level Services

- Base Services

- User-Defined Services

- Grid Service Container

**Hosting Environment**

- Web Service Engine

- OGSI Spec Implementation

## Hosting Environment

-    GT3 currently offers support for four Java hosting environments:
- Embedded
- Standalone
- Servlet
- EJB

## Virtual Hosting Environment Framework

- Virtual hosting allows Grid services to be  distributed across several remote containers
- Useful in implementing solutions for problems common to distributed computing
- Load balancing
- User account sandboxing

## GT-OGSA Grid Service Infrastructure

- Security Infrastructure

- System-Level Services

**Base Services**

- User-Defined Services

- Grid Service Container

- Hosting Environment

- Web Service Engine

- OGSI Spec Implementation

## Resource Management

- GRAM Architecture rendered in OGSA
- The MMJFS runs as an unprivileged user, with a small highly-constrained setuid executable behind it
- Individual user environments are created using virtual hosting

- MJS

- MJS

- MJS

- MJS

- User 1

- User 2

- User 3

- Master User

- MJS

- MJS

- MMJFS: Master Managed Job FactoryService

- MJS: Managed JobService

- User Hosting
- Environment

## GRAM Job Submission Scenario

- Index
- Service

**1. From an **
**index service,**
**the client**
**chooses **
**an MMJFS**

## GRAM Job Submission Scenario

- Client

- Index
- Service

**2. The client calls the**
**createService**
**operation on the factory**
**and supplies RSL**

-  MMJFS

**1. From an **
**index service,**
**the client**
**chooses **
**an MMJFS**

## GRAM Job Submission Scenario

- Client

- Index
- Service

-  MMJFS

-  MJS

**3. The factory**
**creates a**
**Managed Job**
**Service**

**1. From an **
**index service,**
**the client**
**chooses **
**an MMJFS**

**2. The client calls the**
**createService**
**operation on the factory**
**and supplies RSL**

## GRAM Job Submission Scenario

- Client

- Index
- Service

-  MMJFS

-  MJS

-  **4. The factory**
**returns a locator**

**1. From an **
**index service,**
**the client**
**chooses **
**an MMJFS**

**2. The client calls the**
**createService**
**operation on the factory**
**and supplies RSL**

**3. The factory**
**creates a**
**Managed Job**
**Service**

## GRAM Job Submission Scenario

- Client

- Index
- Service

-  MMJFS

-  MJS

**5. The client subscribes to****the MJS’ status SDE and **
**retrieves output**

**1. From an **
**index service,**
**the client**
**chooses **
**an MMJFS**

**2. The client calls the**
**createService**
**operation on the factory**
**and supplies RSL**

**3. The factory**
**creates a**
**Managed Job**
**Service**

-  **4. The factory**
**returns a locator**

## Information Services

- Index service as caching aggregator
- Caches service data from other Grid services
- Index service as provider framework
- Serves as a host for service data providers that live outside of a Grid service to publish data

## Reliable File Transfer

- OGSI-compliant service exposing GridFTP control channel functionality
- 3rd-party transfer between GridFTP servers
- Recoverable Grid service
- Automatically restarts interrupted transfers from the last checkpoint
- Progress and restart monitoring

- GridFTP
- Server 1

- GridFTP
- Server 2

**RFT**

- JDBC

## Reliable File Transfer Service

- File
- Transfer

*Internal*
*State*

*Data transfer operations*

## GT-OGSA Grid Service Infrastructure

- Security Infrastructure

- System-Level Services

- Base Services

- User-Defined Services

- Grid Service Container

- Hosting Environment

- Web Service Engine

- OGSI Spec Implementation

## GT3 User-Defined Services

- GT3 can be viewed as a Grid service development kit that includes:
- Primitives, APIs, tools and runtime services designed to ease the task of building OGSI-compliant services
- Primitives for provisioning security
- Base services that provide an infrastructure with which to build higher-level services

## GT3 User-Defined Services (cont.)

- ANT

- User source files

- GT3 build files

- User build file

- Grid service
- executable files

- (Diagram inspired by Borja Sotomayor’sexcellent GT3 tutorial)

## Overview

- Grid background
- Open Grid Services Architecture
- Open Grid Services Infrastructure
- Beyond OGSI: other OGSA services
- Globus Toolkit v3 implementation
**Early GT3 performance results**
- Scientific and commercial perspectives
- Summary

## Early GT3 Performance Analysis

- Goal: explore GT3 under heavy load
- Maximal throughput/rate of GT3 services
- Identify limiting factors
- Three GT3 Grid services measured
- GRAM
- DummyService
- IndexService
- Note: Preliminary results, performance continues to improve rapidly
**Work performed by ****Massimo Lamanna, David Foster, et al., at CERN**

## GT3 GRAM Performance: Setup

- GRAM in GT3 standalone container
- Managed-job-globusrun clients started simultaneously on up to 32 client nodes (lxplus) in non-batch mode used to submit jobs to GT3 GRAM
- GRAM hardware: 2 * Intel Pentium III 600MHz processors, 256MB RAM
- Note: 1 managed-job-globusrun client is able to submit 1 job

## GT3 GRAM performance

- Results: service node
- Saturation throughput for job submission on the service node: 3.8 jobs/minute with an average CPU user+system usage of 62%
- Comments:
- Scalability issue for heavily used servers

## GT3 GRAM performance

- Results: client node
- Using a 2 * Intel Pentium III 600MHz processors, 256MB RAM client node, a managed-job-globusrun client consumes at average 16 seconds CPU user+system time (on both CPU’s) for 1 job
-  Comment:
- Lightweight clients (e.g., written in "C") needed

## DummyService performance

- Setup (1)
- Each DummyService client executes these steps:
- Calls DummyServiceFactory to create a DummyService instance
- Executes 2 simple methods (echo and getTime) on the DummyService instance
- Calls DummyService instance to destroy itself
- Up to 1000 clients talking to the DummyService from up to 45 client nodes (lxplus)
- With & without GSI message level authentication
- Grid service node hardware: 2 * Intel Pentium III 600MHz processors, 256MB RAM
- Setup (2)
- Same, but repeats step #2 one hundred times

## DummyService performance

- Preliminary Results
- Security overhead needs further investigation
- Cross check our implementation/setup with Globus team foreseen

|  setup | authen-tication |  service 
container  | saturation
 throughput |  average CPU u+s usage,  % |
| --- | --- | --- | --- | --- |
| 1 | - | GT3 standalone |  41  services/s | 89  |
| 1 |  yes | GT3 standalone  | 1.3  services/s | 88  |
| 1 | - | Tomcat  | 60  services/s | 89 |
| 1 |  yes | Tomcat  | 1.2  services/s  | 88  |
| 2 | - | GT3 standalone |  300  method calls/s | 96  |
| 2 |  yes | GT3 standalone  | 10  method calls/s | 72 |
| 2 | - | Tomcat  | 290  method calls/s | 96 |
| 2 | Yes | Tomcat  | 13  method calls/s | 79 |

## DummyService Performance

-  Conclusions
- Security overhead needs further investigation
- More tests on more powerful machines
- Container: depending on the setup the Tomcat container may be a bit slower or up to 50% faster, compared to the standalone container
- Notes:
- Results table shows top saturation rates
- With varying number of clients throughput goes down by up to 30% and the average CPU u+s usage varies accordingly

## Slide 106

## The first time the client contacts the DummyServiceFactory, creates a DummyService instance, and calls the first method, it takes about 10s to accomplish it
These actions take about 1s on subsequent occasions

- The first time the client contacts the DummyServiceFactory, creates a DummyService instance, and calls the first method, it takes about 10s to accomplish it
- These actions take about 1s on subsequent occasions

## IndexService performance

- Setup (1): IndexService acting as a notification source (pushing data)
- Multiple notification sinks subscribe to the IndexService "Host" Service Data Element (SDE), and are notified about each update of "Host" SDE, happening at a fixed rate
- No security
- Grid service node hardware: 2 * Intel Pentium III 600MHz processors, 256MB RAM
- Setup (2): IndexService responding to findServiceData requests (pulling data)
- Multiple ogsi-find-service-data clients are run sequentially and in parallel asking for IndexService "Host" Service Data Element
- No security
- Grid service node hardware: 2 * Intel Pentium III 600MHz processors, 256MB RAM

## IndexService Performance

|  setup |  service 
container  | saturation
 throughput |  average CPU u+s
usage, % |
| --- | --- | --- | --- |
| 1 | GT3 standalone |  10-15 notifications/s | 81 – 87 |
| 1 | Tomcat  | - |  |
| 2 | GT3 standalone | 200 requests/s | 88 |
| 2 | Tomcat  | 200 requests/s | 90 |

## IndexService Performance

- Saturation throughput with findServiceData is ~13-20 times higher than with notifications
- Setup (1) measurement using Tomcat failed due to a thread bug, is fixed, fix announced to appear in next (4.1.28) Tomcat version
- Preliminary measurement with a faster service node (2 * Intel(R) Xeon(TM) 2.40GHz processors, 1GB RAM):
- Saturation throughput for setup (1) was about 32 notifications/s for 800 listeners compared to 10 notifications/s with 400 listeners on the 2 * 600MHz machines – not quite 4 times faster

## Slide 111

## Slide 112

## Overview

- Grid background
- Open Grid Services Architecture
- Open Grid Services Infrastructure
- Beyond OGSI: other OGSA services
- Globus Toolkit v3 implementation
- Early GT3 performance results
**Scientific and commercial perspectives**
- Summary

## Scientific Perspectives

- Importance of Grid technologies growing with “eScience” & “cyberinfrastructure”
- OGSA offers big opportunities
- Leverage commercial technologies
- Achieve collaborative software ecosystem
- But also concerns
- Potentially competing demands of industry
- Sometimes slow pace of standards definition
- Critical mass of R, D, and support

## NEESgrid Earthquake Engineering Collaboratory

- U.Nevada Reno

- www.neesgrid.org

## NEESgrid Core Capabilities

- Tele-control and tele-observation of experiments
- Data cataloging and sharing
- Remote collaboration and visualization tools and services
- Simulation execution and integration

## NEESgrid High-level Structure

## Architecture of NEESgrid Equipment Site 

## Tele-Control Services

- Transaction-based protocol and service (NTCP) to control physical experiments and computational simulations.
- OGAI based implementation (GT3.0)
- Plug-ins to interface the NTCP service
- A computational simulation written in Matlab
- Shore Western control hardware
- MTS control hardware (via Matlab and xPC)
- Security architecture, including GSI authentication and a flexible, plug-in-based authorization model.

## Multi-site Online Simulation Test (MOST)

- A large-scale experiment conducted in multiple geographical locations.
- Combine physical experiments with numerical simulation
- Psuedo-dynamic testing
- Ideal for network latency reasons

## Substructure Pseudo-dynamic Testing

*Structural Test*

*Geotechnical Test*
*at Another Lab*

*Structural FE*
*Simulation**** 1***

*Geotechnical FE*
*Simulation 2*

***Total System***

**Physical Tests**

**Numerical Simulation**

## Test Structure for MOST Experiment

- Note: for ease of programming, all computational models were written in Matlab.

## MOST: A Grid Perspective

**U. Colorado**
***Experimental Model***

**UIUC***** ***
***Experimental Model***

**NCSA**** **
***Computational Model***

- SIMULATION
- COORDINATOR

## Tele-Control Services

## Industry Trends

- Economies of scale and outsourcing
- Computing center outsourcing
- Application Service Providers (ASPs)
- Storage Service Providers (SSPs)
- Services orientation
- Web Services (and CORBA) influences
- Tantalizing dreams of B2B
- Still a sense that B2B market is huge
- If only enough inter-organization problems can be overcome ...

## The Value of Grid Computing:IBM Perspective

- Reduced Complexity
- & Cost

- Higher Quality of Service

- Increased Productivity
- & ROI

- Increased
- Efficiency

- The Value of Grid Computing:IBM Perspective

- Improved Resiliency

## IBM Grid Product Offerings

- IBM Grid Toolbox:
- Includes GT 2.2
- IBM value-added extras
- Commercial support!
- Websphere Application Server (supports OGSI-compliant Grid services)
- Grid education services
- IT consulting/infrastructure planning
- Compute/storage hardware provision
- Integrated solutions for market sectors

## Butterfly.net: Enterprise Optimization

- Butterfly.net: Enterprise Optimization

- A scalable, resilient infrastructure for creating & running massive multiplayer games
- Developers avoid upfront costs
- Improved end-user experience
- Demonstrated 8x increase in profitability over centralized model
- Dynamic provisioning & on demand capacity
- Uses Globus Toolkit & runs on IBM Global Services hosting environment

## “The HP Stack”

- HP’s value add is the UDC, management and security, and consulting services to enhance and build upon industry standards

- HP Consulting Services

- Management and Security

- Applications

- Globus/OGSA

- Web Services

- Grid-Enabled Resources & Resource Utilities (UDC)

**Notes:**
The boxes shown in gray above come from HP’s 3rd party partners (eg BEA for web services)  and from open source (eg the Globus Toolkit for OGSA support).   
The boxes shown in blue are HP value add, including:
OpenView for Management of Web Services and Grids
Grid-enabled systems and storage
The Utility Data Center, to provide a grid-enabled resource utility
Consulting servces from HP Services   

HP's view of a GRID solution is that it consists of more than just a set of APIs. Interacting networked applications will be built upon web services. Some of these web services, such as OGSA,  will be standardized to support interactions with physical resources. The physical resources may exist in a resource utility where virtualization techniques will simplify the way applications and human operators interact with these shared resources. Management, especially automated control, are essential in delivering large-scale applications and resource utilities in a flexible, cost effective manner. Security must exist at all level of the solution. HP's consulting services are available to assist customers in the evaluation, design, deployment, evolution and operations of GRID based solutions.

## On the Road to Planetary Computing

- On the Road to Planetary Computing

- shared, traded resources

- value

- clusters

- grid-enabled systems

- programmable data center

- virtual data center

- Open VMS clusters, TruCluster, MC ServiceGuard

- Tru64, HP-UX, Linux

- UDC

- computing utility or GRID

- today

**Notes:**
HP Labs, in close cooperation with the business units, is researching advanced technologies to simplify these complex GRID solutions. This research program is called Planetary Scale Computing. Its goal is to create a flexible, global secure IT infrastructure. This program builds upon the successes of clusters and GRID enabled platforms to create programmable data centers that support the dynamic allocation of servers and storage from a shared pool. These programmable data centers can be aggregated to create a virtual data center that supports the automatic and secure provisioning and assurance of services across geographical and corporate boundaries.

## HP Grid Product Offerings

- Globus Toolkit for HP-UX, Tru64 Unix, Linux
- Globus Toolkit 2.4
- Tested and optimized for HP platforms
- Commercial support!
- HP Utility Data Center (UDC)
- Data Center operation & construction services
- Service-centric design
- Intent is to construct UDC products using OGSI-compliant services
- Enterprise Grid consulting

## Oracle’s Use of Grid Technology

- Use Grid technology to build better products
- Oracle Database 10g
- Enhanced scalability, relocation, & distributed SQL
- Max database size -> 8 exabytes
- Oracle Application Server 10g
- Already based on J2EE/Web Services
- Extending to include OGSI yields powerful capabilities
- Improves scalability and flexibility
- Increases in both scalability and efficiency
- Improves competitiveness of existing products

## Oracle Grid Product Offerings

- Oracle Database 10g
- Transportable tables
- Distributed SQL
- Managed using OGSI-compliant interfaces(?)
- Oracle Application Server 10g
- Hosting for OGSI-compliantGrid services
- Development environment
- Application Server can be managed and configured using OGSI-compliant interfaces(?)

## Platform Symphony:Real-Time Online Processing

**Servers:**
**Execution**

**Application**
**Services:**
**Distribution**

**Applications:**
**Delivery**

## Overview

- Grid background
- Open Grid Services Architecture
- Open Grid Services Infrastructure
- Beyond OGSI: other OGSA services
- Globus Toolkit v3 implementation
- Early GT3 performance results
- Scientific and commercial perspectives
**Summary**

## Summary: Standards

- Standards are critical to Grid success
- Grid and Web services are merging
- Grid is an aggressive use case of Web Services
- Web services standards landscape is in great flux, and OGSI will need to evolve with it
- Grid services standards landscape heating up
- W3C, OASIS, GGF are key standards orgs
- Uncertain status of security & policy standards continues to be a big source of concern
- Open source software important for adoption

## Summary

- Grid: resource sharing, integration, virtualization in network systems
- OGSA is defining a standards-based Grid infrastructure
- Based on Web services
- Core specification, OGSI, is complete
- Numerous other specifications underway
- GT3 provides tools for building OGSI-based Grid services
- Available today

## For More Information

- The Globus Alliance®
- www.globus.org
- Global Grid Forum
- www.ggf.org
- Background information
- www.mcs.anl.gov/~foster
**GlobusWORLD 2004**
**www.globusworld.org**
**Jan 20–23, San Francisco**

- 2nd Edition: November 2003