GRID COMPUTINGOGSA and WSRF

Sandeep Kumar PooniaHead Of Dept. CS/IT, Jagan Nath University, Jaipur

B.E., M. Tech., UGC-NET

LM-IAENG, LM-IACSIT,LM-CSTA, LM-AIRCC, LM-SCIEI, AM-UACEE

OGSA is a de facto standard for building the next

generation of service-oriented Grid systems.

The GGF is currently coordinating a worldwide

effort to complete the OGSA specification.

OGSA is based on Web services technologies, but

with some extensions.

OGSA extends Web services by introducing

interfaces and conventions in three main areas.

OGSA

OGSA First, there is a dynamic and potentially transient

nature of services in a Grid environment, in which

particular service instances may come and go as

work is dispatched, as resources are configured

and provisioned, and as system state changes.

Therefore, Grid services need interfaces to

manage their creation, destruction and life cycle

management.

OGSA Second, there is state. Grid services can have

attributes and data associated with them.

This is similar in concept to the traditional

structure of objects in object-oriented

programming.

Objects have behavior and data.

Likewise, Web services needed to be extended to

support state data associated with Grid services.

OGSA Third, clients can subscribe their interests

in services. Once there is any change in a service, the

clients are notified. This is a call-back operation from services

to clients.

OGSA Grid applications can be built from OGSA

compliant services.

Services in OGSA are composed of two parts,

OGSA platform and core services.

The OGSA platform services are Grid-based

services related to user authentication and

authorization, fault tolerance, job submission,

monitoring and data access.

OGSA

Building OGSA compliant Grid applications with OGSI

OGSA OGSA defines various aspects related to a Grid

service, e.g. the features of Grid services, and what

interfaces are needed; but it does not specify how

these interfaces should be implemented.

That is the task of OGSI, which is a technical

specification to specify how to implement the core

Grid services as defined in OGSA in the context of

Web services, specifically WSDL.

The OGSI specifies exactly what needs to be

implemented to conform to OGSA.

Therefore, a Grid services can be defined as an

OGSI compliant Web service.

An OGSA compliant service can be defined as any

OGSI compliant service whose interface has been

defined by OGSA to be a standard OGSA service

interface.

OGSI & OGSA

Service instance semantics

A Grid service instance is an instantiation of a Grid

service that can be dynamically created and

explicitly destroyed.

A Grid service that can create a service instance is

called a service factory, a persistent service itself.

A client can request a factory to create many

service instances and multiple clients can access

the same service instance.

A user job submission involves multiple Grid service instances

Service instance semantics

Service instance semantics

A Grid Service Handle (GSH), a globally unique URIthat distinguishes a specific Grid service instancefrom all other Grid service instances, identifies eachGrid service instance.

However, Grid services may be upgraded during theirlifetime.

The GSH carries no protocol- or instance-specificinformation such as a network address andsupported protocol bindings.

This information is encapsulated, along with all otherinstance specific information required to interact witha specific service instance, into a single abstractioncalled a Grid Service Reference.

Service instance semantics

Unlike a GSH, which is invariant, the GSR(s) for aGrid service instance can change over that service’slifetime.

A GSR has an explicit expiration time, or maybecome invalid at any time during a service’slifetime, and OGSA defines mapping mechanisms forobtaining an updated GSR.

The GSR format is specific to the binding mechanismused by the client to communicate with the Gridservice instance.

For example, if the client uses a SOAP binding, theGSR assumes that an annotated WSDL documentformat will be used.

Service data semantics

Each Grid service instance is also associated with

service data, which is a collection of XML elements

encapsulated as Service Data Elements (SDE).

Service data are used to describe information

about a service instance and their run-time states.

Unlike standard Web services, which are stateless,

Grid services are stateful and can be introspected.

Service data semantics

A client can use the standard FindServiceData() methoddefined in the GridService portType for querying andretrieving service data associated with a Grid serviceregistered in a registry, i.e.

the service type; if it is a service instance, the GSH of the service

instance; the location of a service factory; and the run-time states.

Service data semantics

A hierarchical view of service factory, service data and service data elements

Service data semantics

A service factory can create many service instances,of which each has a Service Data Set. A Service DataSet can contain zero or multiple SDEs. Each SDE canbe of a different type.

The first instance has two “type A” SDEs and one“type B” SDE. The second instance has only one“type A” SDE.

The third instance has no SDEs at all (it does have anempty Service Data Set).

Notice how SDEs of the same type always contain thesame information (“type A” has data X, Y, Z; “type B”has data R and S). The SDEs are the ones that actuallycontain the data (X, Y, Z, R, S).

OGSA provides the following interfaces, which areextended WSDL portTypes, to define Grid services. InOGSA, the GridService interface must beimplemented by all Grid services, while the otherinterfaces are optional.

OGSA portTypes

OGSA supports the following interfaces. GridService portType Factory portType HandleResolver portType Registration portType NotificationSource/NotificationSink portType

OGSA portTypes

The GridService portType is analogous to the baseObject class within object-oriented programminglanguages such as C++ or Java, in that it encapsulatesthe root behaviour of the component model.The three methods encapsulated by the GridServiceportType are FindServiceData(), SetTerminationTime() and Destroy()that are used for service discovery, introspection andsoft-state life cycle management.

GridService portType

OGSA portTypes

A factory is a persistent Grid servicethat implements the Factory portType.

It can be used to create transient Gridservice instances with itscreateService() method.

Factory portType

OGSA portTypes

A Grid service that implements theHandleResolver portType can be used to resolvea GSH to a GSR using its FindbyHandle()method.

HandleResolver portType

OGSA portTypes

A registry is a Grid service that implements theRegistration port- Type to support servicediscovery by maintaining collections of GSHs andtheir associated policies.

Clients can query a registry to discover services’availability, properties and policies.

Registration portType

OGSA portTypes

Two elements define a registry service The registration interface, which allows a

service instance to register a GSH with theregistry service, and

A set of associated service data, that containsinformation about the registered GSH and therun-time states of the service instance.

RegisterService() and UnRegisterService() are the twomethods defined in the portType for serviceregistration and unregistration.

The OGSA notification model allows interested parties tosubscribe to service data elements and receivenotification events when their values are modified.

A Grid service that implements the NotificationSource

portType is called a notification source.

A Grid service that implements the NotificationSink

portType is called a notification sink.

OGSA portTypes

NotificationSource/NotificationSink portType

OGSA portTypes

To subscribe notification to a particular Grid service,

a notification sink invokes a notification source using

the SubscribeToNotificationTopic() method in the

NotificationSource interface, giving it the service GSH

of the notification sink and the topics interested.

OGSA portTypes

A notification source will use the DeliverNotification()method in the NotificationSink interface to send astream of notification messages to the sink, while thesink sends periodic messages to notify the source thatit is still interested in receiving notifications.

To ensure reliable delivery, a user canimplement this behaviour by defining anappropriate protocol binding for the service.

The structure of a Grid service in OGSA

OGSA defines standard mechanisms for service creation, destruction, life cycle management, service registration, discovery and service notification.

A Grid service can be a persistent service, or a transientservice instance. Each Grid service has a unique GSH andone or more GSRs to refer to its implementation, whichis independent of location, platform and programminglanguage.

A Grid service can be deployed in environments hostedby J2EE, .Net or Apache Axis.

THE GLOBUS TOOLKIT 3 (GT3)

OGSI provides a technical specification forimplementing Grid services defined in the OGSAspecification.

Currently OGSI implementations such as GT3,MS.NETGrid, OGSI.NET, OGSI::Lite, PyOGSI have beenreleased.

THE GLOBUS TOOLKIT 3 (GT3)

The GT3 structure

THE GLOBUS TOOLKIT 3 (GT3)

A hosting environment is a specific executionenvironment that defines not only the programmingmodel and language, but also the development anddebugging tools that can be used to implement Gridservices.It also defines how the implementation of a Gridservice meets its obligations with respect to Gridservice semantics.

Host environment

Slide 30

THE GLOBUS TOOLKIT 3 (GT3)

GT3 supports the following four Java hostingenvironments: Embedded: A library allowing an OGSI-hosting environment

to be embedded in any existing J2SE applications. Standalone: A lightweight J2SE server that hosts Grid

services. J2EE Web container: An OGSI hosting environment inside a

Web server that can be hosted by any Java Servlet-compliantengine, such as the Jakarta Tomcat.

J2EE EJB container: A code generator to allow exposure ofstateful J2EE Entity and Session JavaBeans as OGSI compliantGrid services.

Host environment

Slide 30

THE GLOBUS TOOLKIT 3 (GT3)

A Web services engine is responsible forSOAP message exchange between clients andservices.GT3 currently uses the Apache Axis as itsSOAP engine, which manages SOAP messageexchange.

Web services engine

THE GLOBUS TOOLKIT 3 (GT3)

A Grid services container runs on top of a Webservices engine, and provides a run-time environmentfor hosting various services.The idea of using a container in GT3 is borrowed fromthe Enterprise JavaBeans (EJB) model, which usescontainers to host various application or componentswith business logic.A GT3 container can be deployed into a range ofhosting environments in order to overcome theheterogeneity of today’s Grid deployments. Slide 30

Grid services container

THE GLOBUS TOOLKIT 3 (GT3)

Compared with Web services, there are three majorfunctional areas covered by a Grid service container: Lightweight service introspection and discovery

supporting both pull and push information flows. Dynamic deployment and soft-state management of

stateful service instances that can be globallyreferenced using an extensible resolution scheme.

A transport independent Grid SecurityInfrastructure (GSI) supporting credentialdelegation; message signing and encryption; as wellas authorization.

Grid services container

THE GLOBUS TOOLKIT 3 (GT3)

The GT3 Core implements the interfaces andbehavior defined by OGSI.GT3 core services are focused on theimplementation of the OGSI specification.Apart from that, security and system levelservices are also part of the core services.

GT3 core services

THE GLOBUS TOOLKIT 3 (GT3)

THE GLOBUS TOOLKIT 3 (GT3)

THE GLOBUS TOOLKIT 3 (GT3)

THE GLOBUS TOOLKIT 3 (GT3)

THE GLOBUS TOOLKIT 3 (GT3)

THE GLOBUS TOOLKIT 3 (GT3)

THE GLOBUS TOOLKIT 3 (GT3)

THE GLOBUS TOOLKIT 3 (GT3)

THE GLOBUS TOOLKIT 3 (GT3)