WS-AgreementNegotiation

Document Sample
WS-AgreementNegotiation Powered By Docstoc
					About Negotiation

Table Of Contents:

1.   Negotiation in Web Services ...................................................................................... 1
  1.1.   WS-AgreementNegotiation................................................................................. 1
  1.2.   WS-Negotiation .................................................................................................. 2
2. Negotiation Protocols.................................................................................................. 5
  2.1.   The Contract Net Protocol .................................................................................. 7
  2.2.   A Middleware Negotiation Facility .................................................................... 8
     Example-Print shops ................................................................................................... 9
  2.3.   Xplore ............................................................................................................... 11
     Example –NegotiAuction.......................................................................................... 11
  2.4.   E-Alliance ......................................................................................................... 14
  2.5.   Algorithm to find the Pareto-optimal solutions ................................................ 18
  2.6.   The Rubinstein alternating protocol.................................................................. 20
  2.7.   The Strategic Negotiation model – Simultaneous response protocol ............... 20
3. The Montreal taxonomy for Electronic Negotiations ............................................... 21
     Applying the taxonomy..........................................Error! Bookmark not defined.22
Discussion ......................................................................................................................... 22
References ......................................................................................................................... 22


1. Negotiation in Web Services
     1.1.             WS-AgreementNegotiation

In short, WS-AgreementNegotiation describes the re/negotiation of agreements between
two parties. There are many possible scenarios on how two parties can come to an
agreement depending for example on who initiates the process or if there is any
negotiation at all. It specifies a set of messages and resources that can be used to model
one of these scenarios.

WS-AgreementNegotiation sits on top of WS-Agreement, so that it would be possible to
switch to a different negotiation protocol if needed. However, it requires expressing
negotiation offers with WS-Agreement, which results in tying it strongly to WS-
Agreement. Moreover, it allows renegotiation of existing agreements. Negotiations are
assumed to be between only two parties and can it can be initiated by either the provider
or the requestor.

Following is a high level description of the protocol. Let the provider be the initiator. He
sends an agreement template to the customer. An Agreement template describes the
service (WSDL of the interface), the guarantees and the options available to the other
party. The service consumer responds by sending an offer according to this template. The
provider may accept, reject or make a counter offer based on this offer. An offer may
contain negotiability constraints that have to be satisfied in any counter-offer. Offers are
sent back and forth until an agreement is reached and both parties are committed to it (the
agreement becomes “observed”).

The agreement negotiation process described in a lower level as presented in [15]:
   1) The initiator calls the createAgreementAndNegotiation operation on the
       specialized Negotiation Factory service to generate an Agreement and a
       Negotiation.
   2) The Factory service returns an EPR to an Agreement and an EPR to a
       Negotiation.
   3) The initiator calls the negotiate operation on the Negotiation service in order to
       change the current state of the agreement: the terms being negotiated or the
       commitment status. The Negotiation service either rejects the offer using a non-
       terminating i.e. continuing fault or accepts the offer and updates the state of the
       Agreement.
   4) Step 3 is repeated until one party decides to stop negotiation or both parties
       commit to the current offer. For example the Negotiation service can send a
       terminal fault, indicating unwillingness to accept any further message.
   5) Eventually both parties commit to an offer and the agreement becomes observed.

Port Types                                          Operations
wsan:NegotiationFacroty       wsan:createNegotiation:      wsan:createNegotiationAgreement:
                              used to generate a           used to generate a wsag:Agreement
                              wsan:Negotiation             and a wsan:Negotiation to
                                                           negotiate it
wsan:Negotiation              wsan:negotiate: used to send offers by WS-Agreement


   1.2.        WS-Negotiation

WS-Negotiation is a domain independent language for generating agreements between a
service provider and a service requestor. It can employ different types of agreement
templates.

Figure 1 depicts a negotiation process. In WS-Negotiation only two parties are
considered: a provider and a requestor which want to negotiate on a set of issues. Some
of these issues are of primary importance and must be negotiated. Among these, there
might be issues that a party does not want to negotiate on their values (fixed) and some
others that are open to negotiations. There can also be issues of less significance that can
be introduced later into the process. The process starts, and all involved parties have to
introduce themselves (“Define Negotiation Environment” task. At this task for example,
a SLA template could be defined). This generates one or more negotiation plans which
are finalized in the “Initial Contact” task. Once this has been settled, the two parties start
exchanging proposals (“Offers and counter-offers” task) which are evaluated according to
the strategy each party has chosen (“Evaluation” task). The last two tasks are repeated
until a mutual acceptable proposal has been submitted or one of the parties has quit the
process (“Outcomes” task. In case of SLA negotiation the outcome is a SLA). In each
one of those cases, the process is completed (“End” task).




Figure 1: The negotiation process




Figure 2: The three parts of WS-Negotiation


As shown in Figure 2, WS-Negotiation consists of 3 parts:

    1) Negotiation Message: This part describes the format of the messages exchanged.
       Some suggested message types are: Offer, Counter-Offer, Rejected, Accepted,
       etc. (The Schema and semantics of the messages are to be defined in the future).
       This part of WS-Negotiation shall tackle the “Initial Contact” and “Offer and
       Counter-Offer” tasks (Figure 1).
    2) Negotiation Protocol: describes the mechanism and the rules the negotiation
       parties should follow to exchange messages. Messages contain the offers and
       counter-offers and can be exchanged between requestor and provider as well as a
       third-party negotiation service (Negotiation Support System-NSS) (Figure 3).
       This part of WS-Negotiation shall also tackle the “Initial Contact” and “Offer and
       Counter-Offer” tasks (Figure 1).
      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. They may have corresponding negotiation messages and they can be
      implemented as Web methods in both sides. 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.
   3) Negotiation Decision-making: This is the component that 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 shall
      tackle the “Evaluation” task (Figure 1).

So in short, in a negotiation scenario between party A and B, the negotiation protocol
orchestrates the negotiation messages, which trigger and conduct the negotiation
decision-making process.

Negotiation issues vary from one business domain to another but there are some issues
that are common or fixed in a domain. So, domain specific vocabularies are introduced
for different types of business contexts. According to the SLA Template Model (Figure)
suggested by [7] domain specific vocabularies can directly or after negotiations (through
WS-Negotiation) generate SLA documents. WSLA is considered a potential solution for
representing SLA templates.

One suggestion on how to implement WS-Negotiation is to embed the negotiation
messages into the SOAP messages.

So far, only bilateral scenarios (one-to-one negotiation) are considered. The multi-party
case (one- to- many) is currently being investigated by the authors of [7].


   1.3.        The Rubinstein alternative protocol in WS

This protocol (defined in Section 2.6) is expressed in XML in [12]. In order to represent
the messages sent back and forth between two parties WS-Agreement could be used.
However, WS-Agreement only provides templates for tow types of messages: offers and
agreements which are constraint according to a template the service provider publishes.
This is not sufficient to model a complete negotiation process. According to [12], there is
a need for a set of speech acts. Moreover, there is no interaction protocol specified in
WS-Agreement and there is a lack of semantics as only higher level templates for offers
and agreements are defined. There is a need of a language to express the elements in the
service description terms and guarantee terms. Finally, there is no indication on how to
access or provision a service from an agreement [12].

The following speech acts are suggested: offer, counter-offer, agree, and reject (WS-
SpeechActs- wssa) [12]. Each of these has parameters: sender, receiver, service
description, the process to be executed and the agreement terms (e.g. deadline, penalties
etc). An offer can be followed by a counter-offer but a counter-offer cannot be followed
by an offer.

State diagram for the Rubinstein alternative protocol:




XML definitions of the documents exchanged, such as counter-offer as well the
Rubinstein alternative protocol is described in [12].


2. Negotiation Protocols

   2.1.        The Contract Net Protocol

The Contract Net protocol was introduced in order to deal with distributed problem
solving and more specifically with the question of how tasks should be distributed among
a set of nodes in order to solve a problem. So, we assume there is a set of nodes that
engage each other in a sort of negotiations that may result in a contract.

During a negotiation, nodes can have two roles: they can be either a manager, that is
looking to outsource a task and initiates a negotiation process or a contractor that bids in
order to insource a task. A node can also operate in both roles at the same time but for
different negotiation processes. The contract net protocol specified the messages that
should be exchanged among the nodes during a negotiation process.
The manager publishes a task with a task announcement message. This message can be
broadcast or sent to specific addresses. It has four slots: the eligibility specification which
indicates the characteristics a node should have in order to receive the task, the task
abstraction which briefly describes the task, the bid specification that describes what an
offer should specify and an expiration time that is the deadline before which the offers
should be sent. All nodes maintain a rank-ordered list with the announcement tasks they
have received that they could undertake and that have not yet expired. So on receiving an
announcement message a node checks whether they fulfill the eligibility specification and
place it on this list. The nodes submit their bid. They choose a task from the list and send
an offer. An offer contains the node abstraction slot which states the node’s capabilities
as a reply to the announced bid specification. The manager also maintains a rank-ordered
list with the bids it receives. The manager checks the bids and awards the task to the most
satisfactory offer (announced award message). This can be done after or even before the
deadline. The announced award message gives all the additional information the node
needs to start executing the task (task specification slot). If no bids are received, if for
example all nodes are busy with other tasks at the time, the manager can wait and resent
an announcement. During the task execution the manager and the contractor can
communicate with (general) information messages. Report messages can be sent by the
contractor to inform on the progress (interim report) or on the completion (final report)
of the task. A manager can terminate a task before its completion (terminate message).

When implementing the protocol, trade-offs might be needed to guard the system’s
performance. For example, according to the protocol, a node is allowed to bid for more
than one task announcements. So it is possible that it is awarded with more than one task.
In that case the tasks would queue and the process would be slower. A solution to that
could be for example that a node could only bid for one task. However, in that case nodes
should wait idle until they are informed that their bid was refused. The CNET (Contract
Net system) addresses that by allowing only idle nodes to bid and send only one bid for
each announcement.

The basic negotiation mechanism has been presented above. Following are some
extensions of it to address specific problems. For example what happens when there are
no idle bids or no eligible ones or some nodes that are both idle and eligible have ranked
a task too low. For that the immediate response messages are introduced. When receiving
such a message a node should immediately reply if it is ineligible, eligible but busy or
eligible but low ranking or by a normal bid.

Another special case is when a manager knows which node is more suitable for the task.
In that case a direct contract can be awarded. This is done by a direct award message. No
announcement or bid messages are exchanged. Acknowledgment messages can be
exchanged to either confirm (acceptance message) or reject (refuse message) the task
award.

Nodes might need exchange information in order to complete a task. For that they send
request massages. A node that receives such a message and has the information responds
with the information requested. It might be part of a node’s contract to send this kind of
information upon request. In that case the response might have to follow a special format
defined in the contract.

A negotiation can be initiated by a contractor as well. When a node is idle it can send a
node available message similar to the announcement message. In that case, the eligibility
specification slot describes the characteristics of the task it could execute. When a node
receives such a message it checks the tasks it needs to outsource. If one of them matches
it responds with direct award.

In order for the nodes to be able to communicate a Common Internode Language is
specified [16].


   2.2.       The FIPA Contract Net Interaction Protocol

This is the FIPA (Foundation for Intelligent Physical Agents.) standard for negotiation
between agents. It is based on the Contract Net Protocol [8, 16]. Two kinds of
participants are considered: the manager who initiates the process and the contractor who
submit offers. At any time any agent can be initiator, contractor or both. The protocol
allows contracting and subcontracting.
This is the outline of the protocol:

       1. The Initiator sends out a Call for Proposals (CFP) to m participants. A CFP
       describes the task and the preconditions and constraints the initiator has set. To
       make sure that the initiator will not wait infinitively for a reply, a deadline is set.
       Proposals received after the deadline, are rejected.
       2. Participants review the CFP and bid on the feasible ones. In the proposals a
       value for each one of the preconditions and constraints should be suggested. N of
       them are able to generate n responses. J of them will actually reply with a bid and
       N-J will refuse.
       3. After the deadline, the Initiator evaluates the proposals, chooses the best L bids
       and sends back an accept_ proposal act.
       4. Initiator rejects other bids by sending a reject_ proposal act.
       5. Once a task is completed, the Participant sends a inform_ done act to the
       Initiator. In case it fails to complete it it sends a failure message.

Figure 4 summarizes all the above:
Figure 3: FIPA Contract Net Interaction Protocol



    2.3.        A Middleware Negotiation Facility

This is also based on the FIPA CNIP protocol.

Here, the negotiation process is modeled by a negotiation tree. Each branch corresponds
to a choice during the negotiation, which may not be exclusive and each node contains
information on the parameters negotiated. Each component involved in the negotiation
process has its own copy and communicates with the others through the modifications it
performs on its copy. These modifications are propagated by the middleware level which
is also responsible for synchronizing the different tree copies.

The interaction protocol consists of the following verbs [1]:
    Open (n1, n2) creates a new node in a negotiation tree from the node. (Creation of
       a new negotiation branch.)
       Close (n) prevents any further development from the node in a negotiation tree.
        (Disabling a negotiation branch.)
       Request (n, p, a) requests information on an aspect a of the parameter at p at a
        node n of the negotiation tree. (Retrieving information for making informed
        proposals along a negotiation branch.)
       Assert (n, p, a, t) describes an aspect a of the parameter p at a node n by the term
        t. (Refining the negotiation terms.)
       Ready (n) states that the component is ready to enter in the enactment phase in
        the condition expressed by the node. (Phase transition.)

In short, each party will develop its negotiation tree by invoking the operations of the
protocol, which are then propagated to the other participants via the coordinator.


Example-Print shops

Let C be the coordinator, P0 a print shop that wants to outsource a job, which it divides it
into job1 and job2. P0 has the following constraint: the cost should not exceed 100. The
following figure (Figure 5) illustrates a negotiation scenario.




Figure 4: Negotiation Scenario using the refined CLF Middleware protocol [1]

   The coordinator starts a negotiation by initializing a negotiation tree in each print
    shop.
       C->P0.open (0, 1)
       C->P1.open (0, 1)
       C->P2.open (0, 1)

   The print shops ask for information on the negotiation item, for example:

       P1->C. request (1, job1, {cost, date, size})

   The request is sent to the coordinator which is responsible to propagate it further to
    P0, for example:

       C->P0.request (1, job1, {cost, date, size})

   P0 responds by describing the range of the cost and the size it is willing to accept. P1
    and P2 receive the job description they had requested.

       P0->C. assert (1, job1, {cost: 40+-10, size: 20 + -5})
       P0->C. assert (1, job2, {cost: 60+-10, size: 30 + -5})
       C->P1.assert (1, job, {cost: 40+-10, size: 20+-5}
       // P1 had requested job1
       C->P2.assert (1, job, {cost: 60+-10, size: 30 + -5})

   Print shop P1 makes two offers, with the same size but with two different options for
    the cost (it creates a new negotiation branch):

       P1->C.     assert (1, job, {size: 15})
       P1->C.     open (1,2a)
       P1->C.     open (1,2b)
       P1->C.     assert (2a, job, {cost: 30, date: 12/Dec})
       P1->C.     assert (2b, job, {cost: 35, date: 10/Dec})

   The offers are propagated to P0 who needs to decide which alternative would satisfy
    its needs. By choosing one of these 2 offers for job1, job2 should not cost more than
    65-70 (keeping into account that the total cost must not exceed 100). P0 tells that to
    P2 through the coordinator.

       P0->C.assert(2a,job2,{cost:<70})
       P0->C.assert(2b,job2,{cost:<65})

   Finally, P0 accepts the less expensive option for job1 (2a) and rejects the other one
    (2b).

       P0->C.close(2b)
       P0->C.ready(2a)
   2.4.        Xplore

Xplore [3] provides a lightweight coordination platform for multi-party and multi-
attribute negotiations and is based on the interaction protocol described in Section 2.3.

In Xplore a negotiator is modeled as a participant, which in essence is a piece of
encapsulated software. Each participant’s action is considered as a service invocation (e.g
outsource /insource service in case of the print shop example). The negotiation process
can be seen as the process of refining the definition of these services.

Here, the negotiation state is modeled by a directed bi-colored graph called negotiation
graph. The graph consists of two types of nodes: white ones which represent negotiation
contexts and contain information on a participant proposal and black ones which
represent decision points with multiple alternatives. For black nodes two properties
should hold: (1) two paths from the root diverging at a black node may never meet again
afterwards (since they represent exclusive alternatives); and (2) service instances
connected to a graph never see the nodes located on alternative paths from ancestors of
the nodes where they are connected.

The negotiation process is modeled as a collaborative construction of the negotiation
graph among the negotiation participants. Each participant has their own partial copy and
view of the graph, which means that he can only view the evolution of his proposals.
Participants communicate with each other indirectly, through the operations they perform
on their graphs, which are invocations of the Xplore protocol (Connect, Open, Assert etc,
see Section 2.3). Again, these operations are propagated through a coordinator. The
coordinator has the whole view of the graph and is responsible for synchronizing the
participants’ partial copies.

Applications of Xplore have essentially been investigated in the domain of E-Commerce
and B2B process support. Xplore has been also used as the negotiation infrastructure for
Virtual Alliances among organizations (presented later in Section 2.5).


Example –NegotiAuction

Here, an example of using Xplore to describe a NegotiAuction is presented [4].
NegotiAuction is an algorithmic Internet-based auction procedure that combines auction
and negotiation characteristics. In a NegotiAuction an Auction Owner initiates the
auction and defines the type of the auction, the goods he wants to sell/buy as well as
whether the process will be open to any participant or they should be explicitly invited.
The type of auction can be reverse or forward. Reverse is a negotiation in which the
buyer posts an offer and the seller refines it, while forward is a negotiation in which the
seller advertises a deal and the buyer submits offers [5]. A negotiation can also be
automatic when specific constraints are set by the Auctioneer during the initialization of
the negotiation, or manual when no constraints are defined. An Auction House is a
component that allows the set up of NegotiAuctions.
We assume a simple scenario with 4 users: Hugo, Jean, Nicolas and Pierre. Hugo is the
Auctioneer, Nicolas and Pierre are bidders to Hugo’s auction and Pierre is also logged in
as Auctioneer. Many auctions can be initiated in the Auction House and take place in
parallel. We focus on Hugo’s case.

The users can use a set of available services to negotiate:
    Auction service: The Auction Owner can invite participants and conduct multiple
       NegotiAuctions.
    Bid service: For requesting information on the auction, demanding the suggested
       price or make a bid
    Coordination service: to make sure that everybody shares the appropriate
       information and to start the transaction.
    Dispatcher bid/ Auction service: manage the connections between users and the
       Auction House.
Invocations of these services will be mapped to the negotiation graph by opening nodes.
The following table summarizes a NegotiAuction scenario. The corresponding
negotiation tree is shown in Figure 6.




Figure 5: Negotiation Graph for NegotiAuction
Table 1: NegotiAuction
Phase                Participant   Description                Nodes     Protocol verb      Service
Opening         the Hugo           Invoke coordination        W(white) Open                Coordination
Auction House                      service                    0 (root)
                     Hugo          Invoke dispatching         B (black) Open               Dispatcher
                                   service             for    2                            Auction
                                   auctioneers
                    Hugo           Invoke dispatching         B3           Open            Dispatcher
                                   service for bidders                                     Bid
Users connect to Hugo                                         W 5, 6       Open            Dispatcher
the Auction House (auctioneer)                                             Connect (at a Bid (5)
(As auctioneers or                                                         service)        Dispatcher
bidders)                                                                   Assert (names Auction (6)
                                                                           and profiles of
                                                                           the users)
                    Pierre         Maybe put all in one W 7                                Dispatcher
                    (auctioneer    cell                                                    Auction
                    and bidder)

                    Jean                                      W4                           Dispatcher
                    (bidder)                                                               Bid
                    Nicolas                                   W3                           Dispatcher
                    (bidder)                                                               Bid

Auctioneer    starts Hugo          Multiple               W9               Open            Auction
negotiation                        NegotiAuctions can
                                   be      handled     in
                                   parallel. For each one
                                   a root is opened.

                                   He decides for a                        Assert     (the
                                   reverse neg. and and                    type         of
                                                                           negotiation)
                                   Opens two nodes, one        W 11, 12    Open            Auction
                                   for each mode and                       Assert (only
                                   asserts the constraints                 for         the
                                   for the participants                    automatic
                                                                           mode - node
                                                                           11)
Hugo is connected to node 6 which is non-alternative to      the nodes 3 to 7. So, according to the rules,
Hugo can see who is logged in and invite him.
Auctioneer invites Hugo            invites Nicolas (in Connect
the bidders                        automatic mode)      node 3 to
                                                        13
                                   Invites    Jean  (in Connect
                                   manual mode).        node 4 to
                                                              14
Setting            the Hugo           Open and refine the W 15             Open            Auction
automatic mode                        general     constraints              Assert
                                      for Nicolas
According to the rules, for competing participants, node 15 and its descendants are not visible because it
is on an alternative branch on their root.
                        Nicolas       Requests            the              Request         Auction
                                      information asserted
                                      in node 15 and its
                                      ancestors
                        Nicolas       Bidding: Asserts and B 16, W Assert                  Bid
                                      waits for Hugo’s 18
                                      reply
This can be repeated until an agreement is reached or someone quits. Nicolas can refine its offer by
opening a white offspring in 16 and asserting his new offer
                        Hugo          Has to validate the 19, 20           Open            Auction
                                      bid by assigning a                   Assert
                                      quantity.
If a better offer appears, Hugo can withdraw this bid or change the assigned quantity.
Setting the manual Jean                                       17           Assert          Auction/ Bid
mode

End of Auction        Hugo          Notifies           the                Ready
                                    coordinator


   2.5.        E-Alliance

Based on Xplore, an infrastructure for supporting negotiations in inter-organizational
alliances in a flexible way with respect to the autonomy of the partners involved has been
developed. It is called e-Alliance [2] and it focuses on:
     1) decentralization
     2) modeling the coordination among concurrent interactions
     3) formalizing negotiations
     4) deploying and maintaining an alliance during its lifecycle
     5) creating administrative contracts

Negotiation Characteristics:
   A negotiation process consists of 3 steps:
          o 1) Initialization
          o 2) Refinement
          o 3) Closing
    As the negotiation process evolves, each participant may react to the
      changes/alternatives proposed/submitted by the other parties. The negotiation
      process shall progress in parallel and asynchronously until commitment is taken.
    Alternatives act as constraints that reduce the range of potential agreements.
Architecture: The platform consists of 3 layers:
   1) Application layer
   2) Layer supporting the job/application. Comprises 3 “Facilities”
          a. AllF (Alliance life cycle management Facility): responsible for member
              subscription/ departure/preferences management. It supervises ConF and
              NegF.
          b. ConF (Contract management Facility): Manages the execution of the
              contract. This would comprise Creation, Execution and Closing of a
              contract.
          c. NegF (Negotiation Facility): analyzed further below.
   3) Middleware and Coordination (CooF): Provides “a generic mechanism to enact
       negotiations in a distributed environment” that supports the second layer facilities.

    (1) and (2) are replicated in each participant.
    (3) is shared among parties.

NegF: Each party has a NegF which manages its negotiations. It provides a set of
services that take place between a Manager and the CooF. And it is also responsible for
managing the negotiation framework (defined later) and the negotiation status.
The architecture of the negotiation facility is depicted in the following figure:




Figure 6: NegF architecture
Manager: Specifies global parameters (duration, max/min messages to be exchanged,
max number of participants in the negotiations, max/min participants in the contract,
tactics, and protocols).
Negotiation Framework: It can be seen as a way of defining some global constraints (i.e.
duration, number of candidates, etc) that would affect the whole negotiation process.
Negotiation Object: A negotiation is performed using “Negotiation Objects”. They
define what is to be negotiated. They are defined (and refined) with the assistance of the
Manager. Negotiation Objects set the dependencies and constraints as well as other
Negotiation Objects that can be contained (A NO may contain several NOs).
Reasoning: This is about functions that assist decisions taken fully or partially
automated.
Negotiation tactics: A tactic defines constraints in the negotiation process. It can be for
example an “outsource as a block” tactic or a “splitting” tactic.

Negotiation Middleware - CooF: It is based on [1] and supports processes provided by
the facilities in the second layer. CooF is the coordinator that supports multiparty,
multidirectional, multi-attribute negotiation.
This process is modeled by a negotiation graph like the one described in Section 2.4. This
structure captures the dependencies between the negotiation interactions. As mentioned
above, each part has its own copy of the negotiation graph. CooF’s job is to
coordinate/synchronize these different copies.

The negotiation process can be considered as a Distributed Constraint Satisfaction
Problem. The “distribution” part deals with constraint propagation between nodes, while
the “satisfaction” part deals with constraint based reasoning and strategic reasoning at
each node. Here, this decomposition corresponds to the role played by the CooF and
NegF.

Constraint Satisfaction Problem (DSP)

Let V be a set of variables V = {X1, X2, …Xn}, with each having an associated nonempty
domain of possible values. C1, C2, …Cn are sets of constraints. of V. Each constraint Ci
involves some subset of the variables and specifies the allowable combinations of values
for that subset. A solution to a CSP is an assignment that does not violate any of the
constraints.
A Distributed CSP [10] is a CSP in which the constraints and variables are distributed
among automated agents.

Example-Print Shops:

Here, the e-alliance consists of print shops that can dynamically join or leave the alliance.
The Manager of a prospect member fills in a contract with the print shop’s characteristics
and preferences. If the alliance committee accepts the new member then this new member
should commit to the alliance rules.
In this case the alliance consists of a coordinator C and three print shops A0, A1 and A2.
A0 wants to outsource a printing job. We assume that he has also chosen to outsource the
job “as a block”.

   Initialization: A0’s Manager has to define:
a negotiation framework:

    (Context :duration 1min :messages 100 :candidates 10 :contractants 1
              :tactics as a block :protocols (:manager inform :negf ICNIP))

and Negotiation object:

    (ON0 :type BWP
    :contractants (A1 A2)
    :job ( (size ? (size==50) pref size) (cost ? (cost<=200) pref cost)
           (quality ? (quality enum {high,low}) pref quality))
           (date ? (date <= 3) pref date)
           (penalty ? (penalty <= 40) pref penalty)) (...) >>
    :dependencies ((quality low ==) (cost 140 <=) if) (penalty (cost 10 /) =))

A0’s Manager sets some global parameters/ constraints on the size, the cost and the date
of delivery.

   Negotiation starts: A0 suggests and sends A1 and A2 the following offers:

To A1
   (message :com (:sender A0 :receiver A1 ...) :mas (:act cfp ....)
            :content (obj :type BWP :job (size ? (size == 50K))
           (cost ? (cost<=150)) (quality ? (qualify enum {high}))))

Which would create a white node (2) in A1’s negotiation graph managed by its
insourcing service (Figure 8).




Figure 7: A1’s and A2’s negotiation graphs


To A2
   (message :com (:sender A0 :receiver A2 ...) :mas (:act cfp ....)
            :content (obj :type BWP :job (size ? (size == 50K))
                (cost ? (cost<=100)) (quality ? (quality enum {low}))))

Which would create a white node (2) in A2’s negotiation graph managed by its
insourcing service (Figure 8).

At the same time, this would create 2 white nodes in the A0’s negotiation graph that is
managed by A0’s outsource service.




Figure 8: A0’s negotiation graph


Based on these offers, A1 and A2’s NegF would have to decide on their negotiation
object and framework they will be using to generate their proposals. CooF will
communicate these proposals by opening new nodes in the negotiation graphs. The
negotiation will stop when A0 would decide to commit to one of the offers.


    2.6.        Algorithm to find the Pareto-optimal solutions

We assume two negotiators N1 and N2 who want to negotiate some issues I1, I2…Im. They
publish their services in a repository (e.g. UDDI).
Assumptions:
 Each one can understand each other issues (they should use the same ontology).
 The issues are independent and can be negotiated independently.
 Only two parties are involved (bilateral negotiation).
 The number and the nature of the issues are fixed.

Before describing the algorithm we define what a “Pareto optimal solution” is. A Pareto
optimal solution is a solution that is not dominated by another solution. A Solution S1
dominates a Solution S2 if S1 would improve the gain of both parties or would improve
the gain of only one party but without decreasing the gain of the other.

Tow Phase Model: The algorithm is divided in two phases: the pre-negotiation phase and
the bargaining phase. In the first phase, the two parties identify the non-Pareto optimal
solutions and delete them. This accelerates the negotiation process. In the second phase,
successive refinements of the initial offer are sent until an agreement is reached. The final
solution will be Pareto optimal (there are more than one Pareto optimal solutions) [9].

Phase 1 - Algorithm

Input: inputListN1 containing N1 preferences and inputListN2 N2’s preferences. It does
not matter whether the N1 is the buyer or the seller. The elements on the Lists are
arranged from the most preferable to the least preferable.

Output: outputListN1 for the negotiator N1 and outputListN2 for the negotiator N2.

Steps:

1. Initialize both outputListN1 and outputListN2 to empty list,
2. Set pointerN1 to the first element of inputListN1,
3. Select one element from inputListN1, call the element eleN1, let pointerN1 point to the
next element in inputListN1,
4. Find the element in inputListN2 that has the same value as eleN1 by scanning
inputListN2 starting from the first element, call the element found in inputList N2 eleN2,
5. Get the ancestor set ancestorSetN1 of eleN1 in inputListN1. This can be done by
traversing from the first element of inputListN1 down to the element before eleN1,
6. Get the ancestor set ancestorSetN2 of eleN2 in inputListN2. Use the same approach as
in step 5,
7. Check whether the intersection of ancestorSetN1 and ancestorSetN2 is empty. If the
intersection is empty, insert eleN1 to the end of outputListN1. Otherwise eleN1 (also
eleN2) is dominated by other elements, so it will not be added to outputListN1,
8. Check whether pointerN1 points to null. If it is, go to step 9, otherwise go back to step
3,
9. Copy outputListN1 to outputListN2, reverse elements in outputListN2,
10. Output outputListN1 and outputListN2.

After the Pareto optimal solutions have been found one of them has to be chosen. Let an
issue Ik. It will have j alternatives: A1, A2…Aj. N1 and N2 will have completely opposite
alternatives for this issue. So if A1, A2…Aj are N1’s alternatives Aj, Aj-1…A1 will be N2’ s
alternatives.
N1 and N2 assign counting numbers Cxy which are integers >=1 that represents the
negotiator’s in that alternative. For example C13 = 4 would mean that negotiator N1 will
offer alternative A3 4 times.

Phase 2 - Algorithm

So, we have the two following lists:
List1 = C11, C12, …C1j and
List2 = C2j, C2j-1, …C21
N1 propose the first alternative. N2 checks if the counting number in the proposal
matches its counting number for the regarding alternative. If so, then an agreement is
reached. Otherwise the bargaining begins and N2 sends his first alternative. Each time an
alternative offer is sent its counting number is reduced by one. When N1 receives the
counterproposal, it goes through the same checking process. This is clearer in the
example described below. Let a provider and a requestor who want to agree on the credit
card company the requestor should pay. For the provider the list is Visa=3, Mc=2,
AMEX=5, DC=4 (in order of the most to the least preferred) and for the provider it is
DC= 2, MC=3, AMEX=4, Visa= 5. The process is shown in Figure 10:




Figure 9: Negotiation process


AMEX is off (underlined), since it is dominated by MC by both the provider and the
requestor. Finally the MC will be accepted.

It can be proved that this algorithm terminates [9]. It is symmetrical, which means that
both parties may initiate the process, easy to understand and full automated with no
required third party involved. However, identifying and having a common understanding
of the issues is not a trivial process. The same holds for the alternatives.


    2.7.        The Rubinstein alternating protocol

This protocol considers only tow parties A1 and A2. They need to reach an agreement on
a given issue. An offer can be sent by A1 or A2 depending on who’s turn it is to submit a
proposal but a proposal only at a particular time in the set T= {t1, t2, …}. So assuming
A1 initiates the process it sends an offer at time instant t1. If A2 agrees then an agreement
is reached. If A2 does not agree, A2 can send a counter-offer at time instant t2. This is
continues until an agreement is reached [14].


    2.8.    The Strategic Negotiation model – Simultaneous
        response protocol
This protocol is based on Rubinstein’s model for alternating offers. We assume N agents
{A1, A2, …AN} which are involved in a negotiation process. They need to reach an
agreement on a given issue. An agent can take action only at a particular time in the set
T= {0, 1, …}. This set is known to the agents. In each t E T it’s one of the agents turn to
make an offer. Each one of the other agents should respond by accepting, refusing or
dropping out of the negotiation, depending on what their negotiation strategy suggests. If
an offer is accepted by all agents an agreement is reached. If the offer is rejected by at
least one agent, a new offer should be submitted in the next time slot (t+1). If someone
drops out then the whole process should be restarted. The function j (t) = (t mod N) + 1
should decide the next agent to make an offer [13].

All agents have the same role. There is no requestor and provider(s). It’s more about
conflict resolution among distributed agents.


3. The Montreal taxonomy for Electronic Negotiations
Main Goal of the Montreal Taxonomy [5]: “to provide a common language for the
descriptive characterization and classification of mainly electronic negotiation scenarios”.

Classification Criteria: They are defined as a “distinctive electronic negotiation scenario
property which is represented as a rule and is associated with a number of potential
criterion values”. There are four types of classification criteria: endogenous and
exogenous, and implicit and explicit. They can be combined to create four classification
categories.




   Exogenous Classification Criteria are determined by the business context of the
   negotiation process. They must be defined before the design process start, which
   means that they cannot be influenced by the designer.

   Endogenous Classification Criteria – Implicit Criteria: This taxonomy has focused
   mostly on this set of criteria. They are characteristics that are related to the
   negotiation protocol. One set of explicit classification criteria is about “Process-
   Overall rules” which comprises aspect like “Variation”: A negotiation can have fixed
   rules, flexible (can be modified but within a fixed range), dynamic (can be modified
   with no constraints) or “Rounds”: A negotiation n can be single-round or multi-
   round. This classification criterion is very detailed and could be used to identify and
   compare different negotiation protocols.

   Endogenous Classification Criteria – Explicit Criteria: this set of criteria can be
   used for evaluation of a negotiation instance as well as an agreement achieved. Some
   of the suggested criteria are: (i) fairness, which is whether a solution is not more
   advantageous for the one side. This can be ensured when all parties are subject to the
   same opportunities, rights and obligations. (ii) Pareto-efficiency: a solution is Pareto-
   efficient when there is no other agreement that could be better for one participant
   without being worse for another. Stability, truth revelation, convergence are some
   other suggested criteria.

   In this classification would criteria for security fall. However there is no such
   criterion suggested.

   There is also no mapping mechanism between endogenous implicit and explicit
   classification criteria which could answer questions like how fairness or Pareto
   efficiency can be ensured in a systemic way.

   The list of criteria suggested, especially the endogenous implicit ones, can be used to
   present different negotiation protocols basic characteristics in a structured was. This
   can facilitate a comparison between different protocols.

Discussion
For the TrustCoM project the negotiation protocol should:
1. Be Multi-party
2. Use WSLA to express negotiation offers (or be independent from the way an offer is
represented).
3. Bidirectional

Ws-AgreementNegotiation is only concerned with bilateral negotiations and uses only
WS-Agreement templates to express negotiation offers. WS-Negotiation on the other
hand fulfills the WSLA requirement, but so far not the multi-party one. None of these are
considered with security issues.
E-alliance seems similar to the TrustCoM framework but it doesn’t tackle trust and
security issues.

References
[1] J.-M. Andreoli and S. Castellani. Towards a flexible middleware negotiation facility
for distributed components. In DEXA ”e-negotiations”Workshop,Munich, Germany,
2001.
[2] J.-M. Andreoli and S. Castellani, Mihnea Bratu and Olivier Boissier, Ilham Alloui and
Karim Megzari. E-Alliance: a Negotiation Infrastructure for Virtual Alliances. In Special
issue of the Group Decision and Negotiation Journal on e-negotiations, 2003
[3]       CCDI:      Fact       sheet:    http://www.xrce.xerox.com/competencies/past-
projects/middleware/negoware/xploreFS.html
[4] Reinhard Brandl, J.-M. Andreoli and S. Castellani. Ubiquitous negotiation games: a
case study. In DEXA ”e-negotiations”Workshop,Munich, 2003.
[5] Sroebel Michael, Weinhrdt Christof, The Montreal Taxonomy for Electronic
Negotiations
[6] Foundation for Intelligent Physical Agents. http://www.fipa.org/specs/fipa00037/
[7] PCK Hung, H Li, JJ Jeng. WS-Negotiation: An overview of research issues. In
Proceedings of the 37th Hawaii International Conference on System Sciences - 2004
[8] Zafeer Alibhai, IRMS Laboratory, SFU The Contract Net Protocol
[9] Haifei Li, David Ahn , Patrick C. K. Hung. Algorithms for Automated Negotiations
and Their Applications in Information Privacy. In 2004 IEEE International Conference
on E-Commerce Technology (CEC'04) pp. 255-262
[10] Makoto Yokoo, et al. The Distributed Constraint Satisfaction Problem:
Formalization and Algorithms. In IEEE Transactions on knowledge and data engineering,
Vol 10, No 5. September 1998.
[11] V. Bui and R Kowalczky. On constraint based reasoning in e-negotiation agents. In
AMEC III, LNAI 2003, pp31-46
[12] Cooperation and Agreement between semantic web services
[13] Automated Negotiation and Decision making in multi-agent environments
[14] Collaborative Negotiation in Web Service Procurement.
[15] WS-AgreementNegotiation Specification
[16] R. G. Smith. The Contract Net Protocol: high Level Communication and Control in
Distributed Problem Solver. IEEE Transactions on Computers, Vol C-29, No12 p. 1104-
1113, 1980.

				
DOCUMENT INFO