Ideen Plugin-System

[fastjack]

Hallo

bei meiner Bekannten geistert im Management eine Idee herum, J2EE Anwendungen + mehrere dazugehörige GUI's als Plugins zu realisieren, die der Kunde sich dann selbst anpassen kann. In ersten Ideen soll der Applikationsserver einen Core bieten, in dem mehrere Grundfunktionalitäten enthalten sind. U.a. werden dann Plugins (Java-Sourcecode) aus einem bestimmten Verzeichnis nachgeladen, zur Laufzeit übersetzt und aktiviert usw. Fast alles soll selbst entwickelt werden, außer die Persistenz, bei der wohl JPA benutzt wird.
Später (nach Erweiterungen und so weiter) sollen sich aus den Plugins dann auch dynamisch GUI's aufbauen können. Der Kunde soll ab einem bestimmten Level alles dynamisch selbst ändern können oder für die Änderungen (die ja laut Management dann rasend schnell gehen werden) teuer bezahlen. Der Kunde soll die Möglichkeit haben, in den Plugins eigene Datenstrukturen aufzubauen und bestehende erweitern zu können. Die Plugin-Kommunikation soll durch Ereignisse asynchron laufen.
Die Entwickler vor Ort haben schwere Bauchweh mit dieser Idee, es soll aber wohl durchgeboxt werden. Der Kunde soll bei Modifikationen, die er selbst durchführt, auch selbst haften.

Ich habe ihr einige Punkte gegeben, die aus meiner Sicht gegen so ein System sprechen:

* Da Plugins direkt zur Laufzeit kompiliert und geändert werden können, kann es schnell zu Fehlern kommen (Logik, Syntax sowieso, Schadcode mit Absicht oder ohne) --> nicht EJB-konform (eigener Classloader, defining von classes zur Laufzeit und co.)
* Schwierige pluginübergreifende Transaktionen, da alles aynchron abläuft und man auch aufpassen muß, das keine Zyklen entstehen. Das wurde vor Ort schon erkannt und das Management beschloß daraufhin auf den völligen Verzicht von Transaktionen und UseCases.
* keine definierten Workflows mehr, da alles geändert werden kann und später keiner mehr richtig sagen kann, wie eine Funktionalität funktionieren sollte (kann ja bei jedem Kunden anders sein...)
* schlechte Testbarkeit, wie testet man Plugins, die überall anders sein können? Fehlersuche wird den Core-Systementwicklern so gut wie unmöglich gemacht, da sie ja womöglich gar nicht über die Kunden Plugins verfügen...
* wenn jeder der Entwickler vor Projektstart schon Bauchweh bei drei- bis vier verschiedenen Punkten hat, ist es ein schlechter Start und ein Indiz, das man vielleicht einen anderen Weg gehen sollte.
* Update-Trouble: Was darf bei Updates überschrieben werden und was nicht?
* mein Vorschlag war ein Standard-System mit Injektionspunkten in bestimmten Workflows, in denen der Kunde dann seinen Code/Klasse einfügen kann, ähnlich SAP. Alles sauber untergebracht in Packages/Projekten usw. und Kunden, die den Workflow direkt ändern möchten (und dafür extra blechen), könnten Zugriff auf das jeweilige Package/Projekt bekommen um da Ihre Modifikationen machen und anschließend neu bauen oder so.

Was haltet Ihr davon?

Gruß Fastjack.

P.S.: Es ist kein Witz Leute, sondern wirklich real und wie es sich anhörte auch sehr dringend, da schon entwickelt werden soll.

 

[TheDarkRose]

Hmm, neuere Applicationserver unterstüzen ja schon OSGI. Wäre das vielleicht ein anhaltspunkt auf OSGI aufbauen? Es wird zwar dann nicht mehr zur Laufzeit kompiliert, aber man kann OSGi-Bundles zur Laufzeit sehr leicht austauschen.

 

[fastjack]

OSGI war dem Management zu komplex, deshalb sollen die alles selber programmieren (bis auf EJB-Container und JPA).

[edit]
Noch ein Nachtrag. Die ganze EJB-Anwendung soll hostbar sein. Das heißt andere Firmen können einen jBoss hosten und diese EJB-Anwendung dann anbieten. Das wird dann aber wieder mit den Plugins problematisch, wie kann man die dann ändern? Da sollen sich die Entwickler etwas einfallen lassen, war der Grundtenor.
[/edit]

 

[maki]

Was haltet Ihr davon?

Die blödesten Ideen kommen aus dem Management

Was du da beschreibst ist um viel komplexer als normale JEE Anwendungen und als OSGi, und selbst die sind den Kunden oft schon zu kompliziert (und vielen Entwicklern auch ).

Selbst bie OSGi/RCP, dem ausgereiftesten Plugin Framework für Java, wechselt/installiert man die Plugins nicht einfach so zur Laufzeit, Eclipse empfiehlt jedesmal einen neustart, nicht ohne Grund.
Man stelle sich Objekt A (auf dem Heap, zur Laufzeit also) aus dem Plugin P vor, das plötzlich zur Laufzeit auf eine neue Version angehoben werden soll, weil Plugin P geupdatet wurde...

 

[MrWhite]

Mit so einem System schießt ihr euch ganz sicher in den Fuß. Alles dynamisch und konfigurabel, jaja, das hätten alle gerne. Alle solche Systeme von denen ich gehört habe, haben versagt. Die waren zu komplex, kaum wartbar und für die Kunden zu kompliziert.

Warum wirfst du Ihnen nicht gleich sowas wie Visual Studio Lightspeed vor die Füße? Das ist dann so ein End-User Programming wie sie es haben möchten. Wird Ihnen dann aber schnell zu komplex und dann werden sie wieder richtige Programmierer anheuern, anstatt selbst irgendwelche Konfigurationsversuche zu starten.

 

[Wildcard]

Selbst bie OSGi/RCP, dem ausgereiftesten Plugin Framework für Java, wechselt/installiert man die Plugins nicht einfach so zur Laufzeit, Eclipse empfiehlt jedesmal einen neustart, nicht ohne Grund.
Man stelle sich Objekt A (auf dem Heap, zur Laufzeit also) aus dem Plugin P vor, das plötzlich zur Laufzeit auf eine neue Version angehoben werden soll, weil Plugin P geupdatet wurde...

Also bei OSGi Frameworks macht man das prinzipiell schon, allerdings muss der Code darauf vorbereitet sein. Das es bei Eclipse nicht so ohne weiteres geht liegt an der Extension Registry, ein Relikt aus der Prä-OSGi Zeit von Eclipse.

Mit so einem System schießt ihr euch ganz sicher in den Fuß. Alles dynamisch und konfigurabel, jaja, das hätten alle gerne. Alle solche Systeme von denen ich gehört habe, haben versagt. Die waren zu komplex, kaum wartbar und für die Kunden zu kompliziert.

Also das OSGi versagt hat kann man nun wirklich nicht sagen.

 

[MrWhite]

Also bei OSGi Frameworks macht man das prinzipiell schon, allerdings muss der Code darauf vorbereitet sein. Das es bei Eclipse nicht so ohne weiteres geht liegt an der Extension Registry, ein Relikt aus der Prä-OSGi Zeit von Eclipse.


Also das OSGi versagt hat kann man nun wirklich nicht sagen.

Ich meinte weniger die komponentenorientierte Architektur als mehr den Wunsch, alles dynamisch und konfigurabel zu halten. Der OP redet von "eigenen, dynamischen und vom Kunden selbst definierten Datenstrutkuren", "dynamischen GUIs" und "keinen fest definierten Workflows mehr". Dafür brauchts dann wahrscheinlich ein Heer von Supportern und damit wird man nur so lange einen Reibach machen, bis die Kunden merken, dass andere, fest-verdrahtete Lösungen meist besser sind und weniger Probleme verursachen.

Ich kenne einige Softwares die das versucht haben und die wurden von großen, wohlhabenden Kunden allesamt ersetzt (die sich durchaus auch guten Support hätten leisten können), durch Lösungen die fester verdrahtet sind, aber dafür problemlos funktionieren.

 

[...ButAlive]

Machen kann man sowas schon, wenn man Google, IBM, Microsoft, Oracle oder SAP heißt. Die Frage die ich mir bei sowas immer stelle, ist was war denn das ursprüngliche Problem, das man damit lösen will?

Ich hab leider auch schon mal erlebt, dass man eine eigene Technologie entwickeln wollte und habe auch schon von anderen Firmen gehört, die das gemacht haben. Es ging eigentlich immer gleich aus, irgendwann wurde die Reißleine gezogen, weil die Kosten aus dem Ruder gelaufen sind. Entweder bekam man noch rechtzeitig die Kurve und war erstmal mit "aufräumen" beschäftigt oder die Firma ging daran kaputt. Ich würde sowas also nicht machen.

Falls du noch mehr Argumente dagegen brauchst:

1. Die Einarbeitungszeit für neue Mitarbeiter verhältnismäßig groß. Das heißt bis jemand produktiv arbeiten kann, vergeht viel Zeit und damit entstehen Kosten.

2. Man kann sich nicht mal schnell einen Freelancer vom Markt holen, wenn ein Termin umbedingt gehalten werden muss. Damit nimmt man sich viel Flexibilität.

3. Es geht viel Zeit für Dokumentation und Schulungsunterlagen drauf. Es geht ja nicht, schnell mal bei Amazon ein Buch darüber zu bestellen oder sich von einem externen Schulungshaus schulen zu lassen. Unter dem Strich wird es wesentlich weniger kosten euch eine Schulung über OSGI zu gönnen, als Schulungsunterlagen selbst zu entwickeln.

4. Wenn ihr nicht ganz allein einen Nischenmarkt besetzt und somit Kongurenz habt, werden eure Kunden die Angebote vergleichen. Normalerweiße spielt bei so einer Bewertung auch folgende Punkte eine Rolle:

- Stabilität
- Dokumentation
- Schulungsaufwand
- Sicherheit
- Performance

Da seh ich bei so einem Konzept euch deutlich im Nachteil gegenüber einer anderen Firma, die komplett auf Standards setzt.

5. Falls ihr ein Multimandantensystem hab auf dem mehrere Kunden sich einen Applicationserver teilen, wie würde man sicher stellen, wenn Kunde A einen Fehler in einem Plugin hat, dass Kunde B trotzdem noch weiter arbeiten kann? Sowas kann mit Regressansprüchen schnell teuer werden.

Ich befürchte aber auch wenn solche Argumente auf deiner Seite sind, werden die dir nicht viel Weiter helfen. Das Problem ist, dass Manager etwas anders ticken als Techniker. Wenn ich lese, das es durchgeboxt werden soll, dann vermute ich mal, dass ein Manager sich ein bisschen zu weit aus dem Fenster gelehnt hat und jetzt sein Gesicht wahren muss. Das einzige was jetzt noch hilft, ist ihm einen Weg zu geben sein Gesicht zu wahren.

Nimm den Vorschlag erst einmal ernst und biete an einen "Proof of concept" zu erstellen um das weitere Vorgehen zu besprechen. Anhand diesem hat man dann eine Diskussionsgrundlage. Was immer bei zieht Managern ist "ZDF" (Zahlen, Daten, Fakten). Führe Performace-Messungen durch, lasse dir Metriken berechnen, zähle "Lines of Code" die man für ein Plugin braucht und stelle dem gegenüber wie viel Code man mit einem Standard gebraucht hätte. Drehe die Zahlen so das sie gut zu deinen Argumenten passen. Es ist vollkommend egal ob dein Gegenüber die Zahlen versteht oder wie hoch die Aussagekraft ist, Manager mögen Zahlen und wer solche Ideen durchboxen will, dessen technisches Verständnis ist vermütlich nicht sehr hoch.

Was du jetzt noch brauchst ist ein Gegenvorschlag, dieser wird höchst wahrscheinlich dankend angenommen. Der Manager kann sich vor seine Kollegen stellen und sagen: "Nach reichlicher Überprüfung des Konzeptes, haben wir einen noch besseren Weg gefunden". Die Techniker können mit Standards arbeiten und alle sind glücklich.

Ganz so einfach wird es wahrscheinlich nicht, aber im Grunde ist, dass der Weg den man gehen muss. Das Wichtigste dabei ist wirklich den Vorschlag ernst zu nehmen und sich so das Vertrauen zu verdienen. Ich spreche dabei aus Erfahrung.

hoffe ich konnte dir damit ein bisschen helfen

...ButAlive