Modularität in Enterprise Systemen - ein vernachlässigter Erfolgsfaktor

1. Integrating Architecture
Apps for the Enterprise
Ein einheitliches Modulsystem
für verteilte Unternehmensanwendungen
Vorstellung und Einführung

2. Ein beliebiger Zeitpunkt
in einem beliebigen Unternehmen
z.B. bei
com.my.company
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 2

3. Die IT Landschaft von
com.my.company
Frontends
FTP Server
HOST
CRM SCM
UNIX Server
IRX CMG VCX
HR FI
Backend
SAP
MQ
Standalone AS-1.0 + AS-3.2
CRM-OV KM-UX
W
F
M
CRX PM-UX
SFE
CM
DOC
KM KTDB DWDB
IDB KMX-DB
Service Bus (ESB)
AFR
AMS
E
X
T
E
R
N
A
L
S
= com.my.XML1
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 3

4. Ein Fachbereich hat eine neue Anforderung
und die IT soll sie umsetzen
z.B.
eine Funktion: zum Abgleich von Kundendaten
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 4

5. Wo und Wie
wird die neue Anforderung umgesetzt?
Frontends
FTP Server
HOST
CRM SCM
UNIX Server
IRX CMG VCX
HR FI
Backend
SAP
MQ
Standalone AS-1.0 + AS-3.2
CRM-OV KM-UX
W
F
M
CRX PM-UX
SFE
CM
DOC
KM KTDB DWDB
IDB KMX-DB
Service Bus (ESB)
AFR
AMS
E
X
T
E
R
N
A
L
S
= com.my.XML1
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 5

6. Wo und Wie
wird die neue Anforderung umgesetzt?
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 6

7. Wo und Wie
wird die neue Anforderung umgesetzt?
Einige mögliche Szenarien sind
die Funktionalität
ist interner Teil eines betimmten Systems
ist Teil eines Systems aber mit Schnittstellen
betrifft die Interna mehrerer Systeme
ist ein eigenständiger zentraler Dienst
ist ein vernetzter Dienst
… usw.
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 7

8. Wie auch immer
in einer modularen Welt
ist die Antwort eine völlig andere
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 8

9. In einer modularen Welt ist die Antwort:
Ein Modul oder eine Modulversion
in einem Modulrepository
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 9

10. In einem modularen System gib es zwei
universelle, zentrale Gegenstände
Modul – und – Repository
1 - natürlich kann es mehrere Repositories geben
1
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 10

11. Was ist ein Modul?
Und was ist ein Modul Repository?
ein zentrales Verzeichnis
mit Unterverzeichnissen
eine Moduldatei mit
eindeutigem Modulnamen
Ein Modul ist eine
abgegrenzte
fachliche oder technische
Funktionalität
Modul Repository (/var/myrepoXY/)
System 1
com.my.CustomerAdjustment-1.0.0
com.my.ModuleXY-2.0.1
… usw.
com.my.xy.ServiceZ-3.5.0
System N
… usw.
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 11

12. An dem eindeutigen Modul(namen) können alle
benötigten Artefakte aus allen Bereichen
festgemacht bzw. identifiziert werden
com.my.CustomerAdjustment-1.0.0
Budgets und Controlling
Aufgaben oder Tasks in der Planung
Spezifikation und Anforderungsliste
Softwareprojekt
Repository in einer Versionsverwaltung
ausführbares Modul
Test, Abnahme, Inbetriebnahme, …, … etc.
alles bezieht sich auf das selbe Modul
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 12

13. In einer modularen Systemlandschaft sind Module
die gemeinsame Sicht aller Beteiligten
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 13

14. Module können beliebige Anforderungen und
beliebige Teile einer Systemlandschaft abbilden
- Module können frei skalieren – von einer ganzen Anwendung bis hin zu einer einzelnen Funktion
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 14

15. Das ist nett – aber
das ist noch keine funktionsfähige
Software in der Anwendungslandschaft!
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 15

16. Für funktionsfähige Software fehlen noch zwei Dinge
eine Verwaltung, die Module verfügbar macht
Middleware in der die Verwaltung läuft
Modul Repository Service Broker
dynamische JEE Server
Verwaltung
Clients
manager.getModule(
„com.my.ServiceXY“
)
module.doBizzMethod
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 16

17. Das sieht aus wie ein übliches,
aber proprietäres JEE Bus/Broker System
mit allen Problemen einer jeden JEE Anwendung!?!
Ist es aber nicht!
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 17

18. Der Broker ist KEINE übliche JEE Anwendung und
besitzt daher auch nicht deren Problematiken
denn …
der Service Broker beinhaltet keine Fachlichkeit
er muss nie geändert oder erweitert werden
er kann in jedes System eingebunden werden
er ist nur ca. 60 KB (Kilobyte) klein
er ist nur Middleware – KEINE Anwendung
die eigentliche Anwendungs-Software
sind NUR die Module
und die sind technologie- bzw. plattformunabhängig
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 18

19. Der Broker ist KEINE übliche JEE Anwendung und
besitzt daher auch nicht deren Problematiken
Der Broker realisiert nur intern die Middleware
Anbindung für die dynamische Modulverwaltung
Service Broker als
Modul Repository Clients
neutrale Middleware API
manager.getModule(
„com.my.ServiceXY“
)
module.doBizzMethod
Session Dienste
Web Dienste
… usw.
ein Client kennt nur die Verwaltung, die ihm
transparent Module zur Verfügung stellt
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 19

20. Die Vorteile dieser Konstruktion
kein Deployment oder spezielle Paketierung
keine komplexen Designs oder Abbildungen
keine Software Versionsprobleme
keine Bindung an JEE Verfahren oder Techniken
ideal für agile, continuous Verfahren
freie system-, technologie- und
plattformübergreifende Funktionen und Dienste
bei gleichzeitig sauberer Kapselung in neutralen,
klar definierten Modulen die
versioniert und austauschbar sind
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 20

21. Welche Protokolle und Datenformate
werden unterstützt?
Client Server Kommunikation
RMI - bzw. alle Protokolle die EJBs unterstützen
JMS, HTTP, WebService, WebSocket, REST,AJAX
… jedes Protokoll, das in JEE oder JSE verfügbar
ist oder für das ein Adapter existiert
Datenformate
… jedes Format, das mit Java verarbeitet werden
kann
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 21

22. Und die Client Seite?
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 22

23. Und die Client Seite?
Module sind für Client und Server gleich
Das Modulsystem unterscheidet NICHT zwischen
Client und Server
Ein Repository Verzeichnis mit Modulen und eine
Verwaltung bilden ein modulares System
das ist alles – auf dem Client wie auf dem Server
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 23

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

25. 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: 25

26. 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: 26

27. 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: 27

28. 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: 28