MessageBroker - Geopras/IdeaWatcher GitHub Wiki

Warum brauchen wir einen Messagebroker?

• Entwurfsmuster, wie der Nachrichtenaustausch zwischen unabhängigen Modulen laufen kann
• strukturiert Austausch von Daten zwischen Modulen
• definiert Schnittstellen --> Single Response Prinzip --> jede KLasse sollte ein eigenes abgeschlossenes System sein

Der MessageBroker ist vergleichbar mit einer Poststelle, er hat einen Eingang und einen Ausgang.

• Methode publish(): damit kann der MessageBroker Nachrichten an die Umwelt verschicken
• Methode subscribe(): damit kann sich ein Modul am MessageBroker registrieren. Bei der Registrierung gibt der Subscriber eine Callback-Methode und ein Thema, bei dem er benachrichtigt werden möchte an.

Wir können den MessageBroker zum Beispiel für den Datenaustausch zwischen Backend und Frontend nutzen.

Fallbeispiel: Use Case Login

Wir haben ein Login-Modul, welches aus einem Controller, einer View und einem Model besteht. Im LoginController steckt auch Business-Logik. Diese definiert, was passieren soll, wenn eine Nachricht vom MessageBroker eingeht.

Wir füllen die Felder der Login_view aus und drücken den Anmeldeknopf. Im Controller gibt es einen EventListener, der reagiert, wenn in der View ein Event ausgelöst wird. Die Daten der View werden dabei übergeben.

Der Login_Controller sendet Daten an das Login_Model (als synchrone Methode). Dieses macht daraus einen so genannten "Request" und sendet diesen zurück an den Controller.

Die Nachricht wird nun an ein Websocket Modul schickt. Dieses ist direkt mit dem Backend verbunden und schickt den Request dorthin.

Das Backend antwortet durch eine "LoginResponse". Diese muss vom Websocket Modul an das LoginModul weitergeleitet werden.

Dazu ruft das WebSocket Modul die publish()-Methode am MessageBroker auf und übergibt die Antwort vom Backend. Der MessageBroker prüft, wer sich für den Nachrichtentyp "LoginResponse" registriert hat und informiert nacheinander alle Subscribers.

Der LoginController ist ein solcher Subscriber. Der MessageBroker ruft die CallbackMethode am LoginController auf, also die Methode mit der der LoginController sich am MessageBroker registriert hat. Diese Methode wird ausgeführt und bewirkt eine entsprechende Reaktion der Login_view.

Das folgende UML Kommunikationdiagramm stellt diesen Ablauf übersichtlich dar.

(UML Kommunikationsdiagramm für den UseCase Login)

Der MessageBroker verfügt über eine Liste der Subscriber. Diese könnte zum Beispiel so aussehen: ["loginResponse"

• ->[ID des ersten Subscribers, CallbackMethode]
• ->[ID des zweiten Subscribers, CallbackMethode] ]

Unsere Navigation funktioniert auch auf Basis eines MessageBrokers. Beim Klick auf ein Menüelement wird eine Nachricht an die publish()-Methode vom MessageBroker geschickt. Dieser generiert die Nachricht, dass eine bestimmte View angezeigt werden soll. Zudem sendet sie eine Nachricht an die View, die beim Menüklick angezeigt wurde und diese wird ausgeblendet.

Sollen sich unsere Views statisch oder dynamisch am MessageBroker registrieren?

Wir wollen, dass sich alle unsere Views beim Aufbau der Internetseite am MessageBroker registrieren.