Ogsa ogsi-a more detailed view
- 1. Prof. Neeraj Bhargava Pooja Dixit Department of Computer Science School of Engineering & System Sciences MDS, University Ajmer, Rajasthan, India 1
- 2. INTRODUCTION The OGSA integrates key grid technologies (including the Globus Toolkit) with Web services mechanisms to create a distributed system framework based on the OGSI. Grid services provide for the controlled management of the distributed and often long-lived state that is commonly required in sophisticated distributed applications. OGSI also introduces standard factory and registration interfaces for creating and discovering grid services. OGSI defines a component model that extends WSDL and XML schema definition to incorporate the concepts of ◦ Stateful Web services ◦ Extension of Web services interfaces ◦ Asynchronous notification of state change ◦ References to instances of services ◦ Collections of service instances ◦ Service state data that augment the constraint capabilities of XML schema definition The OGSI specification defines the minimal, integrated set of extensions and interfaces necessary to support definition of the services that will compose OGSA. 2
- 3. 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. One needs to examine both the client-side programming patterns for grid services and a conceptual hosting environment for grid services. Relationship to Distributed Object Systems: A given grid service implementation is an addressable and potentially stateful instance that implements one or more interfaces described by WSDL portTypes. Grid service factories can be used to create instances implementing a given set of portType(s). Grid service instances are made accessible to (potentially remote) client applications through the use of a grid service handle and a grid service reference (GSR). client application can use a grid service reference to send requests, represented by the operations defined in the portType(s) of the target service description directly to the specific instance at the specified network-attached service endpoint identified by the grid service reference. Client-Side Programming Patterns: Another important issue is how 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. The Web Services Invocation Framework (WSIF) and Java API for XML RPC (JAX-RPC) are among the many examples of infrastructure software that provide this capability. 3
- 4. Figure depicts a possible (but not required) client-side architecture for OGSI. In this approach, a clear separation exists between the client application and the client-side representation of the Web service (proxy), including components for marshaling the invocation of a Web service over a chosen binding. Possible client-side runtime architecture. 4
- 5. Within the client application runtime, a proxy provides a client- side representation of remote service instance’s interface. Proxy behaviors specific to a particular encoding and network protocol (binding, in Web services terminology) are encapsulated in a protocol-specific (binding-specific) stub. Client Use of Grid Service Handles and References: a client gains access to a grid service instance through grid service handles and grid service references. A grid service handle (GSH) can be thought of as a permanent network pointer to a particular grid service instance. The GSH does not provide sufficient information to allow a client to access the service instance; the client needs to “resolve” a GSH into a grid service reference (GSR). The GSR contains all the necessary information to access the service instance. The GSR is not a “permanent” network pointer to the grid service instance because a GSR may become invalid for various reasons; for example, the grid service instance may be moved to a different server. OGSI provides a mechanism, the HandleResolver to support client resolution of a grid service handle into a grid service reference. Figure shows a client application that needs to resolve a GSH into a GSR. 5
- 6. The client resolves a GSH into a GSR by invoking a HandleResolver grid service instance identified by some out-of-band mechanism. The HandleResolver can use various means to do the resolution; some of these means are depicted in Figure. The HandleResolver may have the GSR stored in a local cache. The HandleResolver may need to invoke another HandleResolver to resolve the GSH. The HandleResolver may use a handle resolution protocol, specified by the particular kind (or scheme) of the GSH to resolve to a GSR. The HandleResolver protocol is specific to the kind of GSH being resolved. For example, one kind of handle may suggest the use of HTTP GET to a URL encoded in the GSH in order to resolve to a GSR. Figure: Resolving a GSH 6
- 7. Relationship to Hosting Environment: OGSI does not dictate a particular service-provider-side implementation architecture. A variety of approaches are possible, ranging from implementing the grid service instance directly as an operating system process to a sophisticated server-side component model such as J2EE. Figure: Two approaches to the implementation of argument demarshaling functions in a grid service hosting environment. 7
- 8. Figure illustrates two grid service instances (the oval) associated with container-managed components (e.g., EJBs within a J2EE container). Here, the message is dispatched to these components, with the container frequently providing facilities for demarshaling and decoding the incoming message from a format (such as an XML/SOAP message) into an invocation of the component in native programming language. In some circumstances (the oval), the entire behavior of a grid service instance is completely encapsulated within the component. The bottom part of Figure depicts another scenario wherein the entire behavior of the grid service instance, including the demarshaling/decoding of the network message, has been encapsulated within a single executable. Although this approach may have some efficiency advantages, it provides little opportunity for reuse of functionality between grid service implementations. 8
- 9. The Grid Service:The purpose of the OGSI document is to specify the (standardized) interfaces and behaviors that define a grid service. In brief, a grid service is a WSDL-defined service that conforms to a set of conventions relating to its interface definitions and behaviors. The OGSI document expands upon this brief statement by: ◦ Introducing a set of WSDL conventions that one uses in the grid service specification; ◦ Defining service data that provide a standard way for representing and querying metadata and state data from a service instance ◦ Introducing a series of core properties of grid service, including: Defining grid service description and grid service instance, as organizing principles for their extension and their use Defining how OGSI models time Defining the grid service handle and grid service reference constructs that are used to refer to grid service instances Defining a common approach for conveying fault information from operations. This approach defines a base XML schema definition and associated semantics for WSDL fault messages to support a common interpretation Defining the life cycle of a grid service instance 9
- 10. 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. Web service including those used outside the context of grid applications, one can propose a common approach to exposing Web service state data called “serviceData.” Service data can be exposed for read, update, or subscription purposes. Since WSDL defines operations and messages for portTypes, the declared state of a service must be externally accessed only through service operations defined as part of the service interface. To avoid the need to define serviceData-specific operations for each serviceData element, the grid service portType provides base operations for manipulating serviceData elements by name. 10