Publish Subscribe, Observer?

[Cojote]

Hallo,

ich suche nach dem wissenschaftlich korrekten Namen für folgende Konstruktion, bzw Design Pattern.

Innerhalb einer Anwendung existiert eine zentrale Komponente zum Nachrichtenversand. An dieser Komponente können sich Komponenten, die ein EventListener Interface (mit Methode onEvent)implementieren registrieren und ihr Interesse an bestimmten Ereignissen anmelden.
Aussehen tut das in etwa so:
eventDispatcher.subscribeTo(MyEvent.class, this);

Über die zentrale Komponente werden innerhalb der Applikation Nachrichtenobjekte an den Dispatcher versendet. Also:
eventDispatcher.publish(new MyEvent(...))
Diese publish-Methode hat die Aufgabe jetzt alle Interessenten zu ermitteln und ihre onEvent() Methoden aufzurufen.

Ich habe ein wenig gegoogled und bin auf die Begriffe Observer Pattern und publish subscribe Mechanismus gestoßen.
Observer Pattern ergibt für mich keinen Sinn (kann aber auch sein dass ich nur die konkrete Implementierung des Patterns kenne, die hier so gar nicht passt). Publish Subscribe verbinde ich mit asynchroner Kommunikation, insbesondere mit JMS. Die Kommunikation läuft aber synchron ab.
Ich weiß ich habe auch die Methoden des eventDispatchers publish und subscribe genannt bin aber mit dieser Bezeichnung nicht wirklich zufrieden, weil zumindest ich sie so als asynchron missverstehe.


Hat vielleicht jemand nen Tipp für mich?

 

[Oliver Gierke]

Hallo,

bei einem ObserverPattern ist es üblicherweise so, dass der Observer selbst sich an der zu überwachenden Komponente registriert und die Komponente einfach alle Observer benachrichtigt, ohne diese genau zu kennen. Daher würde ich bei deinem Konstrukt nicht wirklich Observer als Namen wählen. Der Zweck ist wahrscheinlich ein ähnlicher, die Umsetzung allerdings nicht wirklich ein Observer.

Publish Subscribe (P/S) halte ich für sinnvoller, aus folgenden Gründen:

1) P/S sagt erstmal nichts über asynchronität aus. Das Pendant im Messagingbereich zu P/S ist Broadcast (informieren aller Komponenten, keine registrierung auf ein spezielles Event). Bei JMS wird fälschlicherweise oft angenommen, dass es implizit asynchron sei. JMS KANN asynchron sein, kann aber auch im Request/Response Modus benutzt werden einfach um ein P/S zu realisieren
2) Du hast einen "Man in the middle", sprich, jemanden der das ganze orchestriert.
3) Charakteristisch für ein P/S ist eine Art Delimiter, mit dem man angibt, an welchen Nachrichten bzw. Events man interessiert ist. In Termen des Messagings ist das meist eine Queue oder ein Topic auf das sich ein Listener (Subscriber) registriert, das kann wie in deinem Fall auch einfach ein Typ sein.

Ergo halte ich P/S für den "richtigen" Titel. Wichtig ist hierbei, dass es wie so oft kein 100%iges richtig oder falsch gibt. Programmierkonstrukte können in leicht anderem Licht einen anderen Namen bekommen. Daher ist bei Patterns auch der Kontext sehr wichtig. Wenn man den Fokus bei deinem Konstrukt z.B. darauf legt, dass sich Komponenten dynamisch beim Dispatcher registrieren können, kann man da auch ein Plugin Pattern sehen. Je nachdem was die Kompontente tut kann sie wiederum vielleicht ein Adapter sein usw. Lange Rede kurzer Sinn: Patterns sind kein exclusive or, sondern eher eine Suppe, wobei jedes Pattern eben durch bestimmte Charakteristika bestimmt ist die hervorgehoben werden sollen, wenn man von ihm spricht.

Gruß
Ollie

 

[Cojote]

Danke Ollie für die Antwort, damit kann ich etwas anfangen. Publish Subscribe habe ich auch schon öfter im Zusammenhang mit synchronität gelesen. Mit deiner Meinung bleibe ich deshalb dabei.

Könntest du mir noch kurz erklären inwiefern mit JMS aus synchrone Kommunikation möglich ist? Ich dachte immer der JMS Request/Response Mechanismus sei sowas wie asynchronität mit Rückantwort. Als Sender sendet, rennt danach weiter. Empfänger empfängt und verarbeitet und schickt ne Rückantwort über ne Temp-Queue.
Oder meintest du, dass Request/Response dazu verwendet werden kann um synchrone Kommunikation zu implementieren, indem man beispielsweise den Sender nach senden der Nachricht manuell blockiert, wartet bis die entsprechende Rückantwort eintrifft und den Sender damit weiterrennen lässt?
Ich frage aus Interesse, weil ich schon länger nichts mehr mit JMS gemacht hab und auch nicht den 100% igen Durchblick hab.