Im allgemeinen Maklerprotokoll-Ansatz besitzt der Makler eine Tabelle mit Informationen aller ihm bekannten Agenten, die in der Lage sind bestimmte Aufgaben zu bearbeiten. Diese Tabelle kann zentral von einem Dienst-anbieter gepflegt werden, indem alle Agenten beim Eintritt in das System sich in diese Tabelle eintragen müssen (Vgl.: Ferbes, Jacques: Multiagentensysteme, 2001, S. 372). Geschieht dies nicht, können sie bei der Aufgabenverteilung durch den Makler nicht berücksichtigt werden.
Der Ablauf beginnt mit einer Proxy-Message des auftraggebenden Agenten an den Makler. Diese enthält gemäß Spezifikation eine Referenz-Beschreibung der zu lokalisierenden Agenten, den zu übermittelnden Sprechakt selbst und Nebenbedingungen wie z. B. eine maximale Anzahl von Agenten, an die diese Nachricht weitergeleitet werden soll. Exemplarisch ist nachfolgend eine solche Proxy-Nachricht dargestellt.
Agent i requests agent j to do recruiting and request a video-on-demand server to send “SF” programs.
(proxy
:sender (agent-identifier :name i)
:receiver (set (agent-identifier :name j))
:content
"((all ?x (registered(agent-description
:name ?x
:services (set
(service-description
:name video-on-demand)))))
(action (agent-identifier :name j)
(request
:sender (agent-identifier :name j)
:content
\"((action ?y[6]
(send-program (category \"SF\"))))\"
:ontology vod-server-ontology
:language FIPA-SL
:protocol fipa-request
:reply-to (set (agent-identifier :name i))
:conversation-id request-vod-1)
true)"
:language fipa-sl
:ontology brokerage-agent
:protocol fipa-recruiting
:conversation-id vod-brokering-1
…)
Nach Erhalt dieser Nachricht kann der Broker autonom entscheiden, ob er diese Anfrage bearbeiten möchte oder diese zurückweist. Das Zurückweisen erfolgt mittels einer refuse-Nachricht und terminiert die Zusammenarbeit. Generell ist der Makler jederzeit in der Lage die Interaktion mit einer refuse-Nachricht zu beenden. Sollte er diese Anfrage bearbeiten wollen, so teilt er dies dem Auftraggeber mit einer agree-Nachricht mit.
Ist der Makler nun einverstanden als Proxy zu fungieren, sucht er nach Agenten, die der in der Proxy-Nachricht enthaltenen Beschreibung entsprechen. Kann er keine ausfindig machen, schickt er dem Auftraggeber eine failure-no-match-Nachricht und die Zusammenarbeit ist beendet. Alternativ kann der Makler die in der Beschreibung enthaltenen Neben-bedingungen verändern, um so ggf. doch noch passende Agenten zu finden. Hat der Makler nun geeignete Agenten ausfindig gemacht, beginnt er seinerseits jeweils einzelne Kommunikationen mit diesen – diese werden auch Sub-Protokolle genannt. Diese Sub-Protokolle sind abhängig von dem ursprünglich in der Proxy-Message übermitteltem Sprechakt. Die Antworten, die der Makler aus diesen Sub-Protokollen erhält, werden dann an den Auftraggeber weitergeleitet. Hierbei kann es sich um reply-message-sub-protocol-Nachrichten oder failure-Nachrichten handeln.
Agent j informs i that it has failed to open a file.
(failure
:sender (agent-identifier :name j)
:receiver (set (agent-identifier :name i))
:content
"((action (agent-identifier :name j)
(open \"foo.txt\"))
(error-message \"No such file: foo.txt\"))"
:language fipa-sl)
Allerdings besteht auch die Möglichkeit, dass keine Nachrichten vom Makler an den Auftraggeber geschickt werden. Dies ist der Fall wenn der zu übermittelnde Sprechakt in der Proxy-Nachricht lediglich ein inform-Sprechakt war. In diesem Fall ist es die Aufgabe des Maklers nur diesen inform-Sprechakt weiterzuleiten.
Nachdem im allgemeinen Fall alle Sub-Protokolle abgeschlossen wurden, übermittelt der Makler eine letzte reply-Nachricht von den Sub-Protokollen an den Auftraggeber, die diesen Protokollablauf terminiert. Fällt ein Sub-Protokoll und somit ein dienstanbietender Agent aus und antwortet demnach dem Makler nicht mehr, kann dieser, wenn er dieses Problem erkennt, den Protokollablauf mittels failure-brokering-Nachricht terminieren.
Ein weiteres generelles Problem des Maklerprotokolls entsteht, wenn ein Makler mehrere für eine bestimmte Aufgabe geeignete Agenten kennt. Wie bereits erwähnt, würde er mit jedem einzelnen Agenten parallel eine Kommunikation aufbauen. Die aus diesen Sub-Protokollen resultierenden Nachrichten kann er entweder einzeln an den Auftraggeber weiterleiten oder aber sammeln und dann in einer einzigen reply-message-sub-protocol-Nachricht übermitteln. Verfährt er nach letzterer Methode, können aber die Inhalte der einzelnen Nachrichten widersprüchlich und somit inkonsistent sein, da einzelne Agenten zu unterschiedlichen Ergebnissen kommen können. Auch können diese Nachrichten Fehlermeldungen enthalten. Der Makler muss hier also selbst entscheiden, welche Nachrichten er weiterleiten wird, da ja das Weiterleiten einer failure-Nachricht die Terminierung des gesamten Protokollablaufs zur Folge hätte.
Nachfolgend ist das FIPA Brokering Interaction Protocol in einer erweiterten UML-Notation aufgeführt:
Im Fall des Maklerprotokolls lässt sich die Anzahl der verschickten Nachrichten für den allgemeinen Fall mittels folgender Formel berechnen:
M = a * k * N * (2 + 2 * ß * N)
(Vgl.: Ferbes, Jacques: Multiagentensysteme, 2001, S. 375f.)
M steht für die Anzahl der auftretenden Nachrichten, während N die Anzahl aller Agenten angibt. a gibt das Verhältnis zwischen den Auftraggeber-Agenten zu der Anzahl der insgesamt verfügbaren Anzahl an Agenten an. k beschreibt die Anzahl der Anfragen von Auftraggebern an den Makler pro Zeiteinheit und ß definiert das Verhältnis der potentiellen Dienstanbieter zu der gesamten Anzahl der Agenten. Zu beachten ist, dass der Makler als Agent bei der Berechnung nicht berücksichtigt wird.
In diesem Beispiel besitzen die Variablen folgende Werte:
N = 7, a = 3/7, ß = 4/7 und k = 1/3
Setzt man diese Werte in die Formel ein, so erhält man ein Nachrichtenaufkommen von M = 10 Nachrichten. Zu beachten ist, dass ein Makler nur die Dienstanbieter benachrichtigt, die auch zur Lösung der Aufgabe befähigt sind.
Bei dem oben dargestellten Verfahren handelt es sich um eine allgemeine Formel zur Berechnung des Kommunikationsaufkommens in Makler-protokollen. Die ermittelten Werte sind abhängig von der tatsächlichen Implementierung des Protokolls. Im Vergleich zur FIPA-Spezifikation werden nur die elementaren Schritte dieses Protokolls berücksichtigt. Beispielsweise fließt die Antwort des Maklers auf eine Proxy-Nachricht einzugehen nicht in die Berechnung ein. In Bezug auf Systeme mit einer großen Anzahl von Agenten ist aber das Aufkommen dieser vereinzelten Nachrichten zu vernachlässigen.
In der Praxis stellt der mittels eines Maklers zentralisierte Ansatz ein großes Problem dar. Aufgrund dieser Implementierung entsteht ein „Flaschenhals“, (Vgl.: Ferbes, Jacques: Multiagentensysteme, 2001, S. 375) der die Leistungsfähigkeit des Systems mit steigender Anzahl von Agenten stark beeinträchtigen kann. Ein Beispiel wird dies verdeutlichen.
Das Beispielsystem sei durch folgende Werte definiert:
a = 0,5, ß = 0,1 und k = 1
(In Anlehnung an: Ferbes, Jacques: Multiagentensysteme, 2001, S. 375f.)
Das Verhältnis zwischen Auftraggebern und Dienstanbietern sei also ausgeglichen und das Verhältnis der potentiellen Dienstanbieter zu der gesamten Anzahl der Agenten betrüge 0,1. In diesem System besitzt also jeder zehnte Dienstanbieter die Fähigkeiten um eine bestimmte Aufgabe zu lösen und der Grad der Redundanz ist ziemlich gering. Das Kommunikationsaufkommen in Abhängigkeit von der Anzahl der Agenten N ließe sich wie folgt beschreiben:
Bereits ab einem Einsatz von 50 Agenten müssen für nur 25 zu verteilende Aufgaben 300 Nachrichten verschickt werden. Anhand der Abbildung 12 ist leicht der enorme Ressourcenbedarf dieses Protokolls ersichtlich, welcher in Systemen mit einem höheren Grad an Redundanz nochmals deutlich zunimmt.