In order to support both, the discovery and the negotiation of SLAs, a set of protocol primitives has been developed, building on the abovementioned data structures. They are shortly described in the following.
3.3.1. Discovery Phase
The discovery phase basically represents the set of activities ultimately leading to a situation where potential transaction partners (thus SCs and SPs) know one another and can start a negotiation process. This means the discovery phase is supposed to support a given SC to find one or more SI documents fitting the search criteria it received from a respective user. To this end, the SPs should be able to publish the services they offer (thus the respective SI documents) in a way that they can be found by potentially interested SCs.
As a quite common problem in SOC, a mechanism is thus needed that supports the publication and discovery of electronic documents in a distributed setting. A set of the most prominent approaches in that area has been discussed in section 2.2.2. As already elaborated there, the most promising paradigms for the IoS are probably cen-tral (but potentially replicated) registries in combination with multi- or broadcast-based messaging protocols or P2P-based infrastructures. The former offer the advantage of high-performance of the individual registry nodes and the possibility to implement com-plex retrieval algorithms there, whereas the latter have proven to be very resilient to node failures.
For my proof-of-concept implementation, a very simple single registry node, which can be found via a broacast-based discovery protocol, has been chosen. Due to the nature of such a prototype, technical quality metrics such as robustness (favoring P2P solutions) are not of primary interest. Therefore, a simple architecture based on a central registry is more than sufficient for investigating the research question at hand. If in future versions more elaborate mechanisms become necessary, it would nonetheless be possible to integrate them respectively, as shortly sketched in section 5.4.
Consequently, a set of protocol primitives along with the respective messages for such a discovery phase have been developed: The first step for both SP and SC, when pub-lishing or discovering a given service, is to find a respective registry node. For that a registryDiscovery message has been defined, containing the ID of the sender agent.
This message is sent via a broadcast in order to find one or more registries for the next steps. This basically corresponds with the broadcast-based mechanisms described in section 2.2.2. Subsequently, all registry nodes that received this message answer with an acknowledgement (ACK) message stating the EPR, where they are located.
Service Consumer
From now on SP and SC processes differ. A SP, wanting to publish a given SI, first queries whether the respective ST and EST documents associated with the SI are already available at the registry (queryServiceTypes and querySLATemplates messages).
In case either of them is still unknown, the SP registers the respective document with the registry (registerServiceType or registerSLATemplate messages)23. Once both documents are correctly registered (as confirmed again with ACK messages) the actual SI can be published (registerServiceIdentificator message).
The SC queries the SI documents available at the registry (or registries in case more than one was found) using a queryServiceIdentificator message24. After potentially hav-ing found several fitthav-ing SIs the respective EST documents used therein are queried (querySLATemplates message), if not already known.
Given a list of adequate SIs were found (for which also both ST and EST documents could be retrieved), the agent chooses one of them and tries to start / join a negotiation.
In order to do so, the SC must pass through an explicit admission process, for which a central entry point is assumed, the NC. The resulting process consists of a SC requesting admission to a service negotiation at the NC node, which in turn, answers with an ACK (SC was admitted) or NACK (SC was rejected) message25. It is therefore required that the SC inserts its credentials in the joinNegotiation message, so the NC agent can make a
23This is necessary, since respective SCs need both documents when deciding on a SI to negotiate for and when adapting to the stated protocol.
24In the current prototype system only the ID of a distinct ST can be used as a search criteria. The query message was however implemented in a way that other, more powerful queries, for example concerning individual elements of a ST, can be integrated. In that case, the SC would probably first query the ST documents for ones fitting its search criteria and subsequently query the SIs fitting any of the found STs.
25NACK is commonly used for messages stating that some request was “not acknowledged”.
valid decision on whether or not admission can be granted. Figure 3.9 gives an overview on this discovery approach26.
The availability of a service instance is advertised implicitly in that for a busy service (the service is running or the SP is currently negotiating for it and joining this negotiation is not possible) the NC just rejects new admission requests27.
In case of a double auction protocol (CM or CDA), the given SI is posted from the SP to the NC via an offerToSell message and can subsequently be matched with incoming offers to buy. After this matching, the service is busy and will not be considered for future matchings until the offerToSell for this SI is re-posted by the SP agent.
In case of a successful admission the SC and SP now engage in the actual negotiation process.
3.3.2. Negotiation Phase
Since the main goal of this thesis is to define an infrastructure for protocol-generic negotiations, no single one negotiation protocol can be identified for this phase. Rather, a set of negotiation message types along with their respective contents has been defined.
These messages can then be used in a given negotiation process, orchestrated according to the protocol description in the EST document.
To make sure that as many different negotiation protocols as possible can be mapped to the defined message set, a thorough literature review has been conducted, basically creating the minimally necessary superset of messages used in the found protocols defi-nitions (as listed for example in the FIPA protocol library28).
The result reflects the fundamental characteristic of any negotiation protocol, the fact that it mainly consists of a process of exchanging offers followed by a final acceptance or rejection of one of the involved partners. This already implies an offer, an accept and a reject message type. Additionally, some of the protocols found incorporate pull-paradigms within the bidding process in that they distribute callForBids messages to the bidders, which in turn answer with an offer accordingly. Finally, in some cases a central auctioneer just asks the bidders whether or not they are still interested in the currently offered agreement, while it constantly changes its offer, just until only one interested bidder is left, the winner of the negotiation. The identified message set thus results in the message types already introduced on page 82, except for the admission message, which is only used there to model pro-active protocols.
Using these message types, a vast variety of different protocols can be designed and subsequently described in an EST document.
26This figure describes the discovery process from an abstract role-centric view; no assertion on role adoptions by individual agents are made. A detailed description of this aspect is given on page 89.
27In order to give a rejected SC agent a meaningful reason for its rejection (it could be rejected on the basis of its credentials or because the service is unavailable at the moment) a comprehensive fault model should be used, building on a set of standardized fault types.
28www.fipa.org
Service Management
Layer
Economy Sub-Layer
Service Layer
Market Sub-Layer
Registries (RA)
Service Provider and Consumer Processes Service Management
Agents (SP, SC)
Mediators (NC)
manage
bid agree
upon SLA
lookup
invoke
Figure 3.10.: Role-based Architecture