A Coordinated Architecture for the Agent-based Service Level AgreementNegotiation of Web Service Composition

Mohan Baruwal Chhetri1, Jian Lin1, SukKeong Goh1, Jun Yan2, Jian Ying Zhang1, RyszardKowalczyk1

1Faculty of Information and Communication TechnologiesSwinburne University of Technology, Australia

{mchhetri, jlin, sgoh, jyzhang, rkowalczyk}@ict.swin.edu.au

2School of Information Technology and Computer ScienceUniversity of Wollongong, Australia

jyan@uow.edu.au

Abstract

Recent progress in the field of web services hasmade it possible to integrate inter-organizational andheterogeneous services on the web at runtime. If a userrequest cannot be satisfied by a single web service, it is(or should be) possible to combine existing services inorder to fulfill the request. However, there are severalchallenging issues that need to be addressed beforethis can be realized in the true sense. One of them isthe ability to ensure end-to-end QoS of a web servicecomposition. There is a need for a SLA negotiationsystem which can ensure the autonomous QoSnegotiation of web service compositions irrespective ofthe application domain. In this paper we proposeagent-based coordinated-negotiation architecture toensure collective functionality, end-to-end QoS and thestateful coordination of complex services. We describea prototype implementation to demonstrate how thisarchitecture can be used in different applicationdomains. We have also demonstrated how thenegotiation system on the service provider’s side canbe implemented both as an Agent based NegotiationSystem and as a Web Service based NegotiationSystem.

1. Introduction

With recent advances in Web Service technology itis possible to dynamically publish, discover and invokeweb services. The principal objective of the webservices effort is to facilitate an environment in which

service customers and providers can dynamically locateand connect with each other, automatically set theterms and conditions of invocation and then execute thenecessary actions according to the negotiated contract.If a particular user request cannot be satisfied by asingle Web Service, then it is (or should be) possible tocombine existing services together to form a webservice composition which can then fulfill the request.

Service composition is the process of combiningseveral component services and bundling them togetherto meet the specific needs of a user request. It haspotential benefits from both the web service provider’sperspective and the consumer’s perspective. Somebenefits include rapid application development, servicereuse and complex service consummation for theformer and seamless access to a variety of complexservices for the latter [1]. The consumer need not beaware of the actual composition of severalheterogeneous Web Services, since all the integrationlogic is hidden from the user. These are the principleon which Web Service Technology has beendeveloped.

A service composition life-cycle, in general, can becharacterized by five phases – planning phase,definition phase, scheduling phase, construction phaseand the execution phase [2]. A service composition caninitially be described in abstract and then later be madeconcrete and executable. An abstract servicecomposition consists of base service types without anyconcrete bindings. The outcome of the constructionphase results in the concretization of the abstractservice composition, from a set of potentially availablecomponent services.

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

How an abstract service composition is created fromthe user request is outside the scope of this paper andour research efforts. Significant research efforts arebeing carried out in this particular direction and in thearea of web service composition in general [1] [3] [4][26]. We are more interested in how an abstract servicecomposition can be transformed into a concreteexecutable process provided we have the end-to-endQuality of Service (QoS)1 requirements for thecomposition and a list of potential service providers foreach base service type. The research challenge is toprovide a mechanism for the autonomous selection ofsuitable service providers for each service type withinthe service composition while guaranteeing the end-to-end (global) QoS.

Although Service Level Agreement (SLA) contractformation and management has been the focus ofresearch for several years, it has mainly been limited toSLA management for single service provision or, in thecase of web service compositions, the manualconfiguration to determine the QoS constraints onindividual services. The SLA management for a servicecomposition which involves a single consumer andmultiple service providers is still an open researchissue. As other service composition related activitiesbecome automated, having the negotiation between theservice provider and the service requestor conductedvia human agents goes against the very nature of WebService technology. Thus there is a recognized need foran architecture which can support the autonomousnegotiation of QoS constraints for servicecompositions. This paper presents an agent-basedapproach for the coordinated negotiation and re-negotiation of QoS constraints for service compositionsto guarantee end-to-end QoS.

The paper is organized as follow. The next sectionbriefly discusses related work in the areas of SLAManagement and Agent-based negotiation. Section 3discusses the Adaptive Service Agreement and ProcessManagement (ASAPM) project [8], in the context ofwhich this research has been carried out. Section 4discusses the negotiation of service compositions andthe need for coordination as well as the coordinated-negotiation architecture. Section 5 describes the use-case scenario which we have used to demonstrate ourcoordinated-negotiation architecture. Section 6

1 The Quality of Service is a collection of metricsproviding qualitative and quantitative representation ofnon-functional requirements. They are evaluated interms of concrete measures and specify the expectedservice level offered by the service provider.

discusses the implementation of the architecture andsection 7 concludes this paper.

2. Related Work

Research on SLA Management has been activelycarried out for the past couple of years [15]. Thisresearch has generally focused on SLA specificationand definition languages and SLA creation, operation,monitoring and termination. Web Service LevelAgreement (WSLA) [16] and Web Service OfferingsLanguage (WSOL) [18] are two approaches whichpropose the SLA representation. WS-Agreement is aspecification of the Global Grid Forum (GGF) [19]which specifies the agreement structure, a negotiationprotocol and a monitoring interface. Similarly, WS-Negotiation is an XML based language which containsthe Negotiation Message, Negotiation protocol and theNegotiation Decision Making process [24]. It alsoprovides a SLA template model for supportingdifferent types of business negotiations. ServiceNegotiation and Acquisition Protocol (SNAP) [20] hasbeen proposed as a provision for resource managementframework for distributed systems. However, whilethese standards are still evolving, they do have theirlimitations. For instance, WS-Agreement only supportstwo types of messages – offer and agree. Such simplemessage types cannot support coordinated transactionsbetween multiple web services because QoSnegotiation involves different states other than offerand agree such as propose, counter-propose, reject andothers. There needs to be a well-defined protocol toenable such interactions which does not currently existin web services. Another major limitation of the majorapproaches is that they are applicable only to singleservice provision scenarios and cannot be usedautomatically for service compositions.

The use of negotiation as a means of establishingservice contracts has been a topic of considerableinterest for quite some time now within the agentcommunity [5] [22]. Intelligent software agenttechnology is an accepted mechanism in conductingautomatic negotiations [5] [6] [23] and Multiagentsystems have been proposed and used for theautomated negotiation of resource allocation in gridenvironments [20] [21]. Given that agents are flexibleproblem solvers they are able to make context-awareand context-dependent decision about the scope andnature of their interactions. Hence given the similarenvironments in which web services and softwareagents operate, web services can only benefit from thefeatures of multi-agent technology. Again, within thecommunity, this agent based negotiation has principally

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

been in the context of one-to-one negotiation or one-to-many negotiations but for the provision of a singleservice. There hasn’t been much work done in thenegotiation of end-to-end QoS constraints. Our work isa first step in this direction.

3. Background

The work describe in this paper is based on researchconducted in the context of the Adaptive ServiceAgreement and Process Management (ASAPM) inService Grid Project (AU-DEST-CG060081) and theEU FP6 Integrated Project on Adaptive Services Grid(ASG) (EU-IST-004617). This project aims atdeveloping intelligent agent-based techniques and toolsto facilitate the adaptive service management andprocess management in order to ensure collectivefunctionality, end-to-end QoS and the statefulcoordination of complex services. This project has twoprincipal areas of research namely adaptive serviceagreement management and adaptive service processmanagement. The former includes automated serviceagreement negotiation and re-negotiation, serviceagreement lifecycle management and dynamic serviceprofiling (DSP) while the latter includes processenactment, service agreement monitoring, processenactment visualization, and mediated workflow re-planning.

Figure 1 shows the overall architecture of ASAPM.It sits between the application domain system and theactual web service/grid service infrastructure. It focuseson providing adaptive, transparent provision ofcomplex services based upon the user request. TheASAPM architecture consists of four components:• Negotiation Manager – is responsible for the

autonomous SLA negotiation and re-negotiationfor composite services

• SLA Lifecycle Management and Dynamic ServiceProfiling – manages the SLA during their lifetimeand maintains up-to-date service profile which canbe used for SLA negotiation and re-negotiation

• Workflow Enactment, Monitoring andVisualization – is responsible for the enactment ofthe service composition, the monitoring of thenegotiated QoS parameters, and the visualizationof the service composition enactment.

• Mediated Workflow Re-planning – is responsiblefor mediation, aimed at providing alternate plansto satisfy the original user request if anyunrecoverable error occurs

The Application Domain System (ADS) isresponsible for planning the web service compositionin order to satisfy the user request that it receives. The

Composition Planner provides ASAPM with theapplication service workflow as well as the global QoSrequirements for SLA negotiation. The NegotiationManager can get the list of potential service providersfor each base service type within the composition fromthe Service Registry which is part of the ADS. Is isthen the task of the Negotiation Manager to findsuitable candidates which satisfy the QoS constraintsfor each service type while ensuring that the end-to-endQoS is satisfied.

Figure 1: Overall Architecture of ASAPM

4. Negotiation of Web ServiceCompositions

There are two possible ways in which SLAs can beestablished for web service compositions. One is thenegotiate-all-then-enact mode in which SLAs areestablished for all base service types within thecomposition before the enactment of the first service.The second mode is the step-by-step-negotiate-and-enact mode in which each service type is negotiated forand enacted straightaway. Both have their pros andcons. As a first step, we have chosen the negotiate-all-then-enact mode for service composition negotiation.

4.1. Coordinated Negotiation Architecture

The task of the Negotiation Manager is to findsuitable candidates for each service type within theservice composition so that the end-to-end QoS isensured i.e. it is responsible for the concretization ofthe abstract service composition so that the process

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

becomes an executable workflow plan. Figure 2 showsthe architecture we propose to achieve this.

Figure 2: Coordinated-NegotiationArchitecture

From a functional view point, the SLA negotiationof a service composition involves two aspects. Oneaspect is the negotiation between the service consumerand service providers for the QoS constraints of asingle service type within the composition. The otheraspect is the coordination of these concurrent one-to-many negotiations so that the end-to-end QoSconstraints are satisfied. Hence there are two levels ofoperation – at the coordination level and thenegotiation level. The coordinated-negotiation of aservice composition can be supported by a Multi-AgentSystem (MAS).

At the coordination level, the MAS has theCoordinator Agent (CA) which is responsible for thenegotiation of the service composition as a whole. Itinteracts with the Composition Planner (CP) of theADS to receive the abstract service compositiondefinition as well as the end-to-end user QoSrequirements. It then analyses this abstract servicecomposition and decomposes it into base service types.A list of potential providers for each service type isretrieved from the Service Registry (SR) of ADS. Thusprimary phase of coordinated negotiation involvesanalyzing the service composition and the userrequirements which results in a decentralized,distributed architecture. The CA creates a cluster ofNegotiation Agents (NA) which can be modified anddestroyed as required. While the CA has an infinitelife-cycle and the knowledge of the global constraints,the lower level NAs have a finite life-cycle and onlylocal level knowledge.

The NAs act as local problem-solvers which havespecific roles and predefined capabilities which enablethem to fulfill these roles. They act to select the bestservice provider for the particular base service type

they represent. In doing so, they indirectly contribute tothe wider problem solving initiative. Each NA receivesthe local QoS constraints for the service type they arenegotiating along with a list of potential serviceproviders. For example, in Figure 2, NA for Service Awill negotiate with two providers (Provider A1 and A2)and NA for Service B will negotiate with two providers(Provider B1 and B2) under the supervision of the CA.Each NA is required to negotiate with the serviceproviders within the stipulated negotiation time-out anda proposal time-out which is provided to it by the CA.

4.3. Role of the Coordinator Agent

In general, the CA is responsible for the analysis ofthe service composition with a focus of mapping theoverall QoS requirements onto the atomic service levelQoS requirements i.e. QoS requirements for eachservice type within the composition. It is alsoresponsible for the coordination of the negotiation fordifferent services in the composition, with the selectionof the best combination. The main responsibilities ofthe CA can be listed as follows:1. Map the QoS requirements of the user request onto

the QoS requirements of all services within thecomposition

2. Create a cluster of NAs corresponding to eachservice type within the composition

3. Provide these NAs with local-level QoSconstraints, the negotiation timeout and theproposal timeout

4. Coordinate the NAs to negotiate with potentialservice providers for various services in theservice composition in parallel

5. Redistribute the local-level QoS constraints ifoverall QoS constraints are not met

6. Coordinate the re-negotiation of QoS constraints inthe case of service failure or QoS violation

7. Collaborate with the ADS as well as the othercomponents of the ASAPM system.

4.4. Single Service Negotiation

Single service QoS Negotiation refers to the processby which a NA selects and contracts a service providerfrom a list of potential providers. The key concepts inautomated negotiation are – negotiation protocols,negotiation objects, and the decision making model [9].The negotiation protocols define the rules whichgovern the negotiation including how and when it ends.The negotiation objects are the different parameters ofnegotiation such as price, time etc which can bepredefined using a negotiation template [10]

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

acceptable by both sides. The decision making model isused for evaluating and generating offers and counter-offers. It is independent of the negotiation protocol anduses a learning mechanism which models the agent’sbehavior based upon the opponent’s previous offers. Inorder that the negotiation outcome is mutuallyacceptable, it is necessary that the negotiation iscooperative and competitive.

The NA caries out one-to-many negotiations withmultiple service providers using the reserve values forthe local QoS constraints given to it by the CA. it isconstrained by a negotiation timeout (the negotiationtime available) and the proposal timeout (the time itcan wait for a response from a service provider for itsinitial call for proposal).

4.5. Coordinated Negotiation Protocol

The negotiation protocol refers to a set of ruleswhich define the boundaries within which theparticipants can interact. It covers the permissible typesof participants; the negotiation states (e.g. call forproposal, negotiation closed), the events that cause thechange of negotiation states, and the valid actions ofthe agents in the different states of negotiation. In thisresearch we have used the Iterated Contract NetProtocol (ICNP) which is one of the most widely usednegotiation protocol provided by the Foundation ofIntelligent Physical Agents (FIPA) [11]. ICNP supportsrecursive negotiation and allows for multi-rounditerative negotiation to find a compromise. Byexchanging modified proposals and counter-proposals,a more acceptable negotiation result is likely to bereached. While the ICNP protocol is used for theinteraction between the actual negotiating agents, theinteraction between CA and NA also follows the FIPAACL performatives.

ACL Performative ACL Message ContentREQUEST (CA�NA)

• Reserve values (local QoSconstraints)

• Negotiation timeout• Proposal timeout

INFORM (NA� CA) • Negotiation results• Selected provider details

CONFIRM (CA �NA)

Confirmation that selected provideris to be contracted

Table 1: List of ACL Performatives exchangedbetween CA and NA

Table 1 shows the ACL messages exchangedbetween the CA and the NA while Table 2 shows the

messages exchanged between the NAs of the requestor(client) and the service provider. Figure 3 and 4 showthe interaction between the CA and the NA, both whenthe end-to-end QoS constraints are satisfied and whenthey aren’t.

ACL Performative ACL Message ContentCFP (NAC� NASP) Initial Call for ProposalPROPOSE (NASP �NAC)

Offer made by Provider toRequestor

REJECT (NASP � NAC) Reject message if Provider is notinterested in negotiating withRequestor

UNKNOWN (NASP ��NAC)

Message sent by either party ifmessage content is notunderstood

ACCEPT_PROPOSAL(NAC� NASP)

Message sent to Provider onceproposal has been accepted byRequestor

REJECT_PROPOSAL(NAC� NASP)

Message sent if proposal is notacceptable by Requestor

INFORM (NASP � NAC) Message sent by Provider whenRequestor accepts its proposal

FAILURE (NASP �NAC)

Message sent by Provider ifsome error occurs after itreceives ACCEPT_PROPOSAL

Table 2: List of Performatives exchangedbetween NA for Client and the Service

Provider

5. Use Case Scenario Description

The use case scenario which we have chosen for theimplementation of the coordinated negotiationarchitecture is called the Application on Demand(AOD) System. In this scenario shown in Figure 5, auser can request for access to a computer applicationvia the Internet. The user provides the followinginformation as input – IP address, Throughput (in MB),Availability (in percentage), Latency (in milliseconds)and the Maximum cost (in dollars). This information isgiven as input to the Application Domain System(which is the ISP). The ADS creates a composite webservice based upon this user request and forwards thisinformation to the ASAPM system.

The workflow plan generated by the ADS consistsof three service types:

• Provide_Access_Service - web service whichprovides access from the Customer PremiseEquipment (CPE) to the Provider Edge (PE).

• Provide_VPN_Service – web service whichprovides VPN connectivity from the PE to theactual host hosting the requested application.

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

Figure 3: Interaction between CA and NA in case of successful negotiation of global QoS

Figure 4: Interaction between CA and NA in case of failed negotiation of global QoS

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

• Provide_Application_Access – web servicewhich provides access to the requestedapplication

Figure 5: Application on Demand (AOD)System

In the simplest scenario, the composite workflowplan as generated by the ADS will look as shown inFigure 6.

Figure 6: Composite Workflow Plan

After receiving the workflow plan and the userrequest, the Negotiation Manager of ASAPM retrievesa list of prospective providers for each service typewithin the composition from the Service Registry of theADS. The CA is responsible for negotiating the overall(end-to-end) QoS parameters. It creates thecorresponding NAs for each service type. In thisscenario, since there are three service types the Cacreates three corresponding NAs. It then splits theglobal or end-to-end QoS amongst the three NAs. As astarting point, we have used an equal split of the QoSvalues amongst all the NAs. The CA passes thefollowing data to each NA:

• Reserve values for each negotiable attribute• List of prospective service providers (and their

corresponding agent location /id)• The negotiation timeout• The proposal timeoutOnce the CA has created the NAs and provided

them with all the data necessary for carrying out thenegotiation, it waits for the reply from each NA. TheNAs carryout one-to-many negotiations with theService Providers’ NAs until a favorable outcome is

reached or the negotiation timeout is reached. Theythen return the negotiation results back to the CA.

When the CA has received all the negotiationresults, it compares them to see if they satisfy theglobal QoS. If the global QoS is satisfied, it passes thisinformation on to the SLA Manager which thencontracts each service provider. It is then the task of theEnactment, Monitoring and Visualization component toenact the workflow plan in the predefined order whilemonitoring the actual values against the contractedvalues. The user is provided connection to the hostwhich is offering the request application. However, ifthe global QoS is not satisfied, then the CA has to re-distribute the reserve values amongst the NAs andreturn them to the NAs which again try to negotiatewith all the service providers.

Note: Since this is an initial prototype of theCoordinated Negotiation Architecture, we havedemonstrated a simple scenario in which the globalQoS is satisfied.

6. Implementation of the Coordinated-Negotiation Architecture

The Negotiation Manager has been implementedusing the FIPA compliant JADE Agent Framework[12] and WS2JADE [13] [14], a toolkit which enablesthe integration of JADE agents and web services. Thereare two types of QoS Negotiation scenarios – one inwhich the NAs representing the user (part of theNegotiation Manager of ASAPM) directly negotiateswith NAs representing the service provider (external tothe ASAPM), and another in which the NAsrepresenting the user negotiate both with NegotiationAgents and with the Negotiation Web Services usingthe WS2JADE toolkit which sits on top of the JADEframework. Figure 7 shows a scenario in which bothtypes of negotiation are carried out. The NA forService A negotiates directly with the Service ProviderA-1’s NA using ACL Messaging and with theNegotiation Web Service of Service Provider A-2 viathe Proxy Agent. In this case, the mapping from theACL Message to SOAP message is handled by theProxy Agent.

6.1. Direct Negotiation between Agents

Figure 8 shows the exchange of messages betweenthe CA and the NA at the coordination level, as well asthe exchange of messages between the NAs at thenegotiation level. It is a screenshot of the output of theSniffer Agent which is provided by the JADE platform

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

for visualizing the message exchange between JADEagents.

Figure 7: NA for Service Consumer negotiatingwith NA (for Service Provider A-1) and NWS

(for Service Provider A-2) simultaneously

In Figure 8, the CA passes the list of providers andlocal QoS to the NA. This is indicated by the INFORMmessage at the start (A full list of the performativesexchanged between the agents is shown in Tables 1 and2). This NA then issues a CFP to the list of providers itreceives from the CA i.e. three in this case. Eachprovider responds with their own initial proposal whichthe NA collects. If none of the offers are satisfactory, itissues a modified CFP to all providers. If any providerdoes not respond within the proposal timeout, that

particular provider is dropped out of the negotiationprocess. This exchange of messages (proposal, counter-proposals) continues until a favorable outcome isachieved as indicated in the figure. The NA thenreturns this result back to the CA along with theselected Provider ID.

6.2. Negotiation Web Service

One of the primary reasons why we implemented thenegotiation system as a Web service is to address theissue of interoperability among multiple systems. Mostnegotiation support systems have been implemented aspure MultiAgent systems. We want to demonstrate theflexibility of our negotiation system in which the NAscan not only negotiate with NAs on the serviceprovider’s side, but with Negotiation Web Services aswell. This provides service providers with theflexibility to expose their negotiation capabilities eitheras web services which can be discovered, or as anagent-based system. The Negotiation Web Services(NWS) provide uniform interfaces for negotiationwithout disclosing the internal implementation. Theunderlying implementation could either be agent-basedor non-agent based as long as it follows the ICNP. Likeany other web service, a NWS can be published anddiscovered using standards such as UDDI and invokedusing standards such as SOAP.

Figure 8: Sniffer output showing the message exchange between the CA and the NAs

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

Figure 9: Screenshot showing the CA, NAs for Service types A, B and C as well as the Proxy Agentfor the Negotiation Web Service offered by Service Provider A2.

7. Conclusion and Future Work

Service Oriented Computing (SOC) is emerging as aparadigm that utilizes services as fundamental elementsfor developing distributed applications. It promisesorganizations the ability to integrate their systems in aseamless manner by composing distributed businessapplications i.e. service compositions with minimaleffort both within and across organizationalboundaries. The challenge then, given a userspecification, an abstract service composition and a setof component Web Services (for each service typewithin the composition), is to find the best combinationof component Web Services which exactly match or is‘as close as possible’ to the user specification.

In this paper, we have shown an agent basedapproach to address this challenge. We have presentedcoordinated-negotiation architecture for the negotiationof each individual service type within the compositionwhile ensuring that the end-to-end QoS constraints ofthe composition are satisfied. We have presented atwo-layered approach which enables the reuse of thisarchitecture in any application domain. Moreover, inorder to address the issue of interoperability, we haveimplemented the negotiation systems on the provider’sside as a Web Service so that the ASAPM system cannegotiate either with intelligent agents or withNegotiation Web Services.

We have used the negotiate-all-then-enact approachfor the negotiation of the service composition as astarting point. We would like to formalize the protocolfor the coordinated negotiation which involves twolayers of interaction. This paper has not discussed the

decision making strategies both at the negotiation leveland at the coordination level. Future research work willbe focused in developing strong and complicateddecision making mechanisms at both levels. A morecomplete prototype will be developed once we haveaddressed these issues, so that we can demonstrate theoverall functionality of the ASAPM System inproviding adaptive service agreement and adaptiveservice management by integrating the NegotiationSystem with the other components.

8. Acknowledgement

This work is partially supported by the AdaptiveService Agreement and Process Management(ASAPM) in Services Grid project (AU-DEST-CG060081) and the EU FP6 Integrated Project onAdaptive Services Grid (ASG) (EU-IST-004617). TheASAPM project is proudly supported by the InnovationAccess Program – International Science andTechnology established under the AustralianGovernment’s innovation statement, BackingAustralia’s Ability.

9. References

[1] N. Milanovic, and M. Malek, “Current Solutions for WebService Compositions”, IEEE Internet Computing, 2004, pp.51-59

[2] J. Yang, M.P. Papazoglou, “Service Component forManaging Service Composition Life-Cycle”, InformationSystems, Elsevier, 2004, pp. 97-125

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.

[3] M. Matskin, P.Kungas, J. Rao, J. Sampson, S.A. Peterson.“Enabling Web Services Composition with SoftwareAgents”, in the proceedings of the Ninth IASTEDInternational Conference on Internet and MultimediaSystems and Applications, IMSA 2005, Hawaii, USA, ACTAPress, 2005, pp. 93-98

[4] Adaptive Services Grid Project, available online athttp://asg-platform.org/cgi-bin/twiki/view/Public

[5] P. Faratin, C. Sierra, and N.R. Jennings, “Negotiationdecision functions for autonomous agents”, Robotics andAutonomous Systems, 24 (3-4), 1998, pp. 159-182

[6] G. Weiss, “Multiagent Systems – A Modern Approach toDistributed Artificial Intelligence”, MIT Press, 1999 pp. 619

[7] Foster, N. R. Jennings, and C. Kesselmann, “Brain meetsBrawn: Why Grid and agents need each other”, inproceedings of Third International Conference onAutonomous Agents and Multi-Agent Systems, New York,USA, 2004

[8] Adaptive Service Agreement and Process Management(ASAPM) Project, available online athttp://ciamas.it.swin.edu.au/tiki/tiki-index.php

[9] N.R. Jennings, P. Faratin, A.R. Lomuscio, S. Parsons, C.Sierra and M. Wooldridge, “Automated Negotiation:Prospects, Methods and Challenges”, International Journalof Group Decision and Negotiation, 2000

[10] C. Bartolini, C. Preist, and N.R. Jennings, “A SoftwareFramework for Automated Negotiation”, SELMAS 2004,LNCS 3390, 2005, pp. 213-235

[11] Foundation for Intelligent Physical Agents availableonline at http://www.fipa.org/

[12] Java Agent Development Framework available online athttp://jade.tilab.com/

[13] Web Services to Agents: WS2JADE available online athttp://www.it.swin.edu.au/centres/ciamas/tikiindex.php?page=ws2jade-proj

[14] X. T. Nguyen, R. Kowalczyk, M. B. Chhetri, and A.Grant, “WS2JADE: A Tool for Run-time Deployment andControl of Web Services as JADE Agent Services”, inSoftware Agent-Based Applications, Platforms andDevelopment Kits. Whitestein Technologies AG, 2005

[15] M. Calisti, M. Klusch and R. Unland (Eds.) “SoftwareAgent-Based Applications, Platforms and Development Kits”Whitestein Technologies AG, 2005.

[16] H. Kreger, “Fulfilling the Web Services Promise”, inCommunication of the ACM, 46(6), 2003, pp. 29-34.

[17] A. Keller and H. Ludwig, “Defining and monitoringservice level agreements for dynamic e-business”, inProceedings of the 16th System Administration Conference(LISA 2002), November, 2002, Philadelphia, USA

[18] C.K. Hung, H. Li, J. Jeng, “WS-Negotiation: AnOverview of Research Issues”, in the Proceedings of the 37th

Hawaii International Conference on System Sciences, 2004

[19] V. Tosic, B. Pagurek, K. Patel, “WSOL – A languagefor the Formal Specification of Classes of Services for WebServices”, in the Proceedings of ICWS 2003, CSREA Press2003. pp. 375-381.

[20] A. Andrieux, K. Czajkowski, A. Dan, K. Keahey, H.Ludwing, J. Pruyne, J. Rofrano, S. Tuecke and M. Xu, “WebService Agreement Specification (WS-Agreement) 1.1”,2004, available online athttp://www.gridforum.org/Meetings/GGF11/Documents/draft-ggf-graap-agreement.pdf

[21] K. Czajkowski, I. Foster, C. Kesselman, V. Sander, andS. Tuecke, “SNAP: A Protocol for Negotiating Service LevelAgreements and Coordinating Resource Management” inDistributed Systems, 8th Workshop on Job SchedulingStrategies for Parallel Processing, Edinburgh, Scotland, July2002."

[22] L. Nassifi, J.M.Nogueira, M. Ahmed, R. Impey, A.Karmouch. “Agent-based Negotiation for ResourceAllocation in Grid” in the Proceedings of the FourthInternational Joint Conference on Autonomous Agents andMultiagent Systems, Utrecht, Netherlands, 2005

[23] J. Brzostowski, R. Kowalczyk, “On Possibilistic Case-based Reasoning for Selecting Partners for Multi-attributeAgent Negotiation” in the Proceedings of the 4thInternational Joint Conference on Autonomous Agents andMultiAgent Systems, Utrecht, Netherlands, 2005

[24] I. Rahwan, R. Kowalczyk, and H. Pham. “IntelligentAgents for Automated One-to-Many EcommerceNegotiation” in Proceedings of the 25th AustralasianComputer Science Conference,Melbourne, Australia, pages197--204, 2002.

[25] C.K. Hung, H. Lei, J. Jeng, “WS-Negotiation: AnOverview of Research Issues” in the Proceedings of the 37th

Annual Hawaii International Conference on SystemSciences, Hawaii, USA, 2004

[26] I. Mueller, R. Kowalczyk, “Service Compositionthrough Agent-based Coalition Formation” in Proceedings ofthe Workshop on WWW Service Composition with SemanticWeb Services (WSCOMPS05) held in conjunction with the2005 IEEE/WIC/ACM International Joint Conference onWeb Intelligence and Intelligent Agent Technology,Compiegne (France), September 2005. pp. 34 - 43.

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006 IEEE

Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on March 15,2010 at 05:42:44 EDT from IEEE Xplore. Restrictions apply.