Projekt Cloud Seven

Hi,
ich habe in den vergangenen Monaten ein Werkzeug (Framework und SOAP Service) für die Softwarekonfiguration entwickelt und würde dies gerne hier vorstellen.

Es wird eine freie bzw. und eine kostenpflichtige Lizenz geben. Da ich mir nicht sicher bin, ob das von Euch als Werbung empfunden wird und ich das Forum nicht missbrauchen will, erst mal die Frage, ob solche Informationen ebenfalls willkommen sind.

Grundsätzlich denke ich, dass es für den einen oder anderen interessant sein könnte, der ein (Java-)Projekt plant, aber dennoch…

Also, mehr dazu oder nicht? :slight_smile:

Dirk

Ich gehör jetzt nicht zum Foren-Olymp, aber ich denke solange es keine explizite Werbung im Sinne von “Heiße Ware! Kaufen!” ist, sollte eine normale Vorstellung deiner Software in Ordnung sein.

Würde ich jetzt auch mal so unterschreiben

„Allgemeines zu Projekten / Generals - Hier könnt ihr eure Projekte vorstellen und nach Mitarbeitern fragen.“

was kann man mehr vorher sagen, ohne Info nicht zu entscheiden,
außer vielleicht ‚kostenpflichtige Lizenz‘ als zu bewertendes Kriterium…

poste doch den Thread, schreibe da evtl. auch relativierendes rein ‚soll keine Werbung sein‘, schreibe PN an irgendwen
(jetzt weniger, allgemein nicht ganz so aufwendig wie (man stelle sich vor von jedem :wink: ) ein extra Thread vor dem Thread)

Stells einfach vor, meckern können wir dann immer noch :wink:

[QUOTE=SlaterB]„Allgemeines zu Projekten / Generals - Hier könnt ihr eure Projekte vorstellen und nach Mitarbeitern fragen.“

(jetzt weniger, allgemein nicht ganz so aufwendig wie (man stelle sich vor von jedem :wink: ) ein extra Thread vor dem Thread)[/QUOTE]

Wohl wahr, habe ich nicht dran gedacht :slight_smile:

Dann zäume ich das Pferd mal von hinten auf, schildere zunächst die Ausgangssituation und stelle anschließend die Lösung vor.

Das große Thema ist Softwarekonfiguration, also Anpassung einer Anwendung an variable (Kunden-)Anforderungen.
Üblicherweise löst man das über Key/Value Paare in Konfigurationsdateien beliebiger Art (Properties Files, XML, …). Kennt jeder.

Was aber, wenn die Anwendung auf mehreren Rechnern parallel installiert wird (Stichworte Ausfallsicherheit und Skalierbarkeit)?
Die Konfigurationsdateien müssen kopiert werden. Abhängig vom Zielsystem gibt es allerdings bei einigen Parametern möglicherweise Abweichungen, wie z.B. bei Pfadangaben, IP-Adressen. Dann wird’s unpraktisch.
Was sich den meisten von uns als Lapalie darstellt, kann in großen Unternehmen zu scheinbar unüberwindbaren Hindernissen werden. Die Administration von IT ist oft ein ungeheurer Verwaltungsakt mit Zuständigkeitgerangel, Sicherheitsfragen, u.s.w. Mal eben eine Datei irgendwo ablegen oder ändern, herrje! geht ja mal gar nicht :smiley: Das kann so weit gehen, dass Administratoren in Abhängigkeit von ihren Rechten nicht mal auf die System-Shell dürfen :stumm:

Mein Werkzeug (ich komme zum Punkt) ermöglicht eine zentrale Konfiguration, wahlweise als Java-API oder als SOAP-Service.
Basierend auf einer Datenbank wird ebenfalls nach dem Key/Value-Prinzip verfahren, allerdings mit einigen zusätzlichen Features, die für komplexere Anwendungen bzw. Umgebungen interessant sind. Aktuell werden Derby, MySQL, und Oracle unterstützt, PostgreSQL ist in Bearbeitung. Derby ist für diese Zwecke natürlich klasse, weil es ohne viel Zutun eine Nutzung ‚out of the box‘ ermöglicht.

Ausgehend von den Erfahrungen mit unserer eigenen Standardsoftware (Job) gibt es einige Features, die ich hier mal unvollständig aufzähle:
[ul]
[li]Automatismus für identische Keys mit abweichenden Werten in Abhängigkeit vom Rechner, auf dem installiert ist.
[/li][li]Mechanismus für die Abhängigkeit der Werte von Mandanten
[/li][li]Zwei verschiedene ‚intelligente‘ Cachingvarianten der Konfiguration
[/li][li]Nicht persistente Parameter, die also nur zur Laufzeit existieren
[/li][li]Unterstützung von Namespaces, also zusammengesetzte Keys (z.B. keyA.keyB.keyC u.s.w.)
[/li][li]Vater-Kind-Beziehung zwischen Parametern (Parent-Eigenschaft) ermöglicht Abhängigkeitsstrukturen
[/li][li]…
[/li][/ul]
In Bearbeitung sind noch die Verschlüsselung von Werten und einige andere Dinge, u.a. ein Mechanismen für die Versionierung von Parametern und die Unterstützung von JMS.

Mit der Umsetzung der SOAP-Schnittstelle entstand beinahe zwangsläufig die Integration einer Benutzerverwaltung, die ebenfalls über die API und SOAP angesprochen werden kann. Übrigens bedarf es Dank Java 7 keines zusätzlichen Webservers, der ist bereits ‚unter der Haube‘.
Ebenso integraler Bestandteil ist ein Editor, mit dem sich die Konfiguration auf der Konsole bearbeiten lässt.

Interessant ist an dieser Stelle vielleicht noch die Tatsache, dass ich auf weitere Frameworks verzichtet habe. So gibt es keine unnötigen Abhängigkeiten und die Bibliothek ist in Anbetracht des Umfangs relativ klein (rd. 500kb).
Außerdem war mir wichtig, dass möglichst wenig Java-Code notwendig ist, um die API zu nutzen. Auf meiner Webseite ist dazu ein kleines Anwendungs-Beispiel (http://c7.dirk-goldbach.de/code-beispiel/).

Was mich sehr verwundert, ist die Tatsache, dass ich bislang nichts Vergleichbares für eine zentrale Softwarekonfiguration gefunden habe.
Ebenso erstaunlich, dass auch freiberufliche Entwickler, die seit vielen Jahren im Geschäft sind, die - nach meiner Wahrnehmung - offensichtliche Problematik einer Konfiguration in verteilten Umgebungen nicht kennen und meinem Projekt mit Unverständnis begegnen.
Vielleicht ist es auch so, dass zwar die Anwender Bauchschmerzen damit haben, aber diese von denjenigen, die Software spezifizieren, nicht gehört werden.

Mich interessiert brennend, ob Ihr schon mal vor einer vergleichbaren Aufgabe standet oder steht. Oder ist dieses Thema eigentlich gar keines, weil es andere, viel elegantere Ansätze gibt?

Hier noch der Link zur Startseite des Projekts: http://c7.dirk-goldbach.de

Klingt ganz interessant, muss ich mir bei Gelegenheit mal genauer ansehen.

kommt mir bekannt vor - ist total geil bei einer kleinen Detailänderung zu jedem Arbeitsplatz zu rennen um die Konfig einzuspielen

an Versionierung hatte ich noch gar nicht gedacht, aber zumindest an ein zentrales Tool um die Konfiguration zu verteilen, ggf. auch Softwareupdates

Prinzipiell ist eine zentrale Verwaltung ganz praktisch - Du solltest aber auch über andere Sprachen nachdenken.

hand, mogel

[QUOTE=mogel]kommt mir bekannt vor - ist total geil bei einer kleinen Detailänderung zu jedem Arbeitsplatz zu rennen um die Konfig einzuspielen

an Versionierung hatte ich noch gar nicht gedacht, aber zumindest an ein zentrales Tool um die Konfiguration zu verteilen, ggf. auch Softwareupdates

Prinzipiell ist eine zentrale Verwaltung ganz praktisch - Du solltest aber auch über andere Sprachen nachdenken.

hand, mogel[/QUOTE]

Schön, dass es Foren gibt :slight_smile:

Da ich seit rd. 8 Jahren ausschließlich an einer Web-Anwendung arbeite, habe ich die Clients ganz aus den Augen verloren. So betriebsblind kann man werden. Danke für Hinweis, mogel!

Zum Einwand, dass ich andere Sprachen unterstützen soll, kann ich sagen, dass ich dafür den SOAP Server und die JMS-Schnittstelle vorgesehen hatte. Da das offensichtlich nicht offensichtlich ist, gibt es jetzt auf der Webseite die Seite ‚Anwendungsbeispiele‘. Außerdem habe ich das als Anregung für eine FAQ-Seite genommen.

Hmm, gibts auch REST?

Hmm, warum nicht SOAP? :o)

Anfangs habe ich tatsächlich über REST nachgedacht, diesen Gedanken aber schnell wieder fallen lassen, da mir persönlich SOAP geläufiger ist. In REST müsste ich mich zunächst tiefer einarbeiten.

Ist die Implementierung eines REST Clients aus Deiner Sicht einfacher bzw. schneller? Unterm Strich sind ja beide Ansätze ähnlich, die Performance vergleichbar.

Grundsätzlich spricht natürlich nichts gegen eine REST Implementierung. Das mache ich vom Interesse potentieller Anwender abhängig.

Ach ja, falls Ihr zielführende Kritik an der Dokumentation oder der Software habt (ist ja noch in der Beta): ich bin offen für hilfreiche Kommentare.

[QUOTE=dirk-germany]Mich interessiert brennend, ob Ihr schon mal vor einer vergleichbaren Aufgabe standet oder steht. Oder ist dieses Thema eigentlich gar keines, weil es andere, viel elegantere Ansätze gibt?
[/QUOTE]
Meistens verwendet man ein ConfigManagement Tool wie Puppet oder Chef um Maschinen automatisch konfigurieren und SW zu deployen etc. pp., speziell im Cluster/Cloud Umfeld.

http://puppetlabs.com/

Hier noch ein obligatorischer Link zu einem Fowler Artikel:

[QUOTE=maki]Meistens verwendet man ein ConfigManagement Tool wie Puppet oder Chef um Maschinen automatisch konfigurieren und SW zu deployen etc. pp., speziell im Cluster/Cloud Umfeld.

http://puppetlabs.com/

Hier noch ein obligatorischer Link zu einem Fowler Artikel:
http://martinfowler.com/bliki/SnowflakeServer.html[/QUOTE]

Danke, sehr interessant.

Von Puppet hatte ich gehört, aber nicht den direkten Zusammenhang gesehen.
Der Artikel von Fowler gibt ein gutes Gefühl für die Anforderungen und die Möglichkeiten einer Realisierung.

Puppet oder Chef funktionieren nach einem wesentlich weiter gehenden Ansatz, als CLOUD SEVEN (mein Projekt), das ja eher darauf ausgerichtet ist, mit einer bestimmten Software verbandelt zu werden. Stark vereinfacht könnte man sagen, dass diese Systeme da anfangen, wo CLOUD SEVEN aufhört. Andererseits könnte man mein Werkzeug wunderbar nutzen, um eine komplexe Lösung wie Puppet oder Chef darauf basierend zu implementieren.