evolution of grid computing architecture and grid adoption...

Evolution ofgrid computingarchitecture and gridadoption models

by J. JosephM. ErnestC. Fellenstein

During recent years, we have witnessed amajor paradigm shift in distributed computingprinciples, with a focus towards serviceorientation, open standards integration,collaboration, and virtualization. One particulararea of interest centers on the evolution ofgrid computing principles into the mainstreamof distributed computing and Web services. Inthis paper, we focus our analysis on thisevolution and the significance of achievingsome form of standardization of grid-computing architecture principles. This paperpresents the technology standards that aredriving major grid initiatives and explains insimple terms how these standards andtechnologies are aligned with the IBM ondemand business concepts. In addition, wediscuss the recent Web servicesspecifications related to stateful resources(i.e., resources whose behavior is defined withrespect to their underlying state) and howthese standards relate to grid computing.We conclude with discussions exploring majoraspects of grid-computing adoption modelsand some significant attributes that influencethe transformation, collaboration, andvirtualization features of these models.

A distributed system consists of a set of softwareagents that work together to implement some in-tended functionality. Because the agents in a distrib-uted system do not operate in a uniform processingenvironment, they must communicate by protocolstacks that are intrinsically less reliable than directcode invocation and shared memory. Grid-comput-

ing principles focus on large-scale resource sharingin distributed systems in a flexible, secure, and co-ordinated fashion. This dynamic coordinated shar-ing results in innovative applications making use ofhigh-throughput computing for dynamic problemsolving.

In this paper, we analyze the core initiatives that willenable grid computing to evolve into a service-ori-ented computing platform. These initiatives arebased on the concepts of merging grid architectureswith service-oriented architectures (SOAs). Our ap-proach is based on the emergence of open standardsplatforms to build resource collaboration models,combined with the ability to simply construct dy-namic applications that leverage virtualized re-sources. This approach allows for the implementa-tion of well-defined grid adoption models and theirapplication in on demand business environments.

One of the basic requirements of a grid system isthe ability to provide the high-level quality of ser-vice (QoS) needed for a satisfactory user experience.Thus, QoS validation must exist as a basic featurein any grid system, as measured by the available re-source metrics. These metrics include response timemeasurements, aggregated event performance mon-itoring and measurements, security fulfillment, re-source scalability, availability, autonomic features,fail-over mechanisms, and networking services (in-

�Copyright 2004 by International Business Machines Corpora-tion. Copying in printed form for private use is permitted with-out payment of royalty provided that (1) each reproduction is donewithout alteration and (2) the Journal reference and IBM copy-right notice are included on the first page. The title and abstract,but no other portions, of this paper may be copied or distributedroyalty free without further permission by computer-based andother information-service systems. Permission to republish anyother portion of this paper must be obtained from the Editor.

JOSEPH, ERNEST, AND FELLENSTEIN 0018-8670/04/$5.00 © 2004 IBM IBM SYSTEMS JOURNAL, VOL 43, NO 4, 2004624

cluding network circuit provisioning and eventcorrelation).

There are important architectural implications re-lated to the grid adoption model, in light of the factthat all distributed systems require developers (ofboth infrastructure and applications) to consider theunpredictable latency of remote access. This meansdevelopers must take into account issues of concur-rency and the possibility of partial failure.1 Grid com-puting aims to resolve these complexities of distrib-uted computing through a well-defined architecturethat is aligned with SOA, autonomic-computing prin-ciples,2 and open standards for integration andinteroperability.

The remainder of the paper is structured as follows.In the next section, we review grid architecture evo-lution and its alignment with SOAs. We then detailthe standards that are driving this architecture plat-form, especially as they relate to IBM�s on demandbusiness3 and grid4 initiatives. In the last section, wediscuss the grid adoption model, including the stan-dards and attributes that are driving the capabilitiesof this adoption model. Some material presented inthis paper was taken from Reference 5.

Evolution of grid architecture. In 1998, it was statedthat “a computational grid is a hardware and soft-ware infrastructure that provides dependable, con-sistent, pervasive, and inexpensive access to high-endcomputational capabilities.”6 This definition was pri-marily centered on the computational aspects ofgrids. Later iterations broadened this definition withmore focus on coordinated resource sharing andproblem solving in multi-institutional virtualorganizations.7

The grid problem. Grid computing has evolved intoan important discipline within the computer indus-try by differentiating itself from distributed comput-ing through an increased focus on resource sharing,co-ordination, manageability, and high performance.The focus on resource sharing is called the grid prob-lem, which can be defined as the set of problems as-sociated with resource sharing among a set of indi-viduals or groups. This sharing of resources, rangingfrom simple file transfers to complex and collabo-rative problem solving, is accomplished under con-trolled and well-defined conditions and policies. Inthis context, the critical problems are resource dis-covery, authentication, authorization, and accessmechanisms. Resource sharing is further compli-cated when a grid is introduced as a solution for util-

ity computing,8 where commercial applications andresources become available as shareable and on-de-mand resources. This concept of commercial on-de-mand utility grid services adds new, more difficultchallenges to the already complicated grid problemlist,7 including service level features, accounting, us-age metering, flexible pricing, federated security,scalability, and open-ended integration.

Virtual organizations. A virtual organization (VO) isa dynamic group of individuals, groups, or organi-zations who define the conditions and rules for shar-ing resources. The concept of the VO is the key togrid computing. All VOs share some characteristicsand issues, including common concerns and require-ments that may vary in size, scope, duration, soci-ology, and structure. The members of any VO ne-gotiate the sharing of resources based upon the rulesand conditions defined by the VO, and the membersthen share the resources in the VO�s constructed re-source pool.9

Assigning users, resources, and organizations fromdifferent domains to a VO remains one of the keytechnical challenges in grid computing today. Thistask includes the determination of a definition of re-source discovery mechanisms, such as identificationand application of appropriate resource-sharingmethods, specification and application of rules andconditions for member assignment, security feder-ation or delegation, and access control among theparticipants.

Common characteristics typically exist among thecompeting and sometimes distrustful participantsthat contributed to the formation of the VO. Thesemay include the following:7

1. Concerns and requirements exist concerning re-source sharing.

2. Resource sharing is conditional, time-bound, andrules-driven.

3. The collection of participating individuals and/orinstitutions is dynamic.

4. Sharing relationship among participants is peer-to-peer in nature.

5. Resource sharing is based on an open and well-defined set of interactions and access rules.

The above characteristics and requirements lead tothe definition of an architecture for VO establishmentand management and for resource sharing among par-ticipants. We examine this architecture in the follow-ing section, exploring its scope and characteristics.

IBM SYSTEMS JOURNAL, VOL 43, NO 4, 2004 JOSEPH, ERNEST, AND FELLENSTEIN 625

Grid architecture model. A new architecture modeland technology has been developed for the estab-lishment and management of cross-organizationalresource sharing. This new architecture, called gridarchitecture, identifies the basic components of a gridsystem. The grid architecture defines the purpose andfunctions of its components, while indicating howthese components interact with one another.7 Themain focus of the architecture is on interoperabilityamong resource providers and users in order to es-tablish the sharing relationships. This interoperabil-ity, in turn, necessitates common protocols at eachlayer of the architectural model, which leads to thedefinition of a grid protocol architecture as shownin Figure 1.

This protocol architecture defines common mech-anisms, interfaces, schema, and protocols at eachlayer, by which users and resources can negotiate,establish, manage, and share resources. Figure 1shows the component layers of the grid architectureand the capabilities of each layer. Each layer sharesthe behavior of the underlying component layers.The following describes the core features of each ofthese component layers, starting from the bottomof the stack and moving upward.

● Fabric layer—The fabric layer defines the inter-face to local resources, which may be shared. Thisincludes computational resources, data storage,networks, catalogs, software modules, and othersystem resources.

● Connectivity layer—The connectivity layer definesthe basic communication and authentication pro-

tocols required for grid-specific networking-service transactions.

● Resource layer—This layer uses the communica-tion and security protocols (defined by the con-nectivity layer) to control secure negotiation, ini-tiation, monitoring, accounting, and payment forthe sharing of functions of individual resources.The resource layer calls the fabric layer functionsto access and control local resources. This layeronly handles individual resources, ignoring globalstates and atomic actions across the resource col-lection pool, which are the responsibility of the col-lective layer.

● Collective layer—While the resource layer managesan individual resource, the collective layer is re-sponsible for all global resource management andinteraction with collections of resources. This pro-tocol layer implements a wide variety of sharingbehaviors using a small number of resource-layerand connectivity-layer protocols.

● Application layer—The application layer enablesthe use of resources in a grid environment throughvarious collaboration and resource accessprotocols.

Thus far, our discussions have focused on the gridproblem in the context of a virtual organization andthe proposed grid computing architecture as a sug-gested solution to this problem. This architecture isdesigned for controlled resource sharing with im-proved interoperability among participants. In con-trast, emerging architectures help the earlier-definedgrid architecture quickly adapt to a wider (and stra-tegically important) technology domain.

SOA model. A service-oriented architecture (SOA)is a specific type of distributed system frameworkwhich maintains agents that act as “software ser-vices,” performing well-defined operations. We de-fine a SOA as a loosely coupled architecture with aset of abstractions relating to components granularenough for consumption by clients and accessibleover the network with well-defined policies as dic-tated by the components.

Thus, a service acts (in some manner) as a user-fac-ing software component of an application or re-source. This paradigm of functionality enables theusers of that application (or resource pool) to be con-cerned only with the operational description of theservice. In addition, SOA stresses that all services havea network-addressable interface and communicatevia standard protocols and data formats calledmessages.

Figure 1 The layers of the grid architecture and its relationship to the Internet Protocol architecture

Grid Protocol Architecture

Internet Protocol Architecture

Fabric

Connectivity

Resource

Collective

Application

Link

Internet

Transport

Application

Reprinted with permission of Ian Foster

JOSEPH, ERNEST, AND FELLENSTEIN IBM SYSTEMS JOURNAL, VOL 43, NO 4, 2004626

The Web Services Architecture (WSA) helps to en-able and define SOA, where services interact by ex-changing XML (Extensible Markup Language) mes-sages, as shown Figure 2. The main characteristicsof the WSA are:

● It is based on XML technologies such as XML In-formation Model,10 XML Base, and XML Schema.11

● It is independent of the underlying transport pro-tocols (e.g., HTTP [HyperText Transfer Protocol]or SMTP [Simple Mail Transfer Protocol]) and thetransport selected as a runtime bindingmechanism.

● It uses XML message exchanges, while providingthe extensibility model for this message exchangepattern to adapt to various message interchangerequirements (e.g., security, reliability, correlationand privacy.) These interoperable messages couldbe created using Simple Object Access Protocol12

(SOAP) and SOAP extensions. SOAP extensionmechanisms and XML information models are usedto construct Web services extensions.

● Service capabilities are described using descrip-tion languages such as Web Services DescriptionLanguage (WSDL).

● It uses the service discovery, workflow choreog-raphy, and transaction/state management that arebuilt on the XML capabilities and lower-layer spec-ifications in the architecture layer.

The emergence of the SOA concept helps grid re-sources to advertise their capabilities through stan-dard interfaces defined as part of their service ex-tensions. This enables grid users to integrate theresources through open-standards interfaces. In ad-dition, the operational functions of each layer in thegrid architecture can be abstracted to enable easierintegration across all the layers. This service abstrac-tion of each layer of the grid architecture is shownin Figure 3.

In the next section, we discuss the architectural stan-dardization initiatives for the alignment of the SOAand the grid architecture. This discussion focuses onhow these architectures complement each other andon the major open standards that assist this coor-dination and its evolution.

Defining an open-standards platform for grid com-puting. In order to achieve true distributed resourcesharing across heterogeneous and dynamic VOs, grid-computing technologies require several improve-ments in alignment with other computing technol-ogies. In the early days of grid computing, a numberof custom middleware solutions were created to solvethe grid problem, but this resulted in non-interop-erable solutions and problematic integration amongthe participants. As stated earlier, the new wave of

Figure 2 The Web Services Architecture (WSA) and the respective layers in the WSA framework

Security Management

TransportHTTP, SMTP, etc.

XML TechnologiesXML, XML Schema, DTD

Messages

DescriptionsWSDL/DAML

ProcessesDiscovery, Aggregation, Choreography

SOAP

SOAP ExtensionsWS-Reliability, WS-Policy, WS-Correlation, WS-Transactions.....

Reprinted with permission of the Pearson Technology Group.


grid computing focuses on the easier integration, se-curity, and QoS aspects of resource sharing.

Foster et al.13 described the Open Grid Services Ar-chitecture (OGSA) as a solution to the above prob-lem. This architectural concept is a result of the align-ment of existing grid standards with emerging SOAs,as well as with the Web. OGSA provides a uniformway to describe grid services and define a commonpattern of behavior for these services. It defines grid-service behavior, service description mechanisms,and protocol binding information by using Web ser-vices as the technology enabler. This architectureuses the best features from both the grid-computingcommunity and the Web-services community.

OGSA architecture and goal. OGSA is a layered ar-chitecture, as shown in Figure 4, with clear separa-tion of the functionalities at each layer. As seen inthe figure, the core architecture layers are the OpenGrid Services Infrastructure (OGSI) and OGSA plat-form services. The platform services establish a setof standard services including policy, logging, ser-vice level management, and other networking ser-vices. High-level applications and services use theselower-layer platform core components to become apart of a resource-sharing grid.

The Global Grid Forum14 (GGF) has adopted theOGSA platform. There have been many activities inthe GGF to define the use cases and core platformservices, but there has been little activity related tothe platform binding and resource modeling and pro-filing areas. A detailed discussion of OGSA, infrastruc-

ture, and platform services can be found in Refer-ence 5.

The IBM vision of the OGSA is summarized in Figure5. This is a layered architecture, with the lowest layercomprising the basic IT resources, such as servers,storage, and network services. This includes the hard-ware and corresponding software support for oper-ating systems, subsystems, and the components thatcontrol them.

The layer above the IT resources handles functionssuch as security, workflow, databases, file systems,directories, and messaging software. These are typ-ically implemented as general-purpose middlewarecomponents. This middleware generally exploits thelower layer of physical resources and provides func-tions that can be abstracted and “virtualized” asservices.

Grid services standardization

A grid service is (in practice) a Web service that con-forms to a particular set of coding practices, namely,a set of XML coding conventions in the form of stan-dards. For example, grid services can be defined interms of standard XML-based WSDL, with perhapssome minor XML language extensions. These gridservices can now take advantage of standard Webservices binding technologies (for messaging, reli-ability, transactions, and security), such as SOAP, WS-ReliableMessaging (Web Services Reliable Messag-ing), WS-Transaction (Web Services Transaction)and WS-Security (Web Services Security). Grid ser-

Figure 3 Service-oriented grid architecture with service interfaces

Fabric

Connectivity

ResourceService

Collective

Application

Service

Service

Service


vices indeed look like Web services, especially froma programmatic view.

As stated earlier, all of the resources (physical or log-ical) in OGSA are modeled as services. These servicesare built on top of the SOA, and more specificallythe WSA. This enables a grid service to use the ca-pabilities of the message model, service descriptions,and discovery. Web services standards have evolvedto enable these services to extend capabilities for se-cure and reliable transactions. In the next section,we explore the evolution of Web services standardsand the fundamental principles behind these plug-gable extended standards.

Evolution of Web services standards. Standards arecritical to interoperability within a distributed com-puting platform, especially an advanced platform thatprovides a service-oriented, loosely coupled, cross-platform programming model. Standards enableplatform services to more simply integrate with themiddleware and infrastructure. This, in turn, alsohelps to reduce the complexity of heterogeneous andcross-enterprise orchestration and integration.

Figure 6 illustrates some of the evolving standardssupported by industry leaders such as IBM and Mi-crosoft.15 These standards share the following ele-ments:

1. The XML data model— As defined by W3C**(the World Wide Web Consortium), the XML

data model, or XML information set, forms thecore of all XML specifications, including SOAP andWSDL. This common base allows more adaptabletools and XML processors to be created.

2. Modularity—SOAP provides an enveloping andprocessing mechanism for XML messages to beexchanged. SOAP provides a transport-indepen-dent data format for the transfer of XML mes-sages based on the SOAP encoding format asspecified by the SOAP specification or by usingXML schema. Messages encoded by using theXML schema are recommended and are oftenreferred to as document/literal messages.

3. Decentralization and federation—A constraintagreement is a regulatory agreement between aWeb services client and a service provider on theformat of message to be exchanged. Constraintagreements exist between the parties involvedin any Web services integration. The partiesagree on the syntax and semantics of the mes-sages being exchanged although they may dis-agree on the software accepting the messages.They may also disagree on the programming lan-guages used to build the system, the operatingsystems used, and the databases used. This is abenefit as it does not force issues of configura-tion conformance on all participants.

This concept of decentralization allows theparties involved to make their own decisions on

Figure 5 OGSA architecture with Web services-enabled service interface

Applications

Servers

OGSA Enabled

Security

OGSA Enabled OGSA Enabled OGSA Enabled OGSA Enabled OGSA Enabled OGSA Enabled

OGSA Defined Services

Workflow

OGSA Enabled OGSA Enabled

Directory MessagingFile SystemsDatabase

Web Services

NetworkStorage


all aspects of message processing, includingsecurity, policy requirements, and processing.At the same time, the concept of federationallows these parties to exchange informationin meaningful formats. For example, parties canexchange messages even though they disagreeon internal security implementation mecha-nisms.

4. Application and transport neutrality—This is abinding-level decision between the service andthe requestor. This binding agreement is inde-pendent of the message being exchanged. Theapplication neutrality comes from the fact thatthe parties are not defining any specific messageexchange protocol but instead are defining stan-dards-based XML messages that need to beexchanged.

5. Open standards—Most of the specificationsand standard protocol definitions mentionedhere are being submitted to various standardsauthorities, including OASIS (Organization forthe Advancement of Structured InformationStandards) and W3C. Later in this paper, we dis-cuss some of the standards bodies that are play-ing a major role in the grid standardizationprocess.

As seen in Figure 6, the major building blocks iden-tified by these plug-and-play extension standards in-clude the facilities for message-level security, ex-changing transaction-aware messages, messageexchange coordination among participants, and re-

liable message exchange patterns. Other facilities in-clude addressing mechanisms, service and messagepolicies for proper message handling, meta-data in-formation exchange, and a notification frameworkfor consumers and producers exchanging messages.

In the following section, we focus our attention ongrid services and explore the standards that play amajor role in this area.

Grid services as Web services. There are two corestandards that are available in the grid standardiza-tion area. These are OGSI and Web Services Re-source Framework (WSRF).

The OGSI standard. The base component of theOGSA architecture is OGSI. This is a grid software in-frastructure standard based on the emerging Webservices standards. The goal of OGSI is to providemaximum interoperability among OGSA softwarecomponents. Based on the OGSI specification,17 a gridservice instance is a Web service that conforms toa set of conventions expressed by WSDL as serviceinterfaces, extensions, and behaviors. A grid serviceprovides the controlled management of the distrib-uted and often long-lived state that is commonly re-quired in sophisticated distributed applications.

Figure 7 shows the layering of the OGSI componentsin a Web service with new interfaces and behaviors.The most notable point is the extension of WSDL toprovide additional state data description mecha-nisms. In addition to this, the specification is a setof behaviors and interfaces to support service life-

Figure 6 Web services extensions

WS

-Met

adat

aExc

hang

e

WS

-Coo

rdin

atio

n

WS

DL

XM

L S

chem

aBPEL4WS

WS-Notification

WS-Policy

WS-Privacy WS-Federation

WS-ReliableMessaging

WS-Transaction

WS-Authorization

WS-SecureConversation WS-Trust

SOAP

WS-Security

WS-Addressing

XML Information Set

Transport Protocols


cycle stages: for example, service-level management,collection management, state-change notifications,service creation mechanisms, and instance-referencemanagement.

Message-level interoperability is a key feature of thisstandard, and it is achieved by using XML as the coremessage format and schema. One of the require-ments of the services defined by OGSI is the abilityto describe the concepts of state data, life-cycle prop-erties, and instance behaviors using an OGSI descrip-tion model, which is in fact a combination of WSDLand the OGSI GWSDL5,16 (Grid Web Services Defi-nition Language).

The WSRF standard. WSRF is a collection of speci-fications to support grid services or other stateful re-sources (resources whose behavior is defined withrespect to their underlying state) and is comparableto OGSI. There are many motivations behind theWSRF specifications.17 As seen in Figure 8, the mostnotable contribution is the intersection of grid com-puting and Web services standards and their align-ment with SOA principles.

This alignment will continue to help define openstandards through interoperable and compatibleplug-and-play service extensions to the grid archi-tectures, thereby increasing acceptance and facili-tating integration. Through this alignment with theWeb services stack, grid services can use existing Webservices standards, such as WS-Notification,18 WS-Addressing,19 and WS-Security,20 and build exten-

sions for extended capabilities such as service statedata, lifetime, grouping, and reference management.

In the previous discussion, we described grid servicesas service representations of resources. These re-sources could be stateful or stateless (a resourcewhose behavior is not affected by stored behavior).Normally, grid services are assumed to representsome resources that have state. In the following sec-tions, we will suggest how to manage the context inthe case of a stateful resource. This discussion in-troduces aspects of the WS-Resource standard andthe new modeling concepts relating to theseresources.

Introduction to WSRFThere are many motivations behind the WSRF spec-ifications. The most notable contribution of WSRF isto bring grid and Web services standards together.This requires the alignment of WSRF with SOA prin-ciples. This alignment helps to further define open-standards, interoperable, and plug-and-play serviceextensions to the grid architecture. It has been notedthat the OGSI specification, as opposed to WSRF, tendsto be more object-centric, as a complex set of con-cepts with an overutilization of XML schemas; someargue that its extensibility features are not well suitedfor existing Web services tools.21

Another motivating factor is the convergence of gridservices to align with existing languages, program-ming models, tools, and technology directions in Webservices, systems management, and on demand com-puting. Some of the best examples of this conver-

Figure 7 Open Grid Services Infrastructure (OGSI) components

XM

L S

chem

a

WS

DL

GW

SD

L

SOAP

XML Information Set

Transport Protocols

Non-SOAP

Open Grid Services Infrastructure

LifeCycle

Notification

Factory

HandleMap

Service Group

State Management

Figure 8 Web Service Resource Framework with WS specifications

WS

-Met

adat

aExc

hang

e

WS

DL

XM

L S

chem

a

SOAP

XML Information Set

Transport Protocols

WS-Addressing

WS-Security

WS-Notification

WS-RenewableReferences

WS-BaseFaults

WS-ResourceProperties

WS-ServiceGroup

WS-ResourceLifetime


gence are in Web Services Distributed Management(WSDM) and in IBM�s on demand infrastructure vir-tualization areas.

The WSRF specifications are built on top of the im-plied resource pattern, as described in the followingsection. These extended sets of specifications nowenable a stateful resource to manage its lifetime, sendand receive notification on state changes, exposestate data as XML documents, and manage faults.

Implied resource pattern for stateful resources. Theimplied resource pattern22 addresses the relation-ship between Web services and stateful resourcesthrough a set of conventions expressed through com-posable Web services technologies such as the WS-Addressing standard. (By “composable,” we refer tothe Web services set of extensibility points, whichenables composing multiple Web services specifica-tions to enable more advanced features.) The re-questor identifies a stateful resource through the WS-Addressing mechanism called the endpoint reference(EPR). The EPR contains enough information to dis-patch the correct endpoint through the EPR prop-erties. This is a pattern of message exchange withthe implicit resource identifier in the context of mes-sage (using WS-Addressing reference properties) touniquely identify the resource with which to com-municate. A stateful resource that is taking part inthis implied resource pattern is called theWS-Resource.

WS-Addressing. This capability provides transport-neutral mechanisms for locating Web services.19 Itis provided by the specification, utilizing the follow-ing constructs: a flexible and extendable EPR descrip-tion model, a set of SOAP message headers (SOAP

features), and rules to map these reference elementsto the SOAP header elements.

Normally, Web services are invoked by the serviceendpoint information that is provided by the WSDL.For example, a WSDL service port has a location ad-dress, which identifies the endpoint. This informa-tion is suitable in most cases, with the exception ofstateful Web services and cases that add more dy-namic information to the address (instance informa-tion, policy, complex binding, and so on). This re-quires a client or runtime system to uniquely identifya service at runtime, based on this runtime informa-tion. This binding-specific information may includea primary key, unique identifier, and so on. Currently,there is no standard way by which this informationcan be exchanged and then mapped to the runtimeengine while the service is accessed. The WS-Ad-dressing specification addresses this problem by pro-viding a lightweight mechanism for identifying anddescribing the endpoint information and mappingthat information into the SOAP message headers.

The WS-Addressing specification standardizes therepresentation of the address of a Web service de-ployed at a given network endpoint, provides a WS-Addressing EPR that is an XML serialization of a net-work-wide pointer to a Web service, and providesan EPR that contains a service address (wsa:Address),meta-data associated with the Web service (such asservice description information [WSDL]), policy in-formation related to the usage of the service, andreference properties (wsa:ReferenceProperties),which can be used to identify a specific stateful re-source instance associated with the Web service atthe endpoint address.

WS-Resource. This is a stateful resource such as diskstorage, a computer system, an operating system, ora shopping cart. Resources are identified as Web ser-vices resources by participating in the implied re-source pattern (i.e., conforming to the defined pat-tern of interactions for stateful objects). The WS-Resource represents both the stateful resource andan associated Web service.

A WS-Resource has a network-wide EPR to identifythe Web service and a set of reference properties touniquely identify the specific resource through theWS-Addressing reference properties. For example,Figure 9 shows three computer system resources. Itshows a service facade Web service with a network-wide endpoint. Each computer system is identifiedby using the reference properties in WS-Addressing.

Figure 9 A relationship model showing the WS-Resource and associated Web service

WSDLWS-Resource

Computer System Service A

(facade)

Computer System 1

Computer System 3

Computer System 2


The content of the identity information for the WS-Resource is binding-specific, and the service re-questor should not interpret that content. This iden-tity information, which is supplied along with theSOAP header, is used by the Web service facade toidentify the correct resource. A WS-Resource mayimplement multiple interfaces and can associate mul-tiple Web services facades with different EPRs.

The state data of the stateful resource can be exposedto the service requestor through resource propertydocuments (XML document views). Each stateful re-source has a life cycle with a well-defined semanticsassociation for its creation and destruction. The iden-tity of a resource is attached to it when it is created.

WS-Notification. This is the event-driven interactionpattern that is commonly used for interobject com-munications.18 Examples exist in many domains, forexample, in publish/subscribe systems provided bymessage-oriented middleware vendors, or in systemand device management domains. This notificationpattern is being more widely used in a Web servicescontext.

The WS-Notification standard is a family of relatedwhite papers and specifications that define a stan-dard Web services approach for message notifica-tion, using a topic-based publish/subscribe pattern.It includes standard message exchanges to be imple-mented by service providers that wish to participatein notifications, standard message exchanges for anotification-broker service provider (allowing pub-lication of messages from entities that are not them-selves service providers), operational requirementsexpected of service providers and requestors that par-ticipate in notifications, and an XML model that de-scribes topics (i.e., items of interest for subscriptions.)

The WS-Notification family of documents includesa white paper (see Reference 18) as well as threenormative specifications: WS-BaseNotification,23

WS-BrokeredNotification,24 and WS-Topics.25 WS-BaseNotification defines the Web services interfacesfor notification producers and notification consum-ers. This includes standard message exchanges to beimplemented by service providers that wish to act inthese roles, along with operational requirements ex-pected of them. WS-BrokeredNotification defines theWeb services interface for the notification broker.A notification broker is an intermediary, which,among other things, allows publication of messagesfrom entities that are not themselves service provid-ers. It includes standard message exchanges to be

implemented by notification-broker service provid-ers, along with operational requirements expectedof service providers and requestors that participatein brokered notifications. WS-Topics defines a mech-anism to organize and categorize topics. It definesthree topic expression dialects that can be used assubscription expressions in “subscribe request” mes-sages and other parts of the WS-Notification system.It further specifies an XML model for describingmeta-data associated with topics.

The implied resource pattern is used to describe astateful resource interaction. This scenario is shownin Figure 10 and involves the following steps:

1. Create a stateful resource with a specific iden-tity26 and a service interface.

As shown in the specific scenario in Figure 10,we have identified three computer systems,which are stateful with codified state elementssuch as memory, CPU version, bus speed, and soon. These resources are stateful in nature andtheir identities are assigned by the runtime man-ager during their creation. In addition, there isa Web service for these resources with uniqueendpoint information (codified in WS-Address-ing). The identity of each resource is unique inthe domain of the associated Web service, andthere is no need for it to be globally unique.

2. Service requestors interact with the stateful re-sources through implied resource patterns.

A service requestor can interact with a statefulresource through the context established by WS-Addressing and its reference properties. TheWS-Addressing EPR contains the network ad-dress (logical or physical) of the resource Webservice, and the EPR reference properties (wsa:ReferenceProperties) contain the additionalcontext information about the resource.

The above pattern of interaction with the resourceis implicit. That is, the requestor does not providethe identity of the resource as an explicit parameterin the body of the request message; instead, the con-text is established through message headers, as in-dicated by the EPR reference properties. The result-ing SOAP message is shown in Figure 11.

Figure 1227 shows the convergence of grid and Webservices standards. The technology gap and the pro-


gramming model differences are narrowing througha standards convergence model that is movingtowards a common framework. This has been notedin key areas such as Web services extension spec-ifications, WSDL, and WSRF.

In the following, we describe the new set of standardsthat have been recently introduced to describe gridservices, using the above implied resource patterns

for stateful resources. The WSRF specifications thatare of interest for our discussion are WS-ResourceProperties, WS-ResourceLifetime, and WS-Service-Group. We examine these new standards in detailand discuss their relationships to the concept of gridservices.

WS-ResourceProperties. Every grid resource hassome form and state associated with it. This form

WSDL

WS-Resource

Computer System Service A

Computer System 1

Computer System 3

Runtime Environment

Web Service

Figure 10 Scenario showing the implied resource pattern associated with a WS-Resource

<wsa:EndpointReference><wsa:Address>http://test.org/ComputerSystemService</wsa:Address><wsa:ReferenceProperties> <tns:resourceID> C2 </tns:resourceID></wsa:ReferenceProperties></wsa:EndpointReference>

Endpoint reference containing a WS-Resource context

<wsa:EndpointReference><wsa:Address>http://test.org/ComputerSystemService</wsa:Address></wsa:EndpointReference>

Endpoint reference

Disk Storage

Client

1

2

Computer System 2

Figure 11 A SOAP message with a WS-Resource identity

<soap:Envelope> <soap:Header> <wsa:Action> …… </wsa:Action> <!— The action to perform e.g., operation name to invoke - -> <wsa:To> http://test.org/ComputerSystemService </wsa:To> <!— Web service end-point - -> <tns:resourceID> C </tns:resourceID> <!—resource identifier - -> </soap:Header> <soap:Body>

… some message </soap:Body></soap:Envelope>


and state specification constitutes a message schemathat defines and exposes these properties of a re-source, as part of the Web services interfaces, toother resources. These properties may be a part ofthe resource�s state (both logical and physical). Meta-data about the resource and stateful information maybe presented upon request.

This specification does not dictate exactly how thevalues of these properties are constructed. These val-ues may in fact be in the resource, or they may befrom external sources. They are exposed to the re-questor as XML documents. In addition, this spec-ification defines a set of standard message exchangepatterns that allow the requestor to query, insert, andupdate the properties of a resource. As shown in Fig-ure 13, the computer system resource exposes itsstate information through a well-defined set of in-terfaces, as defined by the exposed port types. A cli-ent could use these exposed operations to find, ac-cess, and modify the resource properties.

As shown in the XML code fragment of Figure 14,the “ComputerSystem” resource exposes a propertycalled “current_memory.” This property is definedas a part of the global XML schema element (e.g.,“GetComputerSystemMemory”) and referenced aspart of the WSDL:portType open attribute content.

A service requestor can retrieve this property fromthe resource at runtime as an XML document viewby using the “GetResourcePropertyRequest” or“GetMultipleResourcePropertiesRequest” opera-tions associated with the Web service. The GetRe-sourcePropertyRequest message is shown in the XMLcode fragment of Figure 15. This request is inter-preted by the Web service, which in turn retrievesthe necessary resource property value from the un-derlying resource. A service requestor can insert, de-lete, or update a resource property with a new value.The response is returned to the requestor, as shownin the XML code fragment of Figure 16.

Finally, this specification provides facilities for que-rying, by sending query expressions to retrieve frag-ments of resource properties. The format of this typeof query expression is shown in the XML code frag-ment of Figure 17. The dialect attribute defines thequery expression language of choice, such as XPath,XQuery, or SQL, and the query expression definesthe query to be applied to the resource properties.

It is possible for a service requestor to request no-tification of changes (e.g., updates, deletions, and in-

sertions) made to values of one or more resourceproperty elements of a given WS-Resource. The re-questor is able to take part in this notification pro-cess through the Web service associated with theWS-Resource.

WS-ResourceLifetime. A grid service may be tran-sient, created with a specified lifetime. This statefulresource�s lifetime could be negotiated and con-trolled by its clients. This helps to provide a con-trolled clean-up mechanism for resources. The spec-ification defines a set of standard message exchangepatterns for time-based immediate destruction of aservice. This service lifetime management offers ex-plicit destruction capabilities to a service requestoror a specific service. In addition, it provides the ca-pability for scheduled destruction at a future time.The semantics of destruction of a service are con-trolled by the security and service container policies.The interaction model ensures that once the resourceis destroyed, the resource EPR is no longer valid andthe requestor will not be able to connect to the re-source using the same EPR.

This specification defines a set of service propertiesand two types of service destruction message pat-terns. The properties of a service that are used tomanage its lifetime are InitialTerminationTime, Cur-rentTime, and TerminationTime. The identified ser-vice destruction message exchange patterns for life-time management capabilities are:

Figure 12 Standards convergence graph

WSRFWSDL 2

WSDMWSSOAP 1.2

WSDL 1.1SOAP 1.1

OGSIGWSDL

RPCCORBA

SOAP 1.0

1998 2002 2003 2004

CMM

Technology standard gap

Reprinted with permission from Ian Foster


1. Immediate destruction—A resource that is tak-ing part in the implied resource pattern couldsend a message (DestroyRequest) to the service,in order to immediately destroy the resource.This message could be of the format shown in

Figure 18. The Web service that accepts this mes-sage may destroy the implied resource, or itcould return an exception.

2. Scheduled destruction—The resource that is tak-ing part in the implied resource pattern (by im-

Figure 13 A computer system WS-Resource with WS-ResourceProperties interfaces

Delegation

Resource Properties

GetResourceProperty

SetResourceProperties

WS-Notification<<PropertyChange>>

GetMultipleResourceProperties

QueryResourceProperties

Facade

Computer System C1

Service Requestor

CurrentmemorySetResourceProperties(portType)

QueryResourceProperties(portType)

GetResourceProperty(portType)

GetMultipleResource Properties(portType)

Computer SystemService(Web Service)

Figure 14 A WSDL message with a portType attribute

<xsd:element name="GetComputerSystemMemory" xmlns:tns="http://test.org/computersystem" ><xsd:element ref="tns:current_memory" />

</xsd:element><xsd:element name="current_memory" value="xsd:integer" />

<wsdl:portType name="ComputerSystem" wsrp:ResourceProperties="tns:GetComputerSystemMemory"><operation name="start" .../></wsdl:portType>

Figure 15 A WS-ResourceProperties message with a GetResourcePropertyRequest operation

<wsrp:GetResourcePropertyRequest xmlns:tns="http://test.org/computersystem" > tns:current_memory <!—name of the property to retrieve - -> </wsrp:GetResourcePropertyRequest>


plementing the scheduledTermination interface)could accept a message (SetTerminationTime-Request) to destroy the resource after a spec-ified period of time as indicated in the message.

The time synchronization in a distributed applica-tion is complex. The WS-ResourceLifetime speci-fication provides a capability through which the ser-vice requestor could get the current time of a service(using the CurrentTime resource property).

In addition to the above capabilities, the Web ser-vice associated with the WS-Resource could be a no-

tification producer (as defined in the WS-Notifica-tion specification). Notification producers providenotification topics to allow service requestors to sub-scribe for notification about the destruction of aresource.

WS-ServiceGroup. In some cases, it may be requiredto aggregate a set of Web services. This may be inorder to provide a domain-specific solution, or as asimple collection of services for indexing and otherdiscovery enablement scenarios. The WS-Service-Group specification describes a “by-reference” col-lection of Web services, where these Web services

Figure 16 A WS-ResourceProperties message return with a GetResourcePropertyRequest operation

<wsrp:GetResourcePropertyResponse xmlns:tns="http://test.org/computersystem" > <tns:current_memory> <!—an XML view of the resource property- -> 512 </tns:current_memory> </wsrp:GetResourcePropertyResponse>

Figure 17 A WS-ResourceProperties message to query, send query expressions, and retrieve fragments of resource properties

<wsrp:QueryResourcePropertiesRequest><wsrp:QueryExpression dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">

//current_memory </wsrp:QueryExpression></wsrp:QueryResourcePropertiesRequest>

Figure 18 A SOAP message involved in a lifetime destroy management function

<soap:Envelope> <soap:Header> <wsa:Action> http://test.org/ComputerSystemService/Destroy</wsa:Action> <tns:resourceID> <!—the identity of the resource to destroy- ->

C1</tns:resourceID>

</soap:Header> <soap:Body>

<wsrl:DestroyRequest/> </soap:Body> </soap:Envelope>


may constitute a WS-Resource. It also provides keymanageability interfaces to better manage entries inthe group (e.g., add, delete, and modify).

Although any Web service can become a part of thiscollection, the service group manages its individualentries as WS-Resources. It accomplishes thisthrough the use of other standards for Web services,and WS-Resource standards such as those concern-ing notification, lifetime, properties, and addressing.

In the next section, we compare the existing OGSIspecification with the concepts introduced by WSRF.

Comparison of WSRF with OGSI. Table 127 showsa one-to-one mapping of OGSI-related concepts toWSRF solutions. The most noticeable aspects of thecomparisons shown are:

● The implied resource pattern introduces the con-cept of a stateful resource (WS-Resource), and thispattern replaces the mandatory interface GridSer-vice, as defined by the OGSI specification. This en-ables all stateful resources, including grid services,to be handled through a common set of Web ser-vices tools.

● The Grid Service Handle (GSH) and Grid ServiceReferences (GSR) concepts introduced by the OGSIspecification are replaced by the Web services stan-dard WS-Addressing. GSH and GSR are encodedin the WS-Addressing specification, using EPR andreference properties. This is the most notable con-tribution of the WSRF.

● The WSRF introduces a standard notificationframework for Web services. This enables all Webservices and grid services to share notification pat-terns (i.e., standard and brokered notifications) asintroduced by the specification. This in turn en-ables the messaging providers to define a commonset of interfaces and facilities.

From our observations thus far, the remaining con-cepts that have been introduced are more specificto the grid services concept of stateful resources andtheir management than to Web services. We predictthat these composable specifications will help ser-vice providers to make a selection of the most suit-able choices for their services.

Grid adoption models

Grid computing falls into the domain of several dif-ferent research communities, depending on how thequestion, “What is a grid?” is answered. These gridcommunities include the “compute-centric,” peer-to-peer, utility, data and applications, and collabo-ration areas. Each of these communities may use adifferent model for the adoption of grid technology(i.e., a different “grid adoption model”).

The concept of grid computing is relatively new tocommercial industry. A major focus area surroundsinfrastructure virtualization while dealing with re-sources as utilities. Grid computing is one of the stra-tegic technologies for IBM.

Grid adoption (in the commercial industries) de-pends on the ability of this technology to deliverincreased business value. In this section, we focusour attention on the models for grid adoption anddescribe their basic attributes and the standards thatfacilitate the grid adoption process. The business is-sues related to the grid adoption model include keyfactors, such as leveraging existing hardware invest-ments and resources, reducing operational expenses,creating a scalable and flexible infrastructure, accel-erating development time, improving time to mar-ket, and increasing customer satisfaction and bus-iness productivity. Figure 19 shows the major factorsthat are influencing grid adoption.

Table 1 Comparison of OGSI and WSRF concepts.

OGSI WSRF

Grid service reference WS-Addressing endpoint referenceGrid service handle WS-Addressing endpoint referenceHandleResolver portType WS-RenewableReferencesService data definition and access WS-ResourcePropertiesGridService lifetime management WS-ResourceLifeCycleNotification portType WS-NotificationFactory portType Factory pattern conceptServiceGroup portTypes WS-ServiceGroupBase fault type WS-BaseFaults

Reprinted with permission of Ian Foster


An organization may do business with other orga-nizations within the enterprise or with external or-ganizations. As a result, grids may involve only in-ternal partners or both internal and external partners.The complexity of the business requirements of suchan integration depends on the virtualization require-ments, business impact, trust relationships, securityconsiderations, globalization, and time-to-market re-quirements of the enterprises involved. Based on dif-fering levels of complexity, grids for the enterprisecan be categorized as one of the following types:

● Infra-grid—This grid architecture enables optimiz-ing resource sharing within departments in one di-vision of an organization. This is a very controlledenvironment with well-defined business policies,integration, and security requirements. Becausethe management issues are contained within a sin-gle management domain, the focus can be keptprimarily on gaining technical experience. Thesetypes of grids are sometimes called “cluster grids.”

● Intra-grid—This more complex grid implementa-tion is a scenario for resource integration by us-ing the computing and data/storage resources ofvarious divisions within an organization. These

types of grids need well-defined policies for thesharing of resources within the enterprise, andvaluable experience can be gained in dealing withthe more complex security, data-sharing and re-source-sharing policies required. However, be-cause the resources are within the same enterprise,the primary focus can still be on the technical im-plementation of the policies defined. These typesof grids are sometimes called “enterprise grids”or “campus grids.”

● Extra-grid—These grids deal with sharing of re-sources, including those belonging to a trusted ex-ternal partner with whom a business relationshiphas already been established. These types of gridsare also known as “partner grids.” Because thesegrids extend outside the management domain ofa single enterprise, mutual or shared partneragreements and service-level objectives on re-source utilization are required. Establishing theseagreements provides valuable experience in writ-ing, maintaining, and managing access accordingto grid service-level agreements.

● Inter-grid—An inter-grid enables the sharing ofcomputing and data/storage resources across a

Figure 19 Grid adoption factors

• Increased requirement for value from IT investment

• Maturation of grid standards

• Expanded impact of grid technology

• Increased confidence in grid technology/capabilities

• Opportunity to involve business process improvements as part of the increasing value from IT investment

• Convergence of Web services standardization and grid standardization

• Need for direct interactions/transactions with customers, suppliers and partners

• Need for customers/suppliers and internal staff to work with the same data

Factors triggering transition to the next stage

LAN Licensing WAN Licensing

Increasing organizational complexity

Incr

easi

ng IT

com

ple

xity

VirtualizedApplications

Service Grid

Data Grid

ComputingGrid

InfrastructureOptimization

EnterpriseGrid

Infra-Grid Intra-Grid

PartnerGrid

Extra-Grid Inter-Grid


public Web in collaboration with other enterprises,potentially selling excess capacity (for example).This is more of an on-demand utility conceptionof a grid, with inherent complexities in managingservice-level requirements, security federation, andintegration. Its requirements will, in part, buildupon the experiences and critical skills gained fromthe previous grid implementation types.

The above discussion and Figure 19 accentuate thecomplexity of considerations potentially encounteredwithin any line of business and the requirements ofgrids involving complex business patterns such aspartner integration. More is known about the leftside of the continuum of the abscissa of Figure 19,as opposed to the far right side of the continuum,simply due to industry experience in grid computingto date.

A major factor that determines the adoption rate ofgrid models is the complexity of the IT infrastruc-ture required to implement a grid. In this section,we address the topic of integration of grid resources,including grid adoption in various technology do-mains. The complexity of IT integration across het-erogeneous environments is a real challenge. Thereare various factors we need to take into consider-ation, including enabling grid resources in homoge-neous and heterogeneous environments, enabling re-sources as services to grid partners, and enablingvirtualized applications to grid partners. These re-quirements at the IT level enable us to classify gridsinto various categories, with varying degrees of com-plexity at the integration level, such as:

1. Grids designed to optimize infrastructure2. “Computing grids” with virtualized processing3. “Data grids” with virtualization of data and

storage4. “Service grids” with virtualized services to en-

able easier integration5. Virtualized applications enabled by composing

resources from various partner applicationsthrough service interfaces

Figure 19 shows the levels of IT and organizationalcomplexity of various grids and the specific factorsthat prompt moving from one stage to the next inthe grid adoption process.

The combination of business and technical aspectsmentioned previously gives rise to the grid adoptionmodel framework. By considering both the techni-cal and business requirements within each cell of the

framework, clients considering grid implementationscan better anticipate and prepare for their challenges.The grid adoption framework reveals two significanttransition points. At the outset, projects primarilyfocus on IT and increasing sophistication of IT man-agement capabilities. However, the transition frominternal implementations to those involving exter-nal partners represents a significant advance and ne-cessitates the involvement of not only the IT orga-nization, but also the rest of the business.

The grid architecture and global standards have amajor role in governing the adoption of the grid inthe commercial world. Because these standards arestill evolving and are not sufficiently mature to sup-port the latter stages suggested by the adoptionframework, the framework itself will also have toevolve. These same standards will also restrict thespeed with which these latter stages can be attained.However, grid computing and on demand businessenvironments have been implemented in several ver-tical industries (e.g., finance, education, life science,telecommunications), and these implementationsseem to validate the stages suggested. The primarybenefit of the framework is to clearly articulate whatcapabilities, both in business and IT, are required be-fore an organization can successfully attain its vir-tualization goal.

Clearly, the success of grid computing depends onintegration and services orientation. The ability ofapplications to decompose their capabilities and thenexpose themselves as services is also important forstrengthening the SOA. In addition, a key to successin grid adoption is creating virtualized applicationsto solve specific VO problems by choreographing thebusiness functions exposed through services. This iswhere global standards and architecture frameworkswill help.

The standards for Web services and WSRF, alignedwith OGSA, assist in this integration. The availabilityof technology implementations to facilitate such stan-dardization is important. This includes middlewareapplication platforms, resource virtualization en-gines, workflow models, messaging and correlationsystems, and tool frameworks. Figure 20 shows ahigh-level framework view of an IBM on demand op-erating environment. The figure shows the requiredinfrastructure services such as systems, applications,and business processes at the lower layer, and ap-plication services at the higher level.


Grid standards in the on demand operatingenvironmentAn on demand business is an enterprise whose bus-iness processes—integrated end-to-end across thecompany and with key partners, suppliers, and cus-tomers—can respond with flexibility and speed toany customer demand, market opportunity, or threat.Our strategic intent is to assist clients in achievingvirtualization of on demand services and to increaseIBM’s market share in this area.

When an enterprise begins to virtualize on demandbusiness services, the complete involvement of theaffected business organizations is always required.As a result, systems development is no longer underthe complete control of the IT organization, and col-laboration of various departments within an orga-nization is critical. Similarly, before the virtualiza-tion of specific on demand business services isstarted, the projects involving business services arelargely under the control of the IT organization.

The on demand operating environment is based onthe concept of an SOA. The on demand business mod-els are built upon open standards, intended to de-fine business, applications, and systems at various lev-els within a department, across an enterprise, orspanning an entire industry.

Each element of the SOA is a service, and together,these services implement the operating environment

capabilities. These services communicate over ashared enterprise service bus (as shown in Figure 20),which provides messaging, mediation, transforma-tion, integration, and correlation capabilities. Thisintegration fabric of components is shared across de-partments, enterprises, and partners. The system-level components are integrated through virtualizedresources and services.

SOA is an area where grid computing is beginning toplay a major role. The grid adoption rate may varydepending on the environment�s integration require-ments, for example, whether it operates within anenterprise or includes external partners. Also signif-icant is the virtualization complexity, which is pro-portionate to, and dependent on, the grid applica-tion�s complexities.

Focus areas for grid standards

This section highlights some of the aspects of gridcomputing that still require some form of stan-dardization. This discussion also describes some ofthe existing standards that could be precursors tothis standardization process. Table 2 identifies anddescribes the focus of some of the importantorganizations that are playing a major role in theWeb services standardization area, includingthose related to the grid and systems manage-ment domains. These standardization efforts, aslisted in Table 3, should be aligned with aspects of

Figure 20 A high-level view of the on demand operating environment

Utility Business Service

Service Level Automation and Orchestration

Resource Virtualization Services

Infrastructure Services

USER

BUSINESS

BusinessServices

Application Services

Business ProcessServices

User Interaction Services

InformationManagement Services

Enterprise Service BusBusiness Performance Management


SOA and with the Web services standards, as sug-gested earlier.

ConclusionsThere is a natural convergence of grid services andWeb services. This convergence is occurring rightnow, and it is happening in all industries. It can beobserved in the evolutionary thinking of those peo-ple who are members of VOs and are participatingin this transformation.

The grid architecture and global standards serve amajor role in determining the adoption rate of gridsin the commercial world. These standards are stillevolving.

Grid-service conventions are nontrivial in their func-tions; they solve (in a new way) some of the funda-mental issues in distributed computing. These issuesrelate to the naming, creation, discovery, monitor-ing, and management of the lifetime of stateful ser-vices. More specifically, these conventions supportvery important distributed computing areas, includ-

ing named service instances, a two-level namingschema that facilitates traditional distributed systemtransparencies, a base set of service capabilities, in-cluding rich discovery facilities, and explicitly state-ful services with lifetime management capabilities.

Will the intersections of services and standards thatwe have discussed in this paper continue to be ac-complished in the way that is currently prevalent?Our approach enables a transformation by applyingthe full power of traditional distributed systems togrids, including naming and binding techniques,across the widest possible set of Web services. Thegrid adoption models provide an innovative meansfor accomplishing this transformation, while short-ening the time required to deliver grid computingand other capabilities of grid services.

Clearly, the emergence of grid services is an impor-tant milestone in the development of global Web ser-vices. Grid services are important because they pro-vide uniformity and consistency for many vitaldistributed system functions. The ability to apply the

Table 2 The major grid standards organizations.

Organization Standards Activities Web Site

Global Grid Forum (GGF) Grid computing, distributed computing,and peer-to-peer networking

http://www.ggf.org

World Wide Web Consortium (W3C) World Wide Web, XML, Web services,Semantic Web, XML, mobile, and voice

http://www.w3c.org

Organization for the Advancement ofStructured Information Standards(OASIS)

Electronic commerce, systemsmanagement and Web servicesextensions (WS), BPEL4WS, and portals

http://www.oasis-open.org/

Web Services InteroperabilityOrganization (WS-I)

Interoperable solutions, profiles, bestpractices, and verification tools

http://www.ws-i.org

Distributed Management Task Force(DMTF)

Systems management http://www.dmtf.org

Internet Engineering Task Force (IETF) Network standards http://www.ietf.org

European Computer ManufacturersOrganization (ECMA), InternationalOrganization for Standardization(ISO)

Language standards (C��, C#) http://www.iso.orghttp://www.ecma-international.org

Object Management Group (OMG) Model-Driven Architecture (MDA),Unified Modeling Language (UML**),Common Object Resource BrokerArchitecture (CORBA**), real-timesystem modeling

http://www.omg.org

Java Community Process (JCP) Java standards http://www.jcp.org


Table 3 Grid standards and requirements.

Area Requirements Existing Standards

Policy and service-level agreements

� Policy-based negotiation to establish grid serviceintegration

OGSA Policy, WS-Policy, and WS-Agreements Advance ReservationApplication ProgrammingInterfaces

� Service-level agreement (SLA) management acrossheterogeneous grid providers

� Advance reservation mechanisms based on customerrequirements for QoS

Job management � Identification of individual schedulable entities Resource Specification Language(RSL), Job Submission DescriptionLanguage (JSDL), Job SubmissionInformation Model (JSIM), andBusiness Process ExecutionLanguage (BPEL4WS)

� Definition of a common information model for jobexecution requirements, workflow characteristics

� Definition of scalable and extendable mechanisms for jobdescriptions

Grid scheduling � Scheduling and executing individual jobs, workflowmanagement

Grid local scheduling,Meta-scheduling, andUnified scheduler� Meta-scheduler interfaces with capabilities for resource

discovery, provisioning, resource scheduling, and jobexecution

� Creating a unified scheduler that acts as a provider for allthe grid resources in a virtual organization and as a meta-scheduler for execution of jobs

Grid servicesecurity

� Sandbox (protected domain that places tight controlsaround the execution of downloaded code) security modelfor grid service execution

WS-Security, WS-Trust, WS-Federation, Grid SecurityInfrastructure (GSI), and GenericSecurity Service extensions� Federation of security across heterogeneous resource

providers� Trust model and certificate management in a federated

environment

Grid managementmodel

� A common management model to describe and interactwith heterogeneous resources

Common Management Model(CMM), Grid MonitoringArchitecture (GMA), and WebServices Distributed Management(WSDM)

� A standards-based monitoring system with systemsmanagement capabilities.

� Performance management to meet SLA requirements forresources

� Alignment with systems management concepts

Grid datamanagement

� Access to and integration of structured and semi-structured data across grid

DAIS (Grid Data Access andIntegration), XQuery, Virtual FileSystem, Directory Service (VFSD),Grid File System (GFS), Localreplica catalog services, andGridFTP

� Discovery and storage of multitudes of data� Enhanced data mining for global information exchange� Virtual file system directory service and grid file system� Replica management

Grid and network � Handling varying load on the network infrastructure dueto heterogeneity of resources and policies applied toresources.

Grid High-Performance Network(GHPN) and Open ServiceGateway Initiative (OSGi)

� Handling the varying type data stream and its impact onthe network

� Managing dynamic network conditions� Managing the SLAs among customers and service

providers� Aligning with emerging network standards such as IP-V6� Utilizing mobile network standards

Grid architectureandprogrammingmodels

� Defining an open architecture model for the grid Open Grid Services Architecture(OGSA), Open Grid ServicesInfrastructure (OGSI), WebService Resource Framework(WSRF), Java** Network Initiative(JNI), Semantic Grid, and NewProductivity Initiative (NPI)

� Aligning the architecture with the existing/emergingprogramming models and standards

� Defining use cases, interoperable solutions and bestpractices for grid adoption


grid adoption models described in this paper servesa vital need in efforts for on demand business life-cycle planning.

Acknowledgments

The authors wish to thank George Galambos andJohn Helmbock for their work in the IBM grid adop-tion model. We also thank Ian Foster of the ArgonneNational Lab and Steven Tuecke of the Globus**Alliance for their work in the grid and WSRF areas.Finally, the authors would like to thank the review-ers for their thoughtful comments relating to an earlydraft of this paper.

**Trademark or registered trademark of Massachusetts Instituteof Technology, Sun Microsystems, Inc., Object ManagementGroup, Inc., or the University of Chicago.

Cited references and notes

1. J. Waldo, G. Wyant, A. Wollrath, and S. Kendall, A Note onDistributed Computing, Sun Microsystems Technical ReportSMLI TR-94-29 (November 1994), http://research.sun.com/techrep/1994/smli_tr-94-29.pdf.

2. IBMAutonomicComputing,http://www-3.ibm.com/autonomic/index.shtml.

3. IBM On Demand Business, http://www-3.ibm.com/e-business/index.html.

4. IBM Grid Computing, http://www-1.ibm.com/grid/.5. J. Joseph and C. Fellenstein, Grid Computing, IBM Press,

Pearson Education Publishing, Pearson Technology Group(2003).

6. I. Foster and C. Kesselman, The Grid: Blueprint for a NewComputing Infrastructure, Morgan Kaufmann Publishers, SanFrancisco, CA (1998).

7. I. Foster, C. Kesselman, and S. Tuecke, The Anatomy of theGrid—Enabling Scalable Virtual Organizations, The GlobusAlliance, http://www.globus.org/research/papers/anatomy.pdf.

8. Utility computing can be defined as the network delivery (byservice providers) of IT and business process services.

9. A resource pool is a collection of dynamically created phys-ical and logical resources such as servers, processors, and net-works.

10. XML Information Set, WorldWide Web Consortium (Feb-ruary 2004), http://www.w3.org/TR/xml-infoset/.

11. XML Schema, WorldWide Web Consortium, http://www.w3.org/XML/Schema.

12. XML Protocol Working Group, WorldWide Web Consortium(2004), http://www.w3.org/2000/xp/Group/.

13. I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke, The Phys-iology of the Grid—An Open Grid Services Architecture for Dis-tributed Systems Integration, The Globus Alliance (June 2002),http://www.globus.org/research/papers/ogsa.pdf.

14. Global Grid Forum, http://www.ggf.org.15. D. Box, Global XML Architecture (2002), http://whitepapers.

zdnet.co.uk/0,39025945,60063919p-39000542q,00.htm.16. Final OGSI Specification V1.0 (July 2003), https://forge.

gridforum.org /docman2/ViewProperties .php?group_id�43&category_id�392&document_content_id�347.

17. K. Czajkowski, D. F. Ferguson, I. Foster, J. Frey, S. Graham,I. Sedukhin, D. Snelling, S. Tuecke, and W. Vambenepe, The

WS-Resource Framework (March 2004), http://www-106.ibm.com/developerworks/library/ws-resource/ws-wsrf.pdf.

18. Publish-Subscribe Notification for Web Services (March 2004),http://www-106.ibm.com/developerworks/library/ws-pub-sub/.

19. A. Bosworth, D. Box, E. Christensen, F. Curbera, D. Fer-guson, J. Frey, C. Kaler, D. Langworthy, F. Leymann, S.Lucco, S. Millet, N. Mukhi, M. Nottingham, D. Orchard, J.Shewchuk, T. Storey, and S. Weerawarana, Web Services Ad-dressing (WS-Addressing) (March 2003), http://msdn.microsoft.com/ws/2003/03/ws-addressing/.

20. B. Atkinson, G. Della-Libera, S. Hada, M. Hondo, P. Hallam-Baker, J. Klein, B. LaMacchia, P. Leach, J. Manferdelli, H.Maruyama, A. Nadalin, N. Nagaratnam, H. Prafullchandra,J. Shewchuk, D. Simon, and C. Kaler, Web Services Security(WS-Security) (April 2002), http://www-106.ibm.com/developerworks/library/ws-secure/.

21. K. Czajkowski, D. F. Ferguson, I. Foster, J. Frey, S. Graham,T. Maguire, D. Snelling, and S. Tuecke, From Open Grid Ser-vices Infrastructure to WS-Resource Framework: Refactoring& Evolution (March 2004), http://www-106.ibm.com/developerworks/library/ws-resource/ogsi_to_wsrf_1.0.pdf.

22. I. Foster, J. Frey, S. Graham, S. Tuecke, K. Czajkowski, D.Ferguson, F. Leymann, M. Nally, I. Sedukhin, D. Snelling,T. Storey, W. Vambenepe, and S. Weerawarana, ModelingStateful Resources with Web Services (March 2004), http://www-106.ibm.com/developerworks/library/ws-resource/ws-modelingresources.pdf.

23. S. Graham, P. Niblett, D. Chappell, A. Lewis, N. Nagaratnam,J. Parikh, S. Patil, S. Samdarshi, I. Sedukhin, D. Snelling,S. Tuecke, W. Vambenepe, and B. Weihl, Web Service BaseNotification (WS-BaseNotification) (March 2004), ftp://www6.software.ibm.com/software/developer/library/ws-notification/WS-BaseN.pdf.

24. S. Graham, P. Niblett, D. Chappell, A. Lewis, N. Nagarat-nam, J. Parikh, S. Patil, S. Samdarshi, I. Sedukhin, D. Snel-ling, S. Tuecke, W. Vambenepe, and B. Weihl, Web ServiceBrokered Notification (WS-BrokeredNotification) (March2004), ftp://www6.software.ibm.com/software/developer/library/ws-notification/WS-BrokeredN.pdf.

25. S. Graham, P. Niblett, D. Chappell, A. Lewis, N. Nagarat-nam, J. Parikh, S. Patil, S. Samdarshi, I. Sedukhin, D. Snel-ling, S. Tuecke, W. Vambenepe, and B. Weihl, Web ServiceTopics (WS-Topics) (March 2004), ftp://www6.software.ibm.com/software/developer/library/ws-notification/WS-Topics.pdf.

26. The endpoint creates the reference properties in the EPRand uses these properties to express enough information todispatch the appropriate state of the resource.

27. I. Foster, WS-Resource Framework—Globus Alliance Perspec-tives, http://www.globus.org/wsrf/foster_wsrf.pdf.

Accepted for publication June 4, 2004.

Joshy Joseph IBM Software Group, A0-3A, Building K, Pough-keepsie, New York 12601 ([email protected]). Mr. Joseph is cur-rently working with IBM Software Group�s On Demand Archi-tecture and Development team, which is responsible for thedevelopment of IBM�s on demand incubator projects. His mainfocus is on business integration and business performance man-agement and grid computing. In his current position, he is work-ing as the development lead for the Enterprise Component Bus-iness Architecture (ECBA) pilot projects. Prior to joining thisgroup, he was working on the IBM Systems Group grid comput-ing architecture initiatives. Mr. Joseph is actively involved with


IBM�s contribution to the OGSI standard and the Globus Gridsoftware programming model. Previously, he contributed to IBM�sWebSphere� Catalog Manager and Commerce Integrator teams.He is an architect and programmer with primary skills and expe-rience in the areas of distributed computing, grid computing, work-flow models, and advanced Web services. Mr. Joseph is the co-author of a book on grid computing. He has received a numberof performance and publication awards. He has approximately20 patents pending in the U.S. Patent Office, over 15 inventionswith “file” status within IBM, and a number of invention pub-lications. He has also published a number of articles for IBM de-veloperWorks in the areas of grid computing, business processes,and Web services. Prior to joining IBM, Mr. Joseph worked forBell Atlantic Science and Technology and People�s Bank and wasinvolved in numerous projects in the areas of mobile computing,distributed computing, performance management, and Internetcomputing. He is an expert in the .NET and J2EE� program-ming models.

Mark Ernest IBM Global Services/Integrated Technology Services800 N. Frederick Ave., Gaithersburg, Maryland 20879([email protected]). Mr. Ernest�s primary focus over the pastfour years has been the leadership of the team responsible forthe development, evolution, and application of IT optimizationmethodology. In that role, he helped develop assessment andadoption methods for both grid and autonomic computing. Cur-rently, he holds a position within the Global ITS Organizationas the Chief Technology Officer for operational efficiency. In ad-dition, he is a member of the ITS Technology Council and serveson the core teams of the IT optimization, enterprise systems man-agement, IT cost and value, and e-business infrastructure com-munities of practice. Collectively, these groups are responsiblefor creating many of IBM�s IT consulting-related work products,tools, and techniques. Mr. Ernest joined IBM at the WashingtonSystems Center 26 years ago and was asked to become a found-ing member of IBM�s IT consulting competency in 1992. He wasnamed a Distinguished Engineer by the Corporate TechnologyCouncil in April 2001.

Craig Fellenstein IBM Global Services/Strategic Outsourcing,6 Hunting Ridge Road, Brookfield CT 06804-3710([email protected]). Mr. Fellenstein has served for many yearsas a Global Chief Architect for the IBM Corporation. His pri-mary skills and experience are in the areas of technical supportand large-scale Internet commerce infrastructure design, tradi-tional infrastructures, electronic commerce transformations, andtelecommunications, including development and deployment ofglobal enterprise-wide architectures. Mr. Fellenstein is also a lead-ing member of the IBM Global Services Invention EvaluationTeam, helping evaluators in complicated evaluations for manyIBM patents being submitted to the U.S. Patent Office. Mr. Fel-lenstein has held chair assignments on the IBM Corporate Tech-nology Council chaired by Lou Gerstner, solving difficult tech-nology challenges within IBM. He is currently IBM�s Global ChiefArchitect and Senior Executive Consultant. During the late 1990s,Mr. Fellenstein helped IBM establish its full line of hosting ser-vices, which were instrumental in the IBM Service Delivery Cen-ter deployment strategy and worldwide architecture. Mr. Fellen-stein has several publications, including four books, in advancedareas of computer science, most illustrating an emphasis in sys-tems design, technical architectures, grid computing, on demandbusiness strategies, patents, and artificial intelligence. He currentlyhas over 80 patents pending for IBM, plus other awards for pat-

ents on file with the U.S. Patent Office. He is a disabled veteranof the Vietnam era and a retired member of the U.S. Air ForceTactical Air Command, where he was an aerospace weapons de-livery specialist on the A7-D fighter-bomber aircraft.


evolution of grid computing architecture and grid adoption...

Documents