Make-loses Java mit der z2-Environment
Seite 3: Systemzentrisch
Systemzentrisches Modell
Den mit z2 verfolgten Entwicklungs- und Lifecycle-Management-Ansatz bezeichnet man auch als systemzentrisch. Und tatsächlich: Statt scheinbar unabhängige Module zu entwickeln, die zu Anwendungen verbaut werden, ist in z2 durch die benutzte Codeline (praktisch eine Subversion-URL) immer der komplette Systemzusammenhang hergestellt.
Um Änderungen von System zu System zu propagieren, gleicht z2 Repository-Inhalte, also auch Quellcode, ab – man spricht hier von einem Transport von Modifikationen. Ein rudimentäres Tool stellt der Hersteller dazu bereit. Die Codeline definiert eine Version der gesamten Lösung – ganz nach dem Motto "The Source is the System". Prinzipiell ist alles in der Codeline dem System bekannt und lässt sich – falls nötig – anfragen und ausführen sowie – wichtig – modifizieren und reparieren.
Hierin unterscheidet sich z2 wesentlich von populären Build-Tools wie Apache Maven und darauf aufbauenden Continuous-Integration-Ansätzen. Ein ausführlicher Vergleich geht über die Vorstellung von z2 hinaus, eine Positionierung zu Ant und Maven lässt sich aber auf den Webseiten der z2-Environment nachlesen.
Außer mit dem Make einzelner Projekte beschäftigt sich Maven mit der Versionierung und Freigabe binärer Build-Ergebnisse solcher Projekte sowie der Verwaltung ihrer Abhängigkeiten. Das ist sinnvoll und wichtig, wenn eine Community viele, eher unabhängig verwaltete Projekte wiederverwendet. Werden aber komplette Systeme erstellt und gewartet, sind eine geschlossen versionierte Klammer um alle beteiligten Module und die Möglichkeit, beliebige Teile des Systems unabhängig als Teil des Systems zu modifizieren, unabdingbar. Hier trifft der systemzentrische Ansatz auf das Product Line Engineering.
Anatomisches
Damit die z2-Environment versteht, wie sich Änderungen auswirken, muss sie verstehen, welche "Komponenten" es gibt und wo diese definiert sind. Insbesondere muss sie die Quellverwaltung (bisher wird nur Subversion unterstützt, Git ist in Planung) und für den Entwicklungsfall auch den Entwicklungs-Workspace kennen und analysieren können. In diesen Ablagen erwartet z2 eine Struktur, die die Komponenten des Systems definiert.
Bei den z2-Komponenten handelt es sich um konzeptionelle Elemente, die einen eigenständigen Lebenszyklus haben oder die aus Gründen der Wiederverwendung alleinstehend sind. Beispiele dafür sind, von grob nach klein, Worker-Prozesse, Java-Module, Webanwendungen oder Datenbank-Verbindungskonfigurationen, aber auch Applikationskomponenten wie eine Spring Bean, die einem anderen Modul zur Verfügung gestellt werden soll. Der anfangs beschriebene Synchronisationsmechanismus mit Änderungen von Code oder Konfiguration ist mit der Verwaltung des Komponentenlebenszyklus implementiert.
Das z2-Komponentenmodell ist erweiterbar, und es ist möglich, neue Komponententypen zu definieren. Zur Laufzeit bildet es angefragte Komponenten in sogenannte Ressourcen ab, die die Semantik der Komponente implementieren, also zum Beispiel dem Web-Container eine Webanwendung sowie die impliziten oder expliziten Abhängigkeiten zu anderen Ressourcen dem Laufzeitsystem vorzustellen. Eine Webanwendung ist zum Beispiel abhängig von ihrem Java-Modul, das den Implementierungscode enthält. Als Konsequenz zieht eine Invalidierung des Java-Moduls auch eine Invalidierung, das heißt einen Stopp der Webanwendung nach sich.
Das Komponentenmodell ist auch die Grundlage für die Modularisierung von Applikationen: Mehrfach zu verwendender Java-Code wird in Java-Modulen abgelegt, die ein oder mehrere andere Java-Module referenzieren. Applikationskomponenten lassen sich exponieren und wiederverwenden: Mit der Erweiterung zur Nutzung des Spring Framework können Entwickler zum Beispiel Spring Beans aus dem Spring Application Context eines Moduls in einem Application Context eines anderen Moduls einbinden.
Infrastrukturkomponenten wie der integrierte Jetty-Web-Container sind als Komponenten integriert. Damit fungiert die z2-Environment als Plattform für Infrastrukturkomponenten, die zusammen einen Applikationsserver bilden. Leider scheint es aber daher nicht einfach zu sein, die beschriebenen Qualitäten bei einer losen Integration mit bekannten Applikationsservern wie JBoss oder mit kommerziellen Alternativen zu erhalten.
