8.4 Kommunikationsmodell

 Aufgabe des Kommunikationsmodells ist die Festlegung der kommunizierenden Partner und des Kommunikationsmechanismus zur Durchführung der Überwachungs- und Steuerungsaufgaben.

JMAPI führt kein neues Kommunikationsprotokoll ein, sondern stützt sich auf bereits vorhandene Protokolle ab. Im wesentlichen kommt Java RMI zum Einsatz, nur für die Kommunikation mit nicht-Java-basierten Agenten muß auf andere Kommunikationsprotokolle ausgewichen werden. Die Verwendung existierender, bereits etablierter Protokolle erhöht die Akzeptanz JMAPI-basierter Lösungen und vermeidet Schwierigkeiten, die mit der Einführung neuer Protokolle verbunden sind. Ferner wird durch die Verwendung bereits existierender Protokolle die Integration von Agenten anderer Managementarchitekturen, wie etwa SNMP- oder CORBA-Agenten, erleichtert.

Die Verwendung von anderen Kommunikationsprotokollen als RMI ist allerdings mit dem Nachteil verbunden, daß in diesem Fall der in JMAPI integrierte Transaktionsmechanismus (vgl. Abschnitt 6.6) nicht vollständig genutzt werden kann. Als Beispiel für die hier auftretenden Schwierigkeiten betrachte man einen Client, der auf einem Managed Object Attributwerte verändert, die Aktionen auf einem Agenten nach sich ziehen sollen. Führt nun der Client ein Commit der entsprechenden Transaktion durch, so wird versucht, die veränderten Attributwerte in die Datenbank zu übernehmen. Wird hierbei festgestellt, daß zur gleichen Zeit ein anderer Client ebenfalls Modifikationen am gleichen MO durchgeführt hat, so wird von JMAPI automatisch ein Rollback der Transaktion veranlaßt. Ein Zurücksetzen der alten Attributwerte ist unproblematisch, da dies bei einem Rollback vom DBMS automatisch durchgeführt wird. Schwierigkeiten bereitet in diesem Zusammenhang die Frage, was mit den Änderungen auf dem Agenten geschehen soll. Bei Verwendung von RMI kann der in Abschnitt 6.6 geschilderte Mechanismus über CommitAndRollback-Objekt und Callback Funktionen genutzt werden. Dieser würde dann in transparenter Weise einen Rollback veranlassen. Verwendet man allerdings ein anderes Kommunikationsmodell, bietet sich diese Möglichkeit nicht. Da keine Methode des MOs nach der Datenbanktransaktion ausgeführt wird, müßte der Client überprüfen, ob sich die Attributwerte tatsächlich geändert haben, um so festzustellen, ob die Transaktion erfolgreich war, und gegebenenfalls eine Rollback-Methode des MOs aufrufen. Wie jedoch unmittelbar einsichtig ist, wäre diese Vorgehensweise sehr problematisch, zieht man die Möglichkeit von Race-Conditions durch Modifikationen anderer Clients mit in Betracht.