In vorhergehenden Artikeln (hier und da) bin ich auf Maven als technisches Hilfsmittel für die Dokumenten-Erstellung via XML eingegangen. Maven basiert auf Java, und da gab es jüngst etwas unschöne Streitigkeiten über die Open Source-Natur von Java. Machtfragen, die eigene Investitionsplanungen berühren können. Wer möchte schon von Herstellern in die eine Ecke treiben lassen, wo man ihnen alternativlos ausgeliefert ist, weil man seine Infrastruktur auf gewissen Technologien/Bausteinen gegründet hat? Das machen meist nur Menschen, die mit anderer Leute Geld arbeiten. Machen wir uns also auf mühsame Suche nach Alternativen.
Den Maven-Ansatz fand ich gut, da es damit möglich ist, automatisiert Software-Komponenten auf einen Rechner zu laden und diese dort in einem vordefinierten Arbeitsablauf ausführen zu lassen. Möchte ich also beispielsweise ein Buch im PDF-Format aus einem DocBook-Dokument erstellen, definiere ich einen Arbeitsablauf aus Saxon für die XSL-Transoformation, den DocBook-XSL-Stylesheets und FOP oder RenderX für die PDF-Erstellung. Maven würde dann die benötigten Komponenten aus den angegeben Repositorien laden und sie ausführen.
Aus dem Stegreif fallen mir da drei Möglichkeiten ein, Maven mehr oder weniger zu ersetzen:
- Linux-artige Repositorien (APT, YaST, …)
- das AppStore-Konzept
- Virtuelle Maschinen
Im Bereich Linux, Unix und verwandte Plattformen (OSX) gibt es schon seit langem Code-Repositorien, über die man strukturiert Anwendungen auf einen Rechner laden und dort managen kann — Installation, Update, Löschung. Bekannte Beispiele sind sind APT (Debian/Ubuntu) oder YaST (openSUSE). Das Paketierungsformat der verschiedenen Mechanismen unterscheidet sich natürlich, aber das grundsätzliche Vorgehen ist gleich. Über die eingestellten Repositorien kann man die benötigten Komponente auf einen Rechner laden, die Software erledigt die Ermittlung und das Nach-Installieren von Abhängigkeiten. Je nach Distribution nutzt man bei der Installation vorkompilierte Binärkomponenten oder Quellcode, der erst auf dem Zielrechner übersetzt wird. Für diesen Ansatz würde sprechen, dass er wohlverstanden ist und Anwendungen in vielerlei Programmiersprachen berücksichtigt. Nachteilig wäre, dass der eigentliche Arbeitsablauf der Dokumentenerstellung damit nicht direkt abgedeckt werden kann. Der würde wohl als Skript-Komponente irgendwie integriert werden müssen.
Die zweite Möglichkeit, das AppStore-Konzept, das in jüngster Zeit von Apple propagiert wurde und sich im Smartphone-Bereich schon verbreitet hat, ist technisch gesehen einfach eine Variante des ersten Punktes. Hinter einem AppStore steht auch nur ein Binär-Repositorium, über das Anwendungen auf einen Rechner geladen und dort verwaltet werden können. Man sieht eben, wie z.B. im Falle des iPhones, nicht viel vom Installationsprozess, und dieser geht wegen der begrenzten Hardware-Auswahl, die zu bedienen ist, auch meist glatt vonstatten. Die große Neuerung des AppStore-Konzepts war aus meiner Sicht, dass hier zum ersten Mal im
großen Stil Komponenten über Repositorien verkauft und gemanagt wurden, statt sie wie in der Windows-Welt üblich, eigenhändig installieren zu müssen. Je nachdem wie sich das Konzept in Zukunft auf andere Rechnerwelten übertragen lässt, könnte daraus mal die Möglichkeit entstehen, Produktions-Komponenten oder ganze Prozessketten zu kaufen, zu mieten und standardisiert auf den jeweiligen Rechnern zu betreiben. Also gewissermaßen ein zweiter Weg neben den Web-Anwendungen. Aber das ist Zukunftsmusik.
Bei der dritten der oben angeführten Maven-Alternativen handelt es sich um einen grobkörnigen Ansatz. Virtuelle Maschinen, mit oder ohne Verbindung zu den großen Rechnerwolken, bieten einfach die Möglichkeit eine bestimmte Software-Konfiguration einigermaßen hardware-unabhängig zu betreiben. Im Klartext: habe ich einmal einen Rechner soweit bekommen, dass alle Komponenten, Prozesse so funktionieren, wie ich es mag, kann ich dieses Sammelsurium aus Betriebssystem, Anwendungen und Konfigurationsdateien einfrieren und auf beliebig vielen anderen Rechnern ausführen lassen. Die Virtualisierungs-Software (zum Beispiel XEN oder VMware) sorgt dafür, dass meine Software eine Hardware-Konfiguration vorgespiegelt bekommt, mit der sie klarkommt.
Virtuelle Maschinen können, wie andere Software auch, abgelegt, transferiert und zur Produktion installiert werden, sie sind nur nicht ganz so handlich. Eine solche Maschine kann die Produktionskomponenten und die Arbeitsabläufe enthalten. Im Vergleich mit dem Maven-Ansatz wären virtuelle Maschinen aber im Augenblick noch eine schwergewichtige, grobkörnige Lösung. Da die Virtualisierungs-Anbieter aber dabei sind, ihre Lösungen selbst auf Smartphones zu übertragen, könnte sich das schnell ändern.
Auch bei diesem Ansatz würde der Arbeitsablauf als Skript oder Anwendung in das jeweilige virtuelle Maschine fest integriert werden müssen. Andererseits wäre die Maschine sehr langlebig. Wie langlebig — gemessen an IT-Zyklen — das sein kann, zeigen die beliebten Emulatoren für alte Rechner wie Atari, C64, Apple 2. Da die Rechner noch immer leistungsfähiger werden, ist die Wahrscheinlichkeit groß, dass eine einmal erstellte virtuelle Maschine trotz unterschiedlicher Hardware lange immer wieder eingesetzt werden kann, da sie ja außer dem Hypervisor der Virtualisierungs-Software keine Ahängigkeiten mehr hat. Problematisch können natürlich Hard- oder Software-Schnittstellen nach außen werden. Aber das ist ein anderes Problem.