Pluginsystem Framework

[OnDemand]

Hallo zusammen,

überlege grad wie und ob es sinnvoll ist eine Art Plugin System zu bauen.

Angenommen User hat Basistool von unserer Software und kann dieses um Module erweitern. Jetzt könnte man alle Module reinbauen, nur nicht freischalten. Ich denke aber eher so an Jira. Da kann man Apps hnzufügen die sich dann als Plugin in das System integrieren.

Ich habe folgenden Hintergrund:

Kunde A bekommt unser Programm und möchte Modul 1 (Modul 1 holt Daten von Hersteller X)
Kunde B Möchte Modul 1,2,3,4,5,6,7,8 jedes Modul holt die Daten von einem anderen Hersteller

Nun kann es passieren, dass in Modul 3 ein Bug ist, damit nicht alle Kunden updaten müssen was ja vollkommen unnötig ist, weil die das Modul nicht nutzen, möchte ich das herauslösen.

Gibt es Frankworks o.ä. was man sich unbedingt anschauen muss?

Hatte schon die Idee jedes Modul als eigenes .jar auf dem Kundenserver zu instalieren, aber wie kommuniziert Modul 3 dann mit dem "Hauptprogramm"

Vielleicht hat jemand guten Input?!

 

[Robert Zenz]

Die Frage ist immer: Was macht die Applikation? Wie grosz ist die? Wieviele Plugins wird es geben? Was machen die Plugins/wie tiefen Zugang in den Rest der Applikation brauchen diese?

Solche Standards wie OSGi werden immer wieder fuer solche Sachen vorgeschlagen, auf der anderen Seite kannst du natuerlich auch einfach ein jar in den Klassenpfad werfen und dann ueber den ServiceLoader das Plugin starten. Ein ebenfalls relativ einfacher Weg waere zum Beispiel einfach mit Class.forName(String) sich die konkrete Implementierung einer Schnittstelle zu holen. Wenn diese nicht geladen werden kann (sprich das notwendige Plugin jar nicht im Klassenpfad ist), gibt es die Funktionalitaet halt nicht.

All das setzt natuerlich voraus dass du die Applikation so strukturierst und aufbaust dass die Funktionalitaet ueberhaupt derart abgetrennt werden kann, was nicht immer einfach ist. Und zu guter letzt stellt sich natuerlich auch die Frage wer das System betreut, wenn es der Kunde selbst ist, muss es relativ einfach sein Funktionalitaet hinzuzufuegen. In der selben Schiene stellt sich die Frage ob diese Plugins dann ebenfalls durch irgendeine Form von Lizenz-Mechanismus geschuetzt werden muessen. Wenn ja, macht es weniger Sinn diese nicht direkt mit der Basis-Applikation auszuliefern, da man damit nur eine Trennung der Applikation bei der Auslieferung erzielt, was jetzt nicht so viel bringt.

Last but not least, man koennte dann noch zusaetzlich den "App Store" Weg gehen, und in der Oberflaeche der Applikation anbieten sich Erweiterungen direkt aus einem "App Store" zu installieren.

 

[OnDemand]

Hey vielen dank! Osgi bin ich grad am lesen, sieht sehr kompliziert aus.

plugins soll niemand anderes außer uns anbieten oder hinzufügen können.
Ziemlich komplexes Thema, da einen Einstieg zu finden ist echt schwer

 

[mihe7]

Geht es um Java EE? Dann kann man das mit CDI regeln.

 

[mrBrown]

Um welche Art Anwendung gehts denn?

Web-Anwendung auf euren Servern? Web-Anwendung auf Kunden-Servern? "normale" Anwendung direkt auf Kunden-Rechnern?

 

[Robert Zenz]

Das bedeutet ihr verwaltet den Server effektiv? Wenn ihr den Server kontrolliert, beziehungsweise Betrieb vom Server an Zahlungen an euch geknuepft ist, wuerde ich keinen riesigen Aufriss mit einem Plugin-System machen, da ihr die Sache ja kontrolliert. Ich wuerde dir dennoch raten die Applikation natuerlich sauber zu strukturieren, damit die Funktionalitaet sauber getrennt ist, aber dann spricht nichts dagegen die gesamte Funktionalitaet auszuliefern und das nur ueber die Lizenz/Konfiguration zu machen. Das hat den Vorteil das Deployment um ein vielfaches einfacher ist. Wenn jetzt ein Kunde hergeht, und sich selbststaendig in der Konfiguration alles freischaltet, werdet ihr das frueher oder spaeter merken (koenntet ja auch nach Hause telefonieren) und dem Kunden dann dementsprechend eine Rechnung nachschicken. Wenn ihr dann die Applikation mit aller Funktionalitaet in einem habt, braucht ihr naemlich nie darueber nachdenken welche Version von welchem Plugin der Kunde hat, ob er das Plugin schon hat und so weiter und so weiter, dann reicht es die aktuellste Version hinzuspielen und die Lizenz/Konfiguration entsprechend anzupassen.

Wenn ihr den Server nicht kontrolliert, dann ist wahrscheinlich ein Plugin System besser. Du musst hier aber wirklich ausloten was ihr braucht, weil auch wenn ich damit gegen den Strom schwimme, aber hier das Rad neu zu erfinden kann echt gute Vorteile haben. Weil die meisten Plugin-Frameworks/Systeme welche es fix und fertig gibt sind auf sehr grosze und komplexe Applikationen ausgelegt. Je nachdem was eure Applikation macht, kann das komplett ueberzogen oder am Ziel vorbei sein. Da kann es echt ausreichen wenn ihr euch einfach ueber so etwas wie den ServiceLoader oder CDI die Plugins holt und fertig. Dann kontrolliert ihr dien gesamten Mechanismus und koennt ihn um einiges leichter anpassen auf eure Beduerfnisse.

 

[OnDemand]

Robert, danke macht Sinn. Wir haben vollen Zugriff auf den Server, wir stellen die selber bereit (Partnerunternehmen)

das deployen ist wirklich viel einfacher wenn wir alles ausliefern aber nur freigeben was bezahlt ist.

was mir sorgen macht ist, dass wenn man nur einen kleinen Teil der Applikationen updated will oder muss, ist der gesamte Service betroffen und muss neugestalten werden.
@mrBrown ist eine Vaadin/spring webapp

 

[OnDemand]

Wie könnte man eine saubere, technische Trennung erreichen?
Angenommenen wir haben das Hauptprogramm welches Daten bearbeitet und speichert oder updated. Die Daten kommen aus verschiedenen Modulen (welche je nach Kunde freigegeben sind oder nicht)
Wie könnte man das klar trennen was das Verarbeitungsmodul und und wo fängt das Importmodul an? Über Interfaces?

 

[Robert Zenz]

was mir sorgen macht ist, dass wenn man nur einen kleinen Teil der Applikationen updated will oder muss, ist der gesamte Service betroffen und muss neugestalten werden.

Wenn ihr nicht gerade ein Plugin-System mit Hot-Reload habt, habt ihr das Problem ansonsten auch. Dann muss man auch fuer das Update von dem Plugin eine Pause einplanen. Das wird noch schwieriger wenn man laufende Sessions mit einplanen muss (was macht man mit denen? Zustand verwerfen? Wenn nein, was passiert wenn eine alte Client-Session auf ein neues Backend trifft?).

Wie könnte man das klar trennen was das Verarbeitungsmodul und und wo fängt das Importmodul an? Über Interfaces?

Ja, zum Beispiel. Wenn es eine fest Abhaengigkeit ist die nur mit einer Abfrage gesichert ist (Lizenz), dann kann man die entsprechende Klasse auch hart verwenden. Wenn es unterschiedliche Quellen gibt (von denen es entweder mehrere gibt oder sich welche ausschlieszen) dann braucht man halt einfach ein Interface, und die konkreten Implementierungen werden dann je nach Bedarf geladen. Im simpelsten Fall hat man halt einfach "public interface Plugin" und dann die konkreten Implementierungen wie "public class CsvPlugin implements Plugin" und "public class DatabasePlugin implements Plugin" dazu, welche dann die eigentlich Funktionalitaet stellen. In der Byte-welt Wiki gibt es ein schoenes kurzes Tutorial dazu, nach einem interessanten Framework sieht PF4J aus.

Ohne die Applikation und den Anwendungsfall wirklich zu kennen ist es schwierig hier wirklich Aussagen ueber die Struktur oder die Anforderungen zu treffen.