Die Versionslogik

Die Versionierung von Modulen oder Komponenten, die erst zur Laufzeit zu einer konkreten Anwendung zusammengestellt werden, ist die Basis für eine evolutionäre Entwicklung, die monolitische Bauprinzipien durch kontinuierliche Verbesserung und skalierendes, funktionales Wachstum ersetzt.

Was aber genau ist eine Modulversion? und wie trägt das Konzept “Version” zur Systemevolution bei?

Die Versionslogik der Enterprise Apps lehnt sich eng an gängige Semantiken (z.B. OSGi oder RPM) an, besitzt aber aufgrund des ISA Modulkonzeptes auch Besonderheiten.

Ein wichtiges Merkmal des ISA Modulkonzeptes ist, dass NUR Module die eindeutigen Bausteine eines Systems bilden und damit auch nur Module der Versionierung bzw. der Versionslogik unterliegen (s.a. Unterschied zu OSGi).

Ein konkretes ISA Modul ist dabei eine Datei mit einem eindeutig identifizierenden Namen, der aus einem feststehenden, inhaltlichen Namensteil und einer veränderbaren Version besteht.

  • com.my.ModuleFoo-1.0.1.DEV-SNAPSHOT.jar

Der inhaltliche Namensteil folgt wie üblich der Java Klassennomenklatur und die Version der ebenso üblichen Variante mit drei Versionsnummern und einem Qualifier – also [major].[minor].[revision].[qualifier] – wobei der Qualifier keine kanonische Version darstellt, sondern nur als zusätzliche Info dient.

Durch diese Art der Benennung kann es von einem Modul (z.B. com.my.ModuleFoo) N eindeutige “Varianten bzw. Versionen” nebeneinander geben, die die Veränderung bzw. Evolution des Moduls über die Zeit wiederspiegeln und repräsentieren.
gestern – - – - – - – - – - – heute – - – - – - – - – - – - – morgen – - – - – - – ->

Variante 1: com.my.ModuleFoo-1.0.0

Variante 2: com.my.ModuleFoo-1.0.5

Variante 3: com.my.ModuleFoo-1.7.0

Variante 4: com.my.ModuleFoo-2.0.0

Um diese Art der Bezeichnung bzw. Identifikation “maschinell” oder regelbasiert nutzen zu können – muss die Versions-Nummer eine klar definierte Aussage über die Verwendbarkeit des Moduls treffen – und ein Nutzer muss ebenso klar definieren welche Version(en) für ihn zur Verwendung geeignet sind.

Das erfolgt in ISA wie häufig üblich durch Metainformationen in Form von Manifesteinträgen z.B.

  • PlugIn-Imports: com.my.ModuleBar[version=1.0.0] – genau 1ne Version erlaubt
  • oder PlugIn-Imports: com.my.ModuleBar[version=1.0.*] – alle “revision” Versionen erlaubt
  • oder PlugIn-Imports: com.my.ModuleBar[version=1.0.0>2.0.0] – Versionen: von > bis erlaubt
  • generell wird von den “erlaubten” Versionen immer die “höchste” aktuell verfügbare gewählt

Auf diese Weise werden Module nicht nur technisch zur Laufzeit austauschbar bzw. kombinierbar – sondern sie bieten nun auch die Möglichkeit klare Kompatibilitätsgrenzen zu definieren, die bei der Entwicklung eingehalten werden müssen. ISA definiert diese Grenzen wie folgt:

  • .[revision] – oder auch das “Patchlevel” definiert eine, zur Vorversion vollständig kompatible Veränderung des Moduls zur Fehlerbehebung – ohne eine funktionale Veränderung.
  • .[minor]. – die Minornummer definiert eine interne, funktionale Veränderung, die KEINE Auswirkungen bzw. Inkompatibilitäten auf nutzende Module hat.
  • [major]. – die Majornummer definiert eine funktionale oder die API des Moduls betreffende Veränderung, die Auswirkungen auf nutzende Module hat.

Diese Logik ist ganz bewusst einfach gehalten. ISA will mit diesem Verfahren KEINE neue Paketverwaltung (wie z.B. RPM oder P2) realisieren – sondern nur einen konzeptionellen Rahmen für den Austausch und die Verwendung von Modulen und Komponenten in Geschäftsanwendungen schaffen.

Für Geschäftsanwendungen ist dabei entscheidend:

  • ein einfaches, stabiles Continuous Development und Delivery
  • Minimierung der Downtime bei Updates und Releaswechseln (Zero Downtime)
  • sichere, unkomplizierte und schnelle Reaktionsfähigkeit bei Fehlern

ISA geht davon aus, dass die Definition bzw. die konkrete Realisierung von Modul- und Komponenten-Kompatibilitäten in Geschäftsanwendungen eine fachlich getriebene Aufgabenstellung ist, die über einen rein formalen oder technischen Zusammenhang hinaus geht.

Aus diesem Grund löst ISA nur den technischen Teil von modularer Austauschbarkeit im Rahmen des oben beschriebenen allgemein gültigen Konzeptes – und belässt die konkrete Nutzung und Auslegung von Kompatibilitätsgrenzen im Verantwortungsbereich einer konkreten Entwicklung.

____________________________
1: Bekannte Paketverwaltungen (wie z.B. RPM, P2) haben zum Ziel, ein beliebig tiefes bzw. komplexes Netz von Abhängigkeiten zwischen beliebigen Softwarebausteinen algorithmisch optimal aufzulösen. Dabei geht es in erster Linie um eine technische Kompatibilität in einer vereteilten Welt unterschiedlicher, autarker Hersteller und Anbieter für gemeinsame Plattformen (z.B. Unix Systeme oder Eclipse). Konkrete Bewegungsdaten und Nutzerfunktionen spielen dabei eine eher untergeordnete Rolle da diese i.d.R. von den Kontributoren selbst definiert werden.

Bei individuellen, betrieblichen Softwaresystemen ist das zumeist umgekehrt – hier drücken Versionen in erster Linie konkrete fachliche Funktionalitäten und Datenstrukturen aus, die von einem “Hersteller” für einen spezifischen Nutzer bzw. dessen konkrete Anforderungen erstellt werden. Die rein technische Kompatibilität ist hier zwar auch notwendig – aber i.d.R. kein Problem – weil der “Hersteller” die volle Kontrolle über die Plattform bzw. das System hat und es nicht beliebig viele Kontributoren gibt.

Z.B. muss ein Hersteller eines PlugIn’s für Eclipse, das z.B. eine Eclipse-View für einen Application-Server bietet, nur darauf achten, den technischen Eclipse-Anforderungen gerecht zu werden. Welche Funktionalitäten er jedoch anbietet und wie er diese intern realisiert ist allein sein Verantwortungsbereich.

Das ist bei einem fachlichen Modul für ein individuelles, betriebliches Anwendungssystem wie z.B. einer Stammdatenschnittstelle vollkommen anders. Hier ist Version, Kompatibilität und Funktionstüchtigkeit nicht nur eine Frage der rein technischen API – sondern vielmehr eine Frage der inhaltlichen Verständigung und Vereinbarung zwischen Nutzer und Anbieter. Eine Modulversion ist damit der “identifizierende Ausdruck” einer solchen Vereinbarung.