7. the grid ogsa
DESCRIPTION
OGSAisadefactostandardforbuildingthenextgenerationofservice-orientedGridsystems. TheGGFiscurrentlycoordinatingaworldwideefforttocompletetheOGSAspecification.TRANSCRIPT
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)