Ein einheitliches Modulsystem
für verteilte Unternehmensanwendungen
Vorstellung und Einführung
Integrating ArchitectureApps for the Enterprise
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 2
Ein beliebiger Zeitpunktin einem beliebigen Unternehmen
z.B. bei
com.my.company
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 3
Die IT Landschaft von com.my.company
HOST
Frontends CRM SCM
UNIX Server
VCXCMGIRX
BackendKTDB IDBKM KMX-DB
SAP
MQ
DWDB
Service Bus (ESB)
AFR
Standalone AS-1.0 + AS-3.2
AMS
KM-UXCRM-OV
W
F
M
PM-UXCRX
SFE
HR FI
CM
E
X
T
E
R
N
A
L
S
DOC
FTP Server
= com.my.XML1
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 4
Ein Fachbereich hat eine neue Anforderungund die IT soll sie umsetzen
z.B.eine Funktion: zum Abgleich von Kundendaten
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 5
Wo und Wiewird die neue Anforderung umgesetzt?
HOST
Frontends CRM SCM
UNIX Server
VCXCMGIRX
BackendKTDB IDBKM KMX-DB
SAP
MQ
DWDB
Service Bus (ESB)
AFR
Standalone AS-1.0 + AS-3.2
AMS
KM-UXCRM-OV
W
F
M
PM-UXCRX
SFE
HR FI
CM
E
X
T
E
R
N
A
L
S
DOC
FTP Server
= com.my.XML1
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 6
Wo und Wiewird die neue Anforderung umgesetzt?
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 7
Wo und Wiewird 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: 8
Wie auch immerin einer modularen Welt
ist die Antwort eine völlig andere
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 9
In einer modularen Welt ist die Antwort:Ein Modul oder eine Modulversion
in einem Modulrepository
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 10
In einem modularen System gib es zweiuniverselle, zentrale Gegenstände
Modul – und – Repository
1 - natürlich kann es mehrere Repositories geben
1
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 11
Was ist ein Modul?Und was ist ein Modul Repository?
ein zentrales Verzeichnismit Unterverzeichnissen
eine Moduldatei miteindeutigem Modulnamen
Ein Modul ist eine
abgegrenztefachliche oder technische Funktionalität
Modul Repository (/var/myrepoXY/)
com.my.CustomerAdjustment-1.0.0
com.my.ModuleXY-2.0.1
… usw.
com.my.xy.ServiceZ-3.5.0
System 1
System N
… usw.
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 12
An dem eindeutigen Modul(namen) können allebenö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: 13
In einer modularen Systemlandschaft sind Module die gemeinsame Sicht aller Beteiligten
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 14
Module können beliebige Anforderungen undbeliebige 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: 15
Das ist nett – aberdas ist noch keine funktionsfähige
Software in der Anwendungslandschaft!
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 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
JEE ServerdynamischeVerwaltung
Clients
manager.getModule(„com.my.ServiceXY“
)
module.doBizzMethod
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 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: 18
Der Broker ist KEINE übliche JEE Anwendung undbesitzt 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-Softwaresind NUR die Module
und die sind technologie- bzw. plattformunabhängig
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 19
Der Broker ist KEINE übliche JEE Anwendung undbesitzt daher auch nicht deren Problematiken
� Der Broker realisiert nur intern die Middleware Anbindung für die dynamische Modulverwaltung
Service Broker als neutrale Middleware API
Modul Repository Clients
manager.getModule(„com.my.ServiceXY“
)
module.doBizzMethod
� ein Client kennt nur die Verwaltung, die ihm
transparent Module zur Verfügung stellt
Session Dienste
Web Dienste
… usw.
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 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 dieversioniert und austauschbar sind
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 21
Welche Protokolle und Datenformatewerden 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: 22
Und die Client Seite?
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 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 Systemdas ist alles – auf dem Client wie auf dem Server
Andreas Weidinger
Mobile: 0160 97627398Mail: [email protected]: www.integrating-architecture.de
Integrating ArchitectureIT Consulting
© 2014 Integrating Architecture Seite: 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
Windows Linux / Unix
Apps for the Enterprise
Rich Internet Application
Mobile
Java SE + EE HTML / JavaScript
Zentrales Modul
Repository
ServerModule
Smart ClientModule
Web ClientModule
Mobile ClientModule
Vereinheitlichung von Technologien und Plattformen
- 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: 26
Backup – Nachvollziehbarkeit
� Transparenz, sicheres Management und Governance durch
Beliebige Teile und funktionale Anforderungenan Dienste und Systeme …
… werden durch eindeutige Module in einem zentralen Repository repräsentiert und realisiert
Modul Repository
CRM ModulXY-1.0.0
CRM ModulXY-2.0.0
Modul KT-DB-3.0.0
Modul Messaging-1.0.5
Die Verwaltung und der Service Broker (beide frei von Fachlichkeit) stellen die Module On-Demand zur Verfügung
Projekte
Eindeutige Abbildung und Zuordnung aller Teile und Funktionalitäten einer IT Landschaft
CRM Modul4711-1.0.0
System-CRM
… usw.
Modul SAP Service-2.1.0
1
1 - Hier sind Projektstrukturen der Entwicklung wie z.B. IDE oder SCM „Projekte“ gemeint – nicht organisatorische Projekte des Managements.
IT Systemlandschaft
© 2014 Integrating Architecture Seite: 27
Backup – Client Server Architektur
� Volle Entkopplung der Fachlogik von Plattform und Technik
Server
JEE Application Server
ISA Service Broker Application
Netzwerk
ISA Module System
kennt
ruft
SF Session
SL Session
Servlet
MDB/JMS
WebService
ISA JEE Adapter
delegieren
zentralesRepository
: Objekt
: Modul bzw. App
: Aufruf
automatische, system- und benutzerspezifische Konfiguration und Replikation
- 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
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)
1
4
3
2
Server oder File Server
: optional
nutztVerwaltung
5 - Der ISA SmartClient ist nicht zwingend. Jede Anwendung kann auf den Broker zugreifen
Smart Client
lokalesRepository
ISA Module System
Verwaltung
1‘
ruft
kennt
5
Web Client
Rich Internet Application
Connector
multi
Protokoll
http
Service Consumer
Any ApplicationConnector
multi
Protokoll
© 2014 Integrating Architecture Seite: 28
Backup – Schwachstellen der JEE
� JEE basierte Systeme sind spezifikationsbedingt Monolithen
� weil das Deploymentmodell nur geschlossene Anwendungen kennt
� Die JEE verletzt das SoC Prinzip
� 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
1