(05.07.2018 14:20 )Mechatroniker28 schrieb: Was ist der Unterschied zwischen Queued Message Handler, Ereignistruktur und Producer Consumer? Ich will wissen welche Architektur für welche Bereich geeignet ist?
"Queued Message Handler": QMH
QMH ist, wie der Name besagt, ein System, dass Messages mittels Queues handhabt. QMH ist immer Mittel zum Zweck. Ein Zweck z.B. ist die Producer-Consumer-Strategie.
Hauptzweck einer Queue besteht darin, unabhängige Programmmodule logisch zu verbinden. Jedes einzelne Modul für sich alleine arbeitet quasi selbstständig - strenggenommen ohne zu wissen (ohne wissen zu müssen) wer sonst noch irgendwo arbeitet. Da aber jedes Modul etwas produziert (ein Modul, das nichts produziert, ist zuerst einmal sinnlos), ist es sinnvoll, dass das Modul zum einen diese Daten nach außen geben kann, zum anderen ist es sinnvoll, das das Modul von außen gesteuert werden kann. Vom Modul aus gesehen ist das Außen ein anderes Modul. Die Schnittstelle zwischen den einzelnen Modulen kann man mit Queues realisieren (und/oder Meldern, die als Sonderfall einer Queue angesehen werden können).
Ganz wichtig: Eine Queue hat immer eine Richtung - nämlich vom "Producer" zum "Consumer": Ersterer schreibt Daten in die Queue (versendet also Daten per Queue), Letzterer ließt die Date aus der Queue aus (empfängt also Daten per Queue). Diese Richtungsgebundenheit bedeutet natürlich, dass zum Verbinden zweier Module in der Regel zwei Queues notwendig sind.
"Producer Consumer"
Auch hier gilt: selbsterklärend. Irgendwer produziert etwas, ein anderer konsumiert dieses Etwas. Das Etwas nun muss also vom Produzenten zum Verbraucher (warum sollte es sonst produziert werden). Der Weg, den das Etwas nimmt, heißt Queue.
Beispiel (also Bereich): Das Datenerfassungsmodul "AIn" produziert Daten (Messwerte) dadurch, dass Werte aus dem DAQmx gelesen werden. Diese Daten stellt das Modul sozusagen der Allgemeinheit zur Verfügung - indem es die Daten in eine Queue (kann auch ein Melder sein) schreibt. Wer die Daten haben will, soll sie aus der Queue (dem Melder) herausholen.
"Daten", also das, was in der Queue gehandhabt wird, müssen nicht unbedingt Daten in Form von Messwerten sein. "Daten" können auch Kommandos oder Mitteilungen ("Message") sein. Der Consumer (von Messwerten) sagt z.B. dem Producer (der Messwerte), dass er (der Producer) diese oder jene Kanäle sampeln soll. Das sagt der Consumer selbstverständlich per Queue.
Hinweis:
"Producer/Consumer" kann man im engeren Sinne auf Queues beziehen und im weiteren Sinne auf Module.
"Ereignistruktur"
Das Element "Ereignistruktur" nehme ich immer dann, wenn der Anwender über die GUI eine Eingabe in das System machen will. Eine solche Eingabe ist immer eine einmalige Sache, also ein "Ereignis". Ein Ereignis soll aber immer eine Wirkung haben - z.B. das Starten der Abtastung von Messwerten im AIn-Modul. In dem Ereignis-Case würde man also in eine Queue schreiben, die das AIn-Modul veranlasst, ab jetzt Daten zu samplen.
Fazit:
Das Programm wird aufgeteilt in viele unabhängige Module, die untereinander per Queue/Melder kommunizieren. Die Kommunikation des Anwenders mit den Modulen geschieht am Schnittpunkt "Ereignisstruktur".
Änderungshinweis:
Da war ja ein ganzer Absatz doppelt - blödes Ctrl-V ...
