In June 2003, the Global Grid Forum (GGF) adopted the Open Grid Services Infrastructure (OGSI) specification as a GGF standard. OGSI is essential to the Open Grid Computing vision as it is the foundation on top of which the building blocks of future Grid applications will be placed. Those building blocks, the Grid services, are being defined by various GGF working groups, with the Open Grid Services Architecture (OGSA) working group orchestrating the entire process.

This article introduces OGSA, presents the OGSI specification, and discusses the significant role of Web service standards in Grid computing.

Grid Computing
Grid computing has been a hot topic in the news recently. Major vendors like IBM, HP, and Sun have not only been advertising their plans to support Grid computing, but they have also started rolling out their first e-business and e-science solutions.

All the interest in Grid computing led to the formation of the Global Grid Forum (GGF; www.ggf.org), a forum for the discussion of Grid-related ideas and the promotion of enabling technologies. One of its main activities is the creation of a standards-based platform for Grid computing with emphasis on interoperability.

But, what is the Grid? And, what does the term "Grid computing" mean? It could be about virtual organizations, or the integration of distributed resources, or a universal computer, or even about interconnecting supercomputers depending on who you talk to. A definition of the Grid is beyond the scope of this article. Your favorite Web search engine will provide you with many links to definitions and information. There are also a number of books out there from which you can draw information.

OGSA
The blueprint of the Grid architecture is defined by OGSA (www.ggf.org/ogsa-wg) as a set of fundamental services whose interfaces, semantics, and interactions are standardized by the GGF working groups. OGSA plays the coordinating role for the efforts of these groups. It identifies the requirements for e-business and e-science applications in a Grid environment and specifies the core set of services and their functionality that will be necessary for such applications to be built, while the technical details are left to the groups.

While OGSA has adopted a services-oriented approach to defining the Grid architecture, it says nothing about the technologies used to implement the required services and their specific characteristics. That is the task of OGSI.

Figure 1 shows the relationship between OGSA, OGSI, and the Web services standards. Also, a list, which is not exhaustive, of candidate core services is presented. It is expected that in the months to follow, OGSA will standardize this list.

 

OGSI
The OGSI working group decided to build the Grid infrastructure on top of Web services standards, hence leveraging the great effort - in terms of tools and support-that the industry has put into the field. Nevertheless, the group identified some key characteristics missing from Web services standards that they thought would be instrumental in building Grid applications, including the ability to create new services on demand (the Factory pattern); service lifetime management; statefulness; access to state; notification; and service groups.

OGSI is based on the concept of a Grid service instance, which is defined as "a Web service that conforms to a set of conventions (interfaces and behaviors)" [www.ggf.org/ogsi-wg]. All services in the OGSA platform must adhere to the conventions specified by OGSI and, therefore, they are all Grid services. It is crucial to note that the term "Grid service" is used here to refer to all aspects of OGSI.

Grid Service Description
According to the OGSI specification, each Grid service instance is associated with some transient state and has properties that control its lifetime. Additionally, the specification defines the operations that must be supported and the way the state and lifetime-related information can be accessed. As with Web services, a WSDL document - with few non-compliant extensions to the WSDL standard - is used to describe the operations, messages, and portType (renamed to "interface" in WSDL 1.2) of a Grid service instance. In OGSI terms, the WSDL document is called the "Grid service description."

The specification mandates that the portType of a Grid service inherits (or "extends" in WSDL 1.2) the GridService portType defined by OGSI, guaranteeing that the OGSI-specific operations will be available. Although not part of WSDL 1.1, portType inheritance was deemed necessary by the working group so they not only made use of it in the specification but its importance was reflected in its introduction to the current WSDL 1.2 draft.

Service Data
In addition to operations, a portType of a Grid service instance may also include Service Data Declarations (SDDs), constructs describing the structure of the Service Data Elements (SDEs) that make up the instance's exposed state. The concept of SDDs and SDEs combined with a number of operations defined by OGSI provides a common mechanism to describe the structure of a Grid service instance's exposed state, to access or modify that state, and to use the state for notification purposes. For example, access to an SDE is made possible through appropriate get/set operations in the GridService portType. The inclusion of the SDDs and SDEs in the specification brings the idea of JavaBeans properties and C++/Java instance/class data members in Grid services.

The OGSI working group felt that the SDD and SDE concepts were important enough to the Grid's service-oriented architecture to adopt them in their specification, even though they are not part of any other standard. As with portType inheritance, the group is actively lobbying for the introduction of service data in the next version of WSDL.

Grid Service Handles, References, and Locators
Each Grid service instance is identified by a URI, which is called the Grid Service Handle (GSH). However, a GSH cannot be used to communicate with a Grid service instance. Instead, it has to be resolved to a Grid Service Reference (GSR), which contains a binding-specific endpoint that consumers can use. More than one GSR may exist at the same time pointing to the same Grid service instance through different binding-specific endpoints (e.g., SOAP endpoint or CORBA IOR).

Unlike a GSH, a GSR may expire throughout the lifetime of a Grid service instance. If that happens, the consumer of the service will have to get one (or more) new GSR(s). A HandleResolver portType is defined to support resolutions of GSHs to GSRs. There can be a number of reasons a service provider may want the GSRs to its Grid service instances to expire. If, for example, service mobility was to be implemented, consumers would have to refresh their GSRs to point to the new location of the service. For quality of service, access to service instance may only be allowed through a particular network binding only at certain times.

A locator is a container of GSHs and GSRs that point to the same Grid service instance. It may also contain the qNames of the portTypes that are supported by the referred instance. Many of the operations defined in the OGSI portTypes return or accept Locator constructs as arguments.

Creating Grid Service Instances
The Factory pattern enables the dynamic creation of Grid service instances based on a Grid service description. OGSI specifies the operations and semantics of a factory through the Factory portType. However, a Grid service instance does not have to be created through a service that supports the Factory portType. For example, a hosting environment may create Grid service instances when it starts or as a result of an event.

The implementation of the Factory portType by a Grid service instance is not mandated by the specification.

Notification and Service Groups
The OGSI specification includes portTypes to support notification and service groups. The notification pattern allows interested parties to subscribe to service data elements and receive notification events when their value is modified. Service group portTypes allow registries of grid service instances to be formed. Service groups may denote some kind of relationship between the instances they contain, but that is not a requirement. For example, a service group may contain all the instances that were created by a particular user.

The implementation of the notification and service group portTypes by a Grid service instance is not mandated by the specification.

An Example
The discussion of OGSI so far has given us enough ground to explore an example. We are going to write the Grid service description of a very simple workflow execution Grid service and explore the steps for creating and consuming instances of it.

The Grid service description of our workflow execution Grid service is shown in Listing 1. It supports only a simple operation, "executeWorkflow", plus all the operations in the GridService portType that the workflowExecutionPortType inherits. Note that the gwsdl:portType element is used instead of the wsdl:portType one. This is the temporary solution that OGSI adopted until WSDL 1.2 - with the "extends" attribute for the wsdl:portType element - is published.

The Grid service description shown in Listing 1 does not include "binding" or "service" elements. This is because the document is like a template for the construction of new Grid service instances. The WSDL of those instances will, of course, have to contain binding related information. The OGSI specification says nothing about specific bindings.

So, how do we use this service? First, we need to get access to an instance of it. The hosting environment may create one automatically for us and make it available through a registry, or there may be a factory Grid service instance that we may be able to use. The approach will depend on the semantics of our service. We may want to have a Grid service instance representing the workflow execution engine as a resource, in which case all consumers will have to share it. Alternatively, we may require each consumer to create a new instance that will represent that consumer's interaction with the workflow execution engine, in which case the instance's state may represent interaction-specific information.

Let's assume that there is a factory that can create instances of our data access Grid service. Figure 2 illustrates the necessary steps. We need to obtain a GSH to a factory instance (e.g., by looking into an appropriate registry, Steps 1 and 2). Then, we can resolve the GSH to one or more GSRs, giving us access to the operations of that factory (this step can be part of the query to the registry). If the request to create a new instance (Step 3) of the service is successful (Step 4), we will be given a GSH to the new instance (Step 5). Again, we will have to resolve the GSH to a GSR so we can access the instance. This may happen automatically as part of the create operation or we may have to contact an instance that implements the OGSI HandleResolver portType (the former is assumed in Figure 2).

 

Once we have a GSR to the newly created Grid service instance, we can invoke operations on it (Step 6). We can submit a BPEL script for execution or call the operations that are defined by the GridService portType. Of course, a more useful workflow execution Grid service would probably have operations that stopped and paused the execution of the workflow, queried its state, supported notification, and so on.

Now that we have an idea of how instances are created and consumed, we can introduce service data into our example. We could expose the status of the execution of the submitted workflow (see Listing 2).

The sd:serviceData element declares the existence of the "wf:status" SDE as part of an instance's state. The value of the SDE can be retrieved through appropriate operations defined in the Grid-Service portType.

Comments on Grid Services
OGSA is the Grid community's effort to create a services-oriented platform for building large-scale distributed applications. OGSI constructs the foundations of the OGSA platform on top of Web services.

In making some of the characteristics it introduces a mandatory part of the infrastructure, OGSI has moved away from the vision of the Web services infrastructure as a collection of interoperable components that are built on top of widely accepted standards. Instead, OGSI brings a flavor of object orientation a la CORBA and J2EE into Grid services (e.g., service data and Grid service instances) and introduces noncompliant extensions to the WSDL standard (e.g., portType inheritance and service data).

It's my opinion that OGSI encourages the development of fine-grained, component-based architectures while Web services promote a coarse-grained approach. Due to its nonstandard features, like service data, mandatory statefulness, GSR, and factories, the OGSI specification deviates from common Web services practices. Then again, OGSI is an application of the Web services concept to the Grid application domain so experience may prove that the introduced characteristics are indeed required.

The Future
The OGSI working group has completed its work on version 1.0 of the specification. In the future, more effort will be focused on defining higher-level services for OGSA and, of course, building applications.

The Grid community is building its infrastructure on top of Web services technologies, making the Grid a big user of the emerging standards and an excellent evaluation platform for all the specifications and tools.

Acknowledgments
Thanks to Prof. Paul Watson, Dr. Jim Webber, OGSI working group, and OGSI-Primer working group.