Transition and Evolution Moving to Grid Services

Transition and Evolution

Moving to Grid Services

GT3 is *not* Grid Services

There is nothing special about GT3 GT2 was GT1.1.3 with feature

enhancements to the existing components and a lot of new functionality (GridFTP and RC)

GT3 is all of GT2.4 with feature enhancements to the existing components and a lot of new functionality (OGSI compliant components)

Terminiology

Everyone (including us) has a bad habit of saying GT3 to mean Grid Services.

To be clear we should refer to OGSI or non-OGSI compliant services.

One confusing point: For the first time, there are two ways to do

some things in the toolkit. I.e., non-OGSI job submission .vs. OGSI

compliant job submission

Transition

We use the Linux versioning convention Even number releases, I.e. 3.0, are stable

releases (bug fixes only) Odd number releases, I.e., 3.1 are

experimental (feature additions, possible interface changes)

Our support policy has not changed since GT 2.0. We support the current and one previous

stable release

The Question

How long will we support GT2.x? That is the wrong question

We invested substantial work in packaging so that we could upgrade components separately.

We can also End-Of-Life (EOL) them independently as well.

This is what we will do

The Right Question…And the Answer

When will we EOL specific Components Depends on the component, but what we do

know is this: All components will be present in 3.2 The earliest we could EOL something is 3.4

(though we have no plans for this yet) Therefore, support for all existing components

AT LEAST until the release of 3.6, probably longer

This means late 2004, probably well into 2005

Evolution

How a specific project makes this transition is a huge question depending on a lot of details.

Largely depends on how much you have already invested in Grid development

Obviously, EDG has a significant investment, which makes it harder

However, there are some techniques that should help.

OGSI and non-OGSI in Toolkit

For now, the entire non-OGSI suite is present.

You can install non-OGSI just like you do today and run production, while working on transition issues.

We have provided transition clients where we think it is needed or feasible

Let us know if you think there is something missing.

Where do you put the OGSI Interface?

Build an OGSI service to interface to non-OGSI services RFT to GridFTP

Maintain your client interface and re-implement to send SOAP messages globus-job-run globus-url-copy?

What if I want to use both OGSI and non-OGSI services? Must use discovery of some kind to choose

appropriate client interface

GT3 Key Points

And a glimpse of things to come

Web Services

At the heart of Web services is: WSDL: Language for defining abstract

service interfaces SOAP (and friends): Binding from WSDL to

bytes on the wire Web services appears to offer a fighting

chance at ubiquity (unlike CORBA) But Web services does not go far enough

to serve a common base for the Grid…

Transient Service Instances “Web services” address discovery & invocation of

persistent services Interface to persistent state of entire enterprise

In Grids, must also support transient service instances, created/destroyed dynamically Interfaces to the states of distributed activities E.g. workflow, video conf., dist. data analysis, subscription

Significant implications for how services are managed, named, discovered, and used In fact, much of Grid is concerned with the management of

service instances

The Specification Defines how Entities can Create, Discover and Interact with a Grid Service

Servicedata

element

Servicedata

element

Servicedata

element

Service Implementation

GridService(required) … other interfaces …

(optional) Optional:- Service creation- Notification- Registration- Service Groups

+ application-specific interfaces

Required:- Introspection (service data)- Explicit destruction- Soft-state lifetime

GT3 Core: OGSI Specification

Includes 0 or more Grid Service Handles (GSHs)Includes 0 or more Grid Service References (GSRs)

Service locator

RFT in Action

Registry

* The scenarios in this presentation are offered as examples and are not prescriptive

1. A Grid Service Container is started up; It contains an RFT Factory service; The RFT Factory service registers itself

RFT Factory

Grid Service Container

Client

RFT in Action

Registry


2. From a knownregistry, the client discovers a

factoryby querying theService data of theregistry

RFT Factory


Client

RFT in Action

3. The client calls thecreateServiceoperation on the factory and passes in a TransferRequest

RFT Factory



Client

RFT in Action

RFT Factory


RFT Service Instance- Start the Instance- Deserialize XML to Java- Write Request via JDBC- Persist Service State

4. The instance is started, and the factory returns a locater


Client

RFT in Action

RFT Factory


RFT Service Instance- Start the Instance- Deserialize XML to Java- Write Request via JDBC- Persist Service State

5. Client calls Start(), subscribes to notificaitons, etc.


RFT in Action Service is OGSI

compliant Uses existing

GridFTP (non-OGSI) protocols and tools to execute 3rd Party Transfer for the user

Provides extensive state transition notification

GridFTPServer

GridFTPServer

RFT ServiceInstance


NotificationSink

A Notification Scenario

1. NotificationSink calls thesubscribe operation onNotificationSource

NotificationSource

NotificationSink



NotificationSource

NotificationSubscription

2.NotificationSource createsa subscriptionservice

NotificationSink



NotificationSource



3. Notification Source returns a locator to the subscription service

NotificationSink



NotificationSource




4.b The NotificationSink and Subscription service interactto perform lifetime management

4.a deliverNotificationstream continuesfor the lifetime ofNotificationSubscription

NotificationSink



NotificationSource




4.b The NotificationSink and Subscription service interactto perform lifetime management

4.a deliverNotificationstream continuesfor the lifetime ofNotificationSubscription

The sole mandatedcardinality: 1 to 1

subscribe

Data Service Overview

Resource manager:implements the data virtualization

& manages access to data sources

Grid

Se

rvice

Da

taD

escrip

tion

Da

taA

ccess

Da

taF

acto

ry

Da

taM

an

ag

em

en

t

GSH

Underlyingdata sources

Data serviceimplementation

… …

Perhaps otherinterfaces

Data serviceinterfaces

Grid servicehandle

Multiple Virtualizations Example

FrameFrame

File system

Collectionof files

Relationaldatabase

Collectionof files

Data sources

File system

Movie Frame DatabaseDB

view

Filter

Derivedquantities

Data virtualizations

(OGSI-) 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 All interesting Web/Grid services interactions will be

governed by agreements!

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

Agreement Overview

Agreement Initiator

Agreement Provider

Data Service

Consumer

Data ServiceProvider

AgreementProvider

(extends OGSI factory)

Agreement I/F

(extends GridService I/F)

DataFactory

(extends AgreementProvider)

Agreement

DataAccess

(extends Agreement I/F)

[1]

[4]

[2]

[3]

Steps (Operations):[1] Create Agreement[2] Create Data Service[3] Access Data Service[4] Monitor Agreement

Policy

Documents

Transition and Evolution Moving to Grid Services