Before proceeding further, let's state that clearly it's possible, using standard Web services, to manage and name stateful services using ad hoc methods, e.g. extra characters placed in URLs or extra arguments to functions. Similarly, you can define an introspection service interface and publish it via WSDL. However, the point is not whether it can be done, but whether it is done in a uniform and consistent manner that everyone understands so that the full power of traditional distributed system naming and binding techniques can be brought to bear on the widest possible set of services. Grid services are important because they provide uniformity and consistency for vital distributed system functions.

Named Service Instances
At the heart of the Grid service specification is the notion of a named service instance. A service instance is named by a Grid Service Handle (GSH). The GSH is a classic abstract name - it is not necessarily possible to determine by examination of a GSH such things as the location, number, implementation, operational status (e.g., up, down, failed), and failure characteristics of the associated named object. GSHs by themselves are not useful. Instead they must be resolved into a Grid Service Reference (GSR). A GSR contains sufficient information to communicate with the named grid service instance. Thus, GSHs and GSRs form a two-level naming scheme in which GSHs serve as abstract names and GSRs provide the method and address of delivery. Let's first look at the benefits of having abstract names.

Why Abstract Names?
What is an abstract name? An abstract name refers to a "thing" or "things." In the case of Grid services, the "things" are Grid service instances, which may be stateless, i.e., pure functions that transform or map inputs to outputs in which the outputs are independent of the history of calls on the service instance; or stateful, in which case the output may depend on the history of calls on the service. The advantage of using abstract names rather than addresses is that it permits a level of indirection between the representation of the name and the code that actually implements the service.

Note that the form of the GSH is flexible - syntactically, a GSH is represented as a URI, allowing for many different name schemes. This allows for greater flexibility in choosing how GSHs are resolved into GSRs. For example, you could choose to implement a GSH name space that uses DNS addresses as part of the GSH. However, such a scheme is not required, nor does the inclusion of a DNS address in a GSH tell you anything per se about the location of the named service instance.

Why Use a Two-level Name Scheme Instead of Addresses?
Recall that GSHs (names) resolve to GSRs (addresses). Because GSHs are abstract names, the mapping of GSHs to GSRs need not be static - it is possible that a given GSH may resolve to different GSRs over time. For example, a Grid service instance (named by a GSH) may migrate from location to location in response to load, anticipated failure, or to improve performance by colocating with a client or frequently used service. Furthermore, the mapping may not only vary over time but need not be one-to-one. Other mappings are possible: one-to-many where the same GSH resolves to different GSRs - e.g., for load balancing.

The point is that by utilizing a two-level naming scheme, Grid services enable flexible realization of the traditional distributed system transparencies (see the sidebar: Transparencies). This has been done in many distributed systems in the past, as well as in contemporary Grid systems such as Legion and Avaki.

Base Set of Interfaces
The second important aspect of Grid services is that a Grid service must export (expose) a minimum set of mandatory interfaces and a minimum set of what are called service data elements (SDEs) - essentially service metadata and state. These mandatory services and data elements are interfaces that all GSs can be assumed to have. They include functions and data elements for lifetime management (e.g., set termination time) and functions to query and manipulate SDEs.

The importance of SDEs in the Grid cannot be underestimated. They provide the basic mechanism by which discovery and monitoring of Grid services is achieved, including interface discovery, discovery of other metadata that might be used in services such as scheduling (e.g., policy information), and even the current state of the service instance (e.g., current load).

SDEs that convey dynamic state merit particular attention, for they distinguish Grid services from what is typically found in Web services. While Web service technologies such as WSDL and UDDI (Universal Description, Discovery, and Integration) allow for introspection and discovery of static information such as service interfaces and associated policy, dynamic SDEs provide a much richer basis for discovery and monitoring. This dynamicity is crucial when building dynamic systems in which the set of service interactions may be impossible to know a priori (at configuration time), in which decisions about which services to use may depend heavily on dynamic service state, and in which monitoring of a service's dynamic state is necessary to respond to unpredictable events in the overall system. Service data exploits XML strengths, including XML Schemas for rich modeling of the state and extensible support for rich query languages such as XPath and XQuery for introspection on that modeled state, to provide for a consistent and powerful basis on which discovery and monitoring can be built across all Grid services.

By clearly defining a minimum mandatory set of interfaces that all Grid services must support, as well as optional interfaces that play core roles, OGSI specifications make it possible to write higher-level software services and applications that can make assumptions about both the services and the infrastructure of the Grid. This uniformity simplifies the definition and implementation of the various higher-level services that must be defined to construct a complete Open Grid Services Architecture (OGSA). In addition, by defining base service type interfaces, the OGSI sets the tone and philosophy of both how the Grid will operate and how future extensions will be shaped.

Instantiation and Lifetime Management
The final major extension is the explicit concept of state in Grid services, as described earlier. While Web services may have state, it's not explicit, nor are different discrete units of state (i.e., instances) named in a consistent manner. Once there is namable state the obvious issues are (1) how are new instances created?; and (2) how long do they last? To address these two issues the Grid service specification defines factories and lifetime management services.

New Web services are instantiated in the case of Grid services by factories. The Factory PortType defines an operation that creates a new service instance and returns its GSH (handle) and its initial termination time.

TerminationTime is a powerful concept supported by the OGSI. A significant problem in distributed systems in general, and Grid systems in particular, is the issue of reclamation of resources associated with services in the event of failures (e.g., loss of network connectivity) or lack of interest by any relevant clients (e.g., a service is no longer referenced by any other active process or service).

TerminationTime addresses this problem by setting a time when a service will self-destruct unless kept alive by subsequent increases in its termination time. Thus, a service can be started, and the progenitor need not explicitly destroy the service. Instead, it will be terminated automatically.

Summary
The OGSI specification provides the foundation upon which a wide range of Grid services will be defined, built, and interconnected. Grid services marry important concepts from the Grid computing community with Web services. They extend basic Web services by defining a two-layer naming scheme that enables support for the conventional distributed system transparencies, by requiring a minimum set of functions and data elements that support discovery, and by introducing explicit service creation and lifetime management.

These extensions are more than syntactic sugar. They extend and enhance the capabilities of Web services by providing common, powerful mechanisms that service consumers can rely upon across all services, instead of the service-specific, often ad-hoc approaches typically employed in standard Web services.

Acknowledgements
We'd like to thank Marty Humphrey (University of Virginia), David Snelling (Fujitsu), the OGSI Working Group for their contribution to establishing open standards for Grid technology, Ian Foster (Argonne National Laboratory), and Carl Kesselman (University of Southern California).

References

SIDEBAR

Transparencies

Distributed systems research has a rich literature where virtualization of resources and objects is a common solution to many problems. This virtualization results in a "transparency." Nine of these show up again and again. They are used with respect to accessing a remote service or object. Usually the intent is that the programmer/user need not know or deal with something, but can if they want to. The transparencies are: