Java Reference
In-Depth Information
erfolgt dies durch Adressen, wobei es neben Unicast-Adressen, mit denen genau ein Rech-
ner angesprochen wird, auch Sammeladressen in Form von Multicast- und Broadcast-
Adressen zur Adressierung von Rechnergruppen bzw. zur Adressierung aller am Ethernet
angeschlossenen Rechner gibt. Im So ware-Bereich sind die Komponenten Objekte, die
Methoden bereitstellen, welche auf die auf einem Bus gesendeten Ereignisse (daher der
Name Ereignisbus) reagieren. Die Auswahl der passenden Methoden, die aufgerufen wer-
den, erfolgt in der Regel anhand der Typen der im Ereignis übermittelten Parameter. Im
einfachsten Fall dürfen die Ereignisbehandlungsmethoden nur einen einzigen Parameter
haben, dessen Typ von einer vorgegebenen Ereignisbasisklasse abgeleitet sein muss. In
dem im Folgenden behandelten Framework RRiBbit können die Ereignisbehandlungsme-
thoden beliebige Parameter haben. Beim Senden kann entsprechend eine beliebige Anzahl
von Parametern beliebigen Typs angegeben werden. Die Auswahl der Methoden erfolgt
dann anhand der Anzahl und des Typs der Parameter. Zusätzlich kann bei RRiBbit einer
Methode durch eine Annotation noch ein String zugeordnet werden, der beim Senden (evtl.
neben weiteren Parametern) angegeben werden kann, damit diese Methode durch das Sende-
ereignis aktiviert wird.
Hardware-Bussysteme stoß en bei einer sehr großen Anzahl von Komponenten an ihre Gren-
zen. Dies liegt vor allem an zwei Gründen: Zum einen erfolgt das Senden auf einem Bus
sequenziell. Wenn also viele Komponenten gleichzeitig senden wollen, behindern diese sich
gegenseitig. Zum anderen gibt es für das klassische Ethernet das Problem, dass in vielen
Netzprotokollen mit Broadcast gearbeitet wird, wobei die Broadcast-Nachrichten nicht wirk-
lich für alle sind, sondern ein Rechner erst durch die Analyse des Nachrichteninhalts her-
ausfi nden muss, ob die Nachricht für ihn ist oder nicht. Wenn ein Rechner direkt adressiert
wird, erfolgt die Filterung, ob eine Nachricht angenommen werden muss, in Hardware. Die
Analyse einer Broadcast-Nachricht erfolgt hingegen in So ware. Wenn also immer mehr
Rechner an einem Ethernet angeschlossen werden und somit immer mehr Broadcast-Nach-
richten versendet werden, werden die Rechner immer stä rker belastet mit dem Ausfi ltern
von Nachrichten, die gar nicht an sie gerichtet sind.
Für So ware-Bussysteme hängt es stark von der Implementierung ab, ob die geschilderten
Nachteile von Hardware-Bussystemen auch auf sie zutreff en. Das Senden auf dem Ereignis-
bus kann, muss aber nicht unter gegenseitigem Ausschluss erfolgen. RRiBbit erlaubt bei-
spielsweise einen parallelen Zugriff auf den Ereignisbus. Auch für die Empfängerseite sind
mehrere Formen der Implementierung denkbar. Eine Form zur Auswahl der passenden
Methode ahmt das zuvor geschilderte Ethernet-Broadcast-Szenario nach: Jedes Objekt wird
benachrichtigt und muss selbst überprüfen, ob es eine Methode für die aktuelle Nachricht
hat. Damit handelt man sich dieselben Nachteile ein wie bei Ethernet: Es wird in der Regel
vielfach Code ausgeführt, der nicht der Anwendung dient. In RRiBbit wird die Auswahl der
durch ein Sendeereignis angesprochenen Objekte und Methoden wesentlich e
®
zienter
durchgeführt: Beim Anmelden von Komponenten am Ereignisbus extrahiert das RRiBbit-
Framework mit Hilfe von Refl ection Informationen und legt diese in Form sogenannter Lis-
tener-Objekte so ab, dass die passenden Objekte und Methoden schnell und ohne Zutun der
betroff enen Objekte gefunden und die Ereignisbehandlungsmethoden aufgerufen werden
können. Dennoch wird auch RRiBbit für sehr große Systeme an seine Grenzen stoß en. Zum
einen muss immer noch nach den passenden Methoden gesucht werden. Auch wenn die
Suche e
®
zient ist, so ist ein direkter Methodenaufruf schneller. Zum anderen wird es bei
sehr großen Systemen immer schwerer durchschaubar, welche Komponenten durch eine
