Das Modulsystem

NextISA versteht ein Modul als eine überschaubar abgegrenzte, fachliche oder technische Funktionalität, die einen eindeutigen, identifizierenden Namen besitzt und die technisch durch eine JAR- oder eine Manifest Datei mit genau diesem Namen repräsentiert wird (s.a. Architektur, InnovationSpezifikation).

Das ist alles – alles weitere ist optional und kann individuell variiert oder angepasst werden.

Mit diesem Verständnis verknüpft ISA einen konzeptionellen (fachlichen) Modulbegriff eins zu eins mit dessen physischer Laufzeitrepräsentation und schafft so ein einheitliches und durchgängig funktional orientiertes  Modulkonzept, das

  • von der Anforderung, Spezifikation und Planung
  • über ein Projekt in der Entwicklung
  • bis hin zum fertigen Softwarebaustein eines Systems in Betrieb und Wartung reicht.

Ein Anwendungssystem ist in diesem Konzept ebenfalls einfach ein eindeutiger, fachlicher Name (z.B. com.my.CRM-System-3.1.0) der N Module funktional zusammenfasst – technisch ist ein System ein Verzeichnis mit dem Systemnamen, das N Moduldateien enthält. (s.a. ISA und OSGi)

Modulkonzept

Module System Concept

Auf diese Weise resultieren Systeme, Module und Dienste direkt aus einer übergeordneten IT Perspektive, die primär von fachlich/funktionalen Anforderungen bestimmt ist. Dabei spielt es zunächst keine Rolle, ob die betrachteten Systeme oder Dienste schon real existieren, selbst modular sind, bereits ISA Module nutzen oder auf einer völlig anderen Architektur oder Technologie aufgebaut sind (s.a. Modul Repository Browser - System: com.my.CRM-System-3.1.0-Demo).

Eindeutige Systeme bestehen aus eindeutigen Modulen – und Module realisieren fachliche oder technische Anforderungen in Form von Funktionalität. Dieses genauso einfache, wie transparente und technologieunabhängige Konzept kann auf nahezu jede Aufgabenstellung angewendet werden – Neuentwicklung, Integration, Services, Migration usw. – und ist gleichzeitig auch für jede Betrachtungsperspektive – Management, Fachlichkeit und Technik – gleichermaßen nutzbringend einsetzbar.

Modultechnik

Das folgende UML Class Diagramm zeigt formal die grundlegenden Komponenten des ISA Modulsystems und ihren prinzipiellen Zusammenhang (Modulmanagement Konzept).

UMLModuleSystemConcept

Das folgende UML State Diagramm zeigt den prinzipiellen Lebenszyklus von ISA Modulen

UMLModuleLifeCycleConcept

Das zentral Element ist das Modul – der identifizierende Modulname folgt standardmäßig der üblichen Java Package.Class Nomenklatur (es ist jedoch jede Art der Benennung möglich – solange sie eindeutig ist), die wie üblich durch eine optionale Versionsnummer (siehe… Enterprise Apps Versionslogik) mit optionalem Qualifier ergänzt wird. Zum Beispiel:

  • com.my.ModuleFoo.jar
  • com.my.ModuleFoo-0.9.1.RC.jar
  • com.my.ModuleBar-1.0.0.mf (Textdatei im Manifestformat)

ISA unterstützt z.Z. zwei Formate von nutzbaren Modulen

  • eine JAR Datei mit Implementierung
  • oder nur eine Definition in Form einer Manifest-Datei

Die Manifestdatei ist wie üblich der Metadatenträger, der das Modul und seine Eigenschaften mit Hilfe von Standard-Manifest-Entries beschreibt. Neben dem obligatorischen PlugIn-Name: und der optionalen PlugIn-Version:  z.B.:

  • eine Liste benötigter Bibliotheken (PlugIn-Libraries:)
  • eine Liste benötigter anderer Module und deren Ressourcen (PlugIn-Imports:)
  • eine Liste der nach außen zur Verfügung gestellten eigenen Ressourcen (PlugIn-Exports:)
  • eine Liste von Eigenschaften (PlugIn-Properties:)

Ein Modul, das nur als Manifestdatei vorliegt ist von seiner konkreten Implementierung entkoppelt und bietet so die Möglichkeit jede Form von Implementierung als Modul in das System einzubinden.

Ein Anwendungsfall ist ein Modulmanifest, das ein oder mehrere Bibliotheken als PlugIn-Libraries: definiert, die in einem beliebigen Unterverzeichnis im Repository liegen können. Auf diese Weise können beliebige, bestehende Bibliotheken als Modul eingebunden bzw. deren Funktionalitäten ohne irgend eine Art von Compelierung oder Paketierung nutzbar gemacht werden.

Der Module Resource Identifier (MRI)
Ein Modul wird technologieneutral durch einen einfachen String (eine Art Uniform Resource Identifier URI) dargestellt, referenziert und definiert. Das Format ist:

  • <Modulname>:<Dienst>[<Property-Name>=<Property-Wert>, ...]

zum Beispiel

  • com.my.ModuleFoo[version=1.0.0]
  • com.my.ModuleFoo:doServiceFoo[version=1.0.0, stateless=true]
  • com.my.XmlSerializer[version=0.9.1, internal=isa.XmlTool]

Optionale Verarbeitungsregeln
Aufbauend auf diesem Modulkonzept realisiert das Modulsystem weiterführende Regeln und Mechanismen, die i.d.R optional sind und die leicht durch individuelle, eigene Verfahren erweitert werden können. Z.B.

  • standardmäßig sucht ISA nach einer Klasse mit dem qualifizierten Modulnamen um eine Modulinstanz zu erzeugen.
  • ein Element mit dem qualifizierten Modulnamen und der Endung IFace wird als Modulinterface betrachtet
  • eine XML Datei mit dem qualifizierten Modulnamen .xml im META-INF Verzeichnis wird als Modulkonfigurationsdatei in Form einer Map betrachtet
  • eine Properties Datei mit dem qualifizierten Modulnamen separiert durch Unterstriche statt Punkten und der Endung [Countrycode].properties im Verzeichnis resources wird als Resource Bundle geladen (z.B. /resources/isa_TestService_de.properties)

Alle diese zusätzlichen Konventionen sind optional. Obligatorisch ist nur die JAR- bzw. Manifest Datei mit dem eindeutigen Modulnamen.

Repository und Systeme
Ein Repository ist in ISA einfach ein Verzeichnis mit Modulen. Für Standalone Systeme wie z.B. eine SmartClient Anwendung entspricht das Repository daher der Anwendungsinstallation.

Bei verteilten, serverbasierten Systemen können verschiedene Anwendungssysteme jeweils als ein einzelnes Unterverzeichnis im Repository-Verzeichnis angelegt werden. Das Repository-Verzeichnis beinhaltet dann die Basis des Modulsystems bzw. Module, die allen Anwendungen zur Verfügung stehen. Wohingegen die einzelnen System-Repositories nur die Module eines einzelnen Systems beinhalten, die auch nur für dieses System zugänglich sind. (s.a. Repository Browser).

AppsForTheEnterpriseRepository

Zusätzlich zu den Modulen können in einem Repository auch beliebige andere Ressourcen wie z.B. individuelle Konfigurationen, Werkzeuge und Hilfsprogramme abgelgt werden.

Entscheident ist jedoch, dass alle Teile aller Anwendungen an einer zentralen und unabhängigen Stelle liegen. Damit sind sie sowohl umgebungs- und plattformunabhängig als auch redundanzfrei sowie zentral nutz- und verwaltbar.

Anwendungen und Server
Server basierte Anwendungen benötigen immer eine oder mehrere Servermaschinen bzw. ein Serversystem, das die Anwendung über das Netzwerk verfügbar macht. Da das ISA Modulsystem vollständig von dieser Middleware entkoppelt ist kann zu diesem Zweck im Prinzip jede Technologie verwendet werden.

Standardmäßig nutzt ISA JEE und/oder Web Server für diese Aufgabe. Die Server-Komponente ist dabei der anwendungsunabhängige ISA ServiceBroker, der die einzige Middleware abhängige Komponente in ISA darstellt.

Grundsätzlich können beliebig viele Repositories angelegt und ebenso beliebig viele ServiceBroker betrieben werden (s.a. Betrieb). Dabei gelten folgende Regeln

  • ein ServiceBroker ist ein JEE Deployment1
  • ein ServiceBroker nutzt/kennt genau ein Repository mit N Systemen
  • ein Repository kann von N ServiceBrokern genutzt werden

_____________________
1: Der Standard ISA ServiceBroker unterstützt alle JEE Kommunikationstechnologien und wird daher und weil ein Repository N Anwendungssysteme beinhalten kann auch nur einmal für einen konkreten Application- oder Web-Server benötigt.

Grundsätzlich könnten jedoch auch mehrere ServiceBroker, jeweils unter einem anderen Namen in einem Server installiert werden und daher auch auf unterschiedliche Repositories zugreifen. Eine solche Struktur entspräche einem klassischen Deployment unterschiedlicher JEE Anwendungen auf einen Server (was jedoch auch bei klassischen JEE Anwendungen eher unüblich ist).