The protocol-generic SC Strategy Component

The strategy subcomponent of an SC agent represents one of the central deliverables of this thesis, as basically all routines needed for adaption to a new negotiation protocol are implemented herein.

During the instantiation process for a respective Generic Negotiator (GN) component, it receives from the SC:

• the service description documents,

• the ID of the current negotiation,

• a link back to the SC,

• the constraints the user posed on the SLA to be negotiated (e.g. her reservation values) and

• some additional negotiation parameters, such as timeout or concession values.

As a first step, the GN partitions the stated SLOs into those that are fixed and those that can be negotiated. The former are simply stored. For each of the latter a new SLONeg object is created, containing both the initial SLO (property ID and value) and all additional information that is associated with it (e.g. attributeRestrictions or domain descriptions). These objects are then again saved and subsequently treated as the first offer from the negotiation partner.

Next, the SLOConstraint objects initially received from the user are processed, each of which basically describes the user’s demands on one particular SLO under negotiation (fixed or negotiable). Following the rationale from above, two types of such constraint classes are present: EnumerationSLOConstraints or OrderedSLOConstraints, depending on the value domain of the underlying property³⁷.

Both provide methods for requesting the stated restrictions (e.g. upper or lower reservation values or concession steps in case of an ordered domain) and simple methods calculating whether or not a given (received) value fulfills this constraint or, contrarily, is so far away from any acceptable value that this offer can be regarded as rejectable.

Additionally, they also provide the GN with a method for creating counter offers based on a received value.

An EnumerationConstraint object basically states a set of acceptable values, based on which it can decide whether or not a received SLO value is acceptable. Intuitively received values applying to an EnumerationConstraint are never rejectable, as no as-sertion can be made whether or not the negotiation partner would accept one of the demanded values (these values do not expose any relationship from which such an asser-tion could be deduced). In the current prototype, when creating a counter offer, simply one acceptable value is randomly chosen and returned³⁸.

Contrarily, an OrderedSLOConstraint defines a range of acceptable values, regularly only bounded on one side (either a minimum or maximum reservation value is present³⁹).

Consequently an offer is deemed acceptable based on these boundary values. Deciding

37For each constraint received from the user an internal constraint object, representing it, is created during initialization of the GN.

38In future versions, potentially a list of all acceptable values will be sent in order to assure determinism of the negotiation.

39It is assumed that a negotiator has a clear preference on a ordered negotiation parameter. She will therefore accept all values as long as they are higher / lower than her reservation value. A SC will for example accept a price as long as it is lower that a given reserve value but will not have any lower boundary for the acceptable values.

whether or not an offer is rejectable is more complicated, as it differs from one user to the other.

For the creation of a counter offer, two cases must be distinguished: an offered value for the respected SLO was already received or not. In the latter case, this agent posts the first offer for this SLO. Here it simply offers the best value acceptable for the SP (stated as upper or lower reservation values in the EST) or if such values are not specified it offers half its own upper reservation value / double its lower reservation value⁴⁰. In the former case it just concedes from its lastly posted offer by an amount, specified by the user for this particular SLO during instantiation (concession step value).

Once all this information was extracted the GN checks whether it has to start the negotiation (pro-active protocol). If so, two possible actions can be defined: this agent can be allowed to post an offer or to simply accept all the values stated in the EST (catalogue pricing model).

Here, a basic principle of the GN becomes obvious: it always seeks to maximize its profit and thus will always choose some actions over others (if both are allowed). In this case (pro-active protocol) it will first check, whether an offer is possible, which could further improve the currently offered agreement. If so, an offer will be sent; if not it will simply accept the current values, as no negotiation on them is allowed.

The same principle applies throughout the whole negotiation process. Whenever a negotiation message is dispatched to the GN it checks its options: In case of a reject or accept message the negotiation is over. It simply processes the result in that it passes the respective information / reached agreement to the SC agent. In case of a callForBid message it creates an offer and sends it to the SP agent⁴¹. All these possibilities are straightforward, as they don’t give the GN any option to choose among a set of possible actions.

When receiving an offer, this could potentially change. If the offer is not completely rejectable (this is checked by iterating over all involved SLOConstraint objects) and a counter offer is possible, the GN will always do so. A counter offer is always the best option, as it potentially increases value of the agreement to be reached for the user.

If this is not possible, the GN will check whether a stillInterested message is allowed, providing it with the possibility of an ongoing negotiation, even if it cannot actively influence the changing of the negotiated values. If even this is not possible it will finally check whether the received offer can be accepted or in the end rejected completely and do so. This routine gives the GN the possibility to react on incoming messages in a way that maximizes its further options during the negotiation and in the end potentially even its utility in terms of the reached agreement.

Summarizing this chapter, a detailed overview on the developed service description documents, the employed discovery and negotiation protocols and the designed software agents employed therein has been given. In the next chapter I describe how these concepts can be instantiated and how the prototype system can be deployed and started.

40These factors are chosen randomly and would be provided by the user in future versions.

41Offer messages are simply created by iterating over each not yet fulfilled constraint object and trig-gering each to provide a counter offer value, as described before. These values are then combined to one bundled offer message.

Also, the results of a demonstration of the prototype’s effectiveness (with regard to the stated requirements) as well as its efficiency (evaluation step) are given.

After having presented the infrastructure design in the last chapter, the results of its assessment are presented in the following.