7. the grid ogsa
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

7. the grid ogsa

on

  • 327 views

OGSAisadefactostandardforbuildingthenextgenerationofservice-orientedGridsystems.

OGSAisadefactostandardforbuildingthenextgenerationofservice-orientedGridsystems.
TheGGFiscurrentlycoordinatingaworldwideefforttocompletetheOGSAspecification.

Statistics

Views

Total Views
327
Views on SlideShare
327
Embed Views
0

Actions

Likes
0
Downloads
55
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

7. the grid ogsa Presentation Transcript

  • 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)