Downloaden Sie, um offline zu lesen
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen
- 1. Integrating Architecture Appsfor 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 ITConsulting 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 – ClientServer 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 – Schwachstellender 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