Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

A Web service is defined as an autonomous and self-contained unit of application that is accessible over a network [83]. In recent years, the number of available Web services has increased, and it is believed that in the near future, we may find multiple services offering the same functionalities [57]. Moreover, with maturing standards (e.g., BPEL [79]) it is now possible to combine several services to formulate a composite solution (selecting the most suitable service for the composite solution from among a pool of competing services). However, this selection process is not straightforward as many inter-related variables of the different services may affect the performance of the service composition. To help facilitate this process we can use automated negotiation to provide an effective way for clients to bargain for an optimal customization of their required variables and to discover any overlooked potential solutions. In this chapter, the research problem of automated negotiation of Quality of Service (QoS) components among Web services is analyzed. The chapter is divided into four sections. The first section serves as an introduction to the service oriented paradigm and the concept of Web services, their underlying QoS specifications, and the process of negotiation. Section two focuses on the communication protocols for automated negotiation, while the third section discusses the different techniques/agents used in the negotiation process. In Sect. 18.4, we discuss the overall service negotiation requirements, show how existing solutions perform in the light of these requirements, and define an approach for solving the automated negotiation problem.

1.1 Service Oriented Architecture

Service Oriented Architecture (SOA) is defined as a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains [57]. In other words, boundaries of SOAs are usually explicit, i.e., the services need to communicate across boundaries of different geographical zones, ownerships, trust domains, and operating environments. Moreover, explicit message passing is applied in SOAs instead of implicit method invocations. The services in SOAs are autonomous, i.e., they are independently deployed, the topology is dynamic, i.e., new services may be introduced without advanced acknowledgment, and the applications consuming a service can leave the system or fail without notification [1]. Services in SOAs share schema and contracts. The message passing structures are specified by the schema, and message-exchange behaviors are specified by contracts (both implicit or explicit) for each SOA transaction.

Fig. 18.1
figure 1

Service-oriented interaction model

Full size image

Two major entities are involved in any SOA transaction: service customers and service providers. Figure 18.1 represents a typical Web service interaction model. Service providers offer their services by publishing their information (WSDL) in public registries (UDDI) [46, 54]. Customers then query these registries to find the required services and then bind to the most suitable service, where input parameters are sent to the service provider and output is returned to the customer [2]. Web service registries thus serve as place holders and provide minimal functional information about a service. Service providers may use \(tModels\) [21] to provide any additional information. Since \(tModels\) are static place holders for information (service provider may provide a single value or a range for QoS attribute(s)), hence they have limited usability when it comes to negotiating non-functional requirements of the customers (e.g., availability, reliability etc.). A customer looking for a Web service could benefit from a service which if given both functional and non-functional requirements, could provide the most effective solution by simultaneously negotiating with multiple providers.

1.2 QoS Specification

The Quality of Service (QoS) is defined as a set of non-functional service attributes that indicate the service’s ability to satisfy a stated or implied requirement in an end-to-end fashion [41]. This set of quality attributes not only characterize the service but also any entity used in the path between the service and its client. In a Service Oriented Architecture (SOA), service providers may characterize their services to define both the offered functionalities and the offered quality. Similarly the users may not only express their requirements by listing the desired functionalities, but also define a minimum level of quality that the service must ensure. The main issue here is the subjectiveness of ‘quality’: the quality of a service from the provider’s perspective may be different than the quality experienced by the user. At the same time, the same quality level might be sufficient for a given user and not enough for another one. Hence, QoS parameters consist of both quantitative (availability 99.9 %) and qualitative (privacy, security) parts. Most of the quantitative attributes are not directly proportional in their cost/benefit curve e.g., 99.999 % uptime versus 99.0 % uptime. Hence this non-linear curve naturally generates a disparity among the provided values for these QoS attributes and opens them to negotiation.

1.3 Negotiation

Negotiation is a process that can be defined as the interplay of offers and counter-offers between two entities, with different criteria and goals, working to reach a mutually acceptable solution. A negotiation process enhances acquisition opportunities and enables flexible communication that can lead to a better solution [10, 92].

However, negotiation are usually uncertain (due to incomplete information of both parties) and knowledge intensive. Performing negotiations manually is thus ad-hoc and time-consuming. Automated component negotiations (e.g., on the web) are thus valuable not only for the customers and the providers to continuously customize their needs and tailor their offerings, but also to discover overlooked solutions and to maintain documented rationales for future references and reuse.

An automated negotiation mechanism requires at least three components; a high-level protocol, objectives and strategies [47]. The high-level protocol controls the negotiation process depending on types of negotiations (e.g., auction). The objectives of all parties are based on a set of criteria, representing various parameters along with their respective domain values (e.g., price range). Negotiation strategies include mechanisms (rules and knowledge base) that the agent employs to generate and evaluate offers.

Fig. 18.2
figure 2

Negotiation state chart

Full size image

Figure 18.2 depicts the state diagram of an automated negotiation process. Typically, negotiation starts when the customer requests for proposals for a component service. After receiving the initial offers from service providers, it would then select some providers to engage in bi-lateral negotiations. This would start a round of offers and counter offers among the customer and selected service providers. Once both the provider and the customer agree on a certain attributes (e.g., price) for the services to be provided, they enter into the formal Service Level Agreement (SLA) formation phase. At this point, both parties agree on the terms and conditions of the agreement. These usually include both the functional (service to be provided, cost, etc) and non-functional (QoS parameters, violation terms, penalties, etc). This process could also be modeled as the exchange of offers and counter offers (for SLA terms) among the customer and the selected provider. Once agreed, the parties create/contract an agreement and the services are rendered. If both the parties could not agree on the terms of an SLA the current negotiation session is terminated and a new round of negotiation is started.

2 Communication Protocols for Negotiation

A communication protocol defines the syntax, semantics, rules and synchronization of messages exchanged between the partied involved. There are many communication protocols that have been defined to conduct negotiations. This section discusses some of the widely used negotiation protocols applied in the service’s domain.

2.1 WS-Agreement

WS-Agreement [28] is a protocol for establishing agreements between two parties, such as between a service provider and customer. It uses XML for specifying the nature of the agreement, and agreement templates to facilitate discovery of compatible agreement parties. The specification consists of three parts which may be used in a composable manner: a schema for specifying an agreement, a schema for specifying an agreement template, and a set of port types and operations for managing agreement life-cycle, including creation, expiration, and monitoring of agreement states.

There are two layers of WS-Agreement. The agreement layer provides a Web service-based interface that can be used to create, represent and monitor agreements with respect to provisioning of services implemented in the service layer. The service layer represents the application-specific layer of the service being provided. Although WS-Agreement does not have any negotiation specific structure but there had been discussions for using it in negotiating agreements among parties [5, 87]. An implementation of WS-Agreement to negotiate SLA’s for resource orchestration in grids have been presented in [66]. A bilateral WS-Agreement based negotiation process is used to dynamically negotiate SLA templates. One option is for the originating agent to negotiate separately with each Autonomous System (AS) along each potential path to ensure that an end-to-end path is available. The dominant choice, however is to use a cascaded approach where each AS is responsible for the entire path downstream of itself. To rely on WS-Agreement and minimize the extensions to the proposed standard, the idea is not to negotiate SLAs but to negotiate and refine the templates that can be used to create an SLA. An agreement template defines one or more services that are specified by their Service Description Terms (SDT), their Service Property Terms (SPT), and their Guarantee Terms (GT). Additionally an agreement provider can constrain the possible values within the SDTs, SPTs, and GTs by defining appropriate creation constraints within the templates.

Cremona [48] is an agreement management architecture that facilitates (agreement-based) service binding for a variety of services. It uses WS-Agreement as the communication infrastructure. The Cremona architecture separates multiple layers of agreement management, orthogonal to the agreement management functions: the functions associated with an agreement protocol role, initiator or provider, is the Agreement Protocol Role Management (APRM). It comprises, on the agreement provider side, the agreement factory, the agreement instance implementations, the Web services container in which factory and instances are located and interfaces to an agreement template repository, decision-making functionality for createAgreement requests and the current state of terms. On the agreement customer side, it comprises proxy functions to interact with an agreement factory and created agreements, template processing functions to create agreement instance document from templates, and interfaces to components initiating agreement establishment, to functions deciding on how to fill an agreement template, and to guarantee monitors. The Agreement Service Role Management (ASRM) is the collection of functions that deals with a party’s role in the service relationship, provider or customer, and connects it to the service system. On the service provider’s side, this includes the mapping of agreements to provisioning specifications and other input to the service-implementing system—the agreement implementation plan [44].

OpenCCS [35], AgentScape [58] and VIOLA MetaScheduling Service MSS [87] also use negotiation to refine offers and requests in order to create SLAs. As WS-Agreement does not include a protocol for negotiating the terms of an SLA (but an “accept/reject” protocol for the whole SLA), these three approaches currently use proprietary extensions of WS-Agreement for the negotiation.

2.2 Contract Net

Contract Net [78] is a generic negotiation protocol. It is viewed as a task having four components (1) it is a local process that does not involve centralized control, (2) there is two-way exchange of information, (3) each party to the negotiation evaluates the information from its own perspective, and (4) the final agreement is achieved by mutual selection.

A contract is established by a process of local mutual selection based on a two-way transfer of information. In brief, available contractors evaluate task announcements made by several managers and submit bids on those for which they are suited. The managers evaluate the bids and award contracts to the nodes they determine to be most appropriate. The negotiation process may then recur. A contractor may further partition a task and award contracts to other nodes. It is then the manager for those contracts. This leads to the hierarchical control structure that is typical of task-sharing. Control is distributed because processing and communication are not focused at particular nodes, but rather every node is capable of accepting and assigning tasks. The basic message constructs of contract protocol are Task Announcement, Task Announcement Processing, Bidding, Bid Processing, Contract Processing, Reporting Results, Termination, and Negotiation Tradeoffs.

A variation of Contract Net protocol for Semantic Web service composition is discussed in [43]. The issue of aligning data flow in semantic web service composition is to ensure the robustness when executing the composed service by preventing any cases when the wrong type of data is passed on from one service to the next is tackled by proposing a unique solution that ensures the robustness of data flow when automatically composing web services through the use of agent-based negotiation between web service providers.

Another variation of Iterative model of Contract Net Protocol (CNP) for negotiation is discussed in [65], where the manager initiates the negotiation process through a call for proposals (CFP) announcing the task specification to the contractors. A contractor receiving the CFP evaluates it and decides whether to answer with a refusal or a proposal to execute the task. The manager receives the contractor’s proposals and in turn decides which proposals to accept and which proposals to reject. Rejected contractors consider that the negotiation has terminated, while accepted contractors must expedite the task and send back the results of their work to the manager.

Multiple strategies are implemented using the Iterative model of Contract Net Protocol in [64]. The most basic of them i.e., truth telling strategy, relies on the fact that both the manager and contractors reveal their true preferences. Thus, each CFP is constructed with its preferred value for each issue. A service replies with a proposal where each issue is given its own preferred value for each issue. If the CFP lies outside the reserve values for negotiable issues, then the service’s proposal is grounded with the service’s reserve values.

2.3 WS-Policy

WS-Policy [86] provides a grammar for expressing Web services policies. WS-Policy is used to specify policy information on a broad range of service requirements, preferences, and capabilities. The WS-Policy is represented by a policy expression that is an XML Infoset representation of one or more policy statements. The WS-Policy includes a set of general messaging-related assertions defined in WSPolicyAssertions and a set of security policy assertions related to supporting the WS-Security specification defined in WS-SecurityPolicy.

A framework based on WS-Policy for negotiation of Quality of Service attributes between Web services is proposed in [20]. The approach relies on the definition of an extended SOA in which a service index with QoS information is available. Service provider publishes the non-functional attributes, that may be negotiated by the customer, in the WSDL. This QoS registry could be stored along with WSDL using WSOL, which is a WSDL-compatible language for specifying different service offerings for the same service identified by the different values or constraints on the service QoS attributes [82]. It can include different domain schemas on which the QoS could be defined.

2.4 WS-Negotiation

WS-Negotiation [30] is an independent declarative XML language for Web service’s providers and customers. In general, WS-Negotiation contains three parts: Negotiation Message, Negotiation Protocol and Decision Making. The Negotiation Message part describes the format of the messages exchanged. Some suggested message types are: Offer, Counter-Offer, Rejected, Accepted, etc. This part of WS-Negotiation tackles the “Initial Contact” and “Offer and Counter-Offer” tasks. Negotiation Protocol describes the mechanism and the rules that the negotiation parties should follow to exchange messages. Messages contain offers and counter-offers and can be exchanged between customer and provider as well as a third-party negotiation service (Negotiation Support System-NSS). Negotiation primitives are also defined in order to coordinate and execute the tasks and events. A negotiation primitive sets the pre and post conditions that should hold as well as rules and constraints that should be applied during the negotiation. Example of negotiation primitives are the “Propose” primitive for proposing an offer/counter-offer to the other party, the “Modify” primitive to modify the sent offer/counter-offer before receiving the other party’s reply etc. The Negotiation Decision-making component takes the decisions. It is private and is based on the negotiation strategy each party has chosen (e.g., cost-benefit strategy) and the agreement template. This part of WS-Negotiation tackles the “Evaluation”. Negotiation issues vary from one business domain to another but there are some issues that are common or fixed in a domain. Hence, there are several Service Level Agreement (SLA) template models, with domain specific vocabularies, for supporting different types of business negotiations.

WS-AgreementNegotiation [89] describes the re-negotiation of agreements between two parties. It specifies a set of messages and resources that can be used to model several re-negotiation scenarios. WS-AgreementNegotiation sits on top of WS-Agreement, which makes it possible to switch between different negotiation protocol. However, this requires WS-AgreementNegotiation to express negotiation offers in terms of WS-Agreement constructs. This adds a dependency to WS-Agreement. Moreover, it only allows the re-negotiation of existing agreements among two parties and could be initiated by either the provider or the customer.

2.5 Xplore

Xplore [4] provides a lightweight co-ordination platform focused at multi-party, multi-attribute negotiation. It acts as a “middleware” which aims at addressing general, domain independent requirements on the interaction infrastructure to support negotiation. It is based on the negotiation mechanism which is an extension of the Contract Net protocol [78] with transactional facilities, enabling the coordinated execution of a collection of concurrent, interdependent Contract Nets. It exploits the coordination mechanism provided by CLFMekano [3], a coordination middleware platform designed to integrate negotiation and transaction aspects in distributed systems. CLF contains primitives enabling negotiation and transaction at the lowest level. The primitives are expressed as a set of eight “interaction verbs” a la KQML, similar to speech acts [38]. Xplore extends the unidirectional “announce/collect/decide” paradigm of CLF to incorporate counter offers by providing a multi-directional “announce/refine/decide” paradigm allowing flexible refinement of the negotiation terms. Xplore’s protocol consists of the following negotiation verbs. Open, it creates a new node in the negotiation tree i.e., creating a new negotiation branch. Close, prevents any further development from the current negotiation branch, effectively closing the negotiation on the current options. Request, requests information on an aspect of the parameter passed at the current node of the negotiation tree, retrieving information for making informed proposals along a negotiation branch. Assert, is used the describe the aspects of a parameter i.e., refining the negotiation term. Ready states that the component is ready to enter in the enactment phase in the condition expressed by the passed node. The Reserve, Confirm verbs allow to first reserve and then consume a resource previously returned as an offer. Split in two phases, the operation of resource consumption (Reserve, then Confirm) allows the customer to perform atomic consumption of resources coming from different offers (possibly by different servers), thus realizing the most basic form of transaction. In addition, the Cancel verb allows to cancel a reservation, in case other resources in a transaction become unavailable. Finally, the Insert verb requests an extension of a service capability by insertion of a new resource.

An example of using Xplore to describe a NegotiAuction is presented in [12]. NegotiAuction [81] is an algorithmic Internet-based auction procedure. It combines various elements from negotiation and auction protocols, supports multiple attributes of the auctioned good and allows both fully automated negotiation as well as semi-automated negotiation process. Each NegotiAuction takes place in a one-to-many market environment. Auction owner sets up the auction and defines the form of auction i.e., reverse or forward and describes the goods and the quantity to be bought (or to be sold) and decides whether the potential bidders should be explicitly invited (closed format), or everybody could qualify for bidding (open format).

Another infrastructure based on Xplore for supporting negotiations in inter-organizational alliances in a flexible way with respect to the autonomy of the partners involved is defined as e-Alliance in [15]. It focuses on how to represent decentralized organizations, modeling the coordination of different concurrent interactions, formalization of negotiations, deploying and maintaining an alliance during its life cycle and creating administrative contracts. Similarly, the negotiation middleware CooF supports processes provided by the facilities in the second layer. CooF is the coordinator that supports multi-party, multi-directional, multi-attribute negotiation. This process is modeled by a negotiation graph. This structure captures the dependencies between the negotiation interactions. CooF’s job is to coordinate/synchronize these different copies of negotiation graphs. The negotiation process can be considered as a Distributed Constraint Satisfaction Problem [40]. The “distribution” part deals with constraint propagation between nodes, while the “satisfaction” part deals with constraint based reasoning and strategic reasoning at each node.

3 Negotiation Agents

A negotiation agent can be termed as the brains behind the negotiation process. This component interacts with the domain knowledge and the system rules to calculate the usefulness of an offer and then generate counter offers against it. Hence, it is responsible for the decision making process. There are different types of negotiation agents that adhere to different types of negotiation (e.g., auction, reverse auction, bilateral negotiation). A brief overview of these follows.

3.1 Auction Based Agents

An auction can be described as the simplest form of negotiation where a customer bids on the price of an item and the provider has the option of either accepting the offer or rejecting it. There are multiple types of auctions such as English, Dutch, first-price and Vickery [52]. A service composition agent that both buys components and sells services through auctions has been discussed in [67]. It buys component services by participating in many English auctions. It sells composite services by participating in Request-for-Quotes reverse auctions. Because it does not hold a long-term inventory of component services, it takes risks. It makes offers in reverse auctions prior to purchasing all the components needed, and bids in English auctions prior to having a guaranteed customer for the composite good. The algorithms used are able to manage this risk, by appropriately bidding/offering in many auctions and reverse auctions simultaneously. The algorithms withdraws from one set of possible auctions and moves to another set if this produces a better-expected outcome, but will effectively manage the risk of accidentally winning outstanding bids/offers during the withdrawal process. However only the scenarios with English auction type of negotiation with no one-on-one negotiation are handled. It is assumed that the agent maintains a probabilistic model of expected outcomes of each auction based on past performance of similar auctions. The agent initially identifies the set of options which maximize its a-priori expected utility. These options will consist of a reverse auction for a given composite service, together with a set of English auctions for the required components. It then places bids in these forward/reverse auctions and continues to compete in these auctions, placing more bids when outbid. However, if sufficient competing bids are placed to reduce the expected utility of this set of auctions, then it may change to another set of auctions which can generate the same composite service. It will do this if the expected gain from changing to this new bundle outweighs the expected cost of currently held bids which appear in the old bundle but not in the new bundle. If competing bids are placed in one of the reverse auctions it is participating in, and the expected value of that auction decreases sufficiently it may withdraw from that reverse auction. It may use the associated forward auctions in another option, or may withdraw from them as well. Moreover, the problems of not committing and evaluating each option are solved by limiting the search space to promising offers only.

3.2 Trade-Off Based Negotiation Agents

In trade-off based negotiations the concerned parties make tradeoffs on different negotiation parameters based on their respective importance (weights) to the negotiator. Normally each round of negotiation has a slightly different feature vector based on the counter offer generated in the previous negotiation round. This cumulative information is used to generate future offers and hence reach a mutual agreement. A tradeoff based negotiation mechanism for web service procurement using a bilateral protocol to govern interactions between the negotiation parties is used in [63]. Each party can define its own set of evaluation function, utility function and offer generating algorithm. For simplicity both parties share the same generic tradeoff mechanism for automated offer generation while each party can have its own set of objectives and evaluation function. The multi-round negotiation algorithm used contains strategies that focus on generating a set of offers that have the same utility as the current offers and is based on the offers generated by the opponent agent in the previous round. The idea is to exploit the current utility as much as possible. The generated set of offers is presented to opponent agent that chooses the offer that is most suitable to its preferences based on its evaluation function. The negotiation continues until the opponent presents an offer that is of an equal or greater utility than the agent’s previous offer. A deadlock condition may be reached if no offer that is of a higher utility to the opponent than the previous offer is being generated. In such a situation the agent reduces its utility expecting to find, in the lower level an offer that satisfies both agents. This strategy ensures that the agent concedes utility in a more rational way.

A trade-offs based agent for multi-dimensional goods for the problem of distributed resource allocation has been presented in [25]. It uses a fuzzy similarity to approximate the preference structure of the other negotiator and then uses a hill-climbing technique to explore the space of possible trade-offs for the one that is most likely to be acceptable. Similar approaches have been discussed in [26] and [51]. Trade-off based agents have also been studied in [17, 50, 97].

3.3 Negotiation with Uncertain Data

Having as much information as possible about the other parties is important to strengthen one’s negotiation capabilities [60]. Unfortunately, more often than not, we only have partial information about the negotiation context [50]. Hence it is very important to be able to manage different types of unknown parameters about the negotiation. An approach for bilateral negotiation under uncertainty, where a negotiator is uncertain as to what offer or counteroffer to make, at a particular step in the negotiation is presented in [59] and [93]. This uncertainty is resolved by making use of the negotiation experience of reputable parties in [93]. The idea is similar to the scenario where suppose, one has been offered a new employment and it is time to negotiate benefits, including salary. The negotiating parties are yourself and the hiring manager. The fact that mostly salaries are negotiable and often vary with specific job responsibilities, a new hire may not have all the information needed to make a good decision. In this case, a natural course of action, is to seek out others who are trustworthy and who may have negotiated salaries with this company in the past, for similar types of jobs and use their data to make an informed decision. So the main idea is of using the negotiation experiences of trusted parties with matching interests as aids in deciding which negotiating alternatives and offers should be employed.

A model for bilateral negotiations that considers the uncertain and dynamic outside options is defined in [45]. Outside options affect the negotiation strategies via their impact on the reservation price. The model is composed of three modules: single-threaded negotiations, synchronized multi-threaded negotiations, and dynamic multi-threaded negotiations. The single-threaded negotiation model provides negotiation strategies without specifically considering outside options. The model of synchronized multi-threaded negotiations builds on the single-threaded negotiation model and considers the presence of concurrently existing outside options. The model of dynamic multi-threaded negotiations expands the synchronized multi-threaded model by considering the uncertain outside options that may come dynamically in the future. A Poison Process is used to simulate the arrival process of uncertain (dynamic) options.

3.4 Genetic Algorithm Based Negotiations

Negotiations are a special class of group decision making problems. Multi-party and multi-objective negotiations add a lot of complexity to the already hard problem of negotiation. Such negotiation problems can thus be formulated as constrained multi-objective optimization problems. The main idea is to optimize a series of objectives simultaneously while considering constraints on the system. The Genetic Algorithm (GA) approach is consistent with the complex nature of real-world negotiations and is, therefore, capable of addressing more realistic negotiation scenarios. Since genetic algorithms and evolutionary algorithms in general search for entire populations of solutions, they are well suited for multi-criterion problems. A weighted sum based genetic algorithm to support multiple-party multiple-objective negotiations have been presented in [71]. The weighted sum approach is used to handle multiple objectives of each participant. Since all the participant start negotiation from a different position hence they will also have different preference for those objectives and are described by how far their current position is from the objective. Hence the objective is to minimize this distance. The genetic algorithm solution is represented as a 2-Dimensional matrix, representing the participants and objectives. Similar approaches have been discussed in [22, 62, 96]. A genetic algorithms based approach that evolve Finite State Machines has been presented in [85]. Each individual in the population of FSMs represents a negotiation strategy that competes against other strategies and is modified over time using traditional operators of mutation and cross over. To mutate an FSM, several different operators are used which include changing the target or source of an edge, changing the output or input symbol of an edge and adding or deleting a state or an edge. A repair algorithm ensures that all the FSMs are valid after mutation or crossover operation. A GA based negotiation model using the traditional operators of mutilation and crossover has been presented in [18]. A special penalty based evaluation function is used that measures the prior concessionary behavior of the opponent agent. A negotiation time aware GA based approach has been presented in [9]. The pace of concession of the agent is proportional to the elapsed negotiation time while considering the opponent’s payoff gains and the principal of Pareto optimality. Machine learning and bayesian learning have also been used in conjunction with genetic algorithms to achieve satisfactory results [56, 76].

3.5 Combinatorial Negotiations

A combinatorial negotiation is the type of negotiation where entities can negotiate on a combination of items, rather than negotiating independently on each item from a set of items. Combinatorial negotiation stemmed from the traditional combinatorial auctions. In a combinatorial auction, a set M of items, \(|M| = m\), is sold to n bidders. The combinatorial character of the auction comes from the fact that each bidder values bundles of items, rather than valuing items directly. The idea is to find such a partition of the items so that the return is maximized for the auctioneer.

A Combinatorial Negotiation based decision-support service (iBundler) for highly constrained negotiation scenarios has been proposed in [69]. iBundler acts as a combinatorial negotiation solver for both multi-item, multi-unit negotiations and auctions. The service can be employed by both negotiating agents and auctioneers in combinatorial auctions. It consists of three main components. The Manager agent takes care of all the communication. It provides brokering services of RFQ, collection of bids, winner determination and contracting services. The Translator agent perform the necessary XML translations for the Solver and FIPA-compliant descriptions for the Manager agent. The Solver component extends the iBundler with the offering of an XML language for expressing offers, constraints and requirements. The winner determination is modeled as a mixed integer problem similar to the the binary multi-unit combinatorial reverse auction winner determination problem in [75] with side constraints in [73].

4 Discussion

As mentioned earlier an automated negotiation mechanism consists of three main components, namely, a high-level protocol, negotiation objectives, and decision strategies; while the negotiation context dictates the selection and integration of these components [33]. In existing literature, this has usually been accomplished in an ad-hoc manner, which is of minimal interest in SOAs due to the high developmental costs of such solutions, lack of ubiquity, and dynamic participants. Consequently, the prime requirements for developing comprehensive negotiation mechanisms include:

  • Multi-attribute negotiation. A typical SLA negotiation involves QoS attributes such as reliability, availability, accessibility and response time [94, 95]. These QoS attributes (and others) influence the negotiation protocol and the customer preferences articulation that the negotiation system must support. Hence there may be more than one combination of these attributes that may be suitable under a specified negotiation context. User preferences could be expressed in a variety of ways, e.g., utility functions [25], combination of attributes [23], or fuzzy constraints [50] etc. The negotiation system should not restrict its user to a single negotiable attribute (e.g., price) rather it should allow the users to express multiple attributes for the negotiation process (REQ 1).

  • Support for heterogeneous negotiation protocols. In a service oriented system it is very much expected that all the participants using the system may not be similar. They may implement heterogeneous (probably incompatible) negotiation protocols. Thus, there is a need for supporting multiple negotiation protocols (REQ 2), or be able to consent on the negotiation protocol for cases where a participant supports multiple ones.

  • Heterogeneous decision model articulation. Different participants prefer different negotiation strategies (auction, bargaining etc.) based on their decision models, domains, preferences and history. There are usually two types of decisions that an automated negotiation system has to make. First, it has to generate counter offers in the negotiation by implementing an appropriate algorithm [24, 25, 39, 50]. Second, it has to handle commitment to the new SLA i.e., deciding if the agreement is acceptable and convenient to commit, and in some cases decommitment from previously created SLA [61]. This decision is mostly protocol independent. However, depending upon the negotiation strategy the counter offer generation could be totally different. For instance, in case of a bargaining strategy, there has to be a response for each negotiation message that is received, where as in an auction strategy, bids could be placed at any time. Hence, an automated negotiation system must implement multiple decision models (REQ 3) so that it could support protocol specific negotiations.

  • Dynamic user preferences. Unlike traditional software environments, SOAs enable delivery of the same service to different customers with varied quality of service (QoS) requirements [23]. Moreover, since negotiation is a dynamic and interactive process, the user preferences could change over time. The user may change the required value of a QoS attribute during the negotiation process, (as it learns new information during the negotiation) or may even add or remove new QoS attributes. Thus, the negotiation system should allow the user preference about the negotiation process to be changed over time (REQ 4).

  • Simultaneous negotiations. Since services are not stored or downloadable, the market environment tends to be very dynamic [27]. The ability to create on-the-fly dynamic solutions emphasizes the need of conducting simultaneous negotiation (REQ 5) with multiple component services, owned by different parties, at the same time. On one hand, it is necessary for the system to have a global view of all these negotiations to support them properly. However since the preferences of the parties involved in the negotiation could potentially change, it is beneficial for the system to guide the behavior of each negotiation based on the responses generated by other (simultaneous) negotiations. This allows the system to choose the party that would result in the most profitable agreement.

  • Support for dynamic selection of decision making models. Simultaneous negotiations are desirable in volatile service markets to allow selection of the most profitable agreements for the participants [27]. This entails that the participants are equipped to change their strategies/decisions at runtime (REQ 6), based on market dynamics and changing contexts [70]. The underlying strategy should be robust enough so that it can adapt to different behaviors of participants, and utilize “peripheral knowledge”. For instance, information relating to whether the participant tends to concede, participant reputation, etc. may be used to strengthen one’s negotiation capabilities [60, 61]. Similarly, in some contexts if a more profitable offer is found, there should be a provision to decommit from the current agreement [74].

Table 18.1 Summary of automated negotiation systems
Full size table

Table 18.1 summarizes how the current negotiation systems in the literature perform on the above mentioned requirements. An ‘✓’ in a cell means that the corresponding proposal provides explicit support for the corresponding requirement, whereas a ‘✗’ indicates that the feature is not supported and ‘n/a’ means that there is no information available. The table shows that most of the existing solutions do not do well when it comes to supporting multiple negotiations at the same time or dynamic selection of decision making models. Moreover, none of the solutions provide any dependency modeling among different QoS components. Howsoever this is is an extended requirement in composite solutions that often have dependent QoS objectives. For example, if we were to have a composite solution consisting of taskA and taskB and one of the objective was to have services that could handle a load of 1 million transactions per minute. What if we have multiple services offering such a solution for taskA but could not find any service for taskB that could meet our current objective. It would then be more economical for the composite solution to downgrade taskA to the level of taskB’s solution (since throughput of a system is a composite function of its constituent services). Continuing with this hypothetical scenario, we need the negotiation service to be able to simultaneously negotiate multiple services having multiple objectives with multiple providers. Existing communication protocols [4, 28, 43, 78, 86] lack such capabilities, and a new standard language that could be used to pass on all these constraints and decision model to the negotiation system is required. This leads us to look for a new solution that not only fairs better in comparison with the existing solutions, but also supports all the requirements of a SOA based negotiation system.

4.1 A framework for Web Service Negotiation

In this section, we provide an overview of our solution for the service negotiation problem. Figure 18.3 presents a high level architecture of a negotiation system (defined as WebNeg) that is very flexible in terms of its functionality and the services provided. It is primarily targeted to be invoked by the customer searching for a compatible service from a list of service providers providing similar functionalities. The client does not need to implement any negotiation specific component to use the proposed service. The WebNeg architecture is compatible with both the negotiation scenarios i.e., the negotiating participants could either provide their own negotiation component or send all the necessary information to the service, that would handle all the negotiation process. A brief overview of the major modules of the proposed negotiation architecture is as follows:

4.1.1 Negotiation Service

The negotiation service layer acts as the interface of the whole system. This layer is responsible for any and all external communication of the system. All the internal components use this service to communicate with both the customer and provider as well as with the community (to be discussed later). Customer invokes the service providing its negotiation attributes, negotiation policy as well its decision model. The service then communicates with potential providers and request their decision model and policy attributes for the negotiation process.

Fig. 18.3
figure 3

WebNeg system architecture

Full size image

4.1.2 Policy and Protocol Preprocessor

This component is responsible for standardizing the inputs from the communicating participants. Different participants may use different protocols for describing their decision models and policy attributes. A generic component would ensure that these heterogeneous participants could communicate with the negotiation service. After receiving this data from the negotiation service this component then translates it into a standard form which is used for the internal information exchange among different components of the system. It then stores these participant communication preference in the Policy and Protocol database. Negotiation service would then use this information for any future communication with the participants. This generic module would ensure that the system is compatible with any future communication protocol and ensures that customer and providers using different communication protocols could still negotiate service attributes and form service level agreements (SLA).

4.1.3 Negotiation Manager

Once the service receives a request for negotiation from the customer along with all the necessary data, it then proceeds to the negotiation step. Negotiation manager would then query the Web service directory e.g., UDDI to search for the matching service providers. The customer also has the option of providing its own list of possible providers. Once it has the list of service providers providing similar services, it then ranks these providers based on their ratings, trust and reputation values.

It uses the trust model based on the concept of community [53] where the reputation represents the perception of the users in that community regarding a service. So, the rating of a service represents the average of all the rating provided to the community for that individual service. For the newly starting service that does not have any history, it uses the reputation bootstrapping mechanism defined in [55]. Community is a centralized knowledge base that would be responsible for storing all the data regarding different providers, including reputation, trust and past negotiations. The community ensures that no private information is released to its users but could publish non identifiable data e.g., It does not give out any information about systems that are using lets say ServiceA, but could tell the total number of the systems currently running ServiceA. These pieces of information combined with the above mentioned methods of trust and reputation assessment, help the negotiation manger in selecting appropriate services, from a number of services providing similar functionalities.

4.1.4 Negotiation Component Manager

Since negotiation is a multi-party mechanism, the WebNeg system needs to spawn separate components for each customer and provider. In the most basic scenario at any given instance, the systems would have one customer and multiple provider components. These components operate in their separate context and communicate with their original service through the communication manager. The communication manager is responsible for creating and manging these components.

4.1.5 Negotiation Strategy Manager

There are multiple strategies available for conducting efficient negotiations. One such strategy is defined below in Sect. 18.4.2 (defined as WebNeg). Our system architecture does not restrict the components to any one negotiation strategy. It has multiple strategies for the components to choose from. Participants could opt for using any strategy and could pass on this information as a policy to the system. If none is chosen the system selects one or a combination of strategies for the negotiation process. The negotiation strategy manager selects and binds each component with the appropriate strategy and is responsible for implementing the component policies and decision model in the context of the selected strategy as well as monitoring and storing any transient data related to the negotiation process.

4.1.6 Communication Manager

All the external pre-contract communications are handled by this manager. The component may communicate with their respective services for any decision model or policy/guidance queries. Communication manager ensures that all the communication is related to the current negotiation and adheres to the negotiation service’s policies.

4.1.7 Contract Manager

Once the system identifies perspective negotiation solution(s), it is presented to the respective services, if they agree, contract manager then handles all the formal SLA creation process. If the current selected provider does not agree on the solution, the system would then try the next best available solution, until either an agreement is achieved or the system has ran out of options. If the system could not find a mutually agreeable solution, then the process would be termed as a failure and the customer would be asked to revise its negotiation model.

4.2 WebNeg

We present a GA based approach to solving the Web service negotiation problem [29]. We enhance the traditional GA with a new operator called Norm. Our proposed approach complements the proposed negotiation framework that is designed towards a scenario where a customer is involved in simultaneous negotiations with multiple providers. Each instance of communication among the customer and service provider is private and holds a lot of information. The proposed Norm operator makes it possible to share this private information among all the participants without revealing the source of any of such information. This in turn helps all the agents to adapt quickly and significantly reduces the search space by guiding the negotiation process toward a mutually agreeable solution.

We propose a weighted sum genetic algorithm to support multi-party multi-objective negotiation. All the Web services provide their respective QoS parameters to be negotiated. These are called the component vector of a Web service. Each vector is accompanied by a decision model, i.e., ranges of all the QoS parameters as well as their respective priorities also known as the weights. We assume that all the participating Web services are able to articulate their objectives and prioritize them. Table 18.2 lists the definition of symbols used henceforth.

Table 18.2 Definition of symbols
Full size table

Since all the Web services (participants) start negotiation from a different position, they have different preferences for those objectives, and are described by how far their current position is from the customer’s objective. All the Web services conform to some constraints in the solution. For instance, any QoS vector cannot have a negative value (as shown by Eq. 18.1). The QoS values lie between the maximum and minimum allowable values set by the Web service (as shown by Eq. 18.2). A repair algorithm is applied to GA after each operator, to ensure all these constraints are met.

$$\begin{aligned} C_{j} \ge {0} ~,~ P_{ij} \ge {0} \end{aligned}$$
(18.1)
$$\begin{aligned} C_{j(min)} \le C_j \le C_{j(max)}\;{\text {and}}\;P_{ij(min)} \le P_{ij} \le P_{ij(max)} \end{aligned}$$
(18.2)

Each gene is a combination of customer and provider chromosomes. If we have \(n\) objectives to be negotiated then each gene will have \(2n\) chromosomes. The fitness function is a multi-step calculation that evaluates the level of disagreement between the negotiating Web services. A weighted sum approach is used to combine these multiple QoS parameters (objectives). We use a distance function to measure the difference among the proposed solutions of both the customer and provider Web services. Thus, lower fitness values are desired as they translate to lesser disagreement among the participants. Similarly, lower values translate to higher ranks for the solutions among the solution space. Ranks are then used for selection of subsequent steps of the GA [88]. Each solution represents a probable distribution of values that may be agreed upon by the other Web service in the negotiation. The fitness value of a solution is calculated as follows.

$$\begin{aligned} \varDelta _{ij} = \frac{| C_j - P_{ij}|}{C_j} \end{aligned}$$
(18.3)
$$\begin{aligned} f_j = \sum \limits _{j=0}^n ( WC_j * \varDelta _{ij} + WP_{ij} *\varDelta _{ij}) \end{aligned}$$
(18.4)
$$\begin{aligned} F_s = min\sum \limits _{j=0}^{G}(f_j) \end{aligned}$$
(18.5)

Pareto optimality is not enforced after each generation as it is possible for a Web service to accept a less favorable solution for the time being (in the negotiation process) for a better solution in the long run. However, a secondary population of solutions is kept which is updated after each iteration. This secondary population or Elitism is a an important concept in genetic searches [7, 98]. The probabilistic nature of GA does not guarantee that the best solutions would be preserved in the final generation. Hence a secondary population of best solutions is kept through all generations. Below is the algorithm used to determine the optimal solution. Details follow.

figure a

End Algorithm

4.2.1 Norm Operator

A new operator Norm is implemented to improve the performance of GA and to simulate the exchange of resources based on the common knowledge of the society in a negotiation scenario. The Norm operator is based on the observation that in each society people follow certain trends or norms to conduct negotiations. These norms are either informed by the environment or are discovered by the population based on the prior experiences. These norms are transfered through generations and different people follow different norms. Often people are inclined to abandon or follow a new norm on the basis of the facts if they think they are being better off following or deviating from them. Most helpful norms tend to accumulate more followers, which in turn re-enforces that norm. People tend to abandon less useful norms in the favor of useful ones. Once in a while people just hop around trying to find out what works the best for them. These norms serve as a guide for achieving their desired goals. Figure 18.4 shows a scenario that depicts the concept of norm. Assume we have \(n\) norms (information sources) in the society and \(k\) population subsets. Set 1 may follow Norm 1, Set 2 may follow Norm n and Set m may choose to follow Norm 2 while others may not choose to follow any Norm. The selection of subsets and Norm selections are random. Population in Set 1 is effected by the values of Norm 1 and they in turn effect the values of the Norm. This cycle makes sure that beneficial values are prevailed in the Norms.

Fig. 18.4
figure 4

Norm operator in relation to population sets

Full size image

We have the Norm operator behavior defined above in the GA, so that it takes less time to find the solution and to reduce the search space. Each QoS negotiation criteria is represented as a norm and certain members of the population follow a certain norm. After each generation, the followers update the impact factor of their respective norm. If increasing the value of the norm resulted in a better overall fitness value for the member of population, it would influence the norm into increasing its value. The increase is dependent on the difference of current and previous values of that objective of the reporting individual and the current absolute value of that objective. Both customers and providers share the same influence values of norms. This is an indirect information source for the customer about providers decision model and vice versa. Ideally, we will have one customer and n providers, hence sharing these impact factors does not reveal any trade secrets. These values have the bias of n+1 agents and are averaged out.

Norm is implemented for the exchange of recourses among different participant. Exchange must occur between two distinct objectives, participants can trade some or all of their available objectives and there is at most one exchange per pair per generation. Exchange is implemented probabilistically. Each member of population is reviewed for possible exchange. The participants and objectives involved in the exchange are selected randomly. Then it is decided if an exchange will actually occur based on the willingness of participants. The exchange only occurs if both randomly selected participants are willing to make an exchange. Essentially, willingness to exchange is higher if a participant has more of an objective than he ideally wants and if the information source that he is following is influencing a lower value of that specific objective. If the current Web service is following \(Norm_m\) then the willingness to exchange is calculated as

$$\begin{aligned} E_{ij} = |\frac{C_i}{N_m}| \end{aligned}$$
(18.6)

and the amount exchanged would be

$$\begin{aligned} A_{ij} = (1 - WC_i)|1 - \frac{C_i}{N_m}| \end{aligned}$$
(18.7)

If the current Web service is not following any Norm then the willingness to exchange is calculated as

$$\begin{aligned} E_{ij} = |\frac{C_i}{P_{ij}}| \end{aligned}$$
(18.8)

and the amount exchanged would be

$$\begin{aligned} A_{ij} = (1 - WC_i)|1 - \frac{C_i}{P_{ij}}| \end{aligned}$$
(18.9)

4.2.2 Crossover and Mutation

The crossover operator is invoked after applying the Norm operator. Roulette-wheel selection is used for selecting solution pairs for crossover. Roulette-wheel selection is analogous to a roulette wheel where the probability an individual is selected is proportional to its fitness [32].

Solution rankings are used to implement selection. The population is augmented so that solutions with better ranks are more prevalent in the population. We use both ranks and fitness values for our selection technique because ranking indicates the performance of solutions relative to others in the population and minimizes the effect of large disparities in fitness values within the population [88]. Augmentation of the population for roulette-wheel selection is performed as follows:

$$\begin{aligned} CrossP_{j} = 1 - \frac{1}{R_{j}} (R_j - 1) \end{aligned}$$
(18.10)

Crossover rate is used to determine if crossover will actually occur or if the selected solution will simply be copied over to the next generation. If it is determined that crossover will occur, uniform crossover is implemented on the pair. It has been proved that custom operators provide superior performance for real-valued problems [90].

Mutation is the last operator to act on the population of solutions and is also applied randomly to the elements of the solution, in accordance with the experimentally predetermined mutation rate. A random number is generated for each member in the population and compared to the mutation rate. If the random number is less than or equal to the mutation rate, mutation will occur in that solution. Mutation here involves arbitrarily changing one element of the negotiation vector and then implementing a repair algorithm to ensure that objective values lies within the valid range for that agent.

4.2.3 Study and Results

To determine the efficiency to GA with the Norm operator we performed experiments covering different scenarios. We compared the performance of GA with Norm with other methods of solving similar problems. We used (1) a traditional GA with only mutation and crossover operator, (2) a random search and (3) a hill-climber. We used experiments to determine the GA parameters such as population size, number of generations, crossover rate and mutation rate.

Traditional GA: A traditional GA was implemented by removing the Norm operator. It only uses the simple GA operators of crossover and mutation. All the GA parameters are same as that of GA with Norm operator.

Random Search: Random search simulates the behavior of arbitrarily exploring the search space in the hope of finding a solution. It is applied on one half of the gene at a time. Either the customer’s Web service gene or provider’s Web service gene parameters are augmented. This augmentation likelihood is determined randomly. Once selected, a random number is generated for each QoS parameter that lies between the allowable range for that participant. Then all the numbers are aggregated by subtracting their respective minimum values. This summation is then averaged out and either added or subtracted randomly to all the parameters. Then the repair algorithm is applied to ensure that all the constraints from Eqs. 18.1–18.3 are held. Then we add this new solution of our population. The population is then ranked according to their fitness values and members with higher fitness values are taken to the next generation.

Hill-Climber: Hill-climber uses the concept of randomly exchanging the QoS values. It is somewhat similar to the Norm operator as both use Eq. 18.10 to determine the amount of the objective to be exchanged. However, the GA with Norm uses either Eq. 18.7 or Eq. 18.9 to determine if the exchange will occur, while in hill-climber it is done randomly. Once a gene is randomly selected, the exchange takes place. However, it is guaranteed that only one objective per gene is exchanged and that once selected, that gene does not participate in any other exchange for that generation. We create the initial population and rank them according to their fitness values. We then perform crossover using Roulette-Wheel selection method. Then we apply the mutation operator. After we are done with the basic GA operators we apply the Hill Climbing operator on the population. The repair algorithm ensures that all the constraints from Eqs. 18.1–18.3 are held. All the GA parameters are same as that of GA with Norm operator.

4.3 Experiment Environment

Our development environment consisted of a Windows server 2008 (SP2) based Quad core machine with 8.0 GB of ram. We developed 1 client and 50 provider Web services running on Microsoft .Net version 3.5 to simulate multi-party negotiations. A large number of similar providers are chosen to show the applicability/scalability of the proposed solution. The client negotiated four QoS components of reliability, availability, throughput and accessibility with the providers. We performed 200 iterations consisting of 500 generations each, for all the four algorithms and analyzed the results for efficiency and completeness.

4.4 Results

Figure 18.5 shows results of a representative run of the four algorithms after each generation. Note that these are the actual output values without Elitism [7, 98]. We have plotted the output of 500 generations (X-axis) against the degree of disagreement (Y-axis) among the client and provider Web services. Lower values of degree of disagreement are desired as they show a higher chance of reaching an agreement e.g., Assume that Web service \(A\) wants a solution that has an Availability value of 98 % and the provider \(B\) presents a solution that has an Availability value of 95 %. The degree of disagreement among the \(A\) and \(B\) is small and hence they are more likely to reach a solution. Note that both the customer and provider must have some overlapping search space values for the algorithm to identify a solution. If both the customer and provider have mutually exclusive ranges of QoS parameters, the algorithm fails and no solution is returned.

The graph confirms the assumption that the probabilistic nature of GA does not guarantee that the best solution will be passed on to the next generation. Hence, using Elitism to ensure Pareto optimality is an important factor. Our proposed technique (GA with Norm) takes almost 1/4th the time to reach an agreeable solution. We can see in the graph that Norm found a mutually agreeable solution after 100 generations, where as Hill Climber took 475 generations, Traditional GA took 450 generations and Random Search took 375 generations to find their respective best solutions. Hence, we can find the solution faster with our proposed approach. Similarly our proposed approach finds a lot better solution than any of the other techniques.

Fig. 18.5
figure 5

Sample representation of multi-party negotiation

Full size image

The probabilistic nature of GA does not guarantee the same solution every time. Hence, it is appropriate to analyze the performance of GA over multiple rounds. Table 18.3 shows that average of 200 runs for all four algorithms.

Table 18.3 Average results over 200 iterations
Full size table

We can see that the best solution of 0.00002 returned by Norm is far better that best solution returned by any other technique. Similarly Traditional GA performed better than the Hill Climber in finding a more agreeable solution. As far as the worst solution is concerned, Norm still performed better than any of the other techniques. The worst solution of 0.03163 returned by Norm is almost twice as good as that of Hill Climber, the second best technique. The average solution returned by Norm shows a remarkable improvement from the next best i.e., Hill Climber technique, depicting that the Norm also has the best average case performance among the compared techniques. Similarly our proposed technique has the lowest standard deviation of 0.01157. Lowest mean value combined with the lowest standard deviation indicates that our technique performs consistently better than other techniques.

These results suggest that our approach outperforms other compared methods in terms of finding the optimal solution in the amount of time it takes to find that solution.

5 Conclusion and Future Directions

Designing an automated, flexible and efficient negotiation system that facilitates the Web service selection process, is challenging. None of the existing solutions meet all the requirements for a completely automated solution for Web service negotiation. One of the limitations of the presented techniques involve the assumption of a static environment, where the Web service procurement time window is so small that the user preferences do not change during the course of negotiations. Secondly, most of the solutions use a priori decision model articulation, which requires that all the negotiating participants can identify and share their preferences at the beginning of the negotiation. However, some of these limitations involved with the static environment assumption could be overcome, if participants decide to provide their own negotiating component rather than only articulating their preferences. However, this limits the effectiveness of sharing private information. Therefore, we need to design a negotiation system that can support multiple communication protocols for enabling interactions among different customers and providers as well as supporting multiple negotiation strategies for an optimized solution. The solution should support multiple simultaneous negotiations and provide mechanisms to model the dependency relationships among different component services to achieve an optimal solution.

In this chapter we have presented the framework for Web services negotiation to enable customers and providers negotiating QoS parameters in SLA’s. The presented architecture uses a GA based approach to conduct multi-party multi-objective negotiations. Our approach integrates the concepts of Pareto optimality and multiple decision making preferences of the participants. We have enhanced the traditional GA with a new operator called Norm. This operator is based on the concept of cumulative knowledge of the society over a period of time. This accumulated knowledge influences the decision making process of negotiating participants. Furthermore, Norm provides a platform for sharing private information of all the participants of the negotiation in such a manner that allows for using this shared knowledge for the overall gain of the society, without revealing the identity of information providers. We have compared Norm’s performance with similar optimization techniques i.e., Traditional GA, Hill-Climbing and Random Search. The results show that our proposed technique performs better than any of the above mentioned techniques, and that applying a genetic algorithm based approach to complex negotiation for Web service composition problems is a viable option.

We are currently investigating on enhancing the effectiveness of private information sharing by exploring the possibilities of having people follow multiple information sources rather than following just one source. This is motivated by the fact that composite solutions often have dependent objectives. We want to further extend our approach to incorporate these dependencies among the different QoS parameters of multiple services to formulate optimized solutions. We need to be able to use the information sources of Norm operator to share such information. We need the negotiation service to be able to simultaneously negotiate multiple service having multiple objectives with multiple providers. Existing communication protocols [4, 28, 43, 78, 86] lack such capabilities. This requires a new standard language that could be used to pass on all these dependency constraints and decision model to WebNeg. We are exploring the options of extending WS-Negotiation [30] and WS-AgreementNegotiation [89] by adding the support of complex logical functions for articulating these and similar complex decision models. We are also working on a solution that moves away from the centralized approach in the favor of a more adaptive distributed model.