Robustes Plugin-System

[ele]

Hallo,

Ich stehe vor der Herausforderung ein robustes, modulares System zu Programmieren und möchte gerne eine Diskussion anregen, welches die beste Lösung sein könnte.

Das System soll aus einem Hauptprogramm und verschiedenen Modulen bestehen, die man zur Laufzeit einbinden, starten, stoppen oder auch wieder auskoppeln kann. Eigentlich ein ganz simples Plugin-System...

Das Problem dabei ist, dass ein klassisches Plugin-System mit DLLs funktioniert, die Funktionalität die diese bereitstellen jedoch im gleichen Prozess wie das Hauptprogramm läuft. Das heisst eine einziger Bug in einer der Modul-DLLs kann unter umständen den ganzen Prozess zum Absturz bringen.

Eine mögliche Lösung wäre es, die Module als separate Prozesse zu erstellen. Das Problem dann ist allerdings die Kommunikation zwischen Modul und Hauptprogramm. Wenn also z.B. das Hauptprogramm Verbindungen zur Datenbank aufrecht erhält und ein Modul eine Datenbankabfrage machen möchte, dann hat dieses ja gar keinen Zugriff auf die Verbindungen, da diese sich ja in einem anderen Prozess befinden. Eine entsprechende Schnittstelle zu Programmieren könnte allerdings recht aufwendig sein.

Ich komme irgendwie auf keinen grünen Zweig. Entweder ich löse das mit DLLs und habe ein potentiell unstabiles System oder ich mache es mit verschiedenen Prozessen und muss eine aufwändige Interprozesskommunikation programmieren.

Hat jemand Ideen dazu?

[hanspeter]

Zitat von ele:

Hallo,

Ich stehe vor der Herausforderung ein robustes, modulares System zu Programmieren und möchte gerne eine Diskussion anregen, welches die beste Lösung sein könnte.

Bemühe mal die Suchfunktion. Dazu gibt es schon eine Reihe Diskussionen.
Ich hatte das gleiche Problem und habe alle Varianten, einschließlich teurer Kauftools wie Remobjects Hydra, ausprobiert.

Jetzt bin ich der Ansicht, das es unter Delphi für ein robustes Pluginsystem, das auch von Dritten erweitert werden kann, nur zwei Möglichkeiten praktikabel sind.

Das ist einmal eine getrennte ExeFile. Hier habe ich mir ein Framework geschrieben, was den Datenaustausch realisiert.
Start des Programmes über Kommandozeile. In dieser werden Steuerparameter und das Handle des rufenden Programms übergeben.
Das externe Plugin meldet sich dann über wm_copydata an und übergibt/übernimmt die Steuerparameter.

Die zweite Variante ist die Realisierung als Com-Server.
Einziger Nachteil ist hier die Notwendigkeit einer einmaligen Registrierung bei der Installation.
Wenn man erst einmal mit dem Prinzip klar kommt, es ist einfach aber schlecht dokumentiert, dann ist das die bei weitem eleganteste Lösung.
Alle Plugin ein einheitliches Basisinterface. Den Namen des Plugin in einer Inifile oder ähnlichem eingetragen und das Problem ist gelöst.
Alle anderen Verfahren funktionieren nur mit Klimmzügen, wenn man ohne Laufzeit BPL arbeitet.
Mit Laufzeit BPL handelt man sich eine BPL-Hölle ein, gegen die die DLL Hölle ein Erholungslager ist.

Com hat noch ein paar andere Vorteile.
So kann das Plugin als Exe angelegt werden. Mit COM+ können Plugin rechnerübergreifend eingesetzt werden.
Letztendlich bieten solche Plugin praktisch eine Sprachunabhängikeit, wenn man sich an die in Delphi verfügbaren Datentypen für das Interface hält.
Z.B. kann ein Net Programm mit wenigen Klicks in ein Com-Server verwandelt werden und ist aus Delphi problemlos aufrufbar.
Die Forderung zur Laufzeit laden, entladen erfüllt Window automatisch.

Gruß
Peter

[TheJeed]

Ich stand mal vor der selben Entscheidung. Die wurde mir dadurch erleichtert, dass ich mir ein Konzept erarbeitet habe, wozu meine Plugins eigentlich dienen sollten:

• ein "Typ I" Plugin sollte eine Form darstellen
• ein "Typ II" Plugin ist in etwa vergleichbar mit einer nicht-visuellen Delphi Komponente: Daten in meinem Programm zu importieren, zu exportieren oder zu manipulieren.

Alle Plugins sind DLLs.

Wird ein Typ I - Plugin eingebunden, dann wird eine in jeder DLL gleich gebaute Function aufgerufen, die eine Beschreibung der vom Hauptprogramm zu bastelnden Oberfläche zurückliefert, sowie Zeiger auf mitgelieferte Funktionen. Die Forms werden vom Hauptprogramm zusammengebaut, und zwar aus Komponenten, die es bereits "vorhält". Vereinfacht gesagt: Sagt das Plugin "hier kommt ein Button hin", instanziiert das Hauptprogramm den Button und verknüpft dessen Events mit Funktionen aus der DLL. Bei dieser Vorgehensweise nehme ich die Beschränkung hin, dass die DLL selbst keine Komponenten verwenden kann, die das Hauptprogramm noch nicht kennt.

Ein Typ II - Plugin tritt maximal als zusätzlicher Menüeintrag im Hauptprogramm in Erscheinung, oder wird unsichtbar mit einem Event verknüpft. Das Hauptprogramm stellt für bestimmte Events Publisher zur Verfügung, an denen sich sämtliche Typ II - Plugins als Observer anmelden, sobald sie geladen worden sind.

Das ist mein Ansatz - er hat seine Schranken und mag nicht sonderlich elegant sein, aber er ist im Einsatz und hat bisher keine Probleme bereitet.

[uoeb7gp]

Hallo ele.

Welche Rolle spielt die Performance?

Je nach Anforderung gibt es da ganz unterschiedliche Ansätze.

Welche Maximalleistung erwartest Du von deinem Plugin-Host?

lg.

[nanix]

Why not use MAF Components they are very good and very robust.They also support a lot of DAC's..

[ele]

Danke für eure Antworten.

Die Performance spielt eigentlich eine zweitrangige Ordnung. Das heisst, natürlich lege ich Wert darauf, dass das ganze möglichst performant ist, allerdings ist es wichtiger, dass das System überhaupt mehrere duzend Plugins geladen haben kann. Die einzelnen Plugins müssen nicht alle gleichzeitig aktiv sein. Ich habe einen Pool von Worker-Threads vorgesehen und pro Thread (bzw. Arbeitschritt) wäre nur jeweils ein Modul aktiv. Wichtig dabei ist, dass die Kommunikation sowohl von Hauptprogramm zu Modul (Modul soll eine bestimmte aufgabe erledigen für welche es sich registriert hat), als auch von Modul zu Hauptprogramm (um gewisse Statusinformationen abzufragen oder Datenbankabfragen zu tätigen).

Die DLL-Lösung wäre von der Kommunikation her die ideale Lösung, allerdings ist sie nicht robust. In einem anderen Plugin-System, dass wir verwenden, hat einer der Entwickler einen Rekursionsfehler programmiert, was zu einem Stackoverflow geführt hat, der die ganze Applikation zum Absturz gebracht hat (Das Programm wurde ohne Fehlermeldung abgebrochen). Und so etwas darf einfach nicht passieren. Wenn etwas abstürzt, so soll es nur das betroffene Modul sein.

Die Lösung mit getrennten Prozessen und WM_COPYDATA klingt einfach, aber damit laufe ich Gefahr, dass wenn sich sich im laufe der Zeit die Schnittstelle ändert, das Hauptprogramm mit einem inkompatiblen Modul betrieben wird.

Die Lösung mit getrennten Prozessen und COM/COM+ klingt auch sehr interessant. Ich wusste zwar von der existenz von COM, wäre aber nie auf die Idee gekommen das für ein eigenes Programm einzusetzen. Ich glaube ich werde mich etwas in dieses Gebiet einarbeiten.

Die MAF-Komponenten kenne ich nicht, möglicherweise können sie mir einen Haufen Arbeit sparen. Dazu muss ich mir aber das ganze genauer ansehen.

Mein Favorit ist bisher die Lösung mit getrennten Prozessen und COM. Jetzt muss ich mal ein Grundgerüst bauen und sehen wo die schwierigkeiten liegen.

[hanspeter]

Zitat von ele:

Mein Favorit ist bisher die Lösung mit getrennten Prozessen und COM. Jetzt muss ich mal ein Grundgerüst bauen und sehen wo die schwierigkeiten liegen.

Bei der Lösung bin ich nach vielen Versuchen auch angekommen und ärgere mich über alle Umwege.
Man sollte aber mit Delphi 2009/2010 anfangen, da hier die Com-Geschichte gründlich überarbeitet wurde und
vieles einfacher macht. So wird z.B. die Typlibrary nicht mehr binär editiert, sondern in einer Quellcodedatei vorgehalten ,
welche danach compiliert wird.
Das Anlegen eines Com-Servers untstützt Delphi mit Experten recht gut.
Ein Comserver kommt letztendlich auch nur als dll daher. Die dll sind relativ groß, da sie die Laufzeitumgebung von Delphi mit eingebunden haben. Dafür sind sie aber von der Compilerversion völlig unabhängig.
Das spätere Ändern von Schnittstellen ist ebenfalls kein Problem. Ein Com-Object kann mehrere Schnittstellen beinhalten.
Die alte Schnittstelle wird unverändert gelassen und eine neue Schnittstelle declariert.
Die richtige Schnittstellenzuordnung erfolgt automatisch über die GUID der Schnittstelle.
Man muß nur eisern daran festhalten eine einmal veröffentlichte Schnittstelle nie mehr zu ändern.
Alte Software arbeitet mit der alten Schnittstelle, neuere Software kennt bereits die neueren Schnittstellen.
Mit dem ersten Aufruf eines Com-Objectes läd das OS dieses und gibt es automatisch frei, wenn keine Referenz auf dieses Objekt mehr vorhanden ist.
Praktisch heist das, das ein Com-Object auch entladen wird, wenn das Hauptprogramm abstürzt und seinen Process beendet..
Ein Comserver kann als Inprocess oder outprocess-Server deklariert werden.
Bei einem outprocess-Server können beliebig viele Client auf diesen Server zugreifen, so er das kann.
Vom Comserver zur Anwendung gibt es die Möglichkeit von Events. Das war vor Delphi 2009 etwas schwierig.
Alternativ kann das aufrufende Programm eine Callback Adresse übergeben. Bei mir ist diese parameterlos und fordert den Client nur auf den Serverstatus abzufragen.
Bei Interesse mal die email-Adresse als PM schicken. Ich kann dann eine kleine Demo-Version schicken.
Hier wird die Form aus dem Com-Server z.B. in einem Tabshett als Parent eingebunden.


MAF Components habe ich mir auch angesehen. Dabei bin ich aber wieder bei Abhängigkeit von runtime - BPL.

Ich haffe das hilft
Mit Gruß
Peter

[Dezipaitor]

Soweit ich weiß, kann man COM Objekte zur Laufzeit registrieren. Man muss sie nicht installieren.
http://msdn.microsoft.com/en-us/library/ms973913.aspx

[hanspeter]

Zitat von Dezipaitor:

Soweit ich weiß, kann man COM Objekte zur Laufzeit registrieren. Man muss sie nicht installieren.
http://msdn.microsoft.com/en-us/library/ms973913.aspx

Das geht relativ einfach.
Ich fürchte aber, das da das UAC Monster auf der Lauer liegt.

type
TDLLRegisterServer = functionWORD;
TDLLUnregisterServer = functionWORD;

function RegisterServer(const Filename: String): Boolean;
var
hLib: THandle;
ProcAddress: TDLLRegisterServer;
begin
Result := False;
hLib := LoadLibrary(PChar(Filename));
if hLib <> 0 then
begin
@ProcAddress := GetProcAddress(hLib, 'DllRegisterServer');
if Assigned(ProcAddress) then
begin
Result := ProcAddress = S_OK;
end
end
end;

function UnregisterServer(const Filename: String): Boolean;
var
hLib: THandle;
ProcAddress: TDLLUnregisterServer;
begin
Result := False;
hLib := LoadLibrary(PChar(Filename));
if hLib <> 0 then
begin
@ProcAddress := GetProcAddress(hLib, 'DllUnregisterServer');
if Assigned(ProcAddress) then
begin
Result := ProcAddress = S_OK;
end
end
end;

[ele]

Wenn ich das richtig verstanden habe, muss ich meine Plugins als Local-COM-Server implementieren. Als InProcess-Server würden sie im gleichen Prozess wie das Hauptprogramm laufen.

Im Moment bin ich leider auf Delphi 7 angewiesen. Der Chef hat zwar angedeutet, dass wir vielleicht als Weihnachtsgeschenk ein Delphi 2010 kriegen, aber sicher ist das noch nicht.