FAQs

ISA steht für - Integrated Service Architecture – und ist der technische Name der Enterprise Apps Technologie (s.a. Dokumente).
(Bekannte Browserprobleme: IE < 9, Opera div. Versionen, Ghostery und andere Blocker).

Was ist das Problem?
Was ist die Lösung?
Was ist die Innovation von Enterprise Apps?
Wem nützt die Enterprise Apps Technologie – und wie?

Was ist ein Modul bzw. ein modulares System im ISA Sinne?
Wie wird aus Dateien (Modulen) in einem Repository eine lauffähige Anwendung?
Ist ISA oder ein darauf aufbauendes System eine JEE Anwendung?
Wie kommunizieren die Module miteinander?
Welche Client Server Kommunikation bzw. Middleware wird unterstützt?

Wie werden Module installiert oder deployed?
Ist das Modulsystem ein eigener Prozess oder eine eigene Laufzeitumgebung?
Muss ein Modul bestimmten technischen ISA Konventionen oder APIs entsprechen?
Wo und wie werden die notwendigen Metainformationen abgelegt?
Wie “groß” ist ein Modul bzw. welche Funktionalitäten können Module bieten?
Wie ist das Nutzungsverhältnis zwischen Repositories, Anwendungssystemen und Servern?
Was ist der Unterschied zwischen ISA und OSGi?
Ist Modularität nicht eher eine Frage und Aufgabe von Standards und Java selbst?

Was ist das Problem?
Das Problem sind Softwaremonolithen, deren Beherrschbarkeit und fachliche/technische Veränderbarkeit mit wachsender Systemgröße überproportional abnimmt. In der Folge wachsen stetig die Aufwände, erhöhen sich die Risiken und häufen sich Fehler. Im Ergebnis steigen die Kosten bei gleichzeitig sinkenden fachlichen Entwicklungsmöglichkeiten.

Was ist die Lösung?
Systeme müssen sich evolutionär und unabhängig von ihrer fachlichen Größe und den genutzten Technologien entwickeln können. Der Schlüssel dazu ist Modularität bzw. das Bausteinprinzip mit seiner Fähigkeit zu beherrschbaren Wachstum und einfacher, gezielter Austauschbarkeit.

Was ist die Innovation von Enterprise Apps?
Die Innovation der Enterprise Apps ist – dass, sie erstmals durchgängige, technologieunabhängige Modularität als Bauprinzip aus einer übergreifenden IT-Perspektive und nicht nur aus einer speziellen Technik-Perspektive realisieren. Enterprise Apps sind eine integrierende und optimierende Lösung für alle Bereiche und Aufgaben von Unternehmensanwendungen – und nicht nur ein technisches Framework, das bestimmte technische Aufgabenstellungen löst.
(… mehr dazu).

Wem nützt die Enterprise Apps Technologie – und wie?
Dem Management – durch transparentere, einfachere und damit sicherere Plan- und Steuerbarkeit
Der Fachlichkeit – durch schnellere, flexiblere und kostengünstigere Umsetzung ihrer Anforderungen
Der Technik – durch gesteigerte Innovationsfähigkeit, höhere Qualität und Zukunftssicherheit
Dem Anwender – durch bedarfsgerechte moderne Systeme nach seinen Bedürfnissen
Dem Unternehmen – das so mehr in marktgerechte Weiterentwicklung – als in teuere Wartung investieren kann
(… mehr dazu)

Was ist ein Modul bzw. ein modulares System im ISA Sinne?
Ein Modul ist ein versionierter, austauschbarer Baustein, der abgegrenzte fachliche oder technische Funktionalität zur Verfügung stellt und der als eindeutige Datei in einem neutralen Repository (Verzeichnis) liegt.

Ein System ist die logische Zusammenfassung mehrerer, kooperierender Module unter einem gemeinsamen Namen, die gemeinsam eine größere Aufgabenstellung realisieren.

Wie wird aus Dateien (Modulen) in einem Repository eine lauffähige Anwendung?
Die Module sind Java Programme (Jar Dateien), die von einer Verwaltung On-Demand zur Laufzeit als modulare Anwendungssysteme oder als Dienste eines Service Brokers zur Verfügung gestellt werden. Als Middleware dient die JEE bzw. Application und/oder Web Server.

Ist ISA oder ein darauf aufbauendes System eine JEE Anwendung?
Nein – nicht im üblichen Sinn. ISA Module sind plattform- und technologieunabhängige Java Module. Nur der ISA Service Broker ist eine JEE Anwendung (.ear) – allerdings eine ohne jede Fachlichkeit. Der Broker muss nie geändert oder angepasst werden – er dient nur als neutrale Middleware für JEE Kommunikation und Dienste (ca. 60 KB). ISA ist JEE ohne JEE.

Wie kommunizieren die Module miteinander?
Einfach wie normale Java Objekte. Ein Modul kann von der Verwaltung über seinen eindeutigen Namen und die optionale Version angefordert werden (manager.getService(name, interface)). Der Aufrufer erhält dabei ein Objekt, das die öffentliche Schnittstelle des Moduls realisiert und dementsprechend genutzt werden kann. Dabei stehen alle vom Modul exportierten Klassen und Datentypen zur Verfügung.

Das Modulobjekt selbst ist immer ein Proxy (Stellvertreter) Objekt, wodurch die technische Entkopplung der Module untereinander gewährleistet ist und es weder für den Anwender noch für den Entwickler einen Unterschied zwischen lokalen und serverseitigen Modulen gibt.

Welche Client Server Kommunikation bzw. Middleware wird unterstützt?
Standardmäßig können Module alle Möglichkeiten eines JEE Application- oder Webservers nutzen (RMI, HTTP, REST, WebService, JMS … etc.). Grundsätzlich ist das ISA System aber nicht darauf beschränkt – sondern kann jede Kommunikation nutzen, für die es z.B. ein Adaptermodul besitzt.

Wie werden Module installiert oder deployed?
Das ISA System benötigt kein Deployment – ein Modul wird lediglich in das gewünschte Repository Verzeichnis kopiert – das ist alles. Die Installation erfolgt automatisch zur Laufzeit.

Ist das Modulsystem ein eigener Prozess oder eine eigene Laufzeitumgebung?
Nein – das ISA Modulsystem benötigt keine eigene Laufzeitumgebung. Es ist passiv und arbeitet nur auf Anfrage. Das ist ein entscheidender Grund dafür, dass das System in jede Umgebung eingebunden werden kann.

Muss ein Modul bestimmten technischen ISA Konventionen oder APIs entsprechen?
Nein – eine normale, standard Jar Datei im Repository ist ein ISA Modul. Darüber hinaus steht es jedem Modul frei ob und welche Informationen und/oder Fähigkeiten des ISA Systems es nutzen will.

Wo und wie werden die notwendigen Metainformationen abgelegt?
Wie üblich einfach als Manifest Attribute – im Minimum mit dem Namen des Moduls. Darüber hinaus können dann optional weitere Informationen wie z.B. Version, Exports, Imports etc. dort abgelegt werden.

Wie “groß” ist ein Modul bzw. welche Funktionalitäten können Module bieten?
Das liegt ganz in der Hand des Moduls bzw. dessen jeweiliger Aufgabenstellung. ISA Module skalieren von einer einzelnen, einfachen Funktion bis zu einer ganzen Anwendung – egal ob fachlicher oder technischer Natur. Dadurch ermöglicht das System auch eine sukzessive Modularisierung bestehender Anwendungen und Umgebungen.

Wie ist das Nutzungsverhältnis zwischen Repositories, Anwendungssystemen und Servern?
Dieses Verhältnis ist je nach Bedarf vollkommen frei gestaltbar bzw. skalierbar. Vom Grundgedanken her kann ein Repository N Systeme beherbergen, die von N Servern bzw. N Server Prozessen zur Verfügung gestellt werden. Gleichzeitig können aber auch N Repositories existieren wodurch letztendlich jede Kombination möglich ist.

In jedem Fall aber bildet das Repository eine echte physische Entkopplung der Anwendungen von den Servern, die “nur noch” die Rechenleistung und die Betriebsressourcen zur Verfügung stellen. Unabhängig davon also welche und wie viele Server ein Modul/System für Anwender nutzbar machen – das physische Modul selbst existiert nur einmal in einem Repository.

Neben Skalierungsvorteilen bietet diese Architektur zudem Anwendern potentiell größere und effizientere Möglichkeiten der Einflußnahme auf ihre Systeme – weil der Betrieb, durch das fehlende Deployment, nicht mehr zwangsläufig direkt betroffen ist.

Was ist der Unterschied zwischen ISA und OSGi?
Neben einigen rein technischen Aspekten ist der Hauptunterschied die Zielrichtung – ISA ist von Grund auf dafür ausgelegt auf einfache und konsistente Weise durchgängig modulare, plattformunabhängige Enterprise Anwendungen zu ermöglichen. Dabei steht nicht die Technik im Vordergrund – sondern veränderliche Fachlichkeit und ein möglichst schlanker, effizienter und frei skalierbarer Entwicklungsprozess.

OSGi ist viel mehr aus der rein technologischen Richtung – “universelles Java Modulsystem” – motiviert und vom Ursprung her nicht speziell auf die Notwendigkeiten von Enterprise Entwicklung ausgelegt. (… mehr dazu)

Ist Modularität nicht eher eine Frage und Aufgabe von Standards und Java selbst?
Das ist eine viel und kontrovers diskutierte Frage – wie auch immer – ISA ist eine konkrete Lösung für die eingangs aufgezeigte Problematik von monolithischen Enterprise Anwendungen, die den Anwender Technologien und Standards nutzen lässt – ohne ihn jedoch an diese zu binden.

ISA schafft die Freiheit die “Standards” von heute zu nutzen und gleichzeitig die Möglichkeit sich ihren Veränderungen von morgen anzupassen – das ist Zukunftssicherheit durch Veränderbarkeit.