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

[taveuni]

Ein "Service" ist mehr oder weniger ein Interface.
Da drin können Strukturen, Methoden usw. definiert werden.
Dan gibt es Channels welche als Client und Server benutzt werden können.
Diese wiederum gibt es als Named Pipes, Socket, Http und viele mehr.

Natürlich bindest Du Dich an Remobjects. Wir sind schon seit 7 Jahren dabei.
Die Sourcen sind dabei. Das wichtigste: Du implementierst die Programmlogik.
Das Framework kümmert sich um den Transport.

[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. :pale:

[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:

Zitat von Morphie (Beitrag 1214504)

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.

:-D

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

Delphi-Quellcode:

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. 8-)

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! :thumb: Ich versuche die Sache nicht zu sehr auszuschmücken um nicht zu viel Zeit zu stehlen.

[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.

[mjustin]

Zitat:

Zitat von Phoenix (Beitrag 1214469)

Zitat:

Zitat von mjustin (Beitrag 1214387)

Als Microsoft-spezifische Lösung nenne ich nur mal so MSMQ, Microsoft Message Queuing. ...

Messages überleben in der Queue nicht ewig

Das Timeout kann man nach Bedarf hochsetzen, solange ausreichend RAM vorhanden ist. Microsoft MSMQ ist vermutlich dann aus dem Rennen, wenn man den Server öfter mal neu booten muss, und keine Möglichkeit hat, die noch nicht zugestellten Messages zu persistieren - so wie es andere (RabbitMQ, WebSphere) können.

[Morphie]

Zitat:

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

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.

[Der schöne Günther]

Zitat:

Zitat von mjustin (Beitrag 1214520)

Microsoft MSMQ ist vermutlich dann aus dem Rennen, wenn man den Server öfter mal neu booten muss, und keine Möglichkeit hat, die noch nicht zugestellten Messages zu persistieren

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

Zitat:

Zitat von Morphie (Beitrag 1214521)

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.

In der Theorie, ja. Allerdings muss (und möchte) ich auch davon ausgehen, dass es immer irgendwo eine Fehlermöglichkeit gibt, die das ganze Teil aufhängt oder komplett abstürzen lässt. Die Aufteilung in eigene Prozesse hilft da ungemein da Windows hier alles wieder freigibt.