Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen - Motivation und Grundkonzept

1. Integrating Architecture
Apps for the Enterprise
Ein einheitliches Modulsystem
für verteilte Unternehmensanwendungen
Motivation und Grundkonzept

2. Inhalt
Problem
Ursache
Herausforderung
Grundgedanke
Architektur
Umsetzung
Kontakt
Backup
Vereinheitlichung
Nachvollziehbarkeit
Client Server Architektur
Schwachstellen der JEE
© 2014 Integrating Architecture Seite: 2

3. Das Problem
Enterprise Entwicklung und Wartung ist
aufwendig, riskant und teuer
Kosten für Neuerungen und Änderungen steigen
überproportional zum fachlichen Funktionsumfang an
Fachliche Weiterentwicklung wird immer langsamer,
fehleranfälliger und immer restriktiver
Iterative und agile Verfahren werden mit wachsender
Systemgröße immer mehr ausgebremst
© 2014 Integrating Architecture Seite: 3

4. Die Ursache
Über die Jahrzehnte wurden zwar Softwarearchitekturen,
Verfahren und Technologien stetig weiterentwickelt
… aber das Problem ist geblieben !?!
Weil sich eines über die Zeit nicht geändert hat
es werden komplexe Monolithen gebaut
Das aber ist der Versuch, mit immer besseren Techniken,
immer weiter eckige Räder zu bauen, um sich dann zu
fragen – warum sie nicht rollen.
Monolithen sind für Beständigkeit gedacht – NICHT für Veränderung.
© 2014 Integrating Architecture Seite: 4

5. Die Herausforderung
Enterprise Systeme sind viel mehr als ein Stück Software!
Sie spiegeln die Herausforderungen des Unternehmens
und müssen sich stetig mit diesen weiterentwickeln
Das können sie nur –
wenn sie wie Unternehmen arbeiten und gebaut sind
aus einzelnen Einheiten mit Aufgaben und Grenzen
die durch Kooperation und Management
gemeinsame Ziele realisieren
© 2014 Integrating Architecture Seite: 5

6. Der Grundgedanke
„Von einem Management gesteuerte – einzelne Einheiten
mit eindeutigen Aufgaben und Grenzen, die durch
Kooperation gemeinsame Ziele realisieren“ ? – das
ist ein modulares System!
Module sind eindeutige, autarke Einheiten
mit klar definierten Funktionen, einem geschützten Innen
und einer äußeren Schnittstelle zur Kooperation
Systeme sind eine beliebige Anzahl von Modulen
zusammengefaßt unter einem Namen
die gesteuert durch eine Verwaltung, zusammen eine größere
Aufgabenstellung realisieren
Entwicklung ist Veränderung von Modulen über Versionen
Funktionsumfang ist die Anzahl der Module
© 2014 Integrating Architecture Seite: 6

7. Die Architektur
Alles ist ein eindeutiges, versioniertes Modul – jeder arbeitet
nur noch mit Modulen – und ein Modul kann „alles“ sein
z.B. Gegenstand für: fachliche Anforderungen, Spezifikation, Modellierung, Planung, Controlling, Betrieb etc. und
gleichzeitig neutrales Softwareartefakt wie z.B. Service, Datenbank, Technologie, Fremdsystem, GUI, Schnittstelle etc.
Letztendlich ist ein Modul ein eindeutiger Name (z.B. com.ModuleXY-1.0) und eine Datei mit diesem Namen in einem
zentralen Repository. Alles andere ist Verwendung und technischer Automatismus.
© 2014 Integrating Architecture Seite: 7

8. Die Umsetzung
Enterprise Apps sind eine Technologie, die ohne Aufwand
- plattformunabhängige Modularität
- und technologieunabhängige Kommunikation bietet
Damit können Enterprise Systeme aus leicht handhabbaren, versionierten
Servicemodulen aufgebaut werden, die in einem zentralen Repository liegen
und über eine Verwaltung On Demand als modulare Anwendungen und
zentrale Dienste eines Service Brokers überall nutzbar sind.
Plattformbasis
JEE Server+Broker
etabliert
und
leistungsfähig
Modulverwaltung
dynamisch
und
automatisch
Individuelle, modulare und
automatisierte Systeme
Zentrales Repository
mit allen Modulen
Enterprise Apps befreien dabei von Middlewaretechnologie, von Deployment, von komlexen Designs und
Transformationen sowie von Versions- und Updateproblematiken – einfach nur Module.
© 2014 Integrating Architecture Seite: 8

9. Integrating Architecture
IT Consulting
Andreas Weidinger
Mobile: 0160 97627398
Mail: info@integrating-architecture.de
Home: www.integrating-architecture.de

10. Backup – Vereinheitlichung
Enterprise Apps Module sind von der Spezifikation bis zum
Betrieb gleich und vereinheitlich so alle Technologien und
Plattformen in einer evolutionsfähigen Architektur
Vereinheitlichung von Technologien und Plattformen
Smart Client
Module
Web Client
Module
Apps for the Enterprise
Mobile Client
Module
Rich Internet Application
Server
Module
Java SE + EE HTML / JavaScript
Windows Linux / Unix
Mobile
Zentrales Modul
Repository
- Module
- Dienste
- Regeln
1 - Die Darstellung als „Schicht“ dient nur der Veranschaulichung. Enterprise Apps sind KEINE technische Schicht
und auch KEINE technischen Objekttypen.
1
© 2014 Integrating Architecture Seite: 10

11. Backup – Nachvollziehbarkeit
Transparenz, sicheres Management und Governance durch
Eindeutige Abbildung und Zuordnung aller Teile und Funktionalitäten einer IT Landschaft
Beliebige Teile und funktionale Anforderungen
an Dienste und Systeme …
… werden durch eindeutige Module in einem zentralen
Repository repräsentiert und realisiert
Modul Repository
System-CRM
CRM ModulXY-1.0.0
CRM ModulXY-2.0.0
CRM Modul4711-1.0.0
Modul SAP Service-2.1.0
Modul Messaging-1.0.5
Modul KT-DB-3.0.0
… usw.
IT Systemlandschaft
Die Verwaltung und der Service Broker (beide frei von Fachlichkeit) stellen die Module On-Demand zur Verfügung
Projekte
1
1 - Hier sind Projektstrukturen der Entwicklung wie z.B. IDE oder SCM „Projekte“ gemeint – nicht organisatorische Projekte des Managements.
© 2014 Integrating Architecture Seite: 11

12. Backup – Client Server Architektur
Volle Entkopplung der Fachlogik von Plattform und Technik
Server
JEE Application Server
ISA Service Broker Application
Netzwerk
Server oder File Server
ISA Module System
ruft
kennt
ISA JEE Adapter
SF Session
SL Session
Servlet
MDB/JMS
WebService
4
Verwaltung
delegieren
zentrales
Repository
1
3
2
nutzt
Web Client
Rich Internet Application
Service Consumer
Any Application Connector
ISA Module System
lokales
Repository
http
multi
Protokoll
Connector
multi
Protokoll
automatische, system- und benutzerspezifische Konfiguration und Replikation
: Modul bzw. App
: Objekt
: Aufruf
Smart Client
Verwaltung
1‘
ruft
kennt
- Fachliche Implementierung befindet sich nur in den einzelnen Modulen bzw. den Apps
- Das zentrale Repository ist ein Single Point of Access, hier befinden sich
alle Versionen, aller Module unterteilt nach Systemen - sowohl für die Clients als auch für den Server
5
1
2 - Die JEE Adapter sind generisch und beinhalten keine Fachlichkeit. Sie delegieren immer an die Modulverwaltung
3 - Der Service Broker bzw. die entsprechende JEE Application (.ear) ist nur noch ca. 50 KB klein
4 - Das Modulsystem ist vollständig autark und läuft im Server in einer gekapselten Umgebung (ClassLoader Kontext)
: optional
5 - Der ISA SmartClient ist nicht zwingend. Jede Anwendung kann auf den Broker zugreifen
© 2014 Integrating Architecture Seite: 12

13. Backup – Schwachstellen der JEE
JEE basierte Systeme sind spezifikationsbedingt Monolithen
weil das Deploymentmodell nur geschlossene Anwendungen kennt
Die JEE verletzt das SoC Prinzip
1
weil sie mit ihrem Programmiermodell die Implementierung von fachlichen
Anforderungen als technische Komponenten der Plattform verlangt (z.B.
als WebService, EJB etc.)
JEE Komponenten sind bzgl. verteilter Kommunikation
technologiegebunden (z.B. RMI, HTTP, JMS etc.)
Die JEE bietet kein brauchbares Modulsystem und erschwert durch
ihre Containerkonstruktion auch den Einsatz anderer Modulsysteme
Das Problem mit JEE ist NICHT das Konzept eines Application Servers, der
eine verteilte Infrastruktur zur Verfügung stellt – das Problem ist, dass die JEE
jede Aufgabenstellung lösen will und Anwendungen an ihre monolithische
Plattform und ihre Technologien bindet.
1 - Separation of Concerns – hier Trennung von Fachichkeit und Technik
© 2014 Integrating Architecture Seite: 13