Modulare Enterprise Systeme - Motivation

Home: http://integrating-architecture.de/
Enterprise Apps - Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen

Transcript

1. Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Integrating Architecture Apps for the Enterprise
2. © 2014 Integrating Architecture Seite: 2 Inhalt Problem Ursache Herausforderung Grundgedanke Architektur Umsetzung Kontakt Backup Vereinheitlichung Nachvollziehbarkeit Client Server Architektur Schwachstellen der JEE
3. © 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
4. © 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.
5. © 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
6. © 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
7. © 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.
8. © 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+Broker etabliert und leistungsfähig Modulverwaltung dynamisch und automatisch Plattformbasis Individuelle, modulare und automatisierte Systeme Zentrales Repository mit allen Modulen
9. Andreas Weidinger Mobile: 0160 97627398 Mail: info@integrating-architecture.de Home: www.integrating-architecture.de Integrating Architecture IT Consulting
10. © 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 Repository Server Module Smart Client Module Web Client Module Mobile Client Module 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
11. © 2014 Integrating Architecture Seite: 11 Backup – Nachvollziehbarkeit Transparenz, sicheres Management und Governance durch Beliebige Teile und funktionale Anforderungen an 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
12. © 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 zentrales Repository : 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 nutzt Verwaltung 5 - Der ISA SmartClient ist nicht zwingend. Jede Anwendung kann auf den Broker zugreifen Smart Client lokales Repository ISA Module System Verwaltung 1‘ ruft kennt 5 Web Client Rich Internet Application Connector multi Protokoll http Service Consumer Any Application Connector multi Protokoll
13. © 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