Enterprise Application Integration - home.hs

Enterprise Application Integration
Prof. Dr. Christian Pape
Übersicht
ƒ Überblick
à Literatur
à Was ist EAI?
à Warum EAI?
ƒ Anwendungsfelder
EAI
1-2
Themen
ƒ Übersicht, Beispiele EAI
ƒ Wiederholung / Vertiefung Verteilte Systeme
à Referenzarchitekturen
à J2EE Entwurfsmuster
à CORBA
ƒ EAI Produkte
ƒ EAI Entwurfsmuster
ƒ Evtl. praktische Übung zum Vorlesungsende
EAI
1-3
Literatur
ƒ Wolfgang Keller (Einführung)
„Enterprise Application Integration“
dpunkt Verlag
ƒ Gregor, Hohpe, Bobby Woolf
„Enterprise Integration Patterns“
Addison-Wesley
ƒ Vorlesungsfolien, Übungsblätter:
http://www.home.hs-karlsruhe.de/~pach0003/eai.html
EAI
1-4
Was ist EAI?
ƒ Allgemeine Definition existiert nicht
ƒ EAI: Enterprise Application Integration
à Enterprise: Unternehmen
à Application: Softwareanwendungen
à Integration
ƒ EAI
à Heterogene Softwareanwendungen eines
Unternehmens zusammenbringen, um
unternehmensweite Geschäftsprozesse einheitlich
abzubilden
ƒ Focus Vorlesung
à Heterogene Technik, nicht Prozesse
EAI
1-5
Was ist EAI?
ƒ
Heterogene Technologien
à
à
ƒ
Ändernde Geschäftsprozesse
à
à
ƒ
Homogene Systeme einfach zu integrieren
Alles J2EE Anwendungen mit EJBs, dann kann EJB einer Anwendung
problemlos von anderer verwendet werden
Systeme sind oft Insellösungen zu einem geänderten Geschäftsprozess
Marketingabteilung lässt Datenbank für Pflege von Kundendaten
hinsichtlich Werbezwecke entwickeln (ohne Verbindung zu bestehenden
Kundeninformationssystemen)
Resultat Menge von Stove-pipe-systems
à
nicht vernetzte isolierte Systeme unterschiedlichster Technologie
W2K,
ASP.Net,
MS SQL Server
MVS
3270 Terminal Appl.
DB2
J2EE
EAI
1-6
Was ist EAI?
ƒ Fiktives Beispiel Bank
à Bank verwaltet Konten von Privatkunden
à Prozesse: Konto anlegen, Geld abheben, Zinsen
verbuchen, …
à Softwaresystem dazu, vor 25 Jahren eingeführt
à Technik: COBOL, 3270 Terminal-Emulation und
zentrale Server.
à Software wird im Intranet z.B. an Kassenschalter
verwendet
EAI
1-7
Was ist EAI?
ƒ
Geschäftsprozesse ändern sich
à
à
ƒ
Technik hat sich in 20 Jahren stark gewandelt
à
à
ƒ
15 Jahre später: Geld Automaten ersetzen zunehmend
Kassenpersonal
20 Jahre später: Internetbanking
Geldautomat und Internetanwendung muss Zugriff auf
Konten haben
Zugriff auf alte Bankwendung problematisch
Lösungsalternativen
1. Alte Anwendung durch neue ersetzen
2. Wege suchen, alte Anwendung weiter zu verwenden
EAI
1-8
Was ist EAI?
1. Alte Anwendung ersetzen
à
à
à
à
à
ƒ
à
Teuer (50 Millionen €)
Risikoreich (Projekt könnte scheitern)
Entwicklung und Einführung dauert 2-3 Jahre
(Internet Banking soll aber in 1.5 Jahren
eingeführt sein)
Branchenwissen der COBOL Entwickler geht
verloren
…
Fazit
Die Investition alter Anwendungen ist oft zu
hoch, um sie zu ersetzen
EAI
1-9
Was ist EAI?
2. Wege suchen, alte Anwendung weiter zu
verwenden
ƒ
ƒ
ƒ
EAI Produkte und Methoden einsetzten, um
Technologie Hürden zu überwinden
Alte Anwendung schrittweise modernisieren
Heterogene Systeme integrieren
Internetbanking
Geldautomaten
?
EAI
Alte
Banklösung
1-10
Was ist EAI?
ƒ Abgrenzung zu B2B (B2C)
à Business to Business (Customer)
à Integration von System und
Geschäftsprozessen verschiedener
Unternehmen
à Meist über das Internet oder WWW
à Elektronische Handelsplätze (für
Geschäftskunden)
EAI
1-11
Was ist EAI?
EAI
B2B
Internetbanking
Unternehmen
A
Automaten
Unternehmen
B
Unternehmen
C
Alte
Banklösung
Bankanwendung im Intranet
elektronischer Handelsplatz
im Internet
EAI
1-12
Was ist EAI?
ƒ B2B und EAI
à Unterschiede geringfügig
à Werkzeuge für B2B ähnlich zu EAI
à Sicherheitsanforderungen bei B2B zu EAI
restriktiver
ƒ Ansonsten: Probleme und
Herausforderungen ähnlich
à Technologien überbrücken
à Prozesse neu gestalten
EAI
1-13
Übersicht
ƒ Überblick
à Literatur
à Was ist EAI?
à Warum EAI?
ƒ Anwendungsfelder
EAI
1-14
Warum EAI?
ƒ
Trends, die zur Integration von ITSystemen führen:
1. Time-to-market
2. Zurechtschneidern halbfertiger
Anwendungen, statt Eigenentwicklung
3. Unternehmensfusionen und –
aufspaltungen
EAI
1-15
Warum EAI?
ƒ Time-to-market
à Produktzyklen werden immer geringer
(Mobiltelefon- oder DSL-Abos)
à Neue Produkte müssen immer schneller
eingeführt werden (Voice over IP, TV über
Internet)
à Hat oft neue Prozesse zur Folge (TV bei
Telekommunikationsunternehmen bestellen)
ƒ Neue Prozesse Î IT-Anwendungen müssen
angepasst werden
EAI
1-16
Warum EAI?
ƒ Zurechtschneidern halbfertiger Anwendungen
à Statt teure Eigenentwicklung, Einführung von
„Standard“ Software wie SAP R/3.
à Anwendung im Quelltext ausgeliefert
Î Anbindung z.B. für eigenes Logistiksystem, CRM
System, Webshop nötig
à MOTS (Modifiable off the shelf): Anwendung
halbfertig, muss – teilweise im Quelltext –
angepasst werden
à COTS (Custom off the shelf): Anwendung fix und
fertig, leicht installierbar (z.B. Textverarbeitung)
EAI
1-17
Warum EAI?
ƒ Unternehmensfusionen und Aufspaltungen
à Aufspaltung: Abspaltung von T-Online von T-Com
à Merger & Akquisition (MA)
- Verschmelzen von T-Com und T-Online (2005)
- Übernahme Debis von T-Systems (2000)
à Verschmelzung
Î Unterschiedliche Systeme verschmolzener
Unternehmen integrieren, doppelte abschafften (z.B. nur
ein Lohnbuchhaltungssystem)
à Aufspaltung
Î „verlorene“ Systeme ersetzen und integrieren (z.B.
neues Lohnbuchhaltungssystem)
EAI
1-18
Überblick
ƒ Zusammenfassung
à EAI beschäftigt sich mit der Integration
heterogener Anwendungen und der
zugrunde liegenden Prozesse in einem
Unternehmen
à EAI wird durch technologischen Fortschritt,
schnelleren Produktzyklen und sich stetig
ändernde Unternehmen bedeutender
EAI
1-19
Übersicht
ƒ Überblick
à Literatur
à Was ist EAI?
à Warum EAI?
ƒ Anwendungsfelder
à Multi-Channel-Architekturen
à Applikation-zu-Applikation Kommunikation
à Geschäftsprozessintegration
EAI
1-20
Multi-Channel-Architekturen
ƒ Mehrkanal-Architektur
ƒ Kanal: Vertriebskanal
Verkaufsanwendung
Kernanwendung
DWH / Statistikanwendungen
ERP, HR,
Buchhaltung
à Früher: Meist einige wenige Vertriebskanäle
à Heute: Viele verschiedene Vertriebskanäle
EAI
1-21
Multi-Channel-Architekturen
ƒ Beispiel Versicherung
Verkaufsanwendung
Kernanwendung
DWH / Statistikanwendungen
EAI
ERP, HR,
Buchhaltung
à Kanäle: Versicherungsvertreter, Partnerorganisationen,
Agenten
à Informationsfluss vom Kunden zur Versicherung
hauptsächlich Paper
à Eingabe Daten in einer Verkaufsanwendung (Frontoffice)
oder direkt im Kernsystem (Backoffice)
1-22
Multi-Channel-Architekturen
ƒ Neue Verkaufskanäle kommen hinzu
à
à
à
à
Webanwendung (Prämienberechnung Versicherung)
Off-line Anwendung für Laptop
Wiederverkäufer (Partner)
Call-center
Web
Laptop
Partner
Middleware
Kernanwendung (Backoffice)
EAI
Internet
Call-center
Intranet
1-23
Multi-Channel-Architekturen
ƒ Middleware
à Keine klare, fassbare Definition
à Minimal: Kommunikationsinfrastruktur zwischen
mehreren Systemen (oder Schichten)
ƒ Beispiele
à
à
à
à
Common Object Request Broker (CORBA)
Message Queue (MQ)
Transaktionsmonitor
EAI Produkte (z.B. MS BizTalk)
EAI
1-24
Multi-Channel-Architektur
n:m Kanäle
n:1 Kanäle
ƒ Ein Backoffice für n
Kanäle
ƒ m Hintergrundsysteme
für n Kanäle
EAI
1-25
Multi-Channel-Architektur
ƒ Extrem abstrakte Architektursicht
ƒ EAI in diesem Kontext
Wie soll Zielarchitektur sein?
(nicht-funktionale) Anforderungen
Übersicht der bestehenden Systeme
Einzusetzende Produkte, Middleware (MQ
oder Web Services oder ???)
à Zu entwickelnde Komponenten für diese
Produkte/Middleware?
à
à
à
à
EAI
1-26
Übersicht
ƒ Überblick
à Literatur
à Was ist EAI?
à Warum EAI?
ƒ Anwendungsfelder
à Multi-Channel-Architekturen
à Applikation-zu-Applikation Kommunikation
à Geschäftsprozessintegration
EAI
1-27
A2A Integration
ƒ Application to application (A2A) integration
à Häufigstes Verkaufsargument für EAI
à Dutzende von Client/Server Inselanwendungen
unterschiedlichster Technologie
à Anwendungen dieses Szenarios kommunizieren
direkt miteinander
à Schlimmster Fall: O(n2) Verbindungen
EAI
1-28
A2A Integration
ƒ Probleme bei A2A
à Zu viele direkte Verbindungen (Komplexität hoch)
à Viele verschiedene Technologien,
Kommunikationsprotokolle (System können nicht vernünftig
miteinander gekoppelt werden)
à Nicht normalisierte Schnittstellen (RPC, OO, Datenorientiert,
Granularität verschieden)
à Jedes System von anderen Personen (jahrelang) gewartet
(Wissen ist über gesamte Organisation verteilt)
IIOP
CRM
Sockets
COBOL
IIOP-COM Brücke
native
EJB
SQL
C
HTTP
Babylonische Sprachverwirrung:
Kein System versteht das andere
FTP
VB
ERP
EAI
1-29
A2A Integration
ƒ Typische Lösungsarchitekturen
à Softwarebus (CORBA, MQ)
à Dienst-orientierung (CORBA, WS)
à Hub and Spoke (EAI Produkten)
ƒ Typische Versprechungen
à
à
à
à
O(n) Abhängigkeiten
Schnellere Entwicklung, dank existierender Adapter
Zukunftssicheres Produkt
Geringere Betriebskosten
EAI Server
Bus (MQ, ORB)
CRM
EJB
C
COBOL
EAI
ERP VB
1-30
A2A Integration / Versprechungen
ƒ Mit HALs Autobuzz Technologie nur
noch O(n) Abhängigkeiten
Autobuzz
A1
A1
A2
An
An
A2
O(n2)
O(n)
EAI
1-31
A2A Integration / Versprechungen
ƒ A1 sendet Produktdaten an alle anderen
ƒ A2 sendet Auftragsdaten an alle anderen
ƒ Abhängigkeiten: 2(n-1) statt 2
à Sendendes System muss Daten (einmal) aufbereiten
(einheitliches Format)
à Jedes empfangendes System muss Daten spezifisch
verarbeiten (Adapter)
Autobuzz
A1
A2
A3
An
2(n-1) Adapter
O(n2) Abhängigkeiten eine Architekturstufe tiefer
EAI
1-32
A2A Integration / Versprechungen
ƒ Versprechungen kritisch gegenübertreten
à Welcher Architektursicht „verdangt“ Verkäufer sein Argument?
- Konzeptionelle Sicht auf Infrastruktur (Netzwerkverbindungen,
Hardware)?
- Funktionale Sicht auf Komponenten (Software)?
à Abhängigkeiten genauer untersuchen:
- Welche Aufgaben fallen bei A2A Integration an?
- Welche neuen Komponenten sind notwendig?
ƒ Bei A2A Integration
à Im schlimmsten Fall (alle Anwendungen kommunizieren
miteinander) immer O(n2) funktionale Abhängigkeiten (n =
Anzahl Systeme)
à Schlimmer noch: n = Anzahl Schnittstellen (Ein System kann
mehrere Schnittstellen haben)
EAI
1-33
Architektursichten
ƒ Zachman Framework for Architecture
à www.zifa.com
What
abstrakt
How
Where
Who
When
Why
Architekturebene
Scope
Business
Model
System Model
Technology
Model
Detailed
Representation
detailliert Implementation
EAI
1-34
Zachmann Framework
EAI
1-35
Architektursichten
What
How
Where
Who
When
Why
Scope
Business
Model
System Model
(logical)
O(n)
Technology
Model
Detailed
Representation
Implementation
O(n2)
EAI
1-36
Architektursichten
ƒ Verteilte Sicht (Where)
à (vermutlich) Verbesserung auf O(n)
ƒ Funktionale Sicht (How)
à Weiterhin O(n2), keine O(n)
ƒ Funktionale Sicht kann beträchtliche Kosten
verursachen
à Anforderungsanalyse pro Schnittstelle
à Implementierung
à Testen verteilter Komponenten
EAI
1-37
Übersicht
ƒ Überblick
à Literatur
à Was ist EAI?
à Warum EAI?
ƒ Anwendungsfelder
à Multi-Channel-Architekturen
à Applikation-zu-Applikation Kommunikation
à Geschäftsprozessintegration
EAI
1-38
Geschäftsprozessintegration
ƒ Prozess
à Eingabe (Antragsformular)
à Verarbeitung (Entscheidung über Antrag)
à Ausgabe (pos. Entscheid, Ablehnung)
ƒ Prozesse werden angestoßen
à Kundenbestellung (eShop, Anruf)
ƒ Prozesse können verzweigen
à Bestellung ausliefern und Inkasso betreiben
ƒ Prozesse enden
à Bestellung ausgeliefert
à Bestellung bezahlt
ƒ Prozesse können verschmelzen
à Bestellung ausgeliefert und bezahlt, löst
Teilnahme an einem Wettbewerb aus
EAI
1-39
Geschäftsprozessintegration
ƒ Unternehmen „bestehen“ aus Vielzahl von
Geschäftsprozessen
ƒ Geschäftsprozesse regeln
à abteilungsübergreifende Aufgabenteilung
à Verantwortlichkeiten von Personen/Rollen
à Entscheidungskompetenzen
ƒ Geschäftsprozesse ohne IT (bis ca. 1950)
à Eingabe: Papier (von einer anderen Abteilung)
à Verarbeitung: Mensch
à Ausgabe: Papier (geht an eine weitere Abteilung)
ƒ Heute
à Prozesse sind (teil)automatisiert, Eingabe, Verarbeitung,
Ausgabe elektronisch
EAI
1-40
Geschäftsprozessintegration
ƒ 1950 – heute
ƒ Ein noch manueller Prozess wird
automatisiert oder bereits automatisierte
Prozesse ändern sich. Folge:
à Bestehendes Softwaresystem erweitern oder
à Neues Softwaresystem dazu
à Jeweils neuer Teil in bestehende IT-Landschaft
integrieren
EAI
1-41
Geschäftsprozessintegration
Geschäftsprozess
A1
A3
A2
A4
Automatisierten Prozesse mit bestehenden Systemen
EAI
1-42
Geschäftsprozessintegration
Geschäftsprozess
Soll automatisiert
werden
A1
A3
A2
A4
Automatisierten Prozesse mit bestehenden Systemen
EAI
1-43
Geschäftsprozessintegration
Geschäftsprozess
A1
A2
A5
A3
A4
Neues System dazu
Manuelle Kommunikation mit bestehenden Systemen
wird automatisiert
EAI
1-44
Geschäftsprozessintegration
Geschäftsprozess
A1
A2
A5
A3
A4
Ein-/Ausgabe jetzt mit neuem System
EAI
1-45
Geschäftsprozessintegration
Geschäftsprozess
A1
A2
A5 A3
EAI
A4
Geschäftsprozess vereinfacht durch Automatisierung
EAI
1-46
Geschäftsprozessintegration
ƒ Geschäftsprozesse ändern immer
schneller
à
à
à
à
Kurze Produktzyklen
Fusionen
Outsourceing
Reorganisationen
ƒ Integrationsaufgaben im Unternehmen
nehmen zu
EAI
1-47
Kontextdiagramm
ƒ Beschreibung Schnittstellen System zu
Umwelt
ƒ Syntaktische Regeln
à Nur ein Prozess (Gesamtsystem), erhält
die Nummer 0.
à Mindestens eine Schnittstelle (Teilsystem)
à Zwischen Schnittstellen keine Datenflüsse
(Pfeile)
à Enthält keinen Speicher
à Jede Schnittstelle nur einmal vorhanden
Ausnahme: Übersichtlichkeit
EAI
0.
1-48
Kontextdiagramm
ƒ Semantische Regeln:
Beschreibt Anwendungsbereich des Systems
Zeigt Datenflüsse über die Systemgrenzen
Ist die Zusammenfassung von Diagramm 0
Kann es von derselben Schnittstelle mehrere
Instanzen geben, wird sie einmal dargestellt
à Schnittstelle muss ursprüngliche Quelle oder
Senke einer Information angeben
à Wahl einer Schnittstelle abstrahiert von der
konkreten Eingabe oder Ausgabe
à
à
à
à
EAI
1-49
Kontextdiagramm / Beispiel
ƒ Prozess 0
à Dekan erstellt Stundenplan für Studenten eines
Studiengangs und Semesters sowie für Dozenten
ƒ Schnittstellen
à Student
- Schreibt sich für einen Studiengang ein
à Dozent
- Meldet SWS pro Vorlesung dem Dekan
à Raumvergabe (System)
- Abfrage von Räumen
- Raum belegen und wieder freigeben
EAI
1-50
Kontextdiagramm / Beispiel
Student
Stundenplan
Stundenplan
Dozent
Anmeldung Studiengang
Raum belegen
0.
erstellt
Stundenplan
Freie Räume abfragen
Freie Räume
Raumvergabe
Raum freigeben
Meldung SWS pro Vorlesung
EAI
1-51
Kontextdiagramm
ƒ Angemessene Abstraktion der Datenflüsse
à Zu detailliert: unübersichtlich, überladen
à Zu abstrakt: nichts sagend
ƒ Leitfaden
à Außenstehenden müssen wesentlichen
Informationen über
die Umwelt erkennen
à Problembezogene Namensgebung
à Alle Datenflüsse auf selben Abstraktionsniveau
EAI
1-52
Kontextdiagramm
ƒ In der Geschäftsprozessintegration
à Kontextdiagramm für zu automatisierenden
Prozess aufstellen
à Datenflüsse mit umgebenden
Schnittstellen analysieren
ƒ Startpunkt für Entwurf Schnittstellen
à Anwender zu neuem System
à Bestehende Systeme zu neuem System
EAI
1-53