Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen

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


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


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.


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


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


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.


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


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


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


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


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

Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen

Software

Transcript of Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen