An Emerging Architecture Enabling Grid Based Application Service Provision

An Emerging Architecture Enabling Grid Based Application Service Provision

Theo Dimitrakos,

Damian Mac Randal,

Fajin Yuan

Central Laboratory of the

Research Councils,

Rutherford Appleton Lab,

UK

Matteo Gaeta,

Giuseppe Laria,

Pierluigi Ritrovato

CRMPA, Università di

Salerno, Italy

Bassem Serhan,

Stefan Wesner,

Konrad Wulf

High Performance

Computing Centre, Univ. of

Stuttgart, Germany

AbstractIn this article we examine the integration three emerging

trends in Information Technology (Utility Computing, Grid Computing, and Web Services) new Computing

paradigm (Grid-based Application Service Provision)

that is taking place in the context the European research project GRASP. In the first of the paper, we explain how

the integration of emerging trends can support enterprises in creating competitive advantage. In the

second part, we focus on Grid-based Application Service

Provision (GRASP), which builds a new technology-driven business paradigm on top of such integration. We

conclude by outlining plan for prototyping a GRASP

platform in the context an ongoing European research project

1. From Application Service Provision to

Utility Computing

Application Service Provision (ASP) is a business

model, originally derived from the idea to use the

Internet or other wide area networks to provide online

application services on a rental basis—commercially

delivering computing as a service.

The ASP model takes advantage of several

technological breakthroughs that have made it feasible to

sell computing as a service rather than a product. On the

one hand, personal computers have educated at least a

generation of users and the emergence of the WWW has

provided them with standard interfaces and methods for

accessing information and application services, enabling

a widespread adoption of e-commerce. On the other

hand, the Internet has matured to become the world’s

single largest data and computing service delivery

infrastructure, while high performance computing

technology is increasing the available computing power

and time-sharing operating systems allow for computing

resources to be treated as a divisible utility. As indicated

in [1], [2], one can distinguish two different types of ASPs:

the “traditional” ASP and the Internet Business Service

Provider (IBSP also referred to as the “network-centric”

ASP).

The first category are ASPs who have created their own

“boxed” application services, either by hosting and

managing third party solutions, such as www.corio.com and

www.surebridge.com, or ISVs (Independent Software Vendors) who provide their own product as an application service, such as Oracle and SAP. Common characteristics of this class include:

Adapting packaged enterprise software for Internet delivery. Reducing the cost of deploying and managing complex

enterprise solutions. Unlike traditional outsourcers, these ASPs also promise customer’s visibility into, and control over, their applications and services. Achieving "economies of skill" based on the repetitive

deployment of the same solution for many customers, which allows them --- through repetition and familiarity --- to help their clients avoid mistakes and achieve quick return on investment. Software licensing is similar to internal product

deployment. Tailored installation and management for each client

aims to ensure personalisation in application service provision.

The traditional ASP model can be understood as an evolution of outsourcing. Clients enjoy the benefit of offloading complex and expensive IT to the ASP while maintaining control and visibility of business processes.

However, performance, security, reliability and maintenance are still bound to constraints of solutions that have been originally designed for specialized in-house implementations.

The second category consists of ASPs providing applications that are network-centric (e.g. being themselves a bundle of loosely coupled Internet-enabled services) and Internet-enabled by design. These include IBSPs such as

www.atomz.com, www.openair.com, www.employease.com,and www.salesforce.com. Their common characteristics include:

In addition to economies of skill, they also target economies of scale, by running their services in a multi-tenancy model and supporting thousands of customers with a single code base. They cut their hardware and systems-administration

costs, by partitioning their resources to a large number of clients They streamline customer support and upgrade

cycles, by maintaining a single back-end application. Reduction of client-side development investment

and maintenance by using standard Web technology

as their client-side interface.

In contrast to traditional ASPs, providing application

services that are Internet-enabled by design, allows

IBSPs to build in the necessary performance, security,

and management controls and balances. Instead of

adapting the source code of their applications in order to

provide personalized services, IBSPs will usually try to

ensure that the applications are designed in a way that

supports customization through changing the

configuration of the application rather than the source

code of its components. IBSPs therefore move closer to

building their businesses on a utility model than

traditional ASPs.

Utility computing presents a paradigm where shared

infrastructure can be provided on demand to multiple

customers [22]. It describes a system that lets companies

pay for IT services as needed. Rather than buying their

own servers (or additional machines) and hiring the

maintenance staff associated with them, a company

simply purchases server time or processing power from

another company, which also takes care of upkeep and

other such concerns. Services companies expect to

charge customers the same way an electric company

does: When usage spikes, so does the bill. Common

characteristics include:

Pay-per-use or metered use

Available on demand

Dynamic allocation and integration

Further advancements in application service provision

are happening now, in parallel to the maturation business

models and fine-grained accounting models for utility

computing. Essential in the classical definition is the

‘‘one-to-many model’’, which is a generalization of the

client-server interaction architectural model where the

same application is offered to many customers. As we

move from traditional ASP, through IBSP to pure Utility

Computing, we expect the classical ASP model to give

way to two new models:

The ‘‘federated’’ model, which is concerned with

the on-demand creation of dynamic virtual

organizations of service providers, which share

resources, capabilities and information for a limited

period of time and responding to a specific market need.

The ‘‘many-to-many’’ model, which is essentially an

evolution of the classic “one-to-many” ASP model,

achieved by evolving its foundation from the client-

server to the service-oriented paradigm: the entity can

take the role of either a consumer or a service provider

in the context of the same application depending on the

required interactions. Furthermore, ASP users may

count their material contribution to the provision of the

overall application provision as a means of payment

towards using that application.

At present a few initiatives, such as the EU GRASP

project [21], mentioned in section 3, are experimenting with

the use of novel technology paradigms such as Grid

computing in order to support the operation and evaluate the

sustainability of these new models of ASP and thus

contribute to the evolution from traditional ASP via IBSP to

pure Utility computing.

This paper is organized as follows: Section 2 summarizes

the requested background and in particular the basic

principles of the Open Grid Service Architecture, Section 3

introduces the GRASP European project, Section 4

examines the main functionalities of GRASP environment,

Section 5 reports the current state of the GRASP project,

and Section 6 concludes the paper.

2. Grid Services: an enabling technology

In this section we summarize the background assumed in the

rest of the paper: The basic principles of the Service

Oriented Architecture paradigm and their realization in the Grid Service specification [4] via the Open Grid Service Architecture vision [5], [6].

2.1 Elements of SOA

A service is a network-enabled entity that provides some

capability. Service oriented architectures (SOA) aim to

provide the shared organizing principles that underpin the

collaborative operation of services in open dynamic

distributed systems. Service-oriented architectures focus on

how services are described and organized to support their

dynamic, automated discovery and use at run-time (In

contrast, for example, to systems based on manually

hardwired interactions, such as those used in EDI systems).

SOA provide the architectural concept behind the Web

Services standards. The fundamental characteristics of SOA

include:

Service providers publishing the availability of their

services.

Service brokers registering and categorizing published

services and providing search services.

Service requesters using broker services to find a

needed service and then employing that service.

Computer-accessible, hierarchical categories, or

ontologies, based upon what the services in each

category do and how they can be invoked. These

taxonomies aim to assist the dynamic automated

discovery of appropriate services.

The collaborations among these main roles (provider,

broker, requester) are supported by a standardized

network protocol. Service descriptions in a standard

machine-readable format (such as XML) are associated

with each service. These service descriptions are key to

all three roles in that they provide the information

needed to categories, choose, and invoke an e-business

service. In a service-oriented view, the interoperability

problem can be broken down into two sub problems: the

definition of service interfaces and the identification of

the protocol(s) that can be used to invoke a particular

interface.

A service-oriented approach addresses the need for

standard interface definition mechanisms, local/remote

transparency, and adaptation to local OS services, and

uniform service semantics. It also simplifies the

encapsulation mechanism that is necessary behind a

common interface of diverse implementations. Such a

mechanism allows for consistent resource access across

multiple heterogeneous platforms, enables the mapping

of multiple logical resource instances onto the same

physical resource and the management of resources

within a virtual organization based on composition from

lower-level resources. It also supports the composition of

services without regard for how the underlying services

are implemented, and underpins the ability to map

common service semantic behaviour seamlessly onto

native platform facilities.

2.2 Grid Service Architectures

Based on the Internet, Grid computing seeks to extend

the scope of distributed computing to encompass large-

scale resource sharing including massive data-stores,

high-performance networking and powerful computers,

be they supercomputers or networks of workstations.

To explain the idea of Grid computing, one often uses

the metaphor of a power distribution grid [7]. This

metaphor directly relates the Grid computing paradigm

to the Utility computing business models. However for

this metaphor to be realistic, the following issues relating

to Grid computing need to be addressed:

Different kinds of resources: The evolution of

Grid Computing is based on a transition from

sharing hardware resources to sharing data, and then

to sharing applications with the view of sharing

information and effectively knowledge. Indeed, for

Grid computing to evolve to a comparable usability

level to a power grid, the user will expect to

consume at least three different resources: hardware,

data/information and applications.

Different kinds of interaction: The heterogeneity of

resource sharing inevitably results in heterogeneity of

interaction. Beside of that, business as well as private

users will demand for different service levels, in

accordance to non-functional requirements relating to

quality of service, billing scheme, fault tolerance,

security and trust.

Dynamic resource allocation and integration: Being

based on different kinds of shared computing resources

demands for a dynamic way to use these resources.

Users should be supported to contribute resources

whenever desired in addition to consuming resources on

demand.

The applications driving the development of the Grid

computing infrastructure have been large-scale scientific

collaborations, such as [8] and [9], which have a clear need

for the collaborative use of resources, both data and

computational, and established communities which can

pool their resources for common goals. Various tools have

already appeared to support the Grid computing in such

context, notably Globus [10], Unicore [11] and

Avaki/Legion [12]. Currently, Grid computing is finding its

first applications in commerce and industry supporting

distributed collaborative design and engineering, or

distributed supply chains. In order to compensate for a

proliferation of proprietary and heterogeneous Grid tools,

that lack interoperability, the Global Grid Forum

(www.ggf.org) has initiated a standardization initiative

providing a common conceptual architecture (OGSA) and a

standardized interoperability framework (OGSI) for Grid

computing.

The Open Grid Services Architecture (OGSA) extends

the SOA paradigm by integrating conceptualizations of key

technologies from the Grid Computing and Web Services

approaches. Its realization within the Open Grid Service

Infrastructure initiative of the Global Grid Forum

(www.ggf.org) integrates key Grid technologies with Web

Services mechanisms to create a distributed system

framework based around the Grid service [4]. A Grid service instance is a (potentially transient) service that

conforms to a set of conventions (expressed as WSDL

interfaces, extensions, and behaviours) for supporting the

basic functionalities that enable dynamically evolving VOs,

such as on-demand creation of transient service instances,

lifetime management, discovery of characteristics,

notification, etc. Grid services enable the controlled

management of the distributed and often long-lived state

that is commonly required in sophisticated distributed

applications. While OGSA is prescriptive on matters of

basic behaviour (a set of well-defined interfaces and that

follows specific conventions. The interfaces address

discovery, dynamic service creation, lifetime management,

notification, and manageability; the conventions address

naming and upgradeability), it provides only a base

infrastructure definition that supports the creation of the

sophisticated distributed services required in modern

enterprise and inter-organizational computing

environments. OGSA can therefore be viewed as an

architecture reference model for Grid services.

An OGSA compliant grid can be understood as a

collection of services with specific interfaces, which are

potentially able to interact. OGSA does not address how

Grid services are created, managed, and destroyed

within any particular hosting environment. Thus,

services that conform to this specification are not

necessarily portable to various hosting environments,

but any client program that follows the conventions can

invoke any Grid service conforming to this specification

(of course, subject to policy and compatible protocol

bindings). An OGSA compliant grid is a distributed

component system that utilizes basic elements and

patterns of a distributed system, like service discovery,

service creation, lifetime management and notification.

Service discovery requires the ability of a service

to describe itself. This is covered inside the

mandatory GridService port type, which contains a

FindServiceData function. Additionally a service

can act as a registry if it implements the optional

Registry port type.

Dynamic Service creation is a central element of

OGSA. It is supported by the idea of factory

services, which implement the optional Factory port

type. A factory service is responsible for creating a

new Grid Service instance and providing the client

with a handle for accessing the service.

Lifetime management is a basic issue in

distributed systems and is therefore addressed in the

mandatory GridService port type. The basic idea is a

Soft-State approach. This means that each service

has a limited lifetime, therefore no distributed

garbage collection is needed that tracks the necessity

of services within the Grid and destroys them. An

interested client may extend the lifetime if the policy

of the service allows it. If the lifetime is expired, the

service may terminate.

Notification is important because of the dynamic

nature of the collaborating services. There are many

scenarios imaginable, where a service creates

another service and needs to be informed about

specific events or changes in the state of the created

service. Therefore a service can implement one or

both of the optional NotificationSource and

NotificationSink port types, which allow subscription

for asynchronous message delivery.

OGSA/OGSI provide an extensible elementary basis

on top of which service-oriented grid architectures may

be developed. Clearly, sophisticated application services

in a business context require suitable OGSA extensions

which are taking care of service orchestration (including

dynamic service composition, and management of

workflows, collaboration agreements), service level

agreement management, accounting and enterprise security.

Although OGSA/OGSI allow “programming at the

abstract” (similarly to the Web Services paradigm) by

providing a platform independent base framework for

defining and managing grid services, some aspects of the

overall infrastructure are influenced by the chosen

implementation. A number of OGSA implementations exist,

where hosting environments vary from simple operating

systems to sophisticated containers like J2EE or MS.NET.

The ability to handle grid service instances throughout their

lifetime is probably the most important challenge for the

implementation platform.

2.2.1 The role of Web Services technologies.

The Open Grid Services framework uses Web Services

technology as the means for describing software

components to be accessed, methods for accessing these

components, and discovery methods that enable the

identification of relevant service providers. Furthermore

Web Services ensure service interoperability by being

programming language-, programming model-, and system

software-independent. Finally Web Service protocols and

description languages are being defined within the W3C and

other standards bodies such as OASIS and form the basis for

major new industry initiatives involving most key actors.

From an OGSA/OGSI perspective, the Web Services

framework has three advantages:

The need to support the dynamic discovery and

composition of services in heterogeneous environments

necessitates mechanisms for registering and discovering

interface definitions and endpoint implementation

descriptions, and for dynamically generating proxies

based on (potentially multiple) bindings for specific

interfaces. WSDL [14] supports this requirement by

providing a standard mechanism for defining interface

definitions separately from their embodiment within a

particular binding, while WSInspection [16] supports

locating service descriptions published by a service

provider.

The widespread adoption of Web Services mechanisms

means that a framework based on Web services can

exploit numerous tools and extant services, such as

WSDL processors that can generate language bindings

for a variety of languages [17], workflow systems on

top of WSDL, and hosting environments for Web

services [18].

Also the Simple Object Access Protocol (SOAP) [15]

provides a means of messaging between a service provider

and a service requestor. SOAP is just one means (albeit

increasingly popular and standardized) of formatting a Web

Service invocation. Notably, OGSA does not require the use

of SOAP for all communications. If needed, alternative

transports can be used, for example to achieve higher

performance or to run over specialized network protocols.

3. GRASP: towards Grid-based

Application Service Provision

The GRASP project (www.eu-grasp.net) is an

industry driven European research project, which is

exploring the use of Grid Services paradigm as a means

of providing a timely and effective technological basis

supporting the evolution of the ASP market towards a

sustainable Utility Computing model. To achieve this

GRASP is developing an architectural framework for

Grid-based Application Service Provision (GRASP), a

prototype realization of this framework in a GRASP

platform and “proof-of-concept” implementations of

“federated” and “many-to-many” ASP models in the

Finance, eLearning and Biomedical domains.

From a business perspective, GRASP is a practical

experiment, exploring the usefulness of the Grid / Global

Computing paradigms as facilitators of Utility

Computing (with special focus on the ASP market).

From a technological perspective, GRASP is

developing an architectural framework aiming to close

the gap between the effective deployment of Grid

infrastructures, Web Service based enabling

technologies, and enterprise models for application

service provision. Our intention is to improve enterprise

application service provision models so as to be able to

take full advantage of the flexibility offered by Web

Services as a standardized means of integrating

components of heterogeneous systems both within local,

as well as wide area networks, and of the additional

functionality and reliability offered by Grid Services for

supporting dynamic resource allocation, life-time

management of dynamic service instances, resources

integration and efficient distributed computation. We

expect that when properly integrated within a business

workflow this bundle can soften enterprise borders,

giving way to new, more flexible ways of secure and

reliable collaboration. Figure 1 shows the integration role

of GRASP with respect to the three concepts.

Figure 1: GRASP brings together the ASP, Grid, and Web Services concepts

4. Role based models explaining the GRASP

platform architecture

In this section we examine the main functionalities of a

GRASP environment, by means of role-based models to be

realized by the GRASP architecture. These core

functionalities will support common GRASP activities,

including the following:

Service Location: the process of manually or

automatically discovering the logical location of

services.

(Dynamic) Service Instantiation: the process of

dynamically creating (potentially transient) ready-to-use

instances of the services within a Grid.

(Service) Task-based Interactions: how to support and

manage the necessary interactions for executing a

service instance.

Service Orchestration: the co-ordination of the sub-

Services collectively executing a complex business

workflow.

In the following subsections, we examine each of the

above in turn. A detailed description of the GRASP

architecture is out of the scope of this paper. A preliminary

version of the detailed architecture is provided in [19].

4.1 Service Location

The main roles, entities and interactions involved in

service location are summarized in the Figure 2. These

include:

Figure 1: The roles and relations for service location

- SERVICE PROVIDER, which is expected to produce

description of the services it provides using an

appropriate service description language (e.g. WSDL or

GSDL [14], [4]). Domain specific WSDL extensions

dealing with service characteristics of interest for a

particular application domain may also be supported.

Service

locator

Service

provider

Service

requestor

directory

service description

register service request matching services/

return matching services

lookup

update/manage

createsreturned

by locator

provided by

provider

- SERVICE REQUESTOR, which is expected to produce

and communicate a service request (a query

provided in a format allowing to relate the request to

the WSDL-compliant descriptions of services

mentioned above) to the Service Locator.

- SERVICE LOCATOR, which processes the query, looks

up in a service directory for descriptions of

registered services, runs the query against the

relevant service descriptions and returns to the

Service Requestor a short-list of matching services,

potentially accompanied with auxiliary information.

The GRASP architecture is supporting this aspect of

GRASP functionality by, on the one hand, extending the

service discovery functionality of Web Services through

the use of OGSA service discovery concepts such as the

Virtual Organization Registry service and, on the other

hand, addressing the following additional challenges:

- To support queries for discovering and locating

composite services that are collectively

implementing the workflows of non-trivial business

processes, and whose component services are

distributed within the same or different OGSA

compliant Virtual Organization structures.

- To allow service providers maintaining high-level

control of the location of the instances associated

with their services, without restricting the ability of

Grid Services to migrate the hosting environment in

a way that is seamless from the perspective of the

service consumer.

4.2 Service Instantiation

The following Figure 3 shows roles, entities and

interactions involved in the “service instantiation”

process.

selects idle instance

provides access details

Service

host

service instance

requests service

requests instance

Service

requestor

Service

provider

Service

instantiator

runs

monitors

creates instance

instance registry

registers instance

instance host

instance pool

reuse instance

invoke factory

or

factory

remove instance

local

registry

registers instance

Service Hosting Environment

Figure 2: Service Instantiation

The SERVICE REQUESTOR acts on behalf of an application

user or on behalf of another (composite) Service Provider

who is requesting a component service. It sends the service

request to the Service Provider; the request must provide all

the information necessary to identify the service to which

the User Application wants access. The request may also

include optional requirements relating, for example, to

billing, security, or recommended virtual hosting

environment.

The SERVICE PROVIDER should return a service reference

to the Service Requestor. This is in turn the end result of

several interactions between the Service Provider and some

(virtual) Hosting Environment. First, the Service Provider

should send a service instance request to the Service

Instantiator provided by the chosen Hosting Environment.

Second, the Hosting Environment (by means of its Service

Instantiator) will return to the Service Provider a Service

Reference, which the Service Provider should store in its

own repository of live service (instance) references. Third,

the Service Provider should pass the service (instance)

reference to the appropriate Service Requestor.

The SERVICE HOSTING ENVIRONMENT is the virtual environment that supports the production and execution of

the service instances by executing the factory service for

their creation, maintaining an appropriate registry of all

service instances hosted and allocating all necessary

resources to the services.

The SERVICE INSTANTIATOR handles the service

instantiation task for the Service Provider. It can provide a

service instance in two ways:

- Creating a new instance using the OGSA Factory pattern, if an instance of the requested type doesn’t

exist.

- Selecting an instance already created and stored in the

Instance Pool.

The production of services instances within an OGSA-

compliant grid is based on the Factory concept, which

prescribes the presence of a service that creates “on-

demand” potentially transient service instances. (This

realized by means of the implementation of the optional

Factory interface of the OGSA Grid Service specification.)

By analogy to the object-based paradigm, the

implementation of a Factory can be understood as (the part

of) an object that offers the necessary operations to create

other objects. Upon client invocation, the factory creates a

new object and returns a reference to the client.

The instance pooling technique allows reuse of a service

instance, in fact the Instance Pool contains “waiting” service

instances that have finished servicing the request, and that

remain in the “idle” state until another request is invoked on

it. Whether a specific grid service instance is created on-

demand or taken from an existing Instance Pool depends in

each case on the pursued balance between the costs of

instantiation versus the cost of hosting idle instances. For

example, instance pooling is particularly useful in the case

of composite services or services whose instantiation is

time critical or resource consuming.

In addition to providing suitable deployment models

of the OGSA factory concept for the commodity

platforms used in an ASP context, the GRASP

architecture is addressing the following challenger

relating to the realization of the Dynamic Service

Instantiation functionality:

- To ensure that the Service Provider can maintain a

consistent and up-to-date repository of the live

service instances associated with its service.

- To address interference problems stemming from

the potential of allowing multiple client access to

stateful service instances.

- To support the decomposition of composite services

to components distributed in a suitable collection of

“hosting environments”.

- To coordinate the dynamic creation sub-services in

accordance to their use within a business workflow.

The latter is achieved by introducing high-level

factories that create composite end-to-end (E2E) service

instances, by invoking as many as necessary factories of

different hosting environments.

4.3 Task-based interactions

In previous subsections we concentrated on the

problems of locating and instantiating services within an

extension of OGSA and Web Services frameworks. In

this subsection we focus on how to support and manage

the necessary interactions with a service instance for

executing a task. This process involves the roles, entities

and interactions summarized in the Figure 4.

client

runs

Service

host

Service

host

service instance

returns ptr to service

interacts with service

Service

requestor

Service

provider

monitors sets configure

Service

host(s)

returns accounting info

Application

User info/status exchange

Figure 3 - Roles and Relations for service task

interaction

We distinguish two different types of interactions:

Interactions that are concerned with the

administration of the service instance execution; and

Interactions that are part of the service instance

execution.

The latter typically take place between the corresponding

client and the service instance whereas the former take place

between the client or the service instance and the entities

taking the role of Service Requestor, Service Provider, and

the Service Host.

In addition to simplifying the presentation and leading

towards a more modular architecture, we expect that such a

separation of concerns will contribute to the effectiveness of

the task execution. In particular, our intention is to combine

support for peer-to-peer style interaction between the

service client for the purpose of executing a task while

allowing the Service Requestor, Service Provider, or Service

Host to collectively administer the execution of the service

instance, as appropriate. In the following we elaborate this

distinction concentrating on the specific interactions relating

to the administration of a task execution.

4.3.1 Service Requestor interactions.

The Service Requestor (SR) is involved at the beginning

of the task execution. It interacts with the Service Provider

(SP) and client. SP gives to the SR an appropriate pointer to

the service instance (and additional information for

initiating the task execution), and then the SR passes them

to the Client.

4.3.2 Client interactions.

From the client perspective, we distinguish three types of

interactions:

- Interactions with the Service Requestor, which deals

with the initialization and configuration of the task

execution;

- Interaction with the Application User, which deals with

the provision of the necessary input and the

presentation of the results of the task execution;

- Interaction with the service, which deals with the task

execution.

Interaction with the Service Requestor takes place at the

very beginning of the task execution and results in the

provision of the appropriate pointer to the service instance

(e.g. the grid service reference) and any necessary

configuration information for initiating the task execution.

Interaction with the Application User takes place

periodically when input related to the task to be executed is

needed or where notification or results need to be presented

to the Application User. Typically this interaction abstracts

away information related to the location of the service

instance or the specific methods invoked, therefore

providing a seamless interaction with the application

implemented by the service.

Interaction between the client and the service instance

can be further divided into:

- Interaction with the service instance, which is

concerned with the invocation of the methods and the

process of the data and state information provided by

the service instance and takes place in a peer-to- peer

fashion;

- Interaction with the Service Provider, which is

concerned with information about the current status

of the service instance execution, and information

exchange about administrative matters including

billing, and updates to the actual location, usage

policies or access rights to the service;

- Interaction with the Service Host, which is

concerned with information about the service

instance execution including communication related

to the life management and access to the service

instance.

An important design choice to be considered in

relation to the latter two types of interaction is whether

direct communication between the client and the Service

Host for administrative matters is to be allowed.

Typically, the Client is allowed to interact in a peer-

to-peer fashion with the Service Host for the purpose of

accessing methods of the service instance to which

access has been granted. This interaction takes place

without any further intervention from the Service

Provider. However, one can expect that the Service

Provider intercepts interactions relating to changes to the

configuration of the client for using the service instance

or interactions relating to updates of the usage policies,

access rights and billing. This essentially means that the

Service Provider acts as a proxy for interactions between

the Hosting Environment and the Client, but only if those

interactions relate to the administration of how the

service instance is executed. From the Client’s

perspective interactions about administration of the

service instance execution that relate to the Service Host

are always directed towards the service host.

Such interception by the Service Provider allows the

Service Provider to maintain the right to intervene and

endorse or reject updates to the way that the service

instance execution is managed. Since both the frequency

and complexity of such interactions are typically lower

than the interactions directly related to the service

instance execution, we expect that performance of the

service instance execution is not significantly

compromised.

The following figure visualizes this aspect of the

GRASP architecture. C2SI peer-to-peer, C2SP, SH2SP

and SI2SH peer-to-peer interactions are enabled. From

the Client’s perspective C2SH communication is also

taking place but SP is in fact intercepting such

interaction acting as a proxy for the Client.

- Service Instances hosted on behalf of other Service Providers

Service Host Service Provider

Service Instance X

SH2SP

SI2SH

Client Using X

C2SP

C2SI

- Service Instances hosted on behalf of Service Provider SP

Figure 5 – Administration during service execution

4.3.3 Service Provider interactions.

The Service Provider is involved in the following

interactions:

- Interaction with the Service Requestor for the purpose

of providing an appropriate pointer to the service

- Peer-to-peer interaction with the Client (C2SI) for the

purpose of managing billing, access and usage of the

service instance

- Peer-to-peer interaction with the Service Host (SH2SI)

for the purpose of remotely administering the service

instance execution, and monitoring the status of the

service instance.

- Interaction with the Service Instance for the purpose of

monitoring its status or updating its access rights,

lifetime or usage configuration.

SH acts as proxy for some interactions between SP and

Service Instance, in analogy to the SP acting as proxy for

some interactions between SH and Client. (See Figure 5

where intercepted communications are depicted with a

dotted line). Since both the frequency and complexity of

such interactions are typically lower than the interactions

directly related to the service instance execution, we expect

that performance of the service instance execution will not

be significantly compromised.

4.3.4 Service Host Interactions.

For the purpose of executing a task via a live service

instance, the Service Host is involved in the following

interactions:

- Peer-to-peer interaction with the Service Provider

(SH2SP) for the purpose of administering the execution

of the task by the Service Instance and for the purpose

of providing an appropriate pointer to the service for

setting up direct peer-to-peer communication with the

Client and the Service Instance (C2SI).

- Peer-to-peer interaction with the Service Instance

(SI2SH) for the purpose of administering its operation

within the virtual hosting environment.

- Interaction with the Client, which is concerned with

information about the service instance execution

including communication related to the life

management and access to the service instance.

The latter is intercepted by the Service Provider,

which acts as a proxy for the Client (but only for

interactions that relate to the administration of how the

task is executed).

4.4 Service Orchestration

In many cases a Service Provider may wish to

“subcontract” some or all of the work involved in

providing a Service to other Service Providers. To enable

this, they need to be able to locate, invoke and co-

ordinate other Services (possibly including other

Services run by themselves). Mechanisms to locate,

invoke and interact with other Services have been

described above. This section deals with the co-

ordination of these sub- Services.

Co-ordination of the sub-Services is carried out by the

Service Orchestrator. In effect this enacts the business

process (or workflow) that delivers the overall Service.

To achieve this, two things are needed, firstly a

definition of the business process, and secondly an

enactment engine to carry out the process definition.

runs

Service

host

Service

host

service instance

Service

provider

monitors

Service

host(s)

returns accounting info

Service orchestrator

service description

uses

Service

instantiator

requests instance

creates instance

provides access details

Figure 6 – Service Orchestration

Processes are usually defined by means of a Process

Definition Language (PDL), describing the order in

which the Activities (in PDL terminology they represent

unit of processing at the orchestration level which are

mapped to sub-services method invocations for

enactment) take place. PDL can be understood as a high-

level programming language that provides the necessary

control structures to specify run-time dependencies

between Activities. Examples of such control structures

include conditional invocation of an Activity, selection

between alternative Activities, parallel execution of

several Activities, etc. There are different examples of

PDL [23], but in the frame of GRASP project the

emerging BPEL language developed by IBM and

Microsoft for orchestration of Web Services will be used.

In the diagram of Figure 6, the Service Orchestrator runs

the enactment engine (the entity that runs the process

description defined in the PDL document). When the

Service provider is asked for an instance of their Service,

instead of instantiating a Service on a Service Host, they

request a new business process instance from the Service

Orchestrator’s enactment engine. The enactment engine

(which does not necessarily run on the Service Provider’s

environment) fetches, or is given the appropriate business

process definition (the PDL). It then executes the PDL.

When it wishes to instantiate a sub-Service, it uses the same

mechanism that the Service Provider does to instantiate

Services. On receiving the access details back from the

Service Host, it can then pass the needed control data to the

Activity (unless this has already been passed as instantiation

parameters). Finally, it either retrieves from its data store the

process instance data and passes it to the Activity, or it

connects the Activity input to the output of another Activity

(essential for non-trivial datasets if engine and Activities are

on different machines). While the Activity is running, the

enactment engine monitors it so that it can take appropriate

action when it terminates (or fails).

By presenting the enactment of the overall business

process as a composite, it can itself be used by another

service Orchestrator. The GRASP architecture is reflective

with respect to business process enactment: orchestrated

services are bundled as a composite service, which can be

instantiated and each live instance of such a composite

service is given a unique service identity.

4.5 A scenario of putting it all together

In this subsection we explain how the functionality

described in subsections 4.1 to 4.4 is combined in the

delivery of an application requested by a final user.

First, the final user queries a Service Locator in order to

retrieve information about applications that match their

request. The Service Locator returns a list of possible

applications matching the query and the reference to ASPs

that provide them.

Figure 7

Then, the final User chooses the provider that better

matches his needs and contacts it in order to obtain the

chosen application (ApplA). The incoming request from the

final user will be managed by the Publishing Service within

the Application Provider, which queries the Warehouse for

Final User Service Locator

1: queries for Application

2: returns list of applications

3: chooses ASP

retrieving a detailed description of the ApplA, which

explains in detail how it is possible to interact with this

application.

Final User

4: ApplA request

Publishing Service Warehouse

5: queries info about ApplA

6: ApplA description

Application Provider

Figure 8

At the same time a valid PDL for the ApplA

(including specific Grasp extension, e.g. for sub-services

location) will be passed to the Orchestrator that starts up

the operation for instantiating the application. Usually,

the application will be an integration of simpler

component services. The Orchestrator interprets the PDL

and invokes the Service Locator in order to obtain

information about the location of Service Providers

offering the services that constitute the application. We

assume that the Orchestrator has a pre-processed

catalogue of the Service Providers offering the

component services. If such a catalogue is not available

then the Orchestrator would need to compose it before

initiating the enactment process. Service discovery

makes use of service locators, published descriptions of

services and service registries, following similar steps to

those followed by the final user described above. Once

the appropriate Service Providers are identified, the

Orchestrator contacts them so that they can confirm their

ability to provide component services as prescribed in a

schedule provided by the Orchestrator.

Figure 9

Once contacted by the Orchestrator, each component

Service Provider seeks for an appropriate Hosting

Environment and delegates the creation of the

corresponding service instance to its Service Instantiator.

The latter may create a new instance or select an instance

already created and stored in the instance pool. (See also

section 4.2).

Figure 10

Finally, the Orchestrator, through the Enactment Engine,

executes the workflow. During the execution of ApplA the

interaction with the service instances are managed according

to the task-based interactions explained in section 4.3.

An overview of the scenario is provided in Figure 11.

In order to simplify the presentation of the interactions

involved in this process, we adopt a 3-level scheme for

describing the different interactions. This scheme is used for

organizing our presentation and does not have any direct

implication in the design of the GRASP architecture. In

particular it does not entail a choice of a 3-tier architecture

as opposed to the service-oriented approach. In fact, as

already mentioned in this paper, the GRASP project has

adopted a service-oriented approach in developing the

GRASP architecture and the corresponding prototype

implementation. This 3-level scheme consists of:

- An Application Provider level (focusing on interactions

underpinning application service provision to the final

client)

- A Service Provider level (focusing on interactions

underpinning the provision of the basic enabling

services to Application Provider level)

- A Service host level (focusing on interactions

underpinning the provision of resources and an

execution platform to the above levels)

Figure 11

Publishing Service

7: ApplA Description

Orchestrator

From description

retrieves component services

Service Locator

8: Service Information Request9: Service Information

Orchestrator

Application Provider Service Provider

Service Provider

10: Service Request

16: Instance Reference

Service Host

Instantiator Service

13: request for service instance

15: Instance Reference

14: Service Instantiation

Service (instantiator) Locator

11:in

stantio

rre

quest

12:in

sta

ntia

tor

refe

rence

Regis

tration

Publishing Warehouse

4: information about ApplicationA

5: applicationA description

Ap

pli

ca

tio

n p

rov

ide

r

From description

retrieves necessary component

services

Orc

he

str

ato

r

6: ApplicationA Description

Service Locator7: service information request

8: Services information

15: instance Reference

produces PDL

16: PDL

Registration

Serv

ice

pro

vid

er

9: Service Request

Service Provider

(Simple Services)

Service Locator

(instantiator locator)

10: instantiator information request

11: instantiator information

Se

rvic

e h

ost

Service

Instantiator

12: requests service instance

13: Operation for instantiating services

14: Instance Reference

Enactment Engine

17: interaction with instances

17: interaction with instances

Registration

Application User

Service Locator

(Application Locator)

1: application request

2: matching applications

3: applicationA request

Registration

5. Current State of Development & Future

Work

The European GRASP project complements Grid

infrastructure development projects such as [10], [11],

[12], Web technology deployment projects such as [13],

[14] and ASP business model assessment and risk

management projects such as [20] by providing a

tangible “proof-of-concept” for Grid-based Application

Service Provision.

In the context of the GRASP project we have

currently performed a user survey and market analysis,

identifying the requirements and market drivers of the

GRASP project. We have also developed a preliminary

version of the GRASP reference architecture, consisting

of the following:

- A collection of role-based models describing the

main subsystems, roles, interactions of a GRASP

environment, and an explanation of how they meet the

requirements identified in the market analysis and user

surveys. Although these models use concepts relating to

Service Oriented approaches that are also referred to in

Web Services and Grid Service specifications, they are

independent of any specific implementation platform.

- An OGSA-compliant Deployment Architecture,

which is describing the design of the first prototype

reference implementation, and an explanation of how the

architecture design satisfies the above mentioned

models.

- A description of the enterprise & information

viewpoints of the architecture corresponding to three

test-beds, specified following the ODP Reference Model.

The GRASP platform development is following an

iterative application of the Unified Process life-cycle,

consisting of two main iterations. The project is currently

in the middle of the implementation phase of its first

iteration where we implement the basic services

supporting the Location, Instantiation and parts of the

Task-based Interaction and Orchestration models

described in this paper, based on Microsoft .NET

platform and Web Services technologies. A second

version of the GRASP platform architecture is currently

being produced, following feedback from the early

prototypes.

6. References

[1]. Summit Strategies. Market Analysis Report, TraditionalISVs: Moving Along the Software-as-Services Curve. March2002.http://store.yahoo.net/summitresearchcenter/sofasser.html [2]. Summit Strategies. Market Analysis Report, Out of the Box: Top Nine Net-Native Software-as-Services Design Differentiators. June 2002. http://store.yahoo.net/summitresearchcenter/sofasser.html

[3]. Falkowsky, Tanja Feasibility Study on the Use of the ASP Business Model for Enterprise Application Software. Diploma Thesis, Technical University Braunschweig. (http://groups.haas.berkeley.edu/fcsuit/PDFpapers/DiplomaThesis_TanjaFalkowski.pdf)[4]. S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman; Grid Service Specification. Open Grid Service Infrastructure WG, Global Grid Forum, Draft 2, 7/17/2002. [5]. I. Foster, C. Kesselman, J. Nick, S. Tuecke, The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. Open Grid Service Infrastructure WG, Global Grid Forum, June 22, 2002. (extended version of [6]) http://www.globus.org/research/papers/ogsa.pdf [6]. I. Foster, C. Kesselman, J. Nick, S. Tuecke. Grid Services for Distributed System Integration. Computer, 35(6), 2002. http://www.gridforum.org/ogsiwg/drafts/GS_Spec_draft03_2002-07-17.pdf[7]. Foster, I., Kesselman, C. and Tuecke, S. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of High Performance Computing Applications, 15 (3). 200-222. 2001. http://www.globus.org/research/papers/anatomy.pdf [8]. European DataGRID Project, http://www.eu-dataGRID.org[9]. Information Power GRID, http://www.ipg.nasa.gov [10]. The Globus project, ( http://www.globus.org )[11]. The Legion project, ( http://www.cs.virginia.edu/~legion;http://www.avaki.com )[12]. The Unicore project, ( http://www.unicore.org )[13]. The Semantic Web Advanced Development in Europe project ( http://www.w3.org/20017sw/Europe/ )[14]. W3C. The Service Description Language (WSDL) 1.1 http://www.w3.org/TR/wsdl [15]. W3C. Simple Object Access Protocol (SOAP) 1.1 http://www.w3.org/TR/SOAP/ [16]. IBM and Microsoft Corporation. Web Service Inspection Language (WS-Inspection), http://www-106.ibm.com/developerworks/webservices/library/wswsilspec.html[17]. IBM and Microsoft Corporation. Web service invocation sans SOAP, http://www-106.ibm.com/developerworks/webservices/library/wswsif/ [18]. IBM and Microsoft Corporation. Automating business processing and transactions in Web Services, http://www-106.ibm.com/developerworks/webservices/library/wsautobp/[19]. GRASP Consortium. IST-2001-35464-DL8. GRASP preliminary architecture design. January 2003 [20]. The ALTERNATIVE project, http://www.alternativeproject.org[21]. The GRASP project, http://www.eu-grasp.net[22] Vijay Machiraju, Jerry Rolia, Aad van Moorsel, Quality of

Business Driven Service Composition and Utility Computing,

Software Technology Laboratory, HP Laboratories Palo Alto,

HPL-2002-66, March 15th , 2002

[23] Robert Shapiro, A comparison of XPDL, BPML,

BPEL4WS, Cape Visions, September 2002