Modulare Enterprise Systeme - Eine Einführung

Ein einheitliches Modulsystem

für verteilte Unternehmensanwendungen

Vorstellung und Einführung

Integrating ArchitectureApps for the Enterprise

© 2014 Andreas Weidinger at Integrating Architecture de Seite: 2

Ein beliebiger Zeitpunktin einem beliebigen Unternehmen

z.B. bei

com.my.company


Die IT Landschaft von com.my.company

HOST

Frontends CRM SCM

UNIX Server

VCXCMGIRX

BackendKTDB 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


Ein Fachbereich hat eine neue Anforderungund die IT soll sie umsetzen

z.B.eine Funktion: zum Abgleich von Kundendaten


Wo und Wiewird die neue Anforderung umgesetzt?

HOST

Frontends CRM SCM

UNIX Server

VCXCMGIRX

BackendKTDB 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



� 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.


Wie auch immerin einer modularen Welt

ist die Antwort eine völlig andere


In einer modularen Welt ist die Antwort:Ein Modul oder eine Modulversion

in einem Modulrepository


In einem modularen System gib es zweiuniverselle, zentrale Gegenstände

Modul – und – Repository

1 - natürlich kann es mehrere Repositories geben

1


Was ist ein Modul?Und was ist ein Modul Repository?

ein zentrales Verzeichnismit Unterverzeichnissen

eine Moduldatei miteindeutigem Modulnamen

Ein Modul ist eine

abgegrenztefachliche oder technische Funktionalität

Modul Repository (/var/myrepoXY/)

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.


An dem eindeutigen Modul(namen) können allebenö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


In einer modularen Systemlandschaft sind Module die gemeinsame Sicht aller Beteiligten


Module können beliebige Anforderungen undbeliebige Teile einer Systemlandschaft abbilden

- Module können frei skalieren – von einer ganzen Anwendung bis hin zu einer einzelnen Funktion


Das ist nett – aberdas ist noch keine funktionsfähige

Software in der Anwendungslandschaft!


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 ServerdynamischeVerwaltung

Clients

manager.getModule(„com.my.ServiceXY“

)

module.doBizzMethod


Das sieht aus wie ein übliches,aber proprietäres JEE Bus/Broker System

mit allen Problemen einer jeden JEE Anwendung!?!

Ist es aber nicht!


Der Broker ist KEINE übliche JEE Anwendung undbesitzt 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-Softwaresind NUR die Module

und die sind technologie- bzw. plattformunabhängig


Der Broker ist KEINE übliche JEE Anwendung undbesitzt 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.


� 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 dieversioniert und austauschbar sind


Welche Protokolle und Datenformatewerden 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


Und die Client Seite?


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 Systemdas ist alles – auf dem Client wie auf dem Server

Andreas Weidinger

Mobile: 0160 97627398Mail: [email protected]: www.integrating-architecture.de

Integrating ArchitectureIT 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

ServerModule

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 Schicht

und 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

Connector

multi

Protokoll

http

Service Consumer

Any ApplicationConnector

multi

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

Modulare Enterprise Systeme - Eine Einführung

Software

Transcript of Modulare Enterprise Systeme - Eine Einführung