A WS-Agreement Based Resource Negotiation Framework for Mobile Agents

A WS-AGREEMENT BASED RESOURCE NEGOTIATIONFRAMEWORK FOR MOBILE

AGENTS

D. G. A. MOBACH, B. J. OVEREINDER, AND F. M. T. BRAZIER

∗

Abstrat. Mobileagentsrequire aess to omputingresoureson heterogeneous systemsaross the Internet. They need

tobeabletonegotiate theirrequirementswiththe systemson whihthey wishtobehosted. Thispaper presentsanegotiation

infrastruturewithwhihagentsaquiretime-limitedresoureontratsthroughnegotiationwithoneormoremediatorsinstead

ofindividualhostingsystems.Mediatorsrepresentgroupsofautonomoushosts. Thenegotiationprotoolandlanguagearebased

ontheWS-AgreementSpeiation,andhavebeenimplementedandtestedwithintheAgentSapeframework.

Keywords. mobileagents,resouremanagement,agent-basednegotiation,WS-Agreements

1. Introdution. One of the assumptions behind the mobile agent paradigm in open, heterogeneous

environmentsisthatagentswill haveaess toomputingresoures. Littlethoughthasbeengiventotheway

in whih this anbe implemented. Not only do they need aess, theyneed to be able to plan oordinated

resoureusagearossmultipledomains. Reently,negotiationoftheonditionsandqualityofservieofresoure

aess hasbeenonsidered to bean importantapability fordistributed, servie-orientedarhitetures. This

paperfousesonthenegotiationofresoureaessformobileagentappliationsdeployedonInternet-sale,open

distributed systems. The resouresrequired byagentsanvary from CPU type,bandwidth, to the provision

ofspei servies(e.g.,databases,webservers,et.),andlevelofseurityrequired,dependingonthetaskat

hand. Well-dened,openprotoolsandmehanismsareneessaryforagentstonegotiatetheirresoureaess

requirementswithheterogeneoushosts.

Thispaperpresentsanegotiationinfrastruturewithin whih individual agentsaquire time-limited

on-tratsfortheresourestheyneed,throughnegotiationwithoneormoresystemdomainoordinators: mediators

representingmultipleautonomoushosts.Theprotoolswithwhihagentappliations,domainoordinators,and

hostsinterat,arebasedontheWS-AgreementSpeiation[1℄withappliationdependentdomainontologies

forspei resoures.

Thenextsetionspresentthenegotiationinfrastruture,inludingthemodelandthearhiteture. Setion4

desribesaspei implementation ofthis arhiteturewhih isintegratedwithin theAgentSapeframework.

Theappliationdependentdomainontologyforspeiomputerresouresispresentedtogetherwithexamples

oftheWS-Agreementbasedprotool. InSetion5,twodierentpoliiesforrequestdistributionbythedomain

oordinatorsareomparedempiriallyandevaluated. Thepaperonludeswithrelatedworkanddisussion.

2. Negotiationinfrastruture. Theoverallgoalanduseofthenegotiationinfrastrutureistoallowfor

thenegotiationoftermsofonditionsandqualityofservieofresoureaessbyagents. Thenegotiationmodel

inludestheexhangeofagreementoersandaeptaneoftheoersbetweendierentparties.

2.1. Design Goals. The negotiationinfrastruture hasto deal with(i) largenumbersof heterogeneous

agents,and(ii)dynamigroupsofheterogeneoushostseahwiththeirownspei setsofrequirements.

Fromtheagent'sperspetive,thenegotiationinfrastruturedenesauniformandstraightforward

negoti-ation protool and well-dened interfae. Agents are notinterestedin knowinghowthe proessof alloating

spei resouresto spei hostsisahieved: theirinterestisto aquiretheresourestheyneed. The

negoti-ationinfrastrutureneedstohide thedetailsfromtheagentappliations.

Ontheother side,hostsneedto keepfullontrolovertheirownsystem,overtheuseoftheirresouresby

agent appliations. Negotiation poliies spanning multiple hosts,allowingspeiationof resoureaessand

usagepoliiesoveraset of hosts(e.g., for loadbalaning purposes, orvirtualorganization-widepoliies, et.)

mustalsobefailitated.

2.2. Negotiation Model. In our negotiation model, hosts (H) are autonomous entities that provide

resoures(R)toagents (A)underspeiusageandaesspoliies. Hostsareaggregatedintovirtualdomains.

The domain oordinator (DC), represents the hosts (H) within a virtualdomain in the negotiation proess,

negotiatingwithbothagentsandhosts. Figure 2.1showsanoverviewofthemodel.

∗

IIDSGroup,DepartmentofComputerSiene,VrijeUniversiteitAmsterdam,deBoelelaan1081a,1081HVAmsterdam,The

R

R

R

R

R

A

H

H

DC

Fig.2.1.Negotiationmodeloverview.

Theuseofamediatingdomainoordinatormakesatwo-layerednegotiationproesswithinthemodel

pos-sible. Agentsnegotiateresoureaess withdomainoordinators,anddomain oordinators,inturn, negotiate

with groups of host managers in virtual domains to obtain the atual resoures agents require. The results

of negotiation aretime-limited ontratsspeifying whih resouresmay be aessed during thetime span of

theontrat,and underwhih onditionsthe resouresmaybeused. Agentsannegotiatetheiroptionswith

domainoordinatorsofmultiple domains,andselettheDC thatprovidesthebest oer.

In themodel presentedin this paper, a domain oordinator representsa virtualorganization of resoure

providers. Agentsareunawareoftheindividualresouresbehindadomainoordinator: adomainoordinator

isviewedbyagentstobeasinglevirtualresoureprovider. Thetaskofseletingoneappropriateoer(basedon

theavailableresouresataspeipointintime)hasbeendelegatedtothedomainoordinator. Alternatively,a

domainoordinatorouldreturnasetofpossibleoers,lettingarequestingagenthoosethemostappropriate.

Themodelpresentedin this papersupports both options,but onlytherst is disussed. Setion 6addresses

theseondoptionin moredetail.

The negotiationprotooland languageused in ournegotiation model are basedupon theWS-Agreement

Speiation [1℄. This speiation denes theformat used to speify agreement desriptionsand agreement

interations. 1

The speiation denes an XML-based language for agreements between resoure providers

(hosts) andonsumers(agents),and aprotool forestablishingthese agreements(these agreementsare

time-limitedontratsinourmodel). Agreementtermsareusedtodesribethe(levelsof)servieinvolved. Twotypes

oftermsaredistinguishedforagreementspeiations: (i)serviedesription terms,desribingtheserviesto

bedeliveredunder theagreement,and (ii)guarantee terms,expressingtheassuranesonserviequality(e.g.,

minimumbounds)for theserviesdesribedin theservie desriptionterms. An agreementspeiationalso

ontainsaontext setion, ontainingmetainformation abouttheagreement(seeFigure2.2). This setionof

the agreement an beused to speify theparties of the agreement,the duration of the agreement, et. The

speiationofdomain-speitermlanguagesisexpliitlyleftopen.

TheWS-Agreementinteration model(seeFigure 2.3)denesthatonsumers(C)anrequestagreements

fromresoureproviders(P)byissuinganagreementrequest basedonavailableagreementstemplates,whih,if

aepted,resultin newagreements.

Intheproposednegotiation model, hosts provide anagreementinterfaeto thedomain oordinator. The

domain oordinator aggregates the templates oered by the hosts into omposed templates. The domain

oordinator makes these ombined templates available to agents. Agreement requests made by agents are

reeived by the domain oordinator. The domain oordinator negotiates an agreement with the hosts with

requestedresoures.

Theinteration protool asspeied in theWS-AgreementSpeiationonlyallowsfor asinglerequest,

aeptinteration,inwhihtherequestingpartyreeiveseitheranaept ofrejet messagefromtheproviding

partyasaresponsetoan agreementrequest. Thisis averylimitedinteration model. Inthemodelproposed

in this paper,anadditional aept/rejet interation sequeneis introdued, allowingtherequesting party to

1

Agreement

Context

Service

Description

Terms

Guarantee

Terms

Agreement

Fig.2.2. WS-Agreementontents.

C

P

C

P

C

P

template

agreement request

agreement

Fig.2.3.WS-Agreementprotool.

expliitlyaeptorrejet anoerreatedbytheprovidingparty. Forexample,in theontextofmobileagent

appliations,thisallowsagentstonegotiatewithmultiple domainoordinatorssimultaneously,andaeptthe

best oerfrom thesetofoersreeived. Additionally,anexpliitrequestfor templates interationisspeied.

Thisstepintheprotoolallowsfortheinitialexhangeofinformationbetweenagentsandadomainoordinator,

forexampleforauthentiationpurposes. Figure2.4showstheextendedinteration model.

DC

DC

DC

DC

DC

agreement request

A

template

A

A

agreement offer

A

accept/reject

A

for templates

request

Fig.2.4. ExtendedWS-Agreementprotool.

3. NegotiationArhiteture. Thenegotiationarhiteturedenesthesubsystemsandinterfaesofthe

3.1. Host Manager. A host manager is responsible for providing and managing resoures on its host

(see Fig.2.1). This inludes funtionality fornegotiation, reation, and enforement ofagreements. It is the

responsibility of the hostmanager to translateresoureusage and aess poliies into templates on demand.

These templates speify whih resouresan bemade available at a spei point in time. The oer ahost

makesonrequestof adomain oordinatoris basedon thesetemplates. After thenegotiation phase,thehost

managermonitorsandontrolstheresoureusagetoensurethatagreementsarehonored.

Figure 3.1 shows the arhiteture and negotiation interfae of a host manager. The agreements in the

model aretime-limited ontrats: agreementsthat expireafter somepredetermined time. Inthe presentation

ofthearhiteture,thetermleaseisusedinsteadoftime-limitedontrat. Eahhostmanagerisequippedwith

threemodules: aleasing module,implementingthemainnegotiationfuntionality;apoliymanager ontaining

resourepoliies, whihareappliedbytheleasingmodule; aresouremanager withresourehandlers,allowing

monitoringandontrol ofresoureaess. Theomponentsofthehostmanagershownin Fig.3.1are further

desribedbelow.

Template

Management

Management

Lease

Other

Host

Manager

Modules

R

R

Resources

Resource

Policy

Resource

Policy

Host Manager

acceptLease(...)

requestLeaseStatus(...) requestLease(..)

requestTemplates()

Request

Processor

Resource Manager

Handler

Resource

Handler

Resource

Policy Manager

Leasing Module

Fig.3.1. ComponentswithintheHostManager.

3.1.1. LeasingModule. Theleasingmoduleinthehostmanagerimplementsthenegotiationand

agree-mentprotool. Thefuntionalityoftheleasingmoduleisavailableviatheinterfaeofthehostmanager.

Leasing Interfae. Theleasing interfaeoered by host managersto their loation manager ontainsthe

followingalls:

•

requestTemplates(): template-list Requesttheavailableleasetemplates.

•

requestLease(LeaseRequest): lease

Requestaleasebasedonthesuppliedleaserequest.

•

aeptLease(LeaseID)

Aeptalease. Returnstheaeptedleasedoument.

•

requestLeaseStatus(LeaseID): lease

Request theurrentstatus ofalease. Returnsalease doument,inludingthe urrentstatus ofeah

term.

RequestProessor.

•

Creatingleaseoers. Thisinvolvesdeterminingtheavailabilityoftherequestedresoures,andreating oersbasedontheinomingrequest, resoureusageandaess poliies, andtheurrentstatus ofthe

resoures.

Template Management.

•

Creatingtemplatesbasedonavailableresoures,resoureusage,andaesspoliies,andatively main-taining this information. Note that poliies an be dynami, that is, hange over time (e.g., half of

available apaity an be reserved during oe hours, omplete apaity is available outside oe

hours).

LeaseManagement.

•

Enforingtheaeptedleases. Thisinvolvesensuringthat theresouremanagermoduleperformsthe requiredresourenegotiationtasks.

•

Handling expiration of leases. This involves freeing theresoures speiedin the expired lease, and possiblysendingnotiationsofleaseexpirationtothedomainoordinator.

•

Maintaininglease oers: removing theoersafter aertain set time, orimplementingthe oerafter notiationofaeptanehasbeenreeived.

•

Handlingrequestsforstatusinformationontherunningleases.

•

Handling violation of leases. In ases where resoure usage annot be stritly enfored, and only monitoringan be performed, lease violations should be handled. When an appliation violates the

onditionsset in a lease, appropriate ationsshould be performed, suh assuspending or killing the

violatingagent.

3.1.2. PoliyManager. Thepoliymanagermodule ontainsresourepoliy desriptionswhihanbe

usedbytheleasing moduleduring theproessingof requests. Poliiesanbedenedforspei resoures,or

poliies an be dened overingother aspets of inomingrequests (identity of therequesting appliation,or

globalhostpoliiessuhasthetotalnumberofrequests,et.). Aresourepoliyanontainstatiinformation,

suhasthemaximumnumberofallowedrequestsforaresoure,butanalsorefertothemonitoringapabilities

of resourehandlers to inorporate up-to-date monitoringdata onerning the resouresto whih the poliy

applies.

3.1.3. ResoureManager Module. Theresouremanagermoduleontainsasetofresourehandlers,

enablingtheleasingmoduletomanageresouresavailableonthehost. Eahresoureatahostisrepresentedby

aresourehandler. Thehandlerimplementsaresoureindependentinterfaefortheleasingmoduletomonitor

andontroltheresoures. Eahresourehandlersupports: (i)reationof resourereservationsbasedonlease

oers;(ii)implementationofthereservation,whihativatestheresourehandlertostartmonitoringresoure

onsumptionwithrespettoaeptedleases;(iii)releaseofareservation,freeingtheresoure(amount)related

toexpiredorviolatedleases. Eahresourehandleralsosupportsamonitoringinterfae,allowingforretrieval

ofresourespeimonitoringinformation, tobeusedin,forexample,resourepoliies.

•

reserve(LeaseRequest): RefereneID

Canbeusedtoreservearesoure(amount)foraspeileaserequest. Theresourehandler inspets

therequest,andreatesareservation. A refereneidentierisreturnedtoenablefurthermanagement

ofthereservation.

•

implement(RefereneID): void

Usedtorequestimplementationofareservation(indiatedbyRefereneID).

•

release(RefereneID): void

Releaseanimplementedresourereservation(indiatedbyRefereneID).

•

getStatus([RefereneID℄): status

Usedtorequestthestatus ofareservation. Returnedvalueanbeoneof: initialized,reserved,ative,

violated.

•

getMonitorValue(SensorID): domain_speifi_value

Usedtorequestresourespeimonitoringinformationonerningaresoure.

3.2. Domain oordinator. The domain oordinator abstratsfrom theindividual hosts (resoure

pro-viders) and presents the aggregated resoures as one virtual resoure provider. The domain oordinator is

nator,in turn, requests andreeivesinformation onavailabilityof resouresfromitshosts,and ombines this

informationif,andwhenappropriate,toonstrutappliationdiretedtemplates.

Oneatemplate-basedrequestisreeivedfromanappliation,thedomainoordinatorpursuesdelegationof

resourestohosts. Uponreeivingthehostbids,thedomainoordinatorhoosesbasedonavailabletemplates,

hostanddomainpoliies, andreturnsaproposedleaseifpossible. Ifaproposedleaseisaepted,thedomain

oordinatorisresponsibleitseetuationandenforement.

Figure3.2showsanoverviewoftheleasingmodulewithinthedomainoordinator.

Template

Management

Management

Lease

Other

Location

Manager

Modules

Request

Processor

acceptLease(...)

requestLeaseStatus(...) requestLease(..)

requestTemplates()

Host Managers

Leasing Module

Fig.3.2. Leasingomponentswithinthedomainoordinator.

RequestProessor. Thisomponentisresponsibleforthefollowingtasks:

•

Proessingrequestsfortemplatesbyappliations. Thisimplieshekingpoliiestodeterminetowhih templateinformationtheappliationisentitled.

•

Proessingrequestsforleasesbyappliations. This involvesdeterminingwhether therequestisbased onavalidtemplate, andwhethertherequestexeedstheboundssetbythat template.

•

Handling leaseoers returned by hosts in response to requests. If more than onehost was sent the same request, a hoie has to be made between their oers. In addition, if the oers are part of a

requestbaseduponaombinedtemplate,theoersareombinedintoasingleoerfortheappliation.

Further, whenaleaseproposalis aeptedbyanappliation,thehosts oeringtheleaseareinformed

ofaeptane.

•

Determiningfromwhihhostsoersarerequested. Thisinvolvesdeterminingwhihhost(s)areoering relevant templates, and possibly splitting the request into multiple requests for dierent hosts, if a

ombinedleasetemplatewasused bytheappliation.

TemplateManagement. Thisomponentrequests,reatesand maintainsinformation aboutthetemplates

onwhih leasesarebased. This omponentperformsthefollowingtasks:

•

Obtainingandmaintainingtemplateinformationofthehostsurrentlyinthedomain.

•

Creatingtemplate ombinations of resouresfrom multiple hosts in a singletemplate. This involves applyingloaltemplate poliiesspeifyingwhihhosttemplatesanorannotbeombined.

LeaseManagement. Theleasemanagementomponentmaintainsinformation aboutleases,leaserequests

madebyappliations,andleaseproposalsfromhosts,andperformsthefollowingtasks:

•

Maintaining status information of urrentvalid leases. This involves ativelyor passively retrieving leasestatus informationfrom thehosts responsibleforenforingtheleases atingappropriatelyupon

leaseexpiration.

•

Maintaininginformationofurrentlyoutstandingleaseproposals.

4. AgentSapeNegotiationArhiteture. Thenegotiationarhiteturedesribedabovehasbeen

im-plementedin theAgentSapeframework,aframeworkforheterogeneous,mobileagents. Thissetiondesribes

4.1. AgentSape. The AgentSape middleware [8℄ onsists of two layers. At the base of the

middle-ware is the kernel, oering low-level seure ommuniation between middleware proesses, and failities for

seureagentmobility. OntopoftheAgentSapekernel,middlewareproessesprovidehigher-levelmiddleware

funtionality to agents. For example, agent servers provide a run-time environment for agents, and a Web

servie gateway providesagentstheabilitytoommuniatewithwebserviesusingtheSOAP/XMLprotool.

In AgentSape, virtual domains are alled loations. An AgentSape loation onsists of one ormore hosts

runningtheAgentSapemiddleware,typiallywithin asingleadministrativedomain.

Inadditiontothemiddlewareproessesdesribedabove,eahhosthasahostmanager middlewareproess.

This proessis responsible formanaging the middleware omponents runningonthe host, andimplementing

therequirednegotiationfuntionalityas desribedin thearhiteture. Furthermore,eahAgentSapeloation

runsaloation manager proessononeofthehosts,whih implementsmanagementfuntionalityrequiredfor

managingAgentSapehosts,andwhihimplementsthefuntionalityofthedomainoordinator,enablingagent

appliationto enter intoresourenegotiationswithloations. Figure 4.1showsanoverviewofanAgentSape

loation.

Agent

Server

Agent

Server

Server

Agent

Server

Agent

Web

Service

GW

HM

HM

LM

HM

Host B

Host A

Host C

Location

Fig.4.1. OverviewofanAgentSapeloation.

4.2. AgentSape Negotiation Arhiteture. Within AgentSape, agentsanstart negotiations with

anumberof loations,and giventheoerstheloationsprovide,selettheloation oeringthebest options.

Theagentthenmigratesto theloationwithwhihagreementhasbeenreahed.

4.2.1. AgentSape resoures. TheAgentSapenegotiation arhiteturedenesaset of resouresthat

anbealloatedandusedbyagentsin theAgentSapespeiontology. Thisontologyisusedduring

negotia-tion. Currently,thefollowingresouresareinludedinthis ontology:

•

CPUtime: Thetime(inmilliseonds)thatanagentspendsonanagentserver.

•

Communiationbandwidth: Thenumberofbytes/seondthatanagentmaysendto otheragents.

•

Memory: TheamountofRAManagentmayonsumewhilerunningonanagentserver.

•

Web servie aess: The web servies that an agent is allowed to aess using the AgentSape Web ServieGateway.

•

Webservie all rate: Thenumberof alls that anagentis allowedto doon aweb servieusing the gateway.

•

Diskspae: Theamountofdiskspaeanagentisallowedtousewhilerunningonanagentserver. Additionalresouresanbedened in thefuture,asthefuntionalityoeredbyAgentSapeis extended.

The resoures are speied in the XML Shema language, enabling the use of these denitions within the

agreement-basednegotiationsequene. Asan example,onsider thethree resouresspeied in Example4.1.

web-servie-aessresoure is dened as a list of servie names (strings) representing the list of servies

whihmaybeaessed.

<xsd:simpleType name="time-on-pu"

type="xsd:positiveInteg er" />

<xsd:simpleType name="ommuniation-ban dwi dth"

type="xsd:positiveInteg er" />

<xsd:omplexType name="web-servie-aess" >

<xsd:all>

<xsd:element name="servie-name" type="xsd:string"

minOurs="1" maxOurs="unbounded"/>

</xsd:all>

</xsd:omplexType>

Example4.1

AgentSaperesouredenitions.

TheAgentSapespeilanguageisusedwithintheleasemodeltoexpressresourerequirementsandusage

onditions. In Example 4.2, an example of agent resourerequirementsis shown. In this example, an agent

requests50seondsofCPUtime,and50Kb/s ofommuniationbandwidth.

<!-- requirement: 50 seonds CPU time -->

<agentsape:time-on-pu>

50000

</agentsape:time-on-pu >

<!-- requirement: 50Kb/s bandwidth -->

<agentsape:ommuniatio n-ba ndw idth >

51200

</agentsape:ommuniati on-b and with >

Example4.2

Agentresourerequirements.

4.3. AgentSapeHostManager. TheAgentSapehostmanagerisresponsibleforoeringresouresto

theloationmanager. Basedonitsowninformationonthestatusofitsresoures,anditsownpoliiesregarding

these resoures, the host managerreates a set of templates. Example 4.3 showsan example of atemplate,

usingthesyntaxasdened intheWS-AgreementSpeiation. Thetemplatespeiesthatthis hostannow

oer two resoures,eah with spei aess onditions. For therst resoure: the time-on-puresoure,a

maximumvalueof100seondsisspeied. Theseondresoure,ommuniation-bandwidth,isnotrestrited

bythetemplate.

4.4. Loation Manager. The loation manager enters into negotiation with host managers within its

loationonbehalfofagents. Theloationmanagermaintainsinformationonthetemplatesoersbyeahofthe

hostswithin theloation,andusesthisinformationtoprovidetemplatestoagents. Agentsbasetheirrequests

forleasestotheloationmanageronthesetemplates. Asanexample,onsider thefollowingrequest, inwhih

anagentrequestsaloationfor50seondsofCPUtime,and50Kb/s ofommuniationbandwidth.

Tomeetleaserequests byagents,the loationmanagerenters into negotiationwith therelevanthosts in

itsloation(those that anprovidetheresouresrequested). Foreah requestreeivedfrom anagent,one or

moresuitablehosts are seleted(based on theirtemplates). Eah ofthe hosts then reatesan oerbasedon

the urrentresoure onditions. The loation manager selets one of the oers, and disardsthe others, or

ombines anumberof oersintoaomposedoer. Theseletedoeris returnedtothe agent. Asmentioned

inSetion 2.2,multipleoersanbereturnedto theagent,butdoesnotomplywiththeAgentSapemodel.

Inthe following example,aloation managerhasreeived arequestfrom an agent,and hasseleted two

hosts within its loation to whih it forwards the request. The hosts determine if and to whih extent the

<wsag:Name>Template1</ws ag:N ame>

<wsag:Context/>

<wsag:Terms/>

<wsag:CreationConstraint s>

<wsag:Item>

<wsag:Loation>//wsag:Se rvi eDe sri ptio nTe rm//

agentsape:time-on-pu

</wsag:Loation>

<xs:maxInlusive xs:value="100000">

</wsag:Item>

</wsag:Item>

<wsag:Loation>//wsag:Se rvi eDe sri ptio nTe rm//

agentsape:ommuniation- band widt h

</wsag:Loation>

</wsag:Item>

</wsag:CreationConstrain ts>

</wsag:Template>

Example4.3

AgentSaperesouretemplate.

<wsag:AgreementOffer>

<wsag:Name>Offer1</wsag: name >

<wsag:Context>

<wsag:AgreementInitiat or>

agentX

</wsag:AgreementInitia tor>

<wsag:TemplateName>

Template1

</wsag:TemplateName>

</wsag:Context>

<wsag:Terms>

<wsag:All>

<wsag:ServieDesripti onTe rm

wsag:Name="TimeOnCPU"

wsag:ServieName="Loati onY ">

<agentsape:time-on-pu>

50000

</agentsape:time-on-pu >

</wsag:ServieDesript ionT erm>

<wsag:ServieDesripti onTe rm

wsag:Name="Communiation "

wsag:ServieName="Loati onY ">

<agentsape:ommuniatio n-ba ndw idth >

51200

</agentsape:ommuniati on-b and widt h>

</wsag:ServieDesript ionT erm>

</wsag:All>

</wsag:Terms>

</wsag:AgreementOffer>

Example4.4

Leaserequestmadebyagent.

the agent, and ommuniation-bandwidth is dereased to 10 Kb/s. Host 2 also returns a proposal in whih

therequestedtime-on-puis reduedto40seonds, andommuniation-bandwidthisdereasedto30Kb/s.

Also, an ExpirationTimeelementis added to theontext setion of the proposal, indiating when the lease

will expire, if aepted bythe agent. Host 1 denes an expiration time of 23:04:44upon whih it no longer

guaranteestherequestedresoures,andHost 2denesanexpirationtimeof23:10:00.

The proposals are reeived and ompared by the loation manager. Host 1 oers fully the requested

band-<wsag:Context> <wsag:AgreementInitiator> AgentX </wsag:AgreementInitiator> <wsag:AgreementProvider> Host1 </wsag:AgreementProvider> <wsag:ExpirationTime> 2005-07-23T23:04:00 </wsag:ExpirationTime> </wsag:Context> <wsag:Terms> <wsag:All> <wsag:ServieDesriptionTerm wsag:Name="TimeOnCPU" wsag:ServieName="LoationY"> <agentsape:time-on-pu> 50000 </agentsape:time-on-pu> </wsag:ServieDesriptionTerm> <wsag:ServieDesriptionTerm wsag:Name="Communiation" wsag:ServieName="LoationY"> <agentsape:ommuniation-bandwidth> 10240 </agentsape:ommuniation-bandwidth> </wsag:ServieDesriptionTerm> </wsag:All> </wsag:Terms> </wsag:Agreement> <wsag:Context> <wsag:AgreementInitiator> AgentX </wsag:AgreementInitiator> <wsag:AgreementProvider> Host2 </wsag:AgreementProvider> <wsag:ExpirationTime> 2005-07-23T23:10:00 </wsag:ExpirationTime> </wsag:Context> <wsag:Terms> <wsag:All> <wsag:ServieDesriptionTerm wsag:Name="TimeOnCPU" wsag:ServieName="LoationY"> <agentsape:time-on-pu> 40000 </agentsape:time-on-pu> </wsag:ServieDesriptionTerm> <wsag:ServieDesriptionTerm wsag:Name="Communiation" wsag:ServieName="LoationY"> <agentsape:ommuniation-bandwidth> 30720 </agentsape:ommuniation-bandwidth> </wsag:ServieDesriptionTerm> </wsag:All> </wsag:Terms> </wsag:Agreement> Example4.5

Hostleaseproposals.

loserto therequestedvaluethan theoerof Host 1. Theloationmanagermakesaseletionbetweenthese

oersbasedonurrentseletionpoliies,andommuniatesthisoertotheagent. Inourexample,theloation

managerhoosesthe proposal madeby Host 2. The agent hooses to aepttheoer. After aeptane,the

agenthasalimitedtimeinwhihitmustmigratetothetargetloation,ortheleaseoerwillexpire. Afterthe

arrivaloftheagentatthetargetloation,theagentisallowedtoonsumetheagreeduponresouresuntilthe

leaseexpires.

requestWSDLAccess(...)

sendSOAPRequest(...)

requestTemplates(LocationID)

requestLease(LocationID, leaseRequest)

requestLeaseStatus(LocationID, leaseID)

acceptLease(LocationID, leaseID)

...

sendMessage(agentID, messageContent)

receiveMessage()

move(LocationID)

kill()

suspend(timeOut)

Fig.4.2. Leaserelated alls ontheAgentSapeagentinterfae.

4.5. AgentSape Agent Interfae. The interfae presented to agentsby the AgentSape middleware

ontainsseveralleaserelatedalls,asshowninFigure4.2. Theseallsenableagentstoenterintoresourelease

negotiationswithAgentSapeloations.

ofthenegotiationarhitetureto aommodatedomain-wide resourepoliies. Theseondset ofexperiments

fousedontheuseofthenegotiationarhiteturetoapplyqualityofservie poliiesusingindividualizedhost

poliies.

5.1. Experimental setup. A distributed AgentSape loationis set up onsisting ofnine hosts. Eight

hosts areonguredto runahostmanagerand anagentserver, andone hostis ongured to run aloation

manager. The loation manager implements the domain oordinator negotiation funtionality. In eah of

theexperiments, agentsmigrate to theloation after alease hasbeenaquired throughnegotiation with the

loation manager. The hosts used for the AgentSape loation are part of the DAS-2 luster at the Vrije

Universiteit Amsterdam, onsisting of Dual Pentium-III nodes onneted by Fast Ethernet (Myrinet-2000 is

available between mahines at eah luster,but wasnotused in these experiments). Theagentsare inserted

fromahostoutsidetheDAS-2luster,alsoonnetedbyFastEthernet.

In the experiments, CPU-time is the main subjet of the negotiation proess. In eah experiment, one

thousand agents are inserted into the loation. For eah agent, a desired CPU-time amount is generated

aordingto theWeibulldistribution(sale=3.0, shape=2.0,mean=26.587seonds). This valuefrom the

distributionis then used to reate alease request whih is then sent to the loation. The intervals between

leaserequests of individual agentsare distributed aordingto the Poisson distribution (mean =2 seonds).

Eah lease request reeived by theloation manager is translatedinto leaserequests to the8 hostmanagers

within theloation. Eah hostmanagerthen respondswith aleaseoerifthe requestedvalueis in line with

theloalCPU-timepoliy,orrespondswithanemptyoeriftherequestedvalueisnotinlinewiththepoliy.

Intheexperiments,theloadonahostisrepresentedasthenumberof agentsrunningonahost,measuredat

oneseondintervals.

5.2. Domain-wide negotiation poliy experiments. In the area of distributed systems it is useful

to apply domain poliies failitating the distribution of omputational load arossavailable hosts in the

en-vironment. Twostraightforward types of poliies are based on the priniples of: (1) time-division, in whih

omputationalloadissheduledforexeutionatdierenttimes,and(2)spae-division,inwhihomputational

loadis sheduledondierenthosts. In theseexperiments,around-robin(spae-division)negotiationpoliy is

applied, i. e., a loationmanager olletsoersmade bythe hosts,and applies around-robinloadbalaning

poliy to selet oneofthe oersmadeby thehosts. This oeris then sentbak asananswerto the original

lease request. After aeptane of the lease, an agent is inserted at the host that has been seleted during

negotiation. The agent will then start to onsume CPU-time by performing predened alulations. When

the CPU-time delegatedto the agent in the lease is onsumed, the agent is stopped and removed from the

host. Inthisexperiment,hosts areonguredwithanegotiationpoliyditatingthatallleaserequestsshould

be aepted, regardless of the requested CPU-time value. The loation manager seletshost manager oers

aordingtoaround-robinpoliy,withtheaimoftodistributeallagentsevenlythroughouttheloation.

AsameasureforthebalaneoftheloadwithintheAgentSapeloation,theLoadBalaneMetriisused,

as desribed by Bunt and Eager [4℄. This metriis dened by taking the weightedaverage of peak-to-mean

serverloadratios. Thisensuresthatalargerimbalaneduring high-loadsituations hasagreatereet onthe

LBMmeasure thanasmaller imbalaneduring lower-loadonditions. The valueof theLBMmeasure ranges

fromthenumberof servers(8 hostsin theexperiments) to1, wherealowervaluerepresentsahigherbalane

(LBMvalue1meansperfetloadbalane). InFig.5.1,theLBMvaluesaregraphed,alulatedover10seond

intervals. The gure shows that a onsistent balane is ahieved within the loation using the round-robin

poliy, during the insertion of agentsasdesribed in the experimental setup. At the end of the experiment,

loadbalaneannolongerbeenfored,asallagentshavebeeninsertedandloadimbalaneisinduedbythe

ompletionofagentsatahost,whileafrationofthehostsisstillexeutinglongrunningagents. Thisisshown

inthegraphbythesharpinreaseoftheLBMvalue.

5.3. Dierentiated host poliy experiments. In theseond set of experiments, negotiation poliies

were applied to implement a quality of servie poliy aimed at improving responsiveness for agents with a

relativelyshortrunningtime(belowthemeanvalueasdesribedabove). Intheexperiments,twodierenthost

poliies areused: apoliy allowingonlyrequestsbelowthemeanCPU-timevalue,and apoliy allowingonly

requestsabovethemeanCPU-timevalue. (TheCPU-timevaluesaretakenfromthesameWeibulldistribution

1

2

3

4

5

6

7

8

0

500

1000

1500

2000

2500

LBM

time (s)

Fig.5.1.LBMover10seondintervalsusinground-robinnegotiationpoliy.

separately, asattaining abalanedloadwithin groupsisstill desirable,but is notfeasiblearossthedierent

groups.

InTable5.1,theresultsoftheseexperimentsareshown. Intherstolumn,thenumberofhostsaepting

onlyagentswith aCPU-time valuebelow themean isgiven. Theseond and third olumn present aquality

ofservieperentageforagentswithabelow-meanandabove-meanCPU-time valuerespetively. Thequality

of servie perentage metri is dened as the atual CPU-time agents have onsumed divided by the wall

lok timeagentshavespentonahost. Theresultsinthetablearethemeanoverthreeexperiments. A high

quality of servie perentage of 100% indiates a perfet quality of serviewhere the resoureis ompletely

availabletotheagent(theagentsintheexperimentsareCPUbound,and,e.g.,notwaitingforI/Oornetwork

ommuniation). Alowquality ofservie perentagemeansthat the agenthas toompetewith other agents

(orgenerallytasks)to aesstheresoures.

Thevaluesin thebottomrowareobtainedfromtheloadbalaningexperimentspresentedin theprevious

setion,inwhihnodierentiationwasmadebasedonCPU-timevalues,andagentsouldbeplaedonallhosts.

This an be seenas areferene value, indiating the responsiveness in theundierentiated ase. From the

resultsitanbearguedthataongurationwith8hosts,where3hostsaeptingonlyagentswithbelow-mean

CPU-timevalues(andonsequently5hostsaeptingonlyabove-meanCPU-time),givesagentswithashorter

running time abetter responsiveness,at anot toogreat expensefor the longer running agents. For 4hosts

reservedforshortrunningagents,theresponsivenessdramatiallyimproveswithaboutafatorof5ompared

totherefereneresults,whilethelongrunningagentsexperieneaninreasedturnaroundtimeofafatorof1.7.

The experiments have shown that dierent poliies an be relatively easily enfored, both on aggregate

loation level, enforing a round-robin load balaning poliy, as well as on individual host level, aepting

either short orlongrunningagents. It should bestressed that the experimentsarenot intendedto showthe

performaneofspeipoliies,butrathershowhowdierentpoliiesdenedonloationandhostlevelanbe

denedandenforedbytheresourenegotiationinfrastruturepresentedinthis paper.

6. Related Workand Disussion. Thenegotiation arhiteture desribedabovehides theomplexity

ofmanaging aessandusage ofheterogeneousand distributedresouresfrom agents,byprovidingauniform

negotiation infrastrutureaggregating theresoures within avirtual domain. Thearhiteture uses the

WS-AgreementemergingGridstandardasabasisforitsnegotiationprotoolandlanguage.

#belowmean avg.forbelow avg.forabove

hosts meanagents% meanagents%

2 8.3 38.6

3 24.9 13.2

4 76.3 9.7

5 87.7 5.8

6 90.9 4.5

referene 14.5 16.2

Table5.1

QualityofservieperentageresultsoftheCPU-timedierentiatedhostpoliyexperiments.

workhasanumberofshortomings. First,thespeiationonlyprovidesforabasinegotiationprotooland

relatedinformation strutures. This ouldbesuientfor usein servie-orientedenvironmentsfor whih the

modelis intended,however,inaself-managingappliationdomain,asdesribedin thispaper,moreelaborate

negotiation failities ouldprovide these appliations with moreontrol overalloation and use of resoures.

Seond,theframeworkdoesnotprovideamodeldesribinghowenforementofagreementsistobeintegrated

in the system providing the resoures. Although it an be argued that muh of this is very domain-spei

and annot be aptured in a useful model, the framework ould present an abstrat model of the required

informationstruturesand designof anagreement-basedinfrastruturesupporting theWS-Agreement

frame-work.

In this paper, an extension of the WS-Agreement negotiation protool is proposed. The addition of an

expliitaept/rejet interationsequeneallowsagentstoenter intonegotiationswithmultiple providersand

omparereeivedoers. Theproposed framework isimplementedin theAgentSape middleware. Inareent

paper, Paurobally and Jennings[9℄also reognizethe needfor moreomplexnegotiationpatterns other than

possible within theWS-AgreementSpeiation. Intheir paper, riher messagetypes(i. e., inform and bid)

andinterationprotoolsareproposedintheformofanadditionallayer,allowingforthespeiationofagent

interationprotoolsontopoftheWS-Agreementmessaginglayer. TheGrid ResoureAlloationAgreement

Protool(GRAAP)workinggroupalsoextendedtheirworkonWS-AgreementwiththeWS-Agreement

Nego-tiation Speiation[2℄. Here,anegotiation layerisdened to beinorporatedontopof theWS-Agreement

Speiation. Thenegotiationlayerallowstoexpressnegotiationoersintermsexpressedinthemeta-language

alreadydened inWS-Agreement.

Independentfrom theWS-AgreementSpeiationativities,Hungetal.[6℄proposedaWebservie

nego-tiationmodelalled WS-Negotiation. Also,aservielevelagreement(SLA) templatemodelis presented,with

dierent domain spei voabularies for supporting dierent typesof negotiation. The negotiation protool

in their model is gearedtowardintegrativenegotiation, where both parties loateand adopt the optionthat

providegreaterjointutility totheparties takenolletively. Themessagetypesreetthis negotiationmodel

and is more extended than the models presented by Paurobally and Jennings [9℄ and the GRAAP working

group[2℄.

IBM'sCremona[7℄(CreationandMonitoringofAgreements)isaneortto reateanarhitetureandset

oflibrariesthatimplementtheWS-Agreementinterfaesandagreement(template)management,andprovide

agreementfuntionalitysuitableforimplementationsindomain-spei environments. TheCremona

arhite-turespeiesdomain-independentanddomain-speiomponentsrequiredforagreement-basedmanagement,

and theCremona libraries provide implementations of the agreementinterfaes,domain-independent

ompo-nents,andwell-dened interfaesfor thedomain-spei omponents. Cremonaisurrentlybeingoeredasa

partofIBM'sEmergingTehnologiesToolkit.

The design goalsand the realization of the WS-Agreement-basednegotiation infrastruturepresentedin

this paper and the Cremona arhiteture are quite similar. However, the WS-Agreement-based negotiation

infrastrutureextends theCremona arhiteture with the option to ombine templates and agreementsfrom

multipleresoures. Theombinationoftemplatesandagreementsisneessarytoaomplishresoure

The onept of leasing has been used in the area of distributed appliation frameworks, for example in

Jini [10℄,whereleasesareused fordistributed garbageolletion. IntheJiniframework,lientsleaseresoure

aess, suh as for example servie registration within a lookup servie. The aquired lease allows a lient

to make of use of that resourefor a limited time-period. When a lease expires, and no expliit renewal is

requested by the lient (for example beause of network failure), the assoiated resoure is made available

for other lients, preventing unneessary resoure alloation. This harateristi has been inluded in the

negotiationmodelpresentedin thispaper. TheJinispeiation,however,doesnotoveranegotiationmodel

or protool speiation. In the SHARP [5℄ arhiteture, tikets (soft resourelaims) anbe redeemed by

resoureonsumersforleases(hardresourelaims),whihguaranteeaesstoaresoure. Tiket holdersan

delegate resoures to other prinipals by issuing new tikets. The goals of the SHARP arhiteture and the

AgentSapenegotiationarhiteturearesimilarin nature,withtheAgentSapenegotiationarhiteturebeing

moreorientedtowardsagentappliations.

Thefousof oururrentandfuture work inludes extendingthearhitetureand model with agentlevel

omponents,allowingappliationdeveloperstomoreeasilyintegrateandimplementresourenegotiation

inter-ationsintotheirappliations. Asanexample,fortheAgentSapemiddleware,aWS-AgreementbasedAgent

CommuniationLanguagewould enableagents to moreeasily ommuniate with the resourenegotiation

in-frastruture. Furthermore,theadditionofmoreexpressiveandexiblenegotiationprotoolswouldallowboth

appliationsandresouresmorene-grainedontrolofthenegotiationproess.

As statedin Setion 2.2, theurrentimplementation ofthedomain oordinatorin thenegotiation

infras-truturereturnsoneoerinreplytoanagentrequest. Thisisanimplementationdeisionandnotalimitation

of thenegotiation modelor protool. Ifthe domain oordinator returnsmultiple oers,the requesting agent

andeidewhih oerismostappropriatetoomplete itsurrenttask, e.g.,onsideringexpetedomputing

time, exeutionosts,seuritylevel,orotherusesof resoures. Partof theextended negotiation protoolan

bethespeiationbytheagentwhetheritoptsforalight-weightnegotiationprotoolwithsingleoers,ora

moreomplexnegotiationprotool withmultipleoers.

The negotiation arhiteture makes it also possible for a virtualproviderto hek an agent'sredentials

beforeevenstartingto negotiatewithanagent. Asidentitymanagementis animportantaspet inthedesign

oflarge-saleopenagentsystems[3℄,thisaspetisurrentlybeingfurtherexplored,inpartiularinrelationto

legalimpliationsoftheuseofmobile agents.

REFERENCES

[1℄ A.Andrieux,K.Czajkowski, A.Dan, K.Keahey, H.Ludwig, T. Nakata,J.Pruyne,J.Rofrano,S.Tueke,

andM.Xu,Webserviesagreementspeiation (WS-Agreement)(draft)2006,

https://forge.gridforu m.or g/pr oje ts/ graa p-w g

[2℄ A.Andrieux,K.Czajkowski,A.Dan, K.Keahey, H.Ludwig, J.Pruyne,J.Rofrano,S. Tueke,andM.Xu,

Webserviesagreementnegotiationspeiation(WS-AgreementNegotiation)(draft)2004,

https://forge.gridforu m.or g/pr oje ts/ graa p-w g

[3℄ F.Brazier, A.Oskamp, J.Prins, M.Shellekens,andN.Wijngaards,Anonymityandsoftware agents: An

inter-displinaryhallenge,AI&Law,1-2(2004),pp.137157.

[4℄ R.B.Bunt,D.L.Eager,G.M.Oster,andC.L.Williamson,Ahievingloadbalaneandeetiveahinginlustered

Webservers,inProeedingsofthe4thInternationalWebCahingWorkshop,SanDiego,CA,Apr.1999,pp.159169.

[5℄ Y.Fu, J.Chase,B. Chun,S. Shwab, andA.Vahdat,SHARP: Anarhitetureforseure resourepeering,in

Pro-eedingsofthe19thACMSymposiumonOperatingSystemsPriniples,BoltonLanding,NY,Ot.2003,pp.133148.

[6℄ P.C.K.Hung,H.Li,andJ.-J.Jeng,WS-Negotiation: Anoverviewofresearhissues,inProeedingsofthe37thHawaii

InternationalConfereneonSystemSienes(HICSS'04),BigIsland,Hawaii,Jan.2004,pp.3342.

[7℄ H.Ludwig,A.Dan,andR.Keaney,Cremona: AnarhitetureandlibraryforreationandmonitoringofWS-Agreements,

teh.report,IBMResearhDivision,June2004.

[8℄ B. J. Overeinder and F. M. T. Brazier, Salable middleware environment for agent-based Internet appliations, in

ProeedingsoftheWorkshoponState-of-the-ArtinSientiComputing(PARA'04),Copenhagen,Denmark,June2004,

pp.675679.PublishedinAppliedParallelComputing,LNCS3732,Springer,Berlin,2006.

[9℄ S.PauroballyandN. R. Jennings,DevelopingagentWebservie agreements,inProeedingsofthe IEEE/WIC/ACM

InternationalConfereneonIntelligentAgentTehnology,Compiegne,Frane,Sept.2005,pp.464470.

[10℄ J.Waldo,TheJiniarhiteturefornetwork-entriomputing,CommuniationsoftheACM,42(1999),pp.7682.

Editedby: ShahramRahimi,RaheelAhmad

Reeived: November8,2005