apply agent to build grid service management

Apply agent to build grid service management

Li Chunlin*, Li Layuan

Department of Computer Science, Wuhan University of Technology, Wuhan 430063, People’s Republic of China

Received 24 September 2002; received in revised form 20 February 2003; accepted 21 February 2003

Abstract

This paper presents an Agent-based Grid Service Management, which applies the concept of

agents to computational grid. All entities in the Grid environment including computing resources and

services can be represented as agents. Each entity is registered with a Grid Service Manager. A Grid

service can be a service agent that provides the actual grid service to the other grid member. Grid

members communicate with each other by communication space that is an implementation of tuple

space. The design of three grid protocols for grid resource management is given. They are Grid

Service Discovery Protocol, Grid Service Subscription Protocol and Grid Service Access Protocol.

Grid service Subscription Protocol allows user/requestor agents to dynamically subscribe some grid

services for a finite time period. A grid service can be subscribed before it can be configured or used

by the user/requestor agent. A basic performance evaluation is given. Finally, some conclusions

are given.

q 2003 Elsevier Ltd. All rights reserved.

Keywords: Agent; Service; Grid; Service management

1. Introduction

The computational grid is a combination of distributed and heterogeneous computing

resources for executing large-scale applications. Providing an efficient and scalable

infrastructure to support the management of worldwide computational and data resources

is a very complex task. The Grid should provide the necessary computational and data

power to computational and data intensive applications. Inside the Grid many autonomous

components, including computational resource schedulers, replication managers, indexing

systems, monitoring systems, etc., must be combined in order to provide high level

1084-8045/03/$ - see front matter q 2003 Elsevier Ltd. All rights reserved.

doi:10.1016/S1084-8045(03)00018-3

Journal of Network and

Computer Applications 26 (2003) 323–340

www.elsevier.com/locate/jnca

* Corresponding author. Tel/fax: þ86-86534381.

E-mail addresses: [email protected] (L. Chunlin), [email protected] (L. Layuan).

http://www.elsevier.com/locate/jnlabr/yjnca

services to applications. A feasible structure for the Grid is the one in which each

component is specialized in a specific set of services, and complex services that involve

the use of many services, are achieved by making the simpler components collaborate with

one another (Foster and Kesselman, 1999; Chunlin and Layuan, 2001; Chunlin et al., 2001,

2002; Litzkow et al., 1988; Buyya et al., 2000a,b). Agents and Multi-Agent Systems can

provide the necessary technology to fast prototype, experiment, and implement forms of

Grid collaboration.

A series of workshops on Agent-Based Cluster and Grid Computing were initiated in

2001 as part of the IEEE/ACM International Conference on Cluster Computing and the

Grid (Frank Manola and Craig Thompson; Rana and Walker, 2000; Krauter et al., 2002).

The most interesting work in the literature might be is ARMS (Cao et al., 2001). In ARMS,

a hierarchy of identical agents is used to provide an abstraction of the system architecture.

According to Cao et al. (2001), Scalability is one key challenge that must be addressed for

Grid computing. Our approach described below is to address scalable resource

management architecture. In this paper, we propose an Agent-based Computational

Grid (ACG), which combines concept computational grid with agent. It provides a

completely distributed environment within which agent systems and individual agents can

participate in a broader community of agents, utilizing services and capabilities provided

by other participants or the grid itself. ACG allows user/requestor agents to dynamically

subscribe some grid services for a finite time period. A grid service can be subscribed

before it can be configured or used by the user/requestor agent. Grid members

communicate with each other by communication space that is an implementation of

tuple space. ACG supports grid service subscription that allows user/requestor agents to

dynamically subscribe some grid services for a finite time period. The design goals of our

model focus on providing a flexible and efficient grid resource discovery system to

collaborate Grid Service Agents (GSA) in the grid.

The rest of the paper is organized as follows. Section 2 gives an overview of ACG grid.

Section 3 presents grid members communication. Section 4 describes grid resource

specification. Section 5 describes the design of grid protocols to implement grid service

management. Section 6 gives experiment. Section 7 describes some related work. Section

8 concludes the paper.

2. The overview of ACG grid

The ACG Grid is intended to provide a completely distributed environment within

which agent systems and individual agents can participate in a broader community of

agents, utilizing services and capabilities provided by other participants or the Grid itself.

ACG grid applies the grid concept to agents. It provides uniform access layer to a large

variety of Grid services including other libraries and applications. In essence, ACG Grid

can be viewed as a composition or federation of agent systems; it is responsible for

providing services and allocating resources among its members and is used to make agent

systems more interoperable.

The primary goal of the ACG system is to provide users with a consistent and

transparent interface for accessing such services. All entities in the Grid environment

L. Chunlin, L. Layuan / Journal of Network and Computer Applications 26 (2003) 323–340324

including computing resources and services can be represented as GSA. Each entity is

registered with a Grid Service Manager. An ACG Grid service is a service agent that

provides the actual Grid service to the user. ACG grid provides a framework, which

combines the capabilities of a computational grid and agent system architecture. As such,

the grid would need to incorporate services provided by agent system architectures, such

as communications, lifecycle services, matchmaking, facilitating, security, persistence

facilities, system management, and mobility. ACG grid knows not only about agents, but

also about their computational requirements and about available computational resources.

Hence, the ACG grid appears to incorporate both the concepts of the computational grid

and the agent, it provides a unified, heterogeneous distributed computing environment in

which computing resources are seamlessly linked. These agents play the roles of

applications whose computations can be distributed within this distributed computing

environment, resources that can be used within this environment, and infrastructure

components of this environment. There is an interface between the computational and

agent layers. Building the ACG grid involves all the computational grid issues of system

management, distributed computation and load balancing, mobile code, security, etc. This

requires a way of describing resources and capabilities, and resource requirements and

tasks, and a way to map between them, at both agent and computational levels.

The ACG architecture can be viewed as comprising of a number of nodes capable of

running GSA, service requestor agents and some infrastructure services. Grid members

interact with each other to achieve a task. The service usage model is role based. To enable

GSA to be added, updated and removed easily from the network, some form of discovery

system is required. This is the role of the ‘Grid Service Registry ’ which utilizes a database

that can be searched to locate registered grid services. This Grid Service Registry provides

a simple registration mechanism common to all nodes and a simple interface for searching

the registered services common to all nodes; it also provides a mechanism for ensuring the

registration database contains up to date information. It should be robust to guard against

node failure, in meanwhile, it minimize the network traffic required for maintaining the

registration system. Grid Service Registry utilizes a ‘Grid Service Manager’ on every node

in the grid. This manager is located on a fixed, pre-defined port, which is termed the

‘Registry Port’ and provides a common access point into the Grid Service Registry for all

nodes. By locating a server on all nodes, service requestor agents do not need any localized

network information to access the Grid Service Registry. Every node has an individual

Grid Service Manager, so the complete system is defined by the interaction between the

service managers.

3. Grid agents communication by tuple space

In ACG grid, Grid agents communicate with each other by Communication space that

is an implementation of tuple space. Communication space is the key to agent interaction

and collaboration. Communication space supports not only asynchronous messaging, but

also asynchronous group cooperation. In ACG grid, Grid members are wrapped as mobile

agents; they need to communicate over the network. But communication with a remote

mobile agent does have associated problems, caused by the mobility of the agent. Passing

L. Chunlin, L. Layuan / Journal of Network and Computer Applications 26 (2003) 323–340 325

messages to a remote agent requires the receiving agent’s address. However, this

technique can cause problems if the recipient moves to a new location before the

message’s arrival.

The tuple space can be used for indirect communication and more tight cooperation

between agents. Linda introduces an uncoupled communication paradigm that is based on

the abstraction of a tuple space. It acts as a shared store of data, which is kept as tuples that

are addressed associatively by a pattern used in a matching-mechanism to retrieve a tuple.

It is unknown, which agents put the tuples into the tuple space, thus communication

partners remain anonymous to each other. Linda as a coordination language is embedded

in some computational language, by which Linda’s coordination primitives are available.

The primitives out, in and rd deposit and retrieve tuples from the tuple space. The selection

of a tuple with respect to a given pattern provided by in-and rd-operations is governed by a

matching-rule. The basic paradigm of communication is uncoupled in that the sending and

receiving agents do not know about each other. This mechanism therefore needs no

identification scheme of agents, and is more abstract than a directed communication

paradigm. An agent willing to receive data uses a pattern or template to address is

associatively. It specifies what data it is interested in, not what message it wants to receive.

The template makes a semantic statement, whereas “deliver message grid A to grid B” is a

syntactic statement. Linda-like communication paradigm is spatially and temporally

uncoupled by enforcing anonymous and asynchronous interactions. The scheme of

communication through tuple space is shown in Fig. 1.

In order to describe communication via the tuple space, several important objects are

described first. The basic object in implementing Linda-like communication paradigm is

Tuple. Tuple is a set of objects that is referred as Field, each field of the tuple is a reference

to an object that can also represent primitive data type. In order to exploit XML, Class

TupleX, which derive Tuple class, is defined, and FieldX class extends the Field class. A

TupleX is an ordered sequence of Fields that defines a node in the XML DOM tree. A

FieldX is to store XML documents or XML URIs. Given an XML document, it can be

wrapped up in a FieldX simply by naming the XML String as one of the tuple constructor

parameters; the XML string content is passed off and converted into a TupleCluster. A

TupleCluster is essentially a tree of tuples, which as a whole mirrors the DOM (Document

Object Model) tree of the XML document. Every Tuple includes a TupleData object that

embeds the XML related data as one of its fields and its child and its parent Tuple

references. TupleSpace is a shared named collection of tuples. Agent can use TupleSpace

Fig. 1. Communication via Tuple space.


to access the XML tuple space in a Linda-like fashion, i.e., by reading, extracting,

inserting fragments of XML data into the tuple space (Chunlin et al., 2002a,b).

4. Grid resource specification

In ACG grid, Service Requestor Agent discovers a resource using its service

description; access to the resource is governed by its service description. Various services

can be located with the use of Grid Service Manager, which reside within grid. When

searching or browsing for grid service, requestor agent requires a certain amount of

description information in order to decide whether or not the service is useful. If the

requestor agent decides to access the service, then it requires a different set of information

to ensure successful operation of the service. There are two types of description defined in

Grid Resource Specification: Grid Service Description and Service Attribute Description.

4.1. Grid service description

The ACG grid defines a syntax and semantics for describing the attributes of these grid

services called a Grid Service Description. The Service Description is a set of Service

Attributes abstract definitions. In general, a Service Description consists of zero or more

Service Attributes. There are three classes of Grid Service Description that are used in

three contexts:

(1) Service Description is a collection of all the Service Attributes registered and

maintained on a given Grid Service Manager.

(2) Request Description is a collection of Service Attributes representing service

requirements of a Requestor agent. It is generated as a result of a Service Discovery

request. Request description is included in the input parameter of SearchService( ) or

QueryService( ), or in the Query Service call message.

(3) Reply Description is a union between the local Service Description and Request

Description. It is generated as a response to a Service Discovery request. The record

is included in the output parameter of QueryService( ), or in the Query Service reply

.

XML is exploited to describe both service descriptions of grid service agent and service

requestor agent’s request description. XML allows the encoding of arbitrary structures of

hierarchical named values; this flexibility allows various service agents to create

descriptions that are tailored to their type of service. Valid service descriptions have a few

required standard parameters, while allowing service agents to add service-specific

information. An important advantage of XML over name-value pairs is the ability to

validate service descriptions against a set schema, in the form of Document Type

Definitions (DTDs). Unlike a database schema, DTDs provide flexibility by allowing

optional validation on a per tag granularity. This allows DTDs to evolve to support new

tags while maintaining backwards compatibility with older XML documents. Grid Service

Agents encode their service metadata as XML documents and register them with the Grid


Service Manager (GSM). Typical metadata fields include required capabilities, functions,

and timeout period. Service requestor agents specify their request description using an

XML template to match against; the template can include service-specific tags.

The Grid Service Description is as illustrated in Fig. 2.

4.2. Service attribute description

A Service Attribute consists of an Attribute ID field, identifying the type of the

attribute, a Result field that indicates the result of the comparison and a Value field,

containing the value of the attribute (see Table 1). The Result field is used in two ways:

† Attribute in registered or Request Description—This field specifies the type of a

function that compares the Attribute Value of the Service Description with that of the

Request Description.

† Attribute in reply Service description—This field indicates the result of the comparison.

In order to quickly and efficiently process a request query, indexes are used in grid

service attributes description. If no indexes were used for attributes of grid service

description in Grid Service Registry, every grid service defined must be compared to the

constraints specified in the query. This causes very slow lookup performance when GSM

has a large number of registered grid services. To reduce memory requirements for in-

memory repositories, index only the most important attributes in a grid service description.

Only attributes that requestor agent will most commonly use in lookup constraints are

indexed. The Indextype field in the ServiceAttribute allows you to specify the key

attributes. Valid values of Indextype include NO_INDEX and INDEX. If the value is

INDEX, the Grid Service Registry uses the attribute as an index.

Table 2 below describes some possible attributes that would be used within a grid

service description.

Fig. 2. Grid Service Description.

Table 1

Service Attribute Description

Attribute ID Result Value Index type


Service Description contains the following attributes:

† Description: describes some features of this service.

† Access: describes how to invoke and use a grid service. The access method fields

provide the placeholder for any kinds of service invocation schema. A service

description may contain multiple access method tags as they could be multiple ways to

invoke a service. The intent is for the agent to ultimately decide which invocation

mechanism to use. Some agents may want to use a interface of services, some may

decide to download a requestor agent-proxy code, other agent need migrate to

destination node, access the services locally.

† Interface: indicate agent can access service by a standard interface.

† URL: gives location of services supplied by a legacy system.

† Agent platform: The agent platform in which the application was built on.

† Service type: Informs the user the type of service.

† Properties: Denotes a list of properties of the service.

4.3. Comparison of service attribute

Given a Service description and a Request Description, the following steps are taken to

find out whether the two Service descriptions match. If any of the steps indicates

MISMATCH, the two service descriptions do not match.

(1) For each Attribute in the Request Description, do the following until MISMATCH is

detected or until all attributes are processed: Firstly, check for the existence of

Attributes in the Service Description. If an Attribute with the same Attribute ID exists

in the Service Description, proceed to the following steps. Otherwise, this attribute is

considered to match, and then continue to the next attribute. Secondly, comparison of

values in Attributes. The compare function is called with two arguments: the

Attributes of the Service Description, and the Request Description. If the comparison

is performed and the result of the comparison is FALSE, the two attributes do not

match (MISMATCH). Otherwise, the comparison is not performed, or the result is

TRUE. In these cases, the two attributes are considered to match. The Result field is

filled in with TRUE or a reason code indicating why the Attribute Records were not

compared.

(2) If the entire requested Attributes match, the two Service descriptions match, and a

reply service description is built. Otherwise, the two Service descriptions do not

match, and no reply Service description is built.

(3) If any Attribute in the Service Description has not been compared because the

corresponding record does not exist in the Request Description, the Result field is

filled with a reason code indicating “ Attribute Not Requested”.

Table 2

Possible Attributes in a Grid Service Description

Description Access Interface URL Reference Agent platform Service type Properties


5. Grid service management

The main actions involved in grid service management are service discovery,

subscription, and access. There are three protocols: Grid Service Discovery Protocol

(GSDP), Grid Service Subscription Protocol (GSSP) and Grid Service Access Protocol

(GSAP). The GSDP provides a basic mechanism to discover grid services for requestor

agents. GSSP is responsible for grid service detection and subscription. GSSP allows

user/requestor agents to dynamically subscribe some services for a finite time period.

GSAP is used for service requestor agent to access the located service.

5.1. Grid service discovery protocol

The GSDP is used to discover any published resource or service. Resources or services

are represented as advertisements. The GSDP enables a service requester to find

advertisements. The GSDP protocol is the discovery protocol of the Global Grid. Custom

discovery services may choose to leverage GSDP. The GSDP is implemented by three

kinds of components: Grid Service Agents (GSA) that provides services, Service

Requestor Agents (SRA) that request services and entities that constitute Grid Service

Discovery Service itself.

The Grid Service Manager can discover other remote Grid Service Managers and

determine the services registered there. Service Discovery is performed by comparing

required services type(s), as specified by the local grid service manager, with the service

type(s) available on a remote grid service manager. Remote Procedure Calls are used to

transmit the required service type(s) from the local grid service Manager to the remote

Grid Service Manager and to transmit the response from the remote Grid Service Manager

to the local grid service Manager. Through manipulation of the specification of required

service type, GSM can determine characteristics of all the services registered at a remote

grid service manager and the presence of a service on a remote Grid Service Manager

matching a specific set of constraints.

public class DiscoveryServiceProtocol{

private void updateServiceAdv ( ) { }

public DiscoveryServiceProtocol( ) { }

public GridService getService( ){ }

public Advertisement getAdvertisement( ) { }

public int getRemoteAdvertisements(String gridmember, int type,String attribute,

String value,int entrypoint) { }

public Enumeration getLocalAdvertisements(int type, String attribute,String value)

throws IOException { }

public void init(Grid Unit GU, ID assignedID, Advertisement ad)throws UnitException

{ }

public void flushAdvertisements(String id, int type) throws IOException ( ) { }

public void publish(Advertisement adv, int type) throws IOException ( ) { }

public void publish(Advertisement adv, int type,long timeout)throws IOException { }

public void remotePublish(Advertisement adv, int type, long timeout) { }


public void processResponse(ResponseMsg response) { }

public ResponseMsg processQuery(QueryMsg query)throws ResponseException,

IOException { }

public synchronized void addDiscoveryListener(DiscoveryListener listener) { }

private Vector search(int type,String attr, String value, int entrypoint,boolean bytes) { }

private String advToString(Advertisement adv) { }

}

Requests of Requestor Agent are expressed in terms of constraints. Constraints

represent the requirements for the service to be found. In ACG, constraint language of

service discovery is based upon XML. Constraints are passed as strings to the constructor

of the XML class. During construction, the constraint is parsed and the expression tree is

created. The Requestor Agent calls SearchService( ) to ask the local Grid Service Manager

to search for Grid Service Managers containing registered services with a particular

constraints. The local Grid Service Manager returns the list of GSM-IDs to the Requestor

Agent. The Grid Service Manager with the GSM-ID included in the list has information

about Grid Service Agent that can provide the service requested by the Requestor Agent. If

Grid Service Manager is a parent manager it performs the search on the parent Grid

Service Registry that should contain information on all registered services in the grid. If

the local Grid Service Manager is a child manager, it will find a local service if a suitable

one is available otherwise it will query a parent node for a suitable service. The searching

process can also explicitly request a parent Grid Service Manager search. When multiple

parent managers are available, the child manager has the option of selecting a parent based

on some criteria such as node load. GSA provides an XML Description describing its

functionality and properties when it registers into GSM. When a service requestor agent

wants to use a service, it creates a XML DOM object describing the service it needs along

with constraints. Service requestor agent then finds the appropriate service using the XML

match. The XML match handles constraints such as requirements, cost etc. For instance,

Service requestor agent can ask that the service cost less than some amount, or that it must

have some special functions or requirement. Similarly, the matching process ensures that a

service requestor agent gets only those services, which it is capable of executing in the

required hardware or software environment. The register( ) method invoked by GSA is

declared in the Registration interface, which all Registry objects implement. GSA talks to

Grid Service Manager through the Registry object by invoking methods declared in the

Registration interface. Once GSA’s service has registered with Grid Service Manager, that

service is available for use by service requestor agents that will query GSM. Service

requestor agent must find and enlist the help of GSA to perform some task. To find a

service, service requestor agents query Grid Service Manager by invoking the locate( )

method on Registry object. The service requestor agent passes a XML service template as

an argument to locate( ) method, XML service template serves as search criteria for the

query. The locate( ) method sends the XML service template to GSM, which performs the

query and sends back many matching service descriptions.

If the Requestor Agent does not specify any particular constraints when it calls

SearchService( ), the list of all the GSM-ID of Grid Service Managers known to the local

Grid Service Manager is returned. The Requestor Agent calls Queryservice( ) to discover


what grid services are registered at a Grid Service Manager. The Requestor Agent may

specify either the local Grid Service Manager or a remote Grid Service Manager. The

specified Grid Service Manager automatically responds to this query as well as to the

SearchService( ) without involving the specified Grid Service Manager.

5.2. Grid service subscription protocol

The GSSP is responsible for grid service detection and subscription (see Fig. 3). GSSP

allows user/requestor agents to dynamically subscribe some services for a finite time

period. A grid service can be subscribed before it can be configured or used by the user/

requestor agent. The Subscription Service object provides the functionality to locate and to

subscribe/unsubscribe services. It contacts a Grid Service Manager in order to find

available services, and interacts with the service subscription server. This interaction is

necessary to prepare service usage in case of a grid service subscription. The service

subscription server manages all related information of services subscribed by a user/

requestor agent. This information is stored in a Service Subscription Object, which

comprises a formal description of the service and user specific service data. After a grid

service registers itself with a subscription server for the duration of time, a user agent can

present a request to the subscription server to subscribe the service, the request specifies

the parameters of the subscription: start time, duration, entities that participate in the

subscription, and the enforcement mechanism used to control service access during

the subscription. If the requested service is available, the subscription service then grants

the subscription, notifying the “subscribed service” and the users on subscription start/

stop. Service Subscription Server is responsible for the storage and retrieval of grid service

specific data for subscribed services. By means of this server it is possible for GSM to

determine, if the user agent has subscribed a certain grid service and to get hold of the

corresponding user service subscription object.

For each subscribed grid service there exists a service subscription object, which

comprises a reference to the grid service agent, from which the service was subscribed, the

subscription duration (beginning/end of service subscription), a formal service descrip-

tion. If the subscribed grid service is a special type service, GSM contains an additional

service description object, specifying the service. The grid service agent reference is

stored directly in the service subscription object, which can be obtained via getservice( ).

Via listServices( ) GSM can determine all services subscribed by the user agent. This

Fig. 3. The process of GSSP.


method returns a list of references to service subscription objects, which can be used to

present the users a list of their subscribed services, so they can make use of the service

(make a call), or unsubscribe it. Whenever a service is subscribed by the user, a new

service subscription object is created by the subscription component, which is then

inserted into the service subscription server by invoking addService( ) with the service

subscription reference as argument. Similarly, if a subscribed service will be unsubscribed

(or the subscription expires), the subscription component invokes removeService( ), also

with the service subscription reference as argument.

If an user agent requests a certain service, GSM searches for a suitable service by

invoking lookupService( ), which takes a service description object as argument. If one is

subscribed, its related service subscription reference is returned, otherwise an exception

occurs. The beginning and end of a service subscription is stored in a duration object. The

start time can be obtained by invoking getStartTime, while the stop time may be

determined by invoking getStopTime( ).

Via listAvailableServices( ) GSM can locate all available grid services in response.

This method returns a list of strings containing textual service names, which can be

presented to the user agent for selection. If the user agent decides to subscribe a grid

service, GSM invokes subscribeService( ) with the textual grid service name as argument.

If the service is available, a grid service agent reference is determined and stored together

with other grid service information in a service subscription object. This object is then

passed to the service subscription server, which is responsible for the management of the

data of subscribed services. By invoking unsubscribeService( ) GSM can unsubscribe a

subscribed grid service. Therefore it passes the reference of the service subscription object

to the method, which then deletes all service related data. A list of descriptions of all

subscribed services can be obtained by invoking listSubscribedServices( ).

SuscriptionServiceObject defines the interface between a subscribed service and a

subscription service—a subscription service communicates with a subscribed service

using a proxy object which implements the methods of this interface. This is not a Remote

interface, each implementation of a subscribed service exports proxy objects that

implement the SubscriptionServiceObject interface local to a subscription service, using

an implementation specific protocol to communicate with the actual remote manager. All

of the proxy methods obey normal RMI remote interface semantics except where

explicitly noted. Two proxy objects are equal if they are proxies for the same subscription

service.

All subscribed services implement the methods of this interface. A subscribed service

adds a temporal element (the subscription) to its access control decisions. When a concrete

implementation of a service is subscribed, it is presented with a credential for each user,

which is authorized to use it while the subscription is in effect. A subscribed service

enforces access control during a subscribe usage period by determining if the client has a

valid subscription and by verifying that the user has the appropriate permissions. If access

is granted, the subject is allowed to execute the privileged action.

By the method StartSubscription( ), a subscription period of a grid service begins. A

well-behaved service will only be accessible to the users specified in the Subscription-

Control argument once this method is called. The users must also possess any other

permission required in order to use this SubscriptionServiceObject. The service will delete


the SubscriptionControl when the reservation expires. A subscription period for this

service is stopped by StopSubscription( ). When this method is invoked the service should

perform whatever activities it needs to perform in order to end a reservation. The service

should also perform any cleanup and/or state restoration actions required.

† public interface SubscriptionServiceObject

† {public SubscriptionLease StartSubscription(SubscriptionServiceID SSD, long dur-

ation,

† SubscriptionID id, SubscriptionControl list) throws Exception;

† public void StopSubscription(SubscriptionServiceID SSD, SubscriptionID id) throws

Exception;

† }

A helper class SubscriptionControl facilitates access control of subscription services.

SubscriptionControl encapsulates fields and methods used to manage a subscription of a

service: the credentials for the authorized users and the method which should be invoked

on the service to enforce access control during the subscription period A subscription list

includes the credential for each authorized user along with any associated permissions

required during the subscription period. When a subscription is activated, the associated

SubscriptionControl is presented (is an argument in the call of beginSubscription( )). The

service then uses the checkSubscription( ) method of the supplied SubscriptionControl to

determine if the calling user should be allowed to execute the action. When

endSubscription( ) is called, the service clears its SubscriptionControl, allowing method

invocation for all authorized clients, and invokes its cleanup method, ostensibly to cleanup

the reserved service’s states.

5.3. Grid service access protocol

Grid Service Access Protocol is used for service requestor agent to access the located

service (see Fig. 4). Once a requestor agent receives the Reply Description of a Grid

Service Manager, it can start communication with the GSM to use the services. Some

methods and messages are defined to utilize a service provided by a Grid Service Manager.

The local Grid Service Manager is GSM that the requestor agent is calling, and the remote

Fig. 4. Grid Service Access process.


Grid Service Manager is any other Grid Service Manager. The local Grid Service Manager

may actually be in a remote node if the Requestor agent is calling the services through

Remote Procedure Call.

When a Requestor agent wants to use a service provided by a Grid Service Agent under

a Grid Service Manager Protocol, it requests a Grid Service Manager to establish a Service

Session. The Requestor Agent calls ConnectService( ) to ask the local Grid Service

Manager to initiate a service session with a specific Service agent registered at either the

local Grid Service Manager or a remote Grid Service Manager. The Grid Service Manager,

with which the specified grid services is registered, calls ConnectService( ) to notify the

grid service agent of this Connect Service request. The grid service agent may either

accept or reject the request. The result is communicated back to the Requestor Agent

through the return parameter of the ConnectService( ) call. Once the Service session is

established, the Requestor Agent calls SendMessage( ) to ask its respective local Grid

Service Manager to send Requestor Agent-specific data to the other end of the Service

session. The Grid Service Manager at the other end calls ReceiveMessage( ) to pass the

Requestor Agent-specific data received from the other end of the Service session. After

Connection session completes, the Requestor Agent calls EndConnection( ) to ask the

local Grid Service Manager to terminate the Service session. The specified Grid Service

Manager calls EndConnection( ) to notify that the Service Session is terminated.

6. Experiment

Based on the prototype implementation of the proposed model, a basic performance

evaluation was done. Our experiment focuses on overhead of locating a Grid service agent.

The experiment environment consists of twelve machines and a 10 Mb Ethernet adapter.

Every machine has a 300 MHz Pentium processor and 128MB RAM. These machines run

Windows NT 4.0 and the agent execution environment use JDK 1.1. These machines are

located in different subnets. Grid Service Manager is populated with different number of

agents. Timing measurements are made on machines that host agents. There are two main

factors that affect results, one is network latency, and another is machine speed. All the

experiments are repeated at least three times. In the experiments we change some of test

parameters, such as the number of agents used in the test, number of machines comprising

service discovery networks that are denoted by M in bellow figures. We devise tests with

local search and global searches. The size of the agent code without additional data is

around 1.6Kb.

In the first experiment, we also measure times to locate service agents locally vs.

number of agents returned by lookup with different number of lookup agents. We use

twenty, thirty, and fifty lookup agents, respectively, to measure search times. Fig. 5 shows

that time for lookup of many agents increases proportionally to number of agents returned

by the lookup. In the fourth experiment, we measure times to locate service agents globally

vs. number of agents returned by lookup with different number of lookup agents (lookup

20, 30, and 50 agents, respectively) and configure four machines comprising agent/

resource discovery networks ðM ¼ 4Þ: The results are presented in Fig. 6. In this case, it

was interesting to observe that before the number of agents returned by lookup increases to


12, the curves of 30 lookup agents and 50 lookup agents are very close. But from entire

figure, time increases proportionally to number of agents returned by the lookup. In the

fifth experiment, we use eight machines to comprise agent discovery network ðM ¼ 8Þ and

other conditions are as same as third experiment. As can be seen in Fig. 7, the difference of

three curves is small. The curve of 30 lookup agents is parallel to the curve of 50 lookup

agents. In the sixth experiment, the number of machines is increased by 12 ðM ¼ 12Þ and

other conditions remain unchanged. As can be seen in Fig. 8, time of lookup 50 agents

increases dramatically to number of agents returned by the lookup.

Fig. 5. Local search time vs. number of agents returned.

Fig. 6. Global search time vs. number of agents returned ðm ¼ 4Þ.

Fig. 7. Global search time vs. number of agents returned ðm ¼ 8Þ:


Results of above performance evaluations are approximate, but are illuminating. Some

conclusions can be made. Firstly, locating agents globally spend more times than locating

agents locally. Secondly, time to locate many agents increases proportionally to number of

agents returned by the lookup. Further experiments are in progress to refine original

results.

7. Related work and discussion

First, we describe several important computational grid projects that inspire ACG grid.

Then we compare our project with others.

An agent-based grid-computing project is described in(Rana and Walker, 2000). This

work on an ‘Agent Grid’, integrates services and resources for establishing multi-

disciplinary problem solving environments. Specialized agents contain behavioral rules

that can be modified based on their interaction with other agents and the environment in

which they operate. Globus (Foster and Kesselman, 1998) provides software infrastructure

that enables applications to view distributed heterogeneous computing resources as a

single virtual machine. Globus is constructed as a layered architecture in which higher-

level services can be developed using the lower level core services. Globus offers Grid

information services via an LDAP-based network directory called Metacomputing

Directory Services (MDS). Thus MDS follows both push and pull Process for resource

dissemination. Higher-level tools such as resource brokers can perform resource discovery

by querying MDS using LDAP protocols. The MDS namespace is organized

hierarchically in the form of a tree structure. Globus offers QoS in the form of resource

reservation. The resource brokers can use heuristics for state estimation while performing

scheduling or re-scheduling whenever the status of the Grid changes. The DARPA CoABS

(Control of Agent Based Systems) project (The CoABS DARPA Project) aims to develop

agent systems for offering specialized services, such as component interaction managers,

database wrappers, traders/brokers, to resource planners and interactions managers. The

CoABS Grid provides a framework for integrating diverse agent-based systems in a robust

and agile manner. Agents and object-based systems dynamically register and discover

relevant participants in order to collaborate meaningfully. Systems evolve, join and leave

the Grid over time without the necessity to reconfigure the network. If systems become

Fig. 8. Global search time vs. number of agents returned ðm ¼ 12Þ:


unavailable due to partial network failures, other similar systems can be discovered and

substituted for the missing systems. A4 (Agile Architecture and Autonomous Agents)

methodology (Cao et al., 2001), which can be used for resource management for grid

computing. An initial system implementation utilizes the performance prediction

techniques of the PACE toolkit to provide quantitative data regarding the performance

of complex applications running on local grid resources. At the meta-level, a hierarchy of

identical agents is used to provide an abstraction of the system architecture. Each agent is

able to cooperate with other agents to provide service advertisement and discovery to

schedule applications that need to utilize grid resources. A performance monitor and

advisor are in development to optimize the performance of agent behaviors.

Condor (Basney and Livny, 1999) is a high-throughput computing environment

developed at the University of Wisconsin at Madison. It can manage a large collection of

computers such as PCs, workstations, and clusters that are owned by different individuals.

The Condor collector, which provides the resource information store, listens for

advertisements of resource availability. A Condor resource agent runs on each machine

periodically advertising its services to the collector. Customer agents advertise their

requests for resources to the collector. The Condor matchmaker queries the collector for

resource discovery that it uses to determine compatible resource requests and offers. The

agents are then notified of their compatibility. The compatible agents then contact each

other directly and if they are satisfied, then the customer agent initiates computation on the

resource. Resource requests and offers are described in the Condor classified

advertisement (ClassAd) language. ClassAds use a semi-structured data model for

resource description. Thus no specific schema is required by the matchmaker allowing it to

work naturally in a heterogeneous environment.

Legion (Chapin et al., 1999) is an object-based metasystem or Grid operating system

developed at the University of Virginia. Legion provides the software infrastructure so that

a system of heterogeneous, geographically distributed, high performance machines can

seamlessly interact. Legion provides application users with a single, coherent, virtual

machine. The Legion system is organized into classes and metaclasses. Legion appears as

a complete vertically integrated system, its architecture follows the hierarchical model. It

uses an object based information store organization through the Collection objects.

Collections periodically pull resource state information from host objects. Host objects

track load and users can call the individual host directly to get the resource information.

Information about multiple objects is aggregated into Collection objects. Users or system

administrators can organize collections into suitable arrangements.

Compared with above grid projects, our ACG grid provides a uniform higher-level

management of the computing resources and services on the Grid, and provides users

with a consistent and transparent interface for accessing such services. All entities in the

Grid environment including computing resources and services can be represented as

agents. An ACG Grid service can be a service agent that provides the actual grid service

to the other grid member. Grid members communicate with each other by

communication space that is an implementation of tuple space. ACG supports grid

service subscription that allows user/requestor agents to dynamically subscribe some grid

services for a finite time period. A grid service can be subscribed before it can be

configured or used by the user/requestor agent.


8. Conclusions

In this paper, we have presented an agent based grid service management. This paper

mainly describes three grid protocols for grid resource management. They are GSDP,

GSSP and GSAP. Grid members communicate with each other by communication space

that is an implementation of tuple space. Some basic performance evaluations are made.

Acknowledgements

The authors thank editor-in-chief and the anonymous reviewers for their useful

comments and suggestions. The work is supported by National Natural Science

Foundation of China and NSF of Hubei Province.

References

Basney J, Livny M, Deploying a High Throughput Computing Cluster, High Performance Cluster Computing, NJ,

USA: Prentice Hall PTR; 1999. Vol. 1, Chapter 5, pp. 84–96.

Buyya R, Abramson D, Giddy J. Nimrod/G: An Architecture for a Resource Management and Scheduling System

in a Global Computational Grid, International Conference on High Performance Computing in Asia-Pacific

Region (HPC Asia 2000), Beijing, China. USA: IEEE Computer Society Press; 2000b.

Buyya R, Chapin S, DiNucci D. Architectural Models for Resource Management in the Grid, First IEEE/ACM

International Workshop on Grid Computing (GRID 2000). Germany: Springer Verlag LNCS Series; 2000a.

December,17.

Cao J, Kerbyson DJ, Nudd GR, Performance Evaluation of an Agent-Based Resource Management Infrastructure

for Grid Computing, Proceedings of 1st IEEE/ACM International Symposium on Cluster Computing and the

Grid. Brisbane, Australia, 311–318, May 2001.

Chapin S, Karpovich J, Grimshaw A. The Legion Resource Management System. Proceedings of the 5th

Workshop on Job Scheduling Strategies for Parallel Processing; 1999. pp. 162–178.

Chunlin L, Layuan L. A Java-based Multi-tier Distributed Object Enterprise Computing Model. J. Syst. Eng.

Electroc. 2001;12(4):85–90.

Chunlin L, Layuan L. An Agent-oriented and Service-oriented Environment for Deploying Dynamic Distributed

Systems. Journal Computer Standard and Interface 2002;24(4):321–34. Elsevier.

Chunlin L, Zhengding L, Layuan L. A Distributed Computing Model and its Application, IEEE ICCNMC 2001.

IEEE Computer Society Press; 2001. p. 341–6. October.

Chunlin L, Zhengding L, Layuan L. Design and implementation of a distributed computing environment model

for object-oriented networks programming. Journal of Computer Communications 2002;25(5). Elsevier,

March.

Chunlin L, Zhengding L, Layuan L, Shuzhi Z. A Mobile Agent Platform Based On Tuple Space Coordination.

Journal of Advances in Engineering Software 2002;33(4):215–25. Elsevier.

Foster I, Kesselman C, The Globus Project: A Status Report, IPPS/SPDP ’98 Heterogeneous Computing

Workshop, pp. 4–18, 1998.

Foster I, Kesselman C. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann; 1999.

Frank Manola and Craig Thompson, Characterizing the Agent Grid. Technical Report, Object Services and

Consulting, Inc.http://www.objs.com/

Krauter K, Buyya R, Maheswaran M. A Taxonomy and Survey of Grid Resource Management Systems.

Software: Practice and Experience 2002;32(2):135–164.

Litzkow M, Livny M, Mutka MW. Condor—A Hunter of Idle Workstations. Proceedings of the 8th International

Conference of Distributed Computing Systems; 1988. June.


http://www.objs.com/

Rana OF, Walker DW. The Agent Grid: Agent-based Resource Integration in PSEs. Proceedings of 16 th IMACS

World Congress on Scientific Computation, Applied Mathematics and Simulation, Switzerland: Lausanne;

2000.

The CoABS DARPA Project, Control of Agent Based Systems,http://coabs.globalinfotek.com/

Li Chunlin was born in 1974. She received the BE and ME degrees in computer science from Wuhan

Transportation University, China in 1997 and 2000, respectively. She is currently a PhD candidate in the

Department of computer Science and Technology in Huazhong University of Science and Technology. She is

also a lecturer of Computer Science in Wuhan University of Technology. Her research interests include

mobile agent, distributed computing and computational grid. She has published over 10 Papers.

Li Layuan was born in Hubei, China on 26 February 1946. He received the BE degree in Communication

Engineering from Harbin Institute of Military Engineering, China in 1970 and the ME degree in

Communication and Electrical Systems from Huazhong University of Science and Technology, China in

1982. He academically visited Massachusetts Institute of Technology, USA in 1985 and 1999, respectively.

Since 1982, he has been with the Wuhan University of Technology, China, where he is currently a Professor

and Ph.D. tutor of Computer Science, and Editor in Chief of the Journal of WUT. He is Director of

International Society of High-Technol. and Paper Reviewer of IEEE INFOCOM, ICCC and ISRSDC. He was

the head of the Technical Group of Shaanxi Lonan PO Box 72, Ministry of Electrical Industry, China from

1970–1978. His research interests include high speed computer networks, protocol engineering and image

processing. Professor Li has published over one hundred and fifty technical papers and is the author of six

books. He also was awarded the National Special Prize by the Chinese Government in 1993.


http://coabs.globalinfotek.com/

apply agent to build grid service management

Documents