Integrating Architecture Apps for the Enterprise

Transkript

1 Integrating Architecture Apps for 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 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 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. Zentrales Repository mit allen Modulen Plattformbasis Individuelle, modulare und automatisierte Systeme JEE Server+Broker etabliert und leistungsfähig Modulverwaltung dynamisch und automatisch Enterprise Apps befreien dabei von Middlewaretechnologie, von Deployment, von komlexen Designs und Transformationen sowie von Versions- und Updateproblematiken einfach nur Module Integrating Architecture Seite: 8

9 Integrating Architecture IT Consulting Andreas Weidinger Mobile: Mail: Home:

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 Zentrales Modul Repository Server Module Smart Client Module Web Client Module Mobile Client Module - Module - Dienste - Regeln Apps for the Enterprise 1 Rich Internet Application Java SE + EE HTML / JavaScript Windows Linux / Unix Mobile 1 - Die Darstellung als Schicht dient nur der Veranschaulichung. Enterprise Apps sind KEINE technische Schicht und auch KEINE technischen Objekttypen 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 IT Systemlandschaft Modul Repository Projekte 1 System-CRM CRM ModulXY CRM ModulXY CRM Modul Modul SAP Service Modul Messaging Modul KT-DB usw. Die Verwaltung und der Service Broker (beide frei von Fachlichkeit) stellen die Module On-Demand zur Verfügung 1 - Hier sind Projektstrukturen der Entwicklung wie z.b. IDE oder SCM Projekte gemeint nicht organisatorische Projekte des Managements Integrating Architecture Seite: 11

12 Backup Client Server Architektur Volle Entkopplung der Fachlogik von Plattform und Technik Web Client Netzwerk Server Server oder File Server 5 Rich Internet Application Service Consumer Any Application Smart Client ISA Module System Verwaltung ruft kennt lokales Repository 1 http Connector multi Protokoll Connector multi Protokoll nutzt 3 2 JEE Application Server ISA Service Broker Application ISA JEE Adapter SF Session SL Session Servlet MDB/JMS WebService 4 delegieren ISA Module System Verwaltung ruft kennt 1 zentrales Repository automatische, system- und benutzerspezifische Konfiguration und Replikation 1 - 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 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) 5 - Der ISA SmartClient ist nicht zwingend. Jede Anwendung kann auf den Broker zugreifen : Modul bzw. App : Objekt 2014 Integrating Architecture Seite: 12 : Aufruf : optional

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 2014 Integrating Architecture Seite: 13 1