OGSAisadefactostandardforbuildingthenextgenerationofservice-orientedGridsystems. TheGGFiscurrentlycoordinatingaworldwideefforttocompletetheOGSAspecification.

1. GRID COMPUTING
OGSA and WSRF
Sandeep Kumar Poonia
Head 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

2.  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

3. 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.

4. 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.

5. 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.

6. 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.

7. OGSA
Building OGSA compliant Grid applications with OGSI

8. 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.

9.  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

10. 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.

11. A user job submission involves multiple Grid service instances
Service instance semantics

12. Service instance semantics
 A Grid Service Handle (GSH), a globally unique URI
that distinguishes a specific Grid service instance
from all other Grid service instances, identifies each
Grid service instance.
 However, Grid services may be upgraded during their
lifetime.
 The GSH carries no protocol- or instance-specific
information such as a network address and
supported protocol bindings.
 This information is encapsulated, along with all other
instance specific information required to interact with
a specific service instance, into a single abstraction
called a Grid Service Reference.

13. Service instance semantics
 Unlike a GSH, which is invariant, the GSR(s) for a
Grid service instance can change over that service’s
lifetime.
 A GSR has an explicit expiration time, or may
become invalid at any time during a service’s
lifetime, and OGSA defines mapping mechanisms for
obtaining an updated GSR.
 The GSR format is specific to the binding mechanism
used by the client to communicate with the Grid
service instance.
 For example, if the client uses a SOAP binding, the
GSR assumes that an annotated WSDL document
format will be used.

14. 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.

15. Service data semantics
A client can use the standard FindServiceData() method
defined in the GridService portType for querying and
retrieving service data associated with a Grid service
registered 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.

16. Service data semantics
A hierarchical view of service factory, service
data and service data elements

17. Service data semantics
 A service factory can create many service instances,
of which each has a Service Data Set. A Service Data
Set can contain zero or multiple SDEs. Each SDE can
be 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 an
empty Service Data Set).
Notice how SDEs of the same type always contain the
same information (“type A” has data X, Y, Z; “type B”
has data R and S). The SDEs are the ones that actually
contain the data (X, Y, Z, R, S).

18. OGSA provides the following interfaces, which are
extended WSDL portTypes, to define Grid services. In
OGSA, the GridService interface must be
implemented by all Grid services, while the other
interfaces are optional.
OGSA portTypes
OGSA supports the following interfaces.
 GridService portType
 Factory portType
 HandleResolver portType
 Registration portType
 NotificationSource/NotificationSink portType

19. OGSA portTypes
The GridService portType is analogous to the base
Object class within object-oriented programming
languages such as C++ or Java, in that it encapsulates
the root behaviour of the component model.
The three methods encapsulated by the GridService
portType are
 FindServiceData(),
 SetTerminationTime() and
 Destroy()
that are used for service discovery, introspection and
soft-state life cycle management.
GridService portType

20. OGSA portTypes
 A factory is a persistent Grid service
that implements the Factory portType.
 It can be used to create transient Grid
service instances with its
createService() method.
Factory portType

21. OGSA portTypes
A Grid service that implements the
HandleResolver portType can be used to resolve
a GSH to a GSR using its FindbyHandle()
method.
HandleResolver portType

22. OGSA portTypes
 A registry is a Grid service that implements the
Registration port- Type to support service
discovery by maintaining collections of GSHs and
their associated policies.
 Clients can query a registry to discover services’
availability, properties and policies.
Registration portType

23. OGSA portTypes
Two elements define a registry service
 The registration interface, which allows a
service instance to register a GSH with the
registry service, and
 A set of associated service data, that contains
information about the registered GSH and the
run-time states of the service instance.
RegisterService() and UnRegisterService() are the two
methods defined in the portType for service
registration and unregistration.

24. The OGSA notification model allows interested parties to
subscribe to service data elements and receive
notification 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

25. 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.

26. OGSA portTypes
A notification source will use the DeliverNotification()
method in the NotificationSink interface to send a
stream of notification messages to the sink, while the
sink sends periodic messages to notify the source that
it is still interested in receiving notifications.
To ensure reliable delivery, a user can
implement this behaviour by defining an
appropriate protocol binding for the service.

27. The structure of a Grid service in OGSA

28. 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 transient
service instance. Each Grid service has a unique GSH and
one or more GSRs to refer to its implementation, which
is independent of location, platform and programming
language.
A Grid service can be deployed in environments hosted
by J2EE, .Net or Apache Axis.

29. THE GLOBUS TOOLKIT 3 (GT3)
OGSI provides a technical specification for
implementing Grid services defined in the OGSA
specification.
Currently OGSI implementations such as GT3,
MS.NETGrid, OGSI.NET, OGSI::Lite, PyOGSI have been
released.

30. THE GLOBUS TOOLKIT 3 (GT3)
The GT3 structure

31. THE GLOBUS TOOLKIT 3 (GT3)
A hosting environment is a specific execution
environment that defines not only the programming
model and language, but also the development and
debugging tools that can be used to implement Grid
services.
It also defines how the implementation of a Grid
service meets its obligations with respect to Grid
service semantics.
Host environment
Slide 30

32. THE GLOBUS TOOLKIT 3 (GT3)
GT3 supports the following four Java hosting
environments:
 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-compliant
engine, such as the Jakarta Tomcat.
 J2EE EJB container: A code generator to allow exposure of
stateful J2EE Entity and Session JavaBeans as OGSI compliant
Grid services.
Host environment
Slide 30

33. THE GLOBUS TOOLKIT 3 (GT3)
A Web services engine is responsible for
SOAP message exchange between clients and
services.
GT3 currently uses the Apache Axis as its
SOAP engine, which manages SOAP message
exchange.
Web services engine

34. THE GLOBUS TOOLKIT 3 (GT3)
A Grid services container runs on top of a Web
services engine, and provides a run-time environment
for hosting various services.
The idea of using a container in GT3 is borrowed from
the Enterprise JavaBeans (EJB) model, which uses
containers to host various application or components
with business logic.
A GT3 container can be deployed into a range of
hosting environments in order to overcome the
heterogeneity of today’s Grid deployments. Slide 30
Grid services container

35. THE GLOBUS TOOLKIT 3 (GT3)
Compared with Web services, there are three major
functional 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 globally
referenced using an extensible resolution scheme.
 A transport independent Grid Security
Infrastructure (GSI) supporting credential
delegation; message signing and encryption; as well
as authorization.
Grid services container

36. THE GLOBUS TOOLKIT 3 (GT3)
The GT3 Core implements the interfaces and
behavior defined by OGSI.
GT3 core services are focused on the
implementation of the OGSI specification.
Apart from that, security and system level
services are also part of the core services.
GT3 core services

37. THE GLOBUS TOOLKIT 3 (GT3)

38. THE GLOBUS TOOLKIT 3 (GT3)

39. THE GLOBUS TOOLKIT 3 (GT3)

40. THE GLOBUS TOOLKIT 3 (GT3)

41. THE GLOBUS TOOLKIT 3 (GT3)

42. THE GLOBUS TOOLKIT 3 (GT3)

43. THE GLOBUS TOOLKIT 3 (GT3)

44. THE GLOBUS TOOLKIT 3 (GT3)

45. THE GLOBUS TOOLKIT 3 (GT3)