6.1 Der Tie-Mechanismus

 Der Tie-Mechanismus wird benötigt, da Java nur die Einfachvererbung von Klassen unterstützt.

Der 'normale' Weg, ein IDL-Schnittstelle durch eine Klasse zu implementieren ist, daß diese Klasse von einer Skeleton-Klasse, die von einem idl2java-Compiler generiert wird, erbt. Damit scheidet in Java zum einen die Möglichkeit aus, noch eine weitere IDL-Schnittstelle zu implementieren, und zum anderen kann auch von keiner anderen Klasse geerbt werden.

Dieses Dilemma wird durch den Tie-Mechanismus gelöst. Der größte Unterschied zum 'normalen' Weg der Implementierung ist, daß nun die Instanz einer sogenannten Tie-Klasse an den BOA gebunden wird. Als Parameter des Konstruktors der Tie-Klasse wird eine Instanz der Implementierungsklasse übergeben. Die Tie-Klasse leitet die Aufrufe nur an die Implementierungsklasse weiter. Damit kann die eigentliche Implementierungsklasse von einer beliebigen Klasse erben. Der Preis für den Tie-Mechanismus ist die zusätzliche Instanziierung eines Tie-Objekts und ein zusätzlicher Methodenaufruf pro Aufruf einer IDL-Schnittstellenoperation.

Das Agentensystem und alle Agenten werden über den Tie-Mechanismus an den BOA gebunden.

  

Abbildung 6.1: Tie-Hierarchie

Abbildung 6.1 zeigt nun das exakte Objektmodell bezüglich der Vererbungshierarchie im Agenten-Modell. Das Agentensystem besitzt eine äquivalente Vererbungshierarchie, wird aber hier nicht weiter erörtert.

Am Beispiel des IPRouting-Agenten wird nun die Einbindung erklärt. Auf der linken Seite der Abbildung sind die IDL-Schnittstellen AgentService, Migration und IPRouting abgebildet. Aus diesen IDL-Schnittstellen generiert das Programm idl2java u. a. die folgenden Objekte:

• Java-Schnittstellen (z. B. IPRouting und IPRoutingOperations)
• Server Skeletons (z. B. _IPRoutingImplBase)
• Tie-Klassen (z. B. _tie_IPRouting)
• Client Stubs (z. B. IPRoutingHelper), die nicht abgebildet sind, da sie für die Erklärung des Tie-Mechanismus nicht relevant sind.

Diese generierten Objekte wurden im Objektmodell des Kapitel 5 aus Gründen der Übersichtlichkeit vernachlässigt. Die im rechten Teil des Objektmodells angesiedelten Klassen sind aus Kapitel 5 bekannt und stellen den Basis, sowie den IPRouting-Agenten dar. Wie zu sehen ist, implementiert die Klasse Agent die Java-Schnittstelle AgentServiceOperations, die Klasse MobileAgent die Java-Schnittstelle MigrationOperations und die Klasse IPRoutingMobileAgent implementiert die Java-Schnittstelle IPRoutingOperations.

Die Instanziierungen der einzelnen Klassen wird im Folgenden beschrieben:
Der AgentManager erzeugt eine Instanz der Klasse _tie_IPRouting, welche an den BOA als Referenz übergeben wird. Als Parameter wird dem Konstruktor eine Instanz der Schnittstelle IPRoutingOperation übergeben, die von der Klasse IPRoutingMobileAgent implementiert wird:

 1  IPRoutingOperations ipInterface= new IPRoutingMobileAgent();
 2  _tie_IPRouting tieObj= new _tie_IPRouting(ipInterface);
 3  boa.obj_is_ready(tieObj);

Es wird eine Instanz der Java-Schnittstelle IPRoutingOperations erzeugt (Zeile 1). Das Tie-Objekt wird kreiert, indem es mit der Java-Schnittstelle initialisiert wird (Zeile 2). Dieses Tie-Objekt wird zuletzt an den BOA gebunden (Zeile 3).

Die Aufrufhierarchie einer CORBA-Operation ist nun wie folgt:
Wird nun der Operationsaufruf update() über CORBA an den BOA übermittelt, so werden der Reihe nach folgende Klassen aufgerufen:

 1  {\tt \_IPRoutingImplBase.invoke(update)}
 2  {\tt \_tie\_IPRouting.update()}         
 3  {\tt IPRoutingOperations.update()}      
 4  {\tt IPRoutingMobileAgent.update()}