Dieser Ansatz wurde auf vielfältige Weise in unterschiedlichsten Bereichen adaptiert und im Bereich der Multiagentensysteme unter dem Begriff des ContractNet-Protokolls bekannt. Aufgrund der noch in den Kinderschuhen steckenden Standardisierungen gibt es zahlreiche Varianten dieses Protokolls – darunter auch hybride Protokolle, die aus mehreren miteinander kombinierten Ansätzen bestehen. Im Rahmen dieser Ausarbeitung wird die Spezifikation der FIPA zu Grunde gelegt, welche im nächsten Abschnitt detailliert beschrieben wird.
Die Foundation for Intelligent Physical Agents, eine Organisation dessen Zielsetzung es ist Standardisierungen im Bereich der Agententechnologie voranzutreiben, hat zwei auf dem ContractNet-Ansatz basierende Spezifikationen hervorgebracht. Dabei handelt es sich zum einen um das FIPA Contract Net Interaction Protocol und zum anderen um das FIPA Iterated Contract Net Interaction Protocol. Letzteres weist eine entscheidende Erweiterung zum „normalen“ ContractNet-Protokoll auf. Es erlaubt den teilnehmenden Agenten mehrere Gebote abzugeben. Dies wird ermöglicht durch eine Iteration in der Gebotsphase. So ist es möglich mehrere „Gebotsrunden“ nacheinander ablaufen zu lassen, wenn dies vom Manager gewünscht wird.
Beide Protokolle basieren aber auf dem gleichen grundlegenden Schema:
Im Detail wird ein Agent, der eine Aufgabe ausschreiben möchte, auch Manager oder Initiator genannt, den Ablauf des Protokolls mit dem Sprechakt „Call For Proposal“ beginnen. Dies geschieht beispielsweise mittels eines Broadcasts, da dieser Agent nicht weiß, welche anderen Agenten in dem System vorhanden sind. Ferner kennt er nicht die Fähigkeiten anderer Agenten. Dieser Sprechakt enthält eine genaue Aufgabenspezifikation und ggf. Bedingungen unter denen die Aufgabe bearbeitet werden muss.
(cfp
:sender (agent-identifier :name j)
:receiver (set (agent-identifier :name i))
:content
"((action (agent-identifier :name i)
(sell plum 50))
(any ?x (and (= (price plum) ?x) (< ?x 10))))"
:ontology fruit-market
:language fipa-sl)
In diesem Beispiel möchte ein Agent Angebote für den Verkauf von fünfzig Kisten Pflaumen einholen.
Alle Agenten die diese Nachricht erhalten, auch Participant genannt, werden als potentielle Kontraktoren angesehen und können ein Gebot abschicken. Sollten sie nicht an den Geboten teilnehmen wollen, können sie eine refuse-Nachricht abschicken und so die Interaktion mit dem Manager beenden. Sollte in der Ausschreibung eine zeitnahe Deadline angegeben sein, terminieren alle Interaktionen mit Agenten, die bis zu diesem Zeitpunkt noch kein Gebot abgegeben haben. Jeder Agent kann ein solches Gebot mittels einer propose-Nachricht abgeben.
(propose
:sender (agent-identifier :name j)
:receiver (set (agent-identifier :name i))
:content
"((action j (sell plum 50))
(= (any ?x (and (= (price plum) ?x) (< ?x 10))) 5)"
:ontology fruit-market
:in-reply-to proposal2
:language fipa-sl)
In diesem Beispiel ist ein Agent bereit für die fünfzig Kisten Pflaumen fünf Geldeinheiten pro Kiste zu bieten. Diese Gebote müssen nicht zwingend Geldeinheiten darstellen. Abweichend von diesem Beispiel kann sich eine Ausschreibung auch auf Zeiteinheiten beziehen. In diesem Fall würde ein Agent gesucht werden, der eine bestimmte Aufgabe in kürzest möglicher Zeit bewältigen kann.
Nach Ablauf der Deadline bewertet der Manager alle ihm vorliegenden Gebote und entscheidet mit welchem Agenten er zusammen arbeiten möchte. Diese erhalten eine accept-proposal-Nachricht. Allen übrigen Agenten weist er ihr abgegebenes Gebot zurück und schickt ihnen eine reject-proposal-Nachricht
Sollte kein Gebot seinen Anforderungen entsprechen, kann er auch alle Gebote zurückweisen. Andererseits besteht auch die Möglichkeit mit mehreren Agenten zusammen zu arbeiten.
Den Agenten, die einen Zuschlag erhalten haben, wird nun die konkrete Aufgabe zur Bearbeitung überlassen. Ist ein Agent in dieser Phase nicht in der Lage die Aufgabe gemäß Spezifikation zu beenden wird dies dem Manager mittels einer failure-Nachricht angezeigt. Nach erfolgreicher Bearbeitung hingegen kann dieser Agent mittels inform-done-Nachricht den Manager über die erfolgreiche Bearbeitung der Aufgabe informieren. Alternativ kann auch direkt das Ergebnis mit einer inform-result-Nachricht übertragen werden.
Nachfolgend ist die FIPA-Spezifikationen in erweiterter UML-Notation aufgeführt:
Wie bereits erwähnt, gibt es eine zweite von der FIPA hervorgebrachte ContractNet-Spzifikation. Bei dem FIPA Iterated Contract Net Interaction Protocol besteht für den Manager die Möglichkeit mehrere Gebotsphasen nacheinander einzuleiten. Im Detail handelt es sich also um eine Spezifikation für einen Spezialfall, wenn ein Manager keine geeigneten Gebote erhält und somit die Interaktion nach dem „normalen“ ContractNet-Protokoll terminieren müsste oder wenn ein Manager trotz Vergabe eine weitere Ausschreibung starten möchte, ist er nun in der Lage eine weitere Gebotsphase einzuleiten.
Nachfolgend ist die FIPA-Spezifikationen für das iterative ContractNet-Protokoll in erweiterter UML-Notation aufgeführt:
M = N + 2 * a * N = (1+ 2 * a) * N
M steht für die Anzahl der auftretenden Nachrichten, während N die Anzahl aller Agenten angibt. a gibt das Verhältnis zwischen den für eine Anfrage bietenden Agenten an der Gesamtzahl N der Agenten (Vgl.: Ferbes, Jacques: Multiagentensysteme, 2001, S. 404) an. Zu beachten ist, dass der Makler als Agent bei der Berechnung nicht berücksichtigt wird.
Für die iterative Form des ContractNet-Protokolls ist die Berechnung abhängig von der Anzahl i der Iterationen der Gebotsphase. Problematisch gestaltet sich die Tatsache, dass sich bei jeder Gebotsphase das Verhältnis von Bietern zur Gesamtzahl der Agenten verändern kann. Außerdem kann ein Manager einzelnen Bietern eine Aufgabe zuweisen und gleichzeitig anderen Bietern ihr Gebot zurückweisen bzw. eine neue Ausschreibung starten.
Bei der hier aufgeführten Formel handelt es sich um eine Formel zur allgemeinen Berechnung des Kommunikationsaufkommens in ContractNet-Protokollen. Im Detail muss aber unter den einzelnen Implementierungen unterschieden werden. So fließen auf Grund einer abgelaufenen Deadline ausstehende Nachrichten trotzdem in die Berechnung ein.
Zur Berechnung des Kommunikationsaufkommens des FIPA Contract Net Interaction Protocol eignet sich die folgende Formel:
M = N + a * N + b * N + c * N = N * (1 + a + b + c)
a gibt das Verhältnis der auf die Ausschreibung antwortenden Agenten an der Gesamtzahl an. Die zeitliche Deadline wird hier also berücksichtigt. Antworten alle Agenten in diesem Limit ist a = 1.
b gibt das Verhältnis der Agenten an der Gesamtzahl an, die ein Gebot ablegen.
c gibt das Verhältnis der Agenten an der Gesamtzahl an, die den Zuschlag erhalten.
Zur Berechnung des Kommunikationsaufkommens des FIPA Iterated Contract Net Interaction Protocol müssen die einzelnen Verhältniswerte durch entsprechende Mittelwerte ersetzt werden und das Ergebnis mit der Anzahl der Iterationen i multipliziert werden. Außerdem muss berücksichtigt werden, dass nicht nur in der letzten Iteration eine Zuteilung zu Stande kommen kann.
Ein Agent der für die Bearbeitung einer ausgeschriebenen Aufgabe nicht die Ressourcen oder Fähigkeiten besitzt, diese aber aus irgendeinem Grund zugeteilt bekommen möchte, kann trotzdem an einer Auktion teilnehmen. Unter Umständen erhält er den Zuschlag und somit die Aufgabe zugeteilt. Nun entsteht für ihn das Problem, dass er einen oder ggf. mehrere andere Agenten finden muss, die für ihn diese Aufgabe lösen müssen. Im schlechtesten Fall sind aber zu diesem Zeitpunkt keine Agenten verfügbar, die als Subkontraktoren fungieren könnten. Dies würde zu einem Deadlock führen und die Aufgabe könnte nicht bearbeitet werden. Das Problem der Subkontraktion kann aber auch über mehrere Ebenen entstehen, wenn sich immer wieder Agenten Aufgaben ersteigern, die sie eigentlich selbst nicht bearbeiten können.
Die oben beschriebene Problematik wird auch als „frühes Binden“ bezeichnet. Ein Agent bindet sich also an eine Aufgabe noch bevor er geeignete Subkontraktoren besitzt.
Alternativ besteht die Möglichkeit, nachdem ein Agent über eine Ausschreibung informiert wurde, sich zuerst Subkontraktoren zu suchen und an sich zu binden um erst danach an der eigentlichen Auktion teil zu nehmen. Dieses Verfahren wird auch als „spätes Binden“ bezeichnet. Problematisch hierbei ist allerdings, dass sich der Agent sehr sicher sein sollte die Aufgabe auch tatsächlich zugeteilt zu bekommen. Sollte dies nicht der Fall sein, geht er ein sehr großes Risiko ein, welches insbesondere in Systemen mit einer großen Menge von Agenten mit ähnlichen Fähigkeiten gegeben ist.
Es handelt sich dabei um ein relativ einfaches Protokoll, welches gerade für verteilte Architekturen geeignet ist. Ein weiterer Vorteil besteht in der hohen Ausfallsicherheit, da grundsätzlich jeder Agent als Manager fungieren kann. Dabei muss der Manager nicht wissen, welche anderen Agenten sich momentan im System befinden und welche Fähigkeiten diese besitzen. Der hohe Grad an Flexibilität ist der wohl größte Vorteil des ContractNet-Protokolls.
Allerdings besitzt dieser Ansatz auch einige Nachteile. Unter Abschnitt 2.4 (Subkontraktoren) wurde bereits ein Solcher aufgeführt.
Ein weiteres neben dem Auftreten von Subkontraktionen entstehendes Problem bezieht sich auf das Eingehen von Verpflichtungen bzw. Reservierungen. In einem System mit einer Vielzahl von Agenten wird die Wahrscheinlichkeit, für den einzelnen Agenten eine Aufgabe zugeteilt zu bekommen, sehr niedrig sein. Aus diesem Grund könnte er sich entscheiden parallel an mehreren Ausschreibungen gleichzeitig teil zu nehmen. Dabei kann aber die Gefahr entstehen, dass ein Agent über seine Kapazitäten hinaus Gebote abgibt. Auch wenn die Wahrscheinlichkeit relativ gering ist bei allen Auktionen den Zuschlag zu erhalten, so stellt dies doch ein gewisses Risiko dar. Es ist nun von der Implementierung des Protokolls abhängig, ob es einem Agenten gestattet ist über „seine Verhältnissse“ sich an Ausschreibungen zu beteiligen um die Chance einer Zuteilung zu erhöhen und so Verpflichtungen einzugehen. Eine Möglichkeit besteht in der Reservierung der Menge an Ressourcen die zur Aufgabenerfüllung benötigt würden, welche mit der Wahrscheinlichkeit der Zuteilung bewertet werden. Auch die Behandlung von Vertragsbrüchen sollte in den einzelnen Implementierungen geregelt werden. So könnten beispielsweise Manager die Zusammenarbeit mit Agenten nach einem eigenen Ratingsystem bewerten um so für zukünftige Ausschreibungen Anhaltspunkte für die Integrität der Dienstanbieter zu besitzen.
Außerdem kann das relativ hohe Kommunikationsaufkommen bei steigender Agentenanzahl stark die Leistung des Systems beeinträchtigen.
Trotz all dieser Nachteile und implementierungsabhängigen Probleme wurde das ContractNet-Protokoll zum meistverwendeten Protokoll im Bereich der Multiagentensysteme, was nicht zuletzt in der hohen Flexibilität und Ausfall-sicherheit begründet ist.