Ein einheitliches Modulsystemfür verteilte Unternehmensanwendungen
Motivation und Grundkonzept
Integrating ArchitectureApps for the Enterprise
© 2014 Integrating Architecture Seite: 2
Inhalt
� Problem
� Ursache
� Herausforderung
� Grundgedanke
� Architektur
� Umsetzung
� Kontakt
� Backup
� Vereinheitlichung
� Nachvollziehbarkeit
� Client Server Architektur
� Schwachstellen der JEE
© 2014 Integrating Architecture Seite: 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: 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: 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: 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: 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: 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.
� Enterprise Apps befreien dabei von Middlewaretechnologie, von Deployment, von komlexen Designs und Transformationen sowie von Versions- und Updateproblematiken – einfach nur Module.
JEE Server+Brokeretabliert
undleistungsfähig
Modulverwaltungdynamisch
undautomatisch
PlattformbasisIndividuelle, modulare und
automatisierte SystemeZentrales Repository
mit allen Modulen
Andreas Weidinger
Mobile: 0160 97627398Mail: [email protected]: www.integrating-architecture.de
Integrating ArchitectureIT Consulting
© 2014 Integrating Architecture Seite: 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
Windows Linux / Unix
Apps for the Enterprise
Rich Internet Application
Mobile
Java SE + EE HTML / JavaScript
Zentrales Modul
RepositoryServerModule
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 Schichtund auch KEINE technischen Objekttypen.
1
© 2014 Integrating Architecture Seite: 11
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: 12
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
Connectormulti
Protokoll
http
Service Consumer
Any Application Connectormulti
Protokoll
© 2014 Integrating Architecture Seite: 13
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
Top Related