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

[sh17]

Ne, ein Buch gibt es nicht, auch Doku ist rar. Kann ich nur auf das Forum verweisen, oder auch hier in die DP.

Aber die Zeit, die Du sparst, ist enorm. Und wenn es doch mal nicht mehr klappt, weil RemObjects pleite geht (wobei da es ein Fallback gibt), Delphi in die falsche Richtung wandert oder die Erde untergeht, kannst Du es immer noch selbst programmieren. Der Schnittpunkt ist recht klein gehalten und damit einfacher austauschbar.

Und für IPC ist es geeignet.

[Der schöne Günther]

RemObjects sieht jetzt auf den ersten Blick wirklich mächtig und gleichzeitig elegant aus. Gleichzeitig habe ich aber weiterhin das Gefühl, dass es ein ziemlicher Overkill ist.

Nach bisheriger Planung muss ein Plug-In nicht mehr leisten als

• Von einem anderen Prozess (dem Kern) seine Konfiguration empfangen (bsp. als XML)
• Einen Befehl "Fange an, zu arbeiten" entgegennehmen, ebenso "Fahre dich herunter"
• seine Oberfläche (bsp. VCL-Form) anzeigen, ebenso verstecken (bzw. Form zerstören)
• seine (durch den Benutzer über die Oberfläche veränderte) Config wieder zurückgeben

Bislang geregelt habe ich das über DLLs die in den Prozess (als separater Thread) eingeklinkt werden. Auf die Nachteile wenn hier etwas abstürzt (und ich bsp. serielle Ports nicht mehr freibekomme) müssen wir sicher nicht mehr reden. Deshalb war der Ansatz, es in gesonderte Prozesse zu packen.

Bislang möchte ich im Kern noch nicht einmal wissen, was in den Plug-Ins vor sich geht und wie sie funktionieren. Mit so einem simplen Weltbild bleibt allerdings eine brauchbare Visualisierung auf anderen Maschinen außen vor, oder?

Insgesamt stehe ich irgendwie vor dem Dilemma, mich im Kern nicht damit befassen zu wollen, was in einem Plug-In vor sich geht und was es kann, aber trotzdem die Möglichkeit behalten möchte, das Plug-In (oder die gesamte Anwendung) später einmal über einen Webbrowser oder eine native Anwendung auf einem anderen System zu steuern. Und das führt auch mittlerweile schon wieder etwas weg vom eigentlichen Thema, ob nun Sockets, Pipes oder Mega-Lösung wie RealThinClient, RemObjects oder sonstwas.

[Morphie]

Naja, eigentlich ist das doch der klassische Anwendungsfall von Pluginframeworks...

Du schreibst, dass du es vorher mit DLLs gemacht hast... Ich bin der Meinung, dass genau das der richtige Weg für dein Vorhaben ist.
Ein einheitliches Interface für die DLLs definieren und gut ist.
Wo genau sind denn deine Probleme hierbei?

Ich sehe das immer wieder, dass einige Softwarehersteller für jede kleine Funktion / Fenster eine eigene Anwendung (*.exe) schreiben und diese dann aus der Hauptanwendung aufrufen... Da kratze ich mir immer den Kopf... Oft heißt es dann, dass das historisch bedingt so entstanden ist...
Für eine Neuentwicklung halte ich das aber für den falschen weg.

[Der schöne Günther]

Zitat von Morphie:

Ich bin der Meinung, dass genau das der richtige Weg für dein Vorhaben ist.
Ein einheitliches Interface für die DLLs definieren und gut ist.

Genau so habe ich es jetzt auch in meinen ersten Delphi-Wochen bislang hingebogen. Die DLLs führen eigentlich auch nur genau die genannten Funktionen nach außen. Für Notfallzwecke gibt es weiterhin noch ein get/setValue(propertyName:Str):Str welches dann über RTTI in den von der DLL erstellten Objekten wühlt.

Toll, dass jemand das genauso sieht, dann bin ich wohl doch kein hoffnungsloser Fall

Der gravierende Schwachpunkt ist allerdings, dass Windows Dinge wie Verbindungshandles und geöffnete Dateien pro Prozess verwaltet. In meinem Anwendungsfall ist die Anwendung dazu da, Hardware zu steuern. Hat sich ein Programmteil aufgehangen oder ist abgestürzt, kann ich den Speicher zwar wieder brauchbar freiräumen, bekomme aber meine Handles nicht wieder - Ich komme an die Ports nicht mehr dran. Der Kunde kann nicht wegen so etwas den gesamten Betrieb lahmlegen und das ganze Programm herunter- und wieder hochfahren. Daher der Wille zur Multi-Prozess-Architektur. Auch der Internet Explorer und Google Chrome halten das seit Neustem mit ihren Plug-Ins und Tabs ähnlich.


Nun gut, dann halt die Module als eigene Prozesse statt Libraries im selben Prozess. Unterhalte ich mich mit denen halt per x-beliebiger Methode. Eigentlich kein wirklicher Unterschied bis hierhin.

Nun wäre es allerdings auch zeitgemäß, auch auf anderen Geräten zu sehen (und steuern), was auf der eigentlichen Maschine vor sicht geht - Ohne Eselsbrücken wie TeamViewer

Jetzt habe ich doch schon mehrere Prozesse - Jetzt sollte ich auch dafür sorgen, dass die Prozesse sich gut fernsteuern lassen! Entweder spuckt mir das Modul nun einen Block (XML) an Dingen aus, die sich bei ihm einstellen lassen, ich bereite das anderswo auf wie ich lustig bin auf und schicke ihm einen XML-Block zurück (den es entweder annimmt, nur teilweise oder komplett zurückweist), oder das Modul bietet nur die interne Logik an ("stellt einen Service bereit"?) den ich dann mittels einer GUI auf der gleichen Maschine oder anderswo direkt darstellen kann (Präsentationsschicht).

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?

Der einzige Grund warum ich damit vielleicht noch hadere, war dass ich bislang nur an reine VCL-Anwendungen auf einem Windows-System gedacht hatte, die Plug-Ins sich auch selbst um ihre VCL-Oberfläche gekümmert haben, und gut war. Wenn ich die Darstellung nun aus den Plug-Ins rausziehe, brauche ich für den lokalen Betrieb (95% der Fälle) nun den Kern, seine n Module und noch einmal n Präsentationsanwendungen. Und irgendwie wird mir das dann langsam etwas zu viel...


Vielen Dank für die Antworten bislang! Ich versuche die Sache nicht zu sehr auszuschmücken um nicht zu viel Zeit zu stehlen.

[Morphie]

Zitat von Der schöne Günther:

Der gravierende Schwachpunkt ist allerdings, dass Windows Dinge wie Verbindungshandles und geöffnete Dateien pro Prozess verwaltet. In meinem Anwendungsfall ist die Anwendung dazu da, Hardware zu steuern. Hat sich ein Programmteil aufgehangen oder ist abgestürzt, kann ich den Speicher zwar wieder brauchbar freiräumen, bekomme aber meine Handles nicht wieder - Ich komme an die Ports nicht mehr dran.

Aber ist das dann nicht ein allgemeines Problem der Ressourcenverwaltung / des Error-Handlings?

Wenn ich eine bestimmte Hardware per COM-Anschluss ansteuere und mein Programm dabei ein Fehler produziert, muss ich doch sicherstellen, dass der COM-Anschluss auch wieder freigegeben wird.

[mjustin]

Zitat von Der schöne Günther:

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.

[QuickAndDirty]

Ich weiß jetzt nicht ganz genau was die Anwendung leisten soll.
Wenn diese "Plug-Ins" jetzt nicht Steuereinheiten für Maschienen sind oder
Spezialisierte Simulatoren oder
andere leistungshungrigen "Echtzeit" Funktionen bieten,
dann würde ich zu einer SOA Struktur auf Basis von Webservies tendieren.
Da hast du alles was du brauchst. Lizensierung , verteilte Ausführung, Konfigurierbarkeit, Erweiterbarkeit ist alles schon abgedeckt.
Manche Administratoren wissen was das ist und wie man das am laufen hält.
Aber auch hier ist das drumherum für dich vermutlich zu viel?

Edit:...hab überlesen das du hardware steuern willst...also einfach ignorieren...

[Der schöne Günther]

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.

[QuickAndDirty]

Zitat von Der schöne Günther:

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 von QuickAndDirty:

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.