Modularer (evtl. verteilter) Programmaufbau - Welche Art von IPC ist die richtige?

[mjustin]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214510)

Zusammenfassend scheinen fertig zu kaufende Lösungen wie eben RemObjects oder RealThinClient mir (in meinem konkreten Fall) die Arbeit abzunehmen, wie ich jetzt meine Präsentationsschicht mit der Anwendungsschicht verknüpfe?

Die fertig zu kaufenden Lösungen sind aber nicht für alle Architekturen optimal geeignet. RO und RTC sind eher Serveranwendugen, an die sich dann Clients (auch sehr viele Clients) wenden, wenn sie ein Anliegen haben - Request / Response und RPC Kommunikation.

Wenn aber alle Plugins als Clients implementiert werden, die sich an einen zentralen Server andocken sollen, wird dem Serverprozess die gesamte Koordination der Anfragen und das Weitergeben an andere Plugins übertragen. Dazu müssten auch Callbacks implementiert werden, so dass der Server aufgrund der Anfrage eines Plugins aktiv einem anderen Plugin Nachrichten senden kann.

Ich stelle mir als Lösung eher einen sehr schlanken Message Bus vor - eine einheitliche Infrastruktur die allen Plugins gleichberechtigt zur Verfügung steht. Dazu würde ich ein sehr kompaktes Protokoll wie MQTT einsetzen, das gerade für kleine Nachrichten und langsame Netze (schwache Hardware wie Arduino) ausgelegt ist. (http://mqtt.org/ und http://mqtt.org/faq)

Jedes Plugin benötigt dann nur eine sehr kompakte und komplett im Prozess integrierte Clientbibliothek, unabhängig von DLLs oder Services wie DCOM ist. Nur TCP wird benötigt, zum Beispiel über Synapse das auch sehr schlank ist.

Anwendungen, die die Daten der Plugins visualisieren wollen, lauschen dann entweder auf dem Message Bus und verarbeiten Daten die momentan darüber gesendet werden, oder senden Befehle über den Message Bus an ein Plugin, das daraufhin zum Beispiel Statusdaten an den Sender zurückschickt.

Auch eine Weboberfläche liesse sich damit problemlos anbinden, selbst wenn sie in einer anderen Sprache geschrieben ist, wenn für das Protokoll (z.B. MQTT) bereits entsprechende Clients existieren.

Der wesentliche Unterschied ist, dass es keine Server- und Clientprozesse gibt sondern jedes Plugin aktiv senden und passiv empfangen kann. Das kann man auch nutzen um eine Benutzeroberfläche fernzusteuern, zum Beispiel abhängig vom Status eines Plugins einen Menüpunkt zu aktivieren - das Plugin sendet eine Nachricht wie "Ich bin jetzt aktiviert!" über den Bus. Das GUI Programm lauscht auf entsprechende Statusnachrichten und schaltet die Menupunkte ein.

[sh17]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214527)

Der Kunde stellt die lustigsten Dinge mit den Maschinen an, einfach Strom ziehen ist nichts ungewöhnliches. Daher...

...ist das Handle wenigstens freigegeben.

[sh17]

und die Instanz vom Message Bus kann im Kern der Anwendung liegen? Oder lieber separat?

[mjustin]

Zitat:

Zitat von sh17 (Beitrag 1214535)

und die Instanz vom Message Bus kann im Kern der Anwendung liegen? Oder lieber separat?

Der Message Bus wird von einem eigenen Prozess bereitgestellt, damit ist er selbst in dem (allerdings unwahrscheinlichen Fall) erreichbar, dass der Anwendungskern komplett abgestürzt ist - und nur noch die Plugin-Prozesse laufen ;) und man kann ihn bei Bedarf auch auf eine eigene (virtuelle) Maschine legen, an der nicht herumgefummelt wird.

[Der schöne Günther]

Faszinierendes Kochrezept.

Für meinen Zweck hatte hätte ich bislang eigentlich bewusst eine Punkt-zu-Punkt-Verbindung zwischen Kern und den Modulen angestrebt. Und zwar da

1. die Module in ihrer Natür sehr autark sind. Was ein einem passiert beinflusst i.d.R. die Tätigkeiten des anderen in keinster Weise, oder nur sehr indirekt
2. ich bewusst verhindern möchte, dass man sich in einem Modul mit Aufgabenbereichen eines eigentlich anderen befasst.

Der Grund für den zweiten Punkt ist folgender: Baut der Kunde an seiner Installation etwas um, möchte ich ihm nur eine neue Konfiguration des Moduls (oder ein anderes) liefern. Wenn ich jetzt noch andere Module habe, die in gewisser Weise von anderen Plug-Ins "abhängig" sind, komme ich in Teufels Küche...


Ich bin begeistert, wie lange sich so ein komplexes Thema hält. :thumb:

[sh17]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214541)

Ich bin begeistert, wie lange sich so ein komplexes Thema hält. :thumb:

Na nur die machen doch Spaß, zumindest interessiert es mich auch.

[QuickAndDirty]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214516)

Aber warum meinst du, dass es sich für den Hardware-Steuerfall nicht eignet?

Nichts hiervon ist auf einem modernen Computersystem wirklich rechenintensiv und sonderlich zeitkritisch ist eigentlich auch nichts.

Einfach so intuitiv würde ich nichts zeitkritisches mit SOA machen.

So wie ich die letzten Posts verstehe würde dir ein gemeinsames Postfach zur Kommunikation reichen.

Vielleicht mit einem Broadcast das ein frühzeitiges Pollen auslöst.

ich glaube nicht das es sowas als middleware gibt...

[mjustin]

Zitat:

Zitat von QuickAndDirty (Beitrag 1214547)

ich glaube nicht das es sowas als middleware gibt...

Zumindest für MQTT sieht es gar nicht so schlecht aus. Die MQTT Home Page listet unter http://mqtt.org/software auch eine kostenlose und sehr kompakte IBM Implementierung namens "Really Small Message Broker" des aktuellen MQTT 3.1 Standards (der kürzlich zu einem offziellen OASIS Standard wurde), aber auch einige andere freie Implementierungen. Einen open source Delphi Client für MQTT habe ich bereits im Netz gesehen, er ist etwas älter und unterstützt die Basisfunktionen des Protokolls.

[Der schöne Günther]

Langsam muss ich auch zu einem Ergebnis kommen...

Nachdem für mich für ein RAD Studio Geld in Höhe des Staatsetats von Timbuktu lockergemacht werden musste, will ich nicht gleich noch neue Lösungen wie RealThinClient oder RemObjects kaufen müssen

1. die ich nicht wirklich verstanden habe
2. damit nicht umgehen kann und Zeit verbrate mich groß in etwas einzuarbeiten
3. dass wir in vollem Umfang garantiert nichtmal ansatzweise brauchen

Leichtgewichtige Sachen wie XML-RPC für Delphi sind anscheinend wirklich tot (siehe auch hier im Forum). Ich könnte mich jetzt noch wochenlang durch x-beliebige Middlewares wühlen.

Ich gebe hiermit mehr oder weniger auf: Wahrscheinlich wird es damit enden, sich wieder selbst etwas zusammenzubasteln (wild Pesudo-XML-Zeichenketten über Sockets hin-und herwerfen)um in zwei Jahren zu merken, dass es doch etwas gegeben hätte, was eigentlich genau gepasst hätte (Was ist eigentlich diese DataSnap-Geschichte?) und konform zu irgendeinem tollen Standard gewesen wäre. Ich habe schlichtweg nicht den geringsten Überblick was da draußen alles vor sich hingeistert.

Insgesamt vielleicht etwas traurig - Egal wo ich hinschaue, alles scheint darum zu gehen, eine potentiell riesige Lemming-Horde an Clients versorgen zu können und toll Daten persistieren zu können. Persistente Datenhaltung spielt bei mir nur eine sehr kleine Rolle und Server und Client befinden sich in 95% der Fälle auf einer Maschine.

[sh17]

Also die angesprochene XML-RPC-Sache mit Delphi hatte ich mal im Einsatz, war sehr einfach und stabil, hat eben gemacht was es sollte. Wenn Du das auf dein Delphi gebogen bekommst, sollte alles machbar sein.