Since a grid consists of both existing and new hardware and software, multiple variations of communication protocols, security schemes, and transaction management systems exist and cooperate at the same time. Today's grids tend to be a patchwork of protocols and noninteroperable "standards" and difficult-to-reuse "implementations." The OGSA uses Web services technologies like WSDL, SOAP, and WSIL to abstract platform and implementation differences, giving transparent access to grid services.

OGSA is an extension and a refinement of a Web services architecture. It describes a system that normally consists of a few persistent and potentially many transient services. The architecture defines basic service behavior including fundamental semantics, life-cycle management, and discovery. Also included is a framework for fault resilience, security, and transaction management.

The services specified in OGSA can be persistent and time limited, supporting delegated authentication credentials using heterogeneous communications protocols. These characteristics are significantly different from the common Web services model in which services are persistent, allowing anonymous communication over HTTP using SOAP. Transient, short-lived services, dynamically created and destroyed, are an essential component of a grid. Examples include: interfaces to the states of distributed activities, data analysis, and streaming video. Much of the work in OGSA deals with the implications of transient service instances on management, naming and discovery.

Fundamental to OGSA are WSDL and interfaces for dynamic discovery and life-cycle management for a specific type of Web service - a Grid Service. WSDL conventions and extensions are used to describe and structure services, while core service activities are expressed using WSDL interfaces and behaviors. Every Grid Service instance has a unique and immutable name called the Grid Service Handle. Lifetime management is provided by mandatory support for the operations Destroy and SetTerminationTime.

WSDL in OGSA
WSDL enables the creation of "tightly contracted/loosely coupled" systems, separating interface, binding, and implementation. The binding component is further divided in transport, the mechanism used to flow bits from A to B, and encoding, how information is communicated from one system to another. This allows for the separation of concerns for building, hosting and accessing services. A service provider can be developed in C++, hosted on zOS, accessed by a Java application running on Solaris, using SOAP over MQ-Series. WSDL defines the service functionality and an access path or on-ramp to invoke it (see Figure 3).

OGSA introduces the following extensions to WSDL:

A basic WSDL instance document only describes that a service implements a port with the given interface; there is no information about what the service does with that port. The OGSA extensions allow the naming of families of services that have identical semantics and to assert that a particular service implements these semantics. The role of the compatibilityAssertion is to declare that two elements with the same underlying type are indeed compatible even if they have different names. As a result, the clients of the service understand its behavior. Figure 4 illustrates how the WSDL extensions relate to each other.

GridService
A Grid Service is a WSDL-defined service that follows a set of conventions relating to its interface definitions and behaviors. The specification details how clients create, discover, and interact with a Grid Service. Note that OGSA doesn't address the actual creation, management, and destruction of the server component in a particular hosting environment. This means that Grid Services may not be portable across hosting environments but any OGSA-compliant client can invoke them. Three characteristics separate a Grid Service from a regular Web service:

1.   A Grid Service is an instance of a service implementation of a service type, a collection of specific interfaces.

2.   The instance implements a Grid Services Handle. This is a Uniform Resource Indicator (URI) for the service instance and is bound to a Grid Service Reference (GSR). The GSR is similar, for example, to the Interoperable Object Reference (IOR) in CORBA and contains the necessary information to bind and use the service. The HandleMap interface is used to map between the GSH and GSR. Introducing the GSR in the specification allows the separation of the service name from the service implementation, facilitating service evolution such as "non-stop" service upgrades.

3.   The instance also implements a port called GridService supporting three operations:

In addition to the required GridService port, OGSA also defines additional, optional service ports. These interfaces define properties commonly required by distributed systems, such as messaging, discovery and registration, instance creation, and full life-cycle management.

The NotificationSource and NotificationSink ports handle messaging. This is a simple publish-subscribe system similar to Java's JMS, using XML messages. Existing messaging systems such as Tibco or MQ Series can also be used to implement the service. Error notification, application monitoring, and dynamic discovery of services are areas where the Notification ports are useful (see Figure 5).

The Registry port is used to bind the metadata of Grid Service instances, identified by their GSH, to a registry. The registry is a particular type of Grid Service that maintains a set of Grid Service Handles and policies associated with the collection. Extracting information from the registry service is done using the FindServiceData method on the GridService port. This method always supports the XPath query language and returns a WS-Inspection document containing the GSHs of a set of Grid Services. Unfortunately, there is no port type defined to add or remove bindings to and from a service. As a workaround, the notification system can be used.

Instances of a Grid Service can be created via a factory or manually. Similarly, they can be destroyed via soft state termination or explicitly. The factory interface operation CreateService can create transient application service and supports reliable service instantiation (once-and-only-once). Interaction with the factory requires creation-lifetime information and can be extended to include an XML document describing service-specific creation parameters. The interface returns a GSH that uniquely identifies the instance over time. The soft-state lifetime management support avoids clients having to tear down services and prevents resource "leaks" in hosting environments.

Implementations hurdles and future
From a technical perspective, OGSA is critical to streamlining and accelerating the creation and deployment of grid applications. The architecture unifies existing grid development approaches and is extensible from a technical perspective to incorporate future developments. However, to expand the reach of grid applications beyond the level of a single enterprise the OGSA needs to more thoroughly address issues concerning:

• Use of WSDL extensions
• Definition and use of service ports
• Heterogeneous, end-to-end, security
• Grid Service manageability

Discovery and life-cycle management deserve a separate interface. In the current OGSA specification, the services are combined in GridService. These services perform distinct roles and are used in different ways. For example, discovery of grid services can be open to anyone, while instantiation and destroy operations require a secure, authenticated connection.

Addressing concerns around authentication, authorization, and trust relations is essential for grid implementations across organizational boundaries. The OGSA should include provisions for "pluggable" security mechanisms that can be discovered by the client using a service description. Service providers, in turn, can plug in a security architecture that fits their infrastructure for Grid Services.

Currently, the OGSA does not indicate how resources are exposed or, in an operational setting, how large sets of Grid Service instances can be monitored and managed. Grid Services are commonly subject to service level agreements that define specific availability, performance, and reliability characteristics. Without agreement on how to instrument and manage, for example, serviceType and portTypes, it will be next to impossible to manage heterogeneous grid applications.

Conclusion
OGSA brings utility-based computing a step closer, and allows the development and deployment of standards-based Grid Services today. The combination of Web services and grid computing virtualizes networked resources using common computing standards, making them accessible to a larger audience. To extend the reach of the architecture and maximize its potential benefits, additional services, such as security and management, need to become an integral part of the specification.

References