Introducing Open Grid Services
Introducing Open Grid Services
Jul. 24, 2003 12:00 AM
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.
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.
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 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
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.
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
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 implementation of the Factory portType by a Grid service instance is not mandated by the specification.
Notification and Service Groups
The implementation of the notification and service group portTypes by a Grid service instance is not mandated by the specification.
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
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 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.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week