SYSTEM PROPERTIES REQUIREMENTS

Fault tolerance. Support is required for failover, load

redistribution, and other techniques usedto achieve fault tolerance.
Fault tolerance is particularly important for long running queries that
can potentially return large amounts of data
Disaster recovery. Disaster recovery is a critical capability for
complex distributed grid infrastructures. For distributed systems,
failure must be considered one of the natural behaviors and disaster
recovery mechanisms must be considered an essential component of
the design.

Self-healing capabilities of resources, services and systems

are required. Significant manual effort should not be required to
monitor, diagnose, and repair faults.
Legacy application management. Legacy applications are
those that cannot be changed, but they are too aluable to give up or
to complex to rewrite
 SYSTEM PROPERTIES REQUIREMENTS

Administration. Be able to ―codify‖ and ―automate‖ the

normal practices used to administer theenvironment. The goal is
that systems should be able to selforganize and self-describe to
managelow-level configuration details based on higher-level
configurations and management policiesspecified by
administrators.

Agreement-based interaction. Some initiatives require

agreement-based interactions capable ofspecifying and enacting
agreements between clients and servers (not necessarily
human) and then composing those agreements into higher-level
end-user structures
Grouping/aggregation of services. The ability to instantiate
(compose) services using some setof existing services is a key
requirement.
RESOURCE MANAGEMENT REQUIREMENTS
Resource management is another multilevel requirement,
encompassing SLA negotiation, provisioning, and
scheduling for a variety of resource types and activities
Provisioning. Computer processors, applications,
licenses, storage, networks, and instruments are all grid
resources that require provisioning.
Resource virtualization. Dynamic provisioning
implies a need for resource virtualization mechanisms
that allow resources to be transitioned flexibly to different
tasks as required for example, when bringing more Web
servers on line as demand exceeds a threshold..
Optimization of resource usage while meeting
cost targets (i.e., dealing with finite resources).Mechanisms
to manage conflicting demands from various organizations,
groups, projects, and users and implement a fair sharing of
resources and access to the grid
RESOURCE MANAGEMENT REQUIREMENTS

Transport management. For applications that

require some form of real-time scheduling, it canbe
important to be able to schedule or provision bandwidth
dynamically for data transfers or in support of the other
data sharing applications.

Management and monitoring. Support for the

management and monitoring of resource usage and the
detection of SLA or contract violations by all relevant
parties. Also, conflict management is necessary

Processor scavenging is an important tool that

allows an enterprise or VO to use to aggregate
computing power that would otherwise go to waste
RESOURCE MANAGEMENT REQUIREMENTS

Scheduling of service tasks. Long recognized

as an important capability for any information
processing system, scheduling becomes extremely
important and difficult for distributed grid systems.
Load balancing. In many applications, it is necessary to
make sure make sure deadlines are met or resources are
used uniformly

Advanced reservation. This functionality may be

required in order to execute the application on reserved
resources.

Notification and messaging. Notification and

messaging are critical in most dynamic scientific problems.
RESOURCE MANAGEMENT REQUIREMENTS

Logging. It may be desirable to log processes

such as obtaining/deploying application
programs because, for example, the
information might be used for accounting.
Workflow management. Many applications can
be wrapped in scripts or processes that require licenses
and other resources from multiple sources. Applications
coordinate using the file system based on events.

Pricing. Mechanisms for determining how to render

appropriate bills to users of a grid.
PRACTICAL VIEW OF OGSA/OGSI
OGSA aims at addressing standardization
(for interoperability) by defining the basic
framework of a grid application structure.
Some of the mechanisms employed in the
standards formulation of grid computing
PRACTICAL VIEW OF OGSA/OGSI
The objectives of OGSA are
Support QoS-oriented Service Level
Agreements (SLAs). The topology of grids is
often complex; the interactions between/among
grid resources are almost invariably dynamic.
PRACTICAL VIEW OF OGSA/OGSI
MPICH-G2: Grid-enabled message passing (Message Passing
Interface)
_ CoG Kits, GridPort: Portal construction, based on N-tier
architectures
_ Condor-G: workflow management
_ Legion: object models for grid computing
_ Cactus: Grid-aware numerical solver framework Portals
_ N-tier architectures enabling thin clients, with middle tiers
using grid functions
_ Thin clients = web browsers
_ Middle tier = e.g., Java Server Pages, with Java CoG Kit,
GPDK, GridPort utilities
_ Bottom tier = various grid resources
PRACTICAL VIEW OF OGSA/OGSI
Unicore, Gateway, Discover, Mississippi
Computational Web Portal, NPACI Grid Port, Lattice
Portal, Nimrod-G, Cactus, NASA IPG Launchpad, Grid
Resource Broker High-Throughput Computing and
Condor
_ High-throughput computing
_ Processor cycles/day (week, month, year?) under
nonideal circumstances
_ ―How many times can I run simulation X in a month
using all available machines?‖
_ Condor converts collections of distributively owned
workstations and dedicated clusters
PRACTICAL VIEW OF OGSA/OGSI
Object-Based Approaches
_ Grid-enabled CORBA
_ NASA Lewis, Rutgers, ANL, others
_ CORBA wrappers for grid protocols
_ Some initial successes
_ Legion
_ University of Virginia
_ Object models for grid components (e.g.,
―vault‖ = storage, ―host‖ = computer
_ Small core: management services
DETAILED VIEW OF OGSA/OGSI
Provides a more detailed view of OGSI
based on the OGSI specification itself. For
amore comprehensive description of these
concepts, the reader should consult the
specificationOGSI defines a component
model that extends WSDL and XML
schema definition toincorporate the
concepts of Stateful Web services
DETAILED VIEW OF OGSA/OGSI
Setting the Context
GGF calls OGSI the ―base for OGSA.‖ Specifically,
there is a relationship between OGSI and
distributed object systems and also a relationship
between OGSI and the existing (and evolving)Web
services framework
Relationship to Distributed Object Systems
Given grid service implementation is an
addressable and potentially stateful instance that
implements one or more interfaces described by
WSDL portTypes
DETAILED VIEW OF OGSA/OGSI
Client-Side Programming Patterns
OGSI interfaces are likely to be invoked from
client applications. OGSI exploits an important
component of the Web services framework: the
use of WSDL to describe multiple protocol
bindings, encoding styles, messaging styles
(RPC versus document oriented), and so on, for
a given Web service.
DETAILED VIEW OF OGSA/OGSI
DETAILED VIEW OF OGSA/OGSI
Client Use of Grid Service Handles and
References
DETAILED VIEW OF OGSA/OGSI
Relationship to Hosting Environment
GRID SERVICE
The Grid Service
The purpose of the OGSI document is to specify the
(standardized) interfaces and behaviors that define a
grid service
WSDL Extensions and Conventions
OGSI is based on Web services; in particular, it uses
WSDL as the mechanism to describe the public
interfaces of grid services.
Service Data
The approach to stateful Web services introduced in
OGSI identified the need for a common mechanism to
expose a service instance’s state data to service
requestors for query, update, and change notification.
GRID SERVICE
Motivation and Comparison to JavaBean
Properties
OGSI specification introduces the service Data
concept to provide a flexible, properties- style
approach to accessing state data of a Web
service. The service Data concept is similar to
the notion of a public instance variable or field
in object-oriented programming languages such
as Java, Smalltalk, and C++.
GRID SERVICE
serviceDataValue

Each service instance is associated with a collection of

serviceData elements: those service Data elements
defined within the various port Types that form the
service’s interface, and also, potentially, additional
service
Dynamic service Data Elements
Although many service Data elements are most
naturally defined in a service’s interface definition,
situations can
arise in which it is useful to add or move service Data
elements dynamically to or from an instance
GRID SERVICE PROPERTIES
Service Description and Service Instance

One can distinguish in OGSI between the description of a grid

service and an instance of a grid service:
A grid service description describes how a client interacts with
service instances.
This description is independent of any particular instance.
Within a WSDL document, the grid service description is
embodied in the most derived port Type A grid service
description may be simultaneously used by any number of grid
service instances, each of which
_ Embodies some state with which the service description
describes how to interact
_ Has one or more grid service handles
_ Has one or more grid service references to it
GRID SERVICE PROPERTIES
Modeling Time in OGSI
The need arises at various points throughout this
specification to represent time that is meaningful to
multiple parties in the distributed Grid.
The GMT global time standard is assumed for grid
services, allowing operations to refer unambiguously to
absolute times. However, assuming the GMT time
standard to represent timedoes not imply any
particular level of clock synchronization between
clients and services in the grid. In fact, no specific
accuracy of synchronization is specified or expected by
OGSI, as this is a service-quality issue
GRID SERVICE PROPERTIES
XML Element Lifetime Declaration
Properties

Service Data elements may represent

instantaneous observations of the dynamic
state of a service instance, it is critical that
consumers of service Data be able to
understand the valid lifetimes of these
observations.