-- StefanKrepp - 23 Jan 2013

Im Folgenden findet sich eine kurze Zusammenstellung der Ergebnisse des Meetings am 23.01.2013. Anwesend waren Ralf H., Günther, Susi, Jutta, Raphael, Barbara und Stefan

Szenarien:

Ergebnisse des Brainstormings mit dem Ziel Einsatzszenarien zu benennen innerhalb derer das Messaging System Verwendung finden kann.

Konkrete Szenarien:

• Alarm System : mit einer hohen Zahl von Alarm-Producern (~2000) auf je eigenen Hosts, geringe Zahl von Alarm Clients (~100), alle im Cluster, kleine Nachrichten (~1KB)
• Diagnostic Logging System : mit einer hohen Zahl von Producern, Nachrichten unterschiedlicher Länge

Szenarien aus bestehenden IPC Modellen oder bereits existierenden Specs abgeleitet:

• Konsolenmanager : Umschalten des Kontextes einer Konsole soll allen Apps der Konsole mitgeteilt werden (20Apps je Konsole, 40 Konsole)
• Lokale Konsolen: Kontrolle von einer zentralen Stelle, ob Kontollberechtigung vorliegt (~20 lokale Konsolen)
• Änderungen von "Initdaten": App A teilt "InitProgramm" Änderung mit, Apps 1-n interessieren sich für gewisse Typen von Änderungen (verschiedene Topics) auf verschiedenen Beschleunigerbereichen (Filter)

allgemeine Szenarien für die Interprozesskommunikation verschiedener Anwendungen:

• Messung/Berechnung/DataAcquisition in Auftrag geben und Ergebnisse empfangen
• Events verschicken bzw. empfangen
• Punkt zu Punkt (Eine App will einer bestimmten App eine Nachricht schicken)
• Publish/Subscribe (Viele Apps interessieren sich für die Meldungen einer App, evtl. thematisch kategorisiert)

Fragestellungen:

Vorausgesetzt wird: Apps laufen in einer Konsole (mit bestimmten Namen), Jede App hat eindeutigen Namen innerhalb einer Konsole.

Wie viele Nachrichten, Producer und Consumer kann ein Broker in angemessener Zeit bedienen/behandeln.

Adressierung von Prozessen: Für den Empfang von Daten müssen Prozesse sich bei Queues/Topics subskribieren um Nachrichten zu empfangen. Um Prozessen exklusive Kommunikationskanäle bereitzustellen bieten sich ggf. eindeutig identifizierbare Queues an. Hierfür muss ein Schema für die Benennung dieser Queues/Topics erarbeitet werden.

Welche Möglichkeiten gibt es Subscriptions mit einem Filter zu erweitern um unötiges Datenaufkommen zu verhindern?

Wie kann sinnvoll Request/Reply Semantik implementiert werden.

Welche Möglichkeiten gibt es das System gegen den Ausfall einzelner Broker abzusichern? (aktuell noch weniger wichtig)

Nächste Schritte

Entwicklug eines Modells/Prototyps im Hinblick auf die Verwendung des Messaging Systems in oben genannten Szenarien unter Berücksichtigung der genannten Fragestellungen. Dabei sollen Machbarkeit und Performanz getestet werden. Nach Möglichkeit sollen dabei bereits verwendbare Module enthalten sein, wie zum Beispiel Abstraktionsmechanismen für die Erzeugung von prozessexklusiven Queues. Als API zum Messaging System wird auf JAVA Clients JMS eingesetzt. Ergänzend soll aber eine Utility API bereitgestellt werden um zum Beispiel das Erzeugen von Queues/Topics weiter zu vereinfachen.