SlideShare ist ein Scribd-Unternehmen logo
1 von 28
Downloaden Sie, um offline zu lesen
Integrating Architecture 
Apps for the Enterprise 
Ein einheitliches Modulsystem 
für verteilte Unternehmensanwendungen 
Vorstellung und Einführung
Ein beliebiger Zeitpunkt 
in einem beliebigen Unternehmen 
z.B. bei 
com.my.company 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 2
Die IT Landschaft von 
com.my.company 
Frontends 
FTP Server 
HOST 
CRM SCM 
UNIX Server 
IRX CMG VCX 
HR FI 
Backend 
SAP 
MQ 
Standalone AS-1.0 + AS-3.2 
CRM-OV KM-UX 
W 
F 
M 
CRX PM-UX 
SFE 
CM 
DOC 
KM KTDB DWDB 
IDB KMX-DB 
Service Bus (ESB) 
AFR 
AMS 
E 
X 
T 
E 
R 
N 
A 
L 
S 
= com.my.XML1 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 3
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: 4
Wo und Wie 
wird die neue Anforderung umgesetzt? 
Frontends 
FTP Server 
HOST 
CRM SCM 
UNIX Server 
IRX CMG VCX 
HR FI 
Backend 
SAP 
MQ 
Standalone AS-1.0 + AS-3.2 
CRM-OV KM-UX 
W 
F 
M 
CRX PM-UX 
SFE 
CM 
DOC 
KM KTDB DWDB 
IDB KMX-DB 
Service Bus (ESB) 
AFR 
AMS 
E 
X 
T 
E 
R 
N 
A 
L 
S 
= com.my.XML1 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 5
Wo und Wie 
wird die neue Anforderung umgesetzt? 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 6
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: 7
Wie auch immer 
in einer modularen Welt 
ist die Antwort eine völlig andere 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 8
In einer modularen Welt ist die Antwort: 
Ein Modul oder eine Modulversion 
in einem Modulrepository 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 9
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: 10
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/myrepoXY/) 
System 1 
com.my.CustomerAdjustment-1.0.0 
com.my.ModuleXY-2.0.1 
… usw. 
com.my.xy.ServiceZ-3.5.0 
System N 
… usw. 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 11
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: 12
In einer modularen Systemlandschaft sind Module 
die gemeinsame Sicht aller Beteiligten 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 13
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: 14
Das ist nett – aber 
das ist noch keine funktionsfähige 
Software in der Anwendungslandschaft! 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 15
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 
dynamische JEE Server 
Verwaltung 
Clients 
manager.getModule( 
„com.my.ServiceXY“ 
) 
module.doBizzMethod 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 16
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: 17
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: 18
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 
Modul Repository Clients 
neutrale Middleware API 
manager.getModule( 
„com.my.ServiceXY“ 
) 
module.doBizzMethod 
Session Dienste 
Web Dienste 
… usw. 
 ein Client kennt nur die Verwaltung, die ihm 
transparent Module zur Verfügung stellt 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 19
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: 20
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: 21
Und die Client Seite? 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 22
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 
© 2014 Andreas Weidinger at Integrating Architecture de Seite: 23
Integrating Architecture 
IT Consulting 
Andreas Weidinger 
Mobile: 0160 97627398 
Mail: info@integrating-architecture.de 
Home: www.integrating-architecture.de
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: 25
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: 26
Backup – Client Server 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: 27
Backup – Schwachstellen der 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: 28

Weitere ähnliche Inhalte

Andere mochten auch

Building the enterprise data architecture
Building the enterprise data architectureBuilding the enterprise data architecture
Building the enterprise data architecture
Costa Pissaris
 

Andere mochten auch (20)

Fachliche Tests mit BITA
Fachliche Tests mit BITAFachliche Tests mit BITA
Fachliche Tests mit BITA
 
DBS-Week1-Introduction&OverviewDigitalMarketing
DBS-Week1-Introduction&OverviewDigitalMarketingDBS-Week1-Introduction&OverviewDigitalMarketing
DBS-Week1-Introduction&OverviewDigitalMarketing
 
Microsoft on Big Data
Microsoft on Big DataMicrosoft on Big Data
Microsoft on Big Data
 
Enterprise Master Data Architecture: Design Decisions and Options
Enterprise Master Data Architecture: Design Decisions and OptionsEnterprise Master Data Architecture: Design Decisions and Options
Enterprise Master Data Architecture: Design Decisions and Options
 
Enterprise data architecture of complex distributed applications & services
Enterprise data architecture of complex distributed applications & servicesEnterprise data architecture of complex distributed applications & services
Enterprise data architecture of complex distributed applications & services
 
Web 20
Web 20Web 20
Web 20
 
Real-time Enterprise Architecture mit LeanIX
Real-time Enterprise Architecture mit LeanIX Real-time Enterprise Architecture mit LeanIX
Real-time Enterprise Architecture mit LeanIX
 
Dokumentenmanagement mit Alfresco
Dokumentenmanagement mit AlfrescoDokumentenmanagement mit Alfresco
Dokumentenmanagement mit Alfresco
 
White Paper - Overview Architecture For Enterprise Data Warehouses
White Paper -  Overview Architecture For Enterprise Data WarehousesWhite Paper -  Overview Architecture For Enterprise Data Warehouses
White Paper - Overview Architecture For Enterprise Data Warehouses
 
Big Data Paris - A Modern Enterprise Architecture
Big Data Paris - A Modern Enterprise ArchitectureBig Data Paris - A Modern Enterprise Architecture
Big Data Paris - A Modern Enterprise Architecture
 
SaaS für Enterprise Architecture Management
SaaS für Enterprise Architecture ManagementSaaS für Enterprise Architecture Management
SaaS für Enterprise Architecture Management
 
Blockchain – grundlagen und architektur
Blockchain – grundlagen und architekturBlockchain – grundlagen und architektur
Blockchain – grundlagen und architektur
 
Building the enterprise data architecture
Building the enterprise data architectureBuilding the enterprise data architecture
Building the enterprise data architecture
 
Enterprise Master Data Architecture
Enterprise Master Data ArchitectureEnterprise Master Data Architecture
Enterprise Master Data Architecture
 
Building a Modern Data Architecture with Enterprise Hadoop
Building a Modern Data Architecture with Enterprise HadoopBuilding a Modern Data Architecture with Enterprise Hadoop
Building a Modern Data Architecture with Enterprise Hadoop
 
Digital Transformation, Enterprise Architecture, Big Data by Danairat
Digital Transformation, Enterprise Architecture, Big Data by DanairatDigital Transformation, Enterprise Architecture, Big Data by Danairat
Digital Transformation, Enterprise Architecture, Big Data by Danairat
 
Architecture for the API-enterprise
Architecture for the API-enterpriseArchitecture for the API-enterprise
Architecture for the API-enterprise
 
The Emerging Data Lake IT Strategy
The Emerging Data Lake IT StrategyThe Emerging Data Lake IT Strategy
The Emerging Data Lake IT Strategy
 
Modern Data Architecture
Modern Data ArchitectureModern Data Architecture
Modern Data Architecture
 
Implementing a Data Lake with Enterprise Grade Data Governance
Implementing a Data Lake with Enterprise Grade Data GovernanceImplementing a Data Lake with Enterprise Grade Data Governance
Implementing a Data Lake with Enterprise Grade Data Governance
 

Ähnlich wie Modulare Enterprise Systeme - Eine Einführung

Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Christian Guenther
 
Adruni Ishan Unified Workplace V2
Adruni Ishan   Unified Workplace V2Adruni Ishan   Unified Workplace V2
Adruni Ishan Unified Workplace V2
Adruni Ishan
 

Ähnlich wie Modulare Enterprise Systeme - Eine Einführung (20)

BATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu Microservices
 
Rapid Application Development mit Openobject
Rapid Application Development mit OpenobjectRapid Application Development mit Openobject
Rapid Application Development mit Openobject
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
 
Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
 
OSLC in Aktion
OSLC in AktionOSLC in Aktion
OSLC in Aktion
 
PLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM TrendsPLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM Trends
 
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit ImplementierungsanteilPLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
 
Migration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud PlattformMigration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud Plattform
 
UnifiedSessionsManager - Virtualisierung und Cloud-Computing
UnifiedSessionsManager - Virtualisierung und Cloud-ComputingUnifiedSessionsManager - Virtualisierung und Cloud-Computing
UnifiedSessionsManager - Virtualisierung und Cloud-Computing
 
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
 
Leistungsvergleich Präsentationsoberflächen für digitale Sammlungen 2013
Leistungsvergleich Präsentationsoberflächen für digitale Sammlungen 2013Leistungsvergleich Präsentationsoberflächen für digitale Sammlungen 2013
Leistungsvergleich Präsentationsoberflächen für digitale Sammlungen 2013
 
Adruni Ishan Unified Workplace V2
Adruni Ishan   Unified Workplace V2Adruni Ishan   Unified Workplace V2
Adruni Ishan Unified Workplace V2
 
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
 
SokaHH: Testen von Rich-Web-UI (German)
SokaHH: Testen von Rich-Web-UI (German)SokaHH: Testen von Rich-Web-UI (German)
SokaHH: Testen von Rich-Web-UI (German)
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
 
20150611 track3 2_bp22_ibm_connections_ist_keine_insel
20150611 track3 2_bp22_ibm_connections_ist_keine_insel20150611 track3 2_bp22_ibm_connections_ist_keine_insel
20150611 track3 2_bp22_ibm_connections_ist_keine_insel
 
InstallShield 2015-DE
InstallShield 2015-DEInstallShield 2015-DE
InstallShield 2015-DE
 
Slides (2) zu Teil 2 der Veranstaltungsreihe Anwendungsentwicklung mit Volt M...
Slides (2) zu Teil 2 der Veranstaltungsreihe Anwendungsentwicklung mit Volt M...Slides (2) zu Teil 2 der Veranstaltungsreihe Anwendungsentwicklung mit Volt M...
Slides (2) zu Teil 2 der Veranstaltungsreihe Anwendungsentwicklung mit Volt M...
 
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
 

Modulare Enterprise Systeme - Eine Einführung

  • 1. Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Vorstellung und Einführung
  • 2. Ein beliebiger Zeitpunkt in einem beliebigen Unternehmen z.B. bei com.my.company © 2014 Andreas Weidinger at Integrating Architecture de Seite: 2
  • 3. Die IT Landschaft von com.my.company Frontends FTP Server HOST CRM SCM UNIX Server IRX CMG VCX HR FI Backend SAP MQ Standalone AS-1.0 + AS-3.2 CRM-OV KM-UX W F M CRX PM-UX SFE CM DOC KM KTDB DWDB IDB KMX-DB Service Bus (ESB) AFR AMS E X T E R N A L S = com.my.XML1 © 2014 Andreas Weidinger at Integrating Architecture de Seite: 3
  • 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: 4
  • 5. Wo und Wie wird die neue Anforderung umgesetzt? Frontends FTP Server HOST CRM SCM UNIX Server IRX CMG VCX HR FI Backend SAP MQ Standalone AS-1.0 + AS-3.2 CRM-OV KM-UX W F M CRX PM-UX SFE CM DOC KM KTDB DWDB IDB KMX-DB Service Bus (ESB) AFR AMS E X T E R N A L S = com.my.XML1 © 2014 Andreas Weidinger at Integrating Architecture de Seite: 5
  • 6. Wo und Wie wird die neue Anforderung umgesetzt? © 2014 Andreas Weidinger at Integrating Architecture de Seite: 6
  • 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: 7
  • 8. Wie auch immer in einer modularen Welt ist die Antwort eine völlig andere © 2014 Andreas Weidinger at Integrating Architecture de Seite: 8
  • 9. In einer modularen Welt ist die Antwort: Ein Modul oder eine Modulversion in einem Modulrepository © 2014 Andreas Weidinger at Integrating Architecture de Seite: 9
  • 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: 10
  • 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/myrepoXY/) System 1 com.my.CustomerAdjustment-1.0.0 com.my.ModuleXY-2.0.1 … usw. com.my.xy.ServiceZ-3.5.0 System N … usw. © 2014 Andreas Weidinger at Integrating Architecture de Seite: 11
  • 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: 12
  • 13. In einer modularen Systemlandschaft sind Module die gemeinsame Sicht aller Beteiligten © 2014 Andreas Weidinger at Integrating Architecture de Seite: 13
  • 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: 14
  • 15. Das ist nett – aber das ist noch keine funktionsfähige Software in der Anwendungslandschaft! © 2014 Andreas Weidinger at Integrating Architecture de Seite: 15
  • 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 dynamische JEE Server Verwaltung Clients manager.getModule( „com.my.ServiceXY“ ) module.doBizzMethod © 2014 Andreas Weidinger at Integrating Architecture de Seite: 16
  • 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: 17
  • 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: 18
  • 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 Modul Repository Clients neutrale Middleware API manager.getModule( „com.my.ServiceXY“ ) module.doBizzMethod Session Dienste Web Dienste … usw. ein Client kennt nur die Verwaltung, die ihm transparent Module zur Verfügung stellt © 2014 Andreas Weidinger at Integrating Architecture de Seite: 19
  • 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: 20
  • 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: 21
  • 22. Und die Client Seite? © 2014 Andreas Weidinger at Integrating Architecture de Seite: 22
  • 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 © 2014 Andreas Weidinger at Integrating Architecture de Seite: 23
  • 24. Integrating Architecture IT Consulting Andreas Weidinger Mobile: 0160 97627398 Mail: info@integrating-architecture.de Home: www.integrating-architecture.de
  • 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 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: 25
  • 26. 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: 26
  • 27. Backup – Client Server 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: 27
  • 28. Backup – Schwachstellen der 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: 28