Modulare Enterprise Systeme - Eine Einführung
Upcoming SlideShare
Loading in...5
×
 

Modulare Enterprise Systeme - Eine Einführung

on

  • 65 views

Modularität in Enterprise Systemen - ein vernachlässigter Erfolgsfaktor

Modularität in Enterprise Systemen - ein vernachlässigter Erfolgsfaktor

Statistics

Views

Total Views
65
Views on SlideShare
65
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Modulare Enterprise Systeme - Eine Einführung Modulare Enterprise Systeme - Eine Einführung Presentation Transcript

  • Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Vorstellung und Einführung Integrating Architecture Apps for the Enterprise
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 2 Ein beliebiger Zeitpunkt in einem beliebigen Unternehmen z.B. bei com.my.company
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 3 Die IT Landschaft von com.my.company HOST Frontends CRM SCM UNIX Server VCXCMGIRX Backend KTDB IDBKM KMX-DB SAP MQ DWDB Service Bus (ESB) AFR Standalone AS-1.0 + AS-3.2 AMS KM-UXCRM-OV W F M PM-UXCRX SFE HR FI CM E X T E R N A L S DOC FTP Server = com.my.XML1
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 4 Ein Fachbereich hat eine neue Anforderung und die IT soll sie umsetzen z.B. eine Funktion: zum Abgleich von Kundendaten
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 5 Wo und Wie wird die neue Anforderung umgesetzt? HOST Frontends CRM SCM UNIX Server VCXCMGIRX Backend KTDB IDBKM KMX-DB SAP MQ DWDB Service Bus (ESB) AFR Standalone AS-1.0 + AS-3.2 AMS KM-UXCRM-OV W F M PM-UXCRX SFE HR FI CM E X T E R N A L S DOC FTP Server = com.my.XML1
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 6 Wo und Wie wird die neue Anforderung umgesetzt?
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 7 Wo und Wie wird die neue Anforderung umgesetzt? Einige mögliche Szenarien sind die Funktionalität ist interner Teil eines betimmten Systems ist Teil eines Systems aber mit Schnittstellen betrifft die Interna mehrerer Systeme ist ein eigenständiger zentraler Dienst ist ein vernetzter Dienst … usw.
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 8 Wie auch immer in einer modularen Welt ist die Antwort eine völlig andere
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 9 In einer modularen Welt ist die Antwort: Ein Modul oder eine Modulversion in einem Modulrepository
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 10 In einem modularen System gib es zwei universelle, zentrale Gegenstände Modul – und – Repository 1 - natürlich kann es mehrere Repositories geben 1
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 11 Was ist ein Modul? Und was ist ein Modul Repository? ein zentrales Verzeichnis mit Unterverzeichnissen eine Moduldatei mit eindeutigem Modulnamen Ein Modul ist eine abgegrenzte fachliche oder technische Funktionalität Modul Repository (/var/myreproXY/) com.my.CustomerAdjustment-1.0.0 com.my.ModuleXY-2.0.1 … usw. com.my.xy.ServiceZ-3.5.0 System 1 System N … usw.
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 12 An dem eindeutigen Modul(namen) können alle benötigten Artefakte aus allen Bereichen festgemacht bzw. identifiziert werden com.my.CustomerAdjustment-1.0.0 Budgets und Controlling Aufgaben oder Tasks in der Planung Spezifikation und Anforderungsliste Softwareprojekt Repository in einer Versionsverwaltung ausführbares Modul Test, Abnahme, Inbetriebnahme, …, … etc. alles bezieht sich auf das selbe Modul
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 13 In einer modularen Systemlandschaft sind Module die gemeinsame Sicht aller Beteiligten
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 14 Module können beliebige Anforderungen und beliebige Teile einer Systemlandschaft abbilden - Module können frei skalieren – von einer ganzen Anwendung bis hin zu einer einzelnen Funktion
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 15 Das ist nett – aber das ist noch keine funktionsfähige Software in der Anwendungslandschaft!
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 16 Für funktionsfähige Software fehlen noch zwei Dinge eine Verwaltung, die Module verfügbar macht Middleware in der die Verwaltung läuft Modul Repository Service Broker JEE Serverdynamische Verwaltung Clients manager.getModule( „com.my.ServiceXY“ ) module.doBizzMethod
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 17 Das sieht aus wie ein übliches, aber proprietäres JEE Bus/Broker System mit allen Problemen einer jeden JEE Anwendung!?! Ist es aber nicht!
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 18 Der Broker ist KEINE übliche JEE Anwendung und besitzt daher auch nicht deren Problematiken denn … der Service Broker beinhaltet keine Fachlichkeit er muss nie geändert oder erweitert werden er kann in jedes System eingebunden werden er ist nur ca. 60 KB (Kilobyte) klein er ist nur Middleware – KEINE Anwendung die eigentliche Anwendungs-Software sind NUR die Module und die sind technologie- bzw. plattformunabhängig
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 19 Der Broker ist KEINE übliche JEE Anwendung und besitzt daher auch nicht deren Problematiken Der Broker realisiert nur intern die Middleware Anbindung für die dynamische Modulverwaltung Service Broker als neutrale Middleware API Modul Repository Clients manager.getModule( „com.my.ServiceXY“ ) module.doBizzMethod ein Client kennt nur die Verwaltung, die ihm transparent Module zur Verfügung stellt Session Dienste Web Dienste … usw.
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 20 Die Vorteile dieser Konstruktion kein Deployment oder spezielle Paketierung keine komplexen Designs oder Abbildungen keine Software Versionsprobleme keine Bindung an JEE Verfahren oder Techniken ideal für agile, continuous Verfahren freie system-, technologie- und plattformübergreifende Funktionen und Dienste bei gleichzeitig sauberer Kapselung in neutralen, klar definierten Modulen die versioniert und austauschbar sind
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 21 Welche Protokolle und Datenformate werden unterstützt? Client Server Kommunikation RMI - bzw. alle Protokolle die EJBs unterstützen JMS, HTTP, WebService, WebSocket, REST,AJAX … jedes Protokoll, das in JEE oder JSE verfügbar ist oder für das ein Adapter existiert Datenformate … jedes Format, das mit Java verarbeitet werden kann
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 22 Und die Client Seite?
  • © 2014 Andreas Weidinger at Integrating Architecture de Seite: 23 Und die Client Seite? Module sind für Client und Server gleich Das Modulsystem unterscheidet NICHT zwischen Client und Server Ein Repository Verzeichnis mit Modulen und eine Verwaltung bilden ein modulares System das ist alles – auf dem Client wie auf dem Server
  • Andreas Weidinger Mobile: 0160 97627398 Mail: info@integrating-architecture.de Home: www.integrating-architecture.de Integrating Architecture IT Consulting
  • © 2014 Integrating Architecture Seite: 25 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
  • © 2014 Integrating Architecture Seite: 26 Backup – Nachvollziehbarkeit Transparenz, sicheres Management und Governance durch Beliebige Teile einer IT Landschaft werden zu eindeutigen Modulen in einem zentralen Repository und zu Projekten in der Entwicklung Modul Repository CRM ModulXY-1.0.0 CRM ModulXY-2.0.0 Modul KT-DB-3.0.0 Modul Messaging-1.0.5 Service Broker (frei von Fachlichkeit) Projekte Eindeutige Abbildung und Zuordnung aller Teile einer IT Landschaft CRM Modul4711-1.0.0 System-CRM … usw. Modul SAPService-2.1.0 1 1 - Hier sind Projektstrukturen der Entwicklung wie z.B. IDE oder SCM „Projekte“ gemeint – nicht organisatorische Projekte des Managements.
  • © 2014 Integrating Architecture Seite: 27 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
  • © 2014 Integrating Architecture Seite: 28 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