Enterprise Application Integration. 1. Grundlagen, Konzepte und Architekturen

Transkript

1 Enterprise Application Integration 1. Grundlagen, Konzepte und Architekturen

2 1.1 Allgemeine Grundlagen der Begriff EAI: Anwendungsintegration Enterprise Application Integration (EAI) befasst sich mit der Anwendungsintegration auf innerbetrieblicher oder zwischenbetrieblicher Ebene EAI umfasst: Methoden Standards und Technologien Architekturkonzepte 2

3 Gründe für EAI-Projekte verbesserte Wettbewerbsfähigkeit durch Erhöhung der Effizienz und Effektivität von Geschäftsprozessen (Prozessoptimierung, Beseitigung von Medienbrüchen und Redundanzen, Vermeidung manueller Nacharbeiten und Kontrollen) Steigerung der Kundenzufriedenheit (Verbesserte Auskunftsbereitschaft, geringere Durchlaufzeiten, höhere Qualität) neue Geschäftsprozesse Unternehmenszusammenschlüsse, Übernahmen Sicherung der Investitionen in bestehende Anwendungen Erhalt des in Altanwendungen enthaltenen Wissens 3

4 Anforderung: Beispiel: Versandhaus durchgängige Unterstützung der Geschäftsprozesse durch IT Problem: Abteilungen verwenden jeweils spezifische IS Auftrags- und Kundendaten werden zum Teil redundant verwaltet Informationsaustausch durch unterschiedliche Plattformen, Datenformate und Architekturen eingeschränkt 4

5 Heterogene Informationssystemlandschaften Windows Unterschiedliche Schnittstellen Standardsoftware IS Fakturierung Unterschiedliche Plattformen IS Auftragsbearbeitung C++, Oracle Versandhaus IS Debitorenbuchhaltung Client Server Anwendung Unterschiedliche Architekturen IS Warenwirtschaft Monolithische Mainframe Anwendung ohne Schnittstellen LINUX J2EE IS Logistik Unterschiedliche Frameworks und Technologien Monolithisch aufgebaute Applikationen ohne Schnittstellen 5

6 Heterogenität Technische Heterogenität Unterschiede auf der Ebene der technischen Infrastrukturen wie DBMS, Hardwareplattformen, Betriebssysteme und Netzwerkkomponenten. Syntaktische Heterogenität Unterschiede in der Datenmodellierung (z.b. relational vs. OO) Schemakonflikte durch uneinheitliche Verwendung von Modellierungskonstrukten (z.b. Vererbung vs. Delegation) Datenkonflikte durch Auswahl unterschiedlicher Objekteigenschaften oder Einsatz uneinheitlicher Bezeichner, Datentypen, Wertebereiche und Skalierungen für semantisch vergleichbare Objekte 6

7 Heterogenität Semantische Heterogenität für ähnliche Konzepte in verschiedenen Systemen unterschiedliche Darstellungen z.b. Mitarbeiter vs. Angestellter Organisatorische Heterogenität Systeme sind räumlich getrennt unterstehen unterschiedlichen Verantwortlichen 7

8 Beispiel: Heterogenität des Datenmodells OO: relational: 8

9 Beispiel: Datenheterogenität Homonyme: Prozess (-> Geschäfts~) Prozess (-> jur. Prozess) Synonyme: Mitarbeiter Angestellte Datentypen: int String (zur Zahlendarstellung) Skalierung: 1,75 m 175 cm Genauigkeit: 0,5276 kg 0,53 kg Integritätsbedingung: Gehalt < 8000 Gehalt < 9000 unterschiedliche Schreibweisen: Weseler Strasse, Weselerstr., Weseler-Straße, etc. Fehler: Tippfehler, Programmfehler, veraltete Daten 9

10 Beispiel: Daten- u. Schema-Heterogenität 10

11 innerbetrieblich zwischenbetrieblich Integrationsreichweite 11

12 1.2 Konzepte und Architekturen der Anwendungsintegration Integrationstopologie: Punkt-zu-Punkt-Integration Bus-Topologie Hub-and-Spokes-Topologie Integrationsebene: Datenintegration Funktionsintegration Benutzerschnittstellenintegration 12

13 Punkt-zu-Punkt-Integration bedarfsgetriebene Verbindung durch spezifische Schnittstellen Vorteile: in überschaubaren Integrationsszenarien einfach zu realisieren Nachteile: enge Kopplung der Systeme hoher Wartungs- und Anpassungsaufwand durch viele Schnittstellen zur vollständigen Integration von n Systemen: (n*(n-1))/2 Schnittstellen 13

14 Bus-Topologie Integrationsfunktionalität dezentral implementiert Vorteile: niedrige Anzahl an Schnittstellen flexible Anpassung an Performanz- und Verfügbarkeitsanforderungen Nachteile: mögliche Redundanz bei den Infrastrukturfunktionalitäten Overhead durch Koordination und Verwaltung der dezentralen Einheiten 14

15 Hub-and-Spokes-Topologie Vorteile: niedrige Anzahl an Schnittstellen Anbindung neuer Systeme mit geringem Aufwand möglich Nachteile: zentraler Hub bietet grundlegende Infrastrukturdienste Verbindung der Anwendungen über Hub standardisierte Schnittstellen hoher initialer Aufwand für die Einrichtung der Integrationsinfrastruktur Hub ggf. Performanz-Engpass oder Single Point of Failure 15

16 Integration auf Datenebene Integration durch Zusammenführung der Daten Datenbank Gateways JDBC ODBC Zugriff auf die Daten einer Anwendung unmittelbar über ihre Datenbank Anwendungslogik und Präsentationsschicht werden dabei umgangen 16

17 Integration auf Datenebene Überwindung der Syntaktischen Heterogenität auf Datenmodell-, Schema- und Datenebene durch Transformation der Daten Abbildung der zu integrierenden Daten auf ein gemeinsames Schema lokale Schemata als Sichten auf das globale Schema 17

18 Behebung von Datenheterogenitäten Transformation in ein gemeinsames Datenmodell zur Beseitigung von Datenmodellkonflikten Beseitigung von Schemaheterogenitäten durch Abbildung der unterschiedlichen Schemata auf ein globales Referenzschema explizite Wertabbildung durch mathematische Funktionen oder Tabellen beseitigt Heterogenitäten bzgl. Bezeichnungen, Skalierungen und Genauigkeiten explizite Typumwandlung zur Überführung von Datentypen Ähnlichkeitsmaße zur Identifikation ähnlicher Werte (bei Tippfehlern, unterschiedliche Schreibweisen) Verwendung einer Ontologie zur Behandlung semantischer Datenheterogenität (z.b. Synonyme) 18

19 Integration auf Datenebene: Eigenschaften Vorteile: einfachzu realisieren, da keine Anpassung in den Datenstrukturen oder der Anwendungslogik des zu integrierenden Systems erforderlich Anbindung neuer Systeme auch möglich, wenn kein Quellcode verfügbar Nachteile: semantische Probleme (z.b. Verletzung von Integritätsbedingungen), wenn bei schreibenden Zugriffen auf die Daten eines Systems die in der Anwendungslogik hinterlegten semantischen Informationen ignoriert werden keine Nutzung der Geschäftsslogik einer Anwendung möglich Änderungen an den Datenstrukturen eines integrierten Systems führen zu Anpassungen an den Transformationen, dem globalen Datenmodell und ggf. an Klienten 19

20 Integration auf Funktionsebene Integration durch Zugriff auf die Geschäftslogik der zu integrierenden Anwendungen Zugriff über: RPC RMI CORBA EJB (Java EE) DCOM MOM semantisch reichhaltigste und flexibelste Art der Anwendungsintegration 20

21 Integration auf Funktionsebene: Eigenschaften Vorteile: semantisch reichhaltigste Art der Integration nicht nur Zugriff auf Daten, sondern auch auf Geschäftslogik Nutzung der Integritäts- und Plausibilitätsprüfungen einer Anwendung vermeidet Integritätsprobleme auch bei schreibenden Zugriffen Nachteile: aufwändig zu realisieren; daher vergleichsweise hohes Risiko unzureichendes Schnittstellenangebot erfordert Anpassung der Anwendung bzw. Wrapper schwierig umzusetzen, wenn entsprechende Schnittstellen fehlen oder nicht dokumentiert sind 21

22 Integration auf Präsentationsebene Integration durch Einbindung der Benutzerschnittstelle einer Applikation mittels geeigneter Werkzeuge Screen Scraping WSRP HttpUnit nur angewendet, wenn andere Integrationsansätze aufgrund fehlender Schnittstellen und Anpassungsmöglichkeiten ausscheiden Performanznachteile und geringe Flexibilität 22

23 Integration auf Präsentationsebene: Vorgehen Verbindung zu einer Anwendung durch Parsen der Bildschirminhalte und Simulation eines Benutzerdialoges oft verwendet zur Integration von HTML-Seiten zur Anbindung von Legacy-Systemen bei fehlenden Schnittstellen, unzureichender Dokumentation und monolithischem Systemaufbau 23

24 Integration auf Präsentationsebene: Eigenschaften Vorteile: mit geeigneten Werkzeuge schnell und einfach zu realisieren auch einsetzbar, wenn Anwendung keine API bereitstellt und der Quellcode nicht verfügbar ist in schwierigen Integrationsszenarien oft die einzige Alternative Nachteile: keine Integration der zugrunde liegenden Daten und Funktionen schlechte Performanz und Skalierbarkeit geringe Flexibilität und Wiederverwendbarkeit 24

25 1.3 Funktionaler Aufbau einer EAI-Infrastruktur Prozessmodellierung, Ablaufsteuerung, Prozessbenchmarking Transformationsdienste, Nachrichtenverwaltung, Synchronisation, Transaktionskontrolle Prozessmanagement Nachrichtenmanagement Middleware... System-/ Dienstmanagement, Identitätsmanagement, Administrationswerkzeuge Anwendung 1 Anwendung n 25

26 Adapter Anbindung einer Anwendung über angepasste Schnittstelle übernimmt häufig elementare Transformationsdienste Direkte Integration über eine API Funktionsintegration über einen Adapter (Wrapper) Middelware API Anwendung Wrapper 26

27 Middleware / Nachrichtenmanagement Infrastruktur zur Kommunikation zwischen den Anwendungen überbrückt Heterogenität sichert ggf. zuverlässigen Nachrichtenaustausch Ggf. regelbasierte Verteilung von Nachrichten (intelligentes Routing) Unterstützung von Transaktionen Bereitstellen von Benachrichtigungsdiensten Datentransformationen (soweit nicht durch Adapter) 27

28 Kommunikationsformen Synchrone Kommunikation: Sender übermittelt Nachricht an Empfänger und wartet auf Antwort in zeitkritischen Anwendungsszenarien unerlässlich Ausfall des Empfängers oder Verlust von Nachrichten blockieren den Sender Asynchrone Kommunikation: Sender übermittelt Nachricht an Empfänger und wartet nicht (sofort) auf Antwort oft: unzustellbare Nachrichten persistent gespeichert, bis Empfänger wieder verfügbar kann synchrone Kommunikation nachbilden die Zustellung und Verwaltung der Nachrichten benötigt eine komplexe Infrastruktur 28

29 Funktionsorientiert: Integrationsparadigmen Kommunikation über Aufruf von Prozeduren und Funktionen fehlende Kapselung der Funktionalitäten bewirkt ggf. enge Kopplung Objektorientiert: stellt Funktionalitäten als Methoden in verteilten Objekten bereit Kapselung und Zugriff durch definierte Schnittstellen Dienstorientiert: Dienste sind meist grobgranular und durch Schnittstellenbeschreibung definiert Dienste können oft in Verzeichnis gesucht und zur Laufzeit eingebunden werden Zugriff auf Dienste erfolgt oft nachrichtenbasiert und lose gekoppelt 29

30 Ordnungsrahmen Integrationstechnologien Durch Kombination einzelner Technologien lassen sich deren Vorteile gezielt nutzen und Schwächen umgehen EJBs können z.b. in Verbindung mit Web Services zur Implementierung einer auf Objektorientierung basierenden sowie Dienst- und Nachrichtenorientierten Integrationsinfrastruktur genutzt werden 30

31 Prozessmanagement ermöglicht das Zusammenspiel einzelner Anwendungen und somit eine Prozessintegration Modellierung, Durchführung, Steuerung und Überwachung von Geschäftsprozessen integrierte Anwendungen implementieren einzelne Schritte übergeordneter Geschäftsprozesse Modellierung der Prozesse und ihrer Informationsflüsse erfolgt unabhängig von der Implementierung der einzelnen Prozessbausteine 31

32 Metadatenbank und Zusatzdienste verwaltet zentrale Informationen, welche für die gesamte EAI-Lösung und alle integrierten Anwendungen relevant sind Verwaltung von Diensten, Ressourcen, Benutzern und Berechtigungen Authentifizierung und Autorisierung von Benutzern (Identitätsmanagement) Protokoll- und Monitoringfunktionen zur Überwachung von Diensten und Interaktionen Bereiststellung von Administrations- und Entwicklungswerkzeugen zur Überwachung, Wartung und Anpassung der Integrationsinfrastruktur 32

33 1.4 Integrationstechnologien Funktionsorientierte und synchrone Integrationstechnologien Remote Procedure Call (RPC): Protokoll für Aufruf entfernter Prozeduren / Funktionen abstrahiert von Übertragungsdetails (z.b. Marshalling, Demarshalling) i.d.r. synchron Remote Method Invocation (RMI): ermöglicht den Zugriff auf Methoden in entfernter Objekten ansonsten vergleichbar mit RPC 33

34 Nachteile von RPC / RMI nicht Plattform-unabhängig (RPC) und nicht Programmiersprachenunabhängig (RPC/RMI) Sender kann durch Ausfall des Empfängers oder Verlust von Nachrichten blockiert werden Unflexibel, da Adressierungsinformationen des Empfängers im Quellcode des Senders codiert sind (keine Adressierung zur Laufzeit) 34

35 Synchrone OO-Integrationstechnologien Common Object Request Broker Architecture (CORBA) Komponentenarchitektur der OMG (Object Management Group) macht Anwendungen als verteilte Objekte zugänglich Kommunikation basiert auf RMI (inkl. Marshalling) Plattform-unabhängige Schnittstellenbeschreibung mittels Interface Definition Language (IDL) Eigenschaften der zugrunde liegenden Hardwareplattform und Netzwerkinfrastruktur bei entferntem Methodenaufruf transparent Vereinfachtes Auffinden von Objekten durch Repositoryfunktionen 35

36 Entfernter Methodenaufruf am Bsp. von CORBA Definition von Schnittstellen mittels Interface Definition Language (IDL) IDL Compiler erzeugt mittels der Schnittstellenbeschreibung auf der Clientseite einen Stub und serverseitig ein Skeleton der Client A ruft den Stub lokal auf dieser übergibt den Aufruf an den ORB (Object Request Broker) serverseitig übergibt der ORB diesen an das Skeleton dieses ruft das entfernte Objekt B lokal auf das Ergebnis geht in umgekehrter Richtung von B über Skeleton, ORB und Stub an A 36

37 Einschränkungen von CORBA und DCOM nur eingeschränkt Programmiersprachen-unabhängig (OO) Interoperabilität der verschiedenen CORBA-Implementierungen problematisch keine vollständige Plattformunabhängigkeit bei DCOM (MS) 37

38 Enterprise JavaBeans Framework zur Entwicklung objektorientierter, komponentenbasierter und verteilter Anwendungen in Java Enterprise JavaBeans (EJB) repräsentieren dabei die Komponenten transaktionsorientierter verteilter Geschäftsprozesse 38

39 Eigenschaften von Enterprise JavaBeans objektorientiert plattformunabhängig serverseitig eingesetzt ggf. verteilt Persistenz automatisch Transaktionskontrolle Sicherheit (Authentifizierung und Autorisierung) können zu komplexen Anwendungen kombiniert werden 39

40 Einsatz von Enterprise JavaBeans Einsatz erfolgt im Kontext eines EJB-Containers Container verwaltet EJBs Container bietet Infrastrukturfunktionalitäten (Namensvergabe, Lebenszyklussteuerung, Persistenz, Messaging, Sicherheit, Transaktionskontrolle) Container ist Teil eines JavaEE-Applikationsservers (z.b. JBoss, WebSphere) 40

41 EJB: Architekturübersicht Client Java EE Server EJB Container EJB OODBMS DBMS Remote Interface Transactions, Naming, Persistance, Security Präsentationsschicht Geschäftslogik & Zusatzdienste durch EJB Container Datenhaltungsschicht 41

42 Eigenschaften von Enterprise JavaBeans Vorteile: Plattform-unabhängig und objektorientiert Container stellt grundlegende Infrastrukturdienste wie Persistenz, Transaktionen und Sicherheit zur Verfügung mit Java Messaging Service (JMS) zur Implementierung asynchroner Kommunikation verwendbar Nachteile: nicht Programmiersprachen-unabhängig keine Konfiguration und Integration von Anwendungen zur Laufzeit 42

43 Message Oriented Middleware (MOM) Kommunikation über Nachrichten asynchrone Aufrufe zwischen Client- und Serveranwendungen möglich aber nicht zwingend Nachrichten werden in Warteschlangen zwischengespeichert und an Ziel- Anwendung weitergereicht Nachrichtenaustausch unabhängig von Plattformen und Technologien Nachrichten enthalten sowohl Daten als auch Meta- und Kontrollinformationen Multicasting: mehrere Empfänger möglich 43

44 Service Orientierte Architekturen (SOA) SOA ist ein Integrationskonzept und keine konkrete Technologie Dienste sind modulare, durch eine Schnittstelle definierte und durch eine Anwendung implementierte fachliche Funktionalitäten Dienste repräsentieren wiederverwendbare Geschäftsprozessbausteine Elementare Dienste lassen sich zu komplexeren Diensten zusammenfügen (orchestrieren) Dienste können über ein öffentliches Verzeichnis anhand ihrer Beschreibung aufgefunden, ausgewählt und zur Laufzeit eingebunden werden Die Kommunikation zwischen einzelnen Diensten sollte zeitlich (asynchron) und logisch (Kapselung) entkoppelt stattfinden 44

45 Interaktionen in einer SOA Service-Anbieter: stellt Dienste zur Verfügung publiziert Dienste in Service- Registry Service-Registry: verzeichnet, wo Dienste gefunden werden können Service-Konsument: findet Dienst in Registry bindet Dienst anhand seiner Beschreibung ein 45

46 Webservices lose gekoppelt (Schnittstelle und Dienstbeschreibung unabh. von Implementierung) wiederverwendbar werden unter Einsatz XML-basierter Standards beschrieben und aufgefunden Interaktion auf der Grundlage XML-basierter Nachrichten Protokoll-unabhängig (verschiedener Protokolle für Nachrichtentransport möglich) 46

47 SOAP XML-basiertes Format zum Nachrichtenaustausch mit Webservices kann verschiedene Internetprotokolle (HTTP, SMTP) als Transport - Mechanismus nutzen Nachricht besteht aus Header mit Kontrollinformationen und Body mit Nutzdaten SOAP kommuniziert normalerweise über einen asynchronen Request/ Response Zyklus (vgl. HTTP) mit SOAP RPC kann ein RPC-ähnlicher synchroner Kommunikationsmechanismus realisiert werden 47

48 WSDL (Web Service Description Language) XML-basierte Sprache zur Beschreibung eines Dienstes und seiner Schnittstelle Beschreibung ist unabhängig von konkreten Transportprotokollen und Programmiermodellen Eine WSDL-Beschreibung spezifiziert: Funktionalität des Dienstes URI zur Adressierung wie erfolgt der Zugriff auf den Dienst Gestaltung der Schnittstelle 48

49 UDDI (Universal Description, Discovery and Integration) Verzeichnisdienst zur Registrierung und zum Auffinden von Webservices ist als Webservice realisiert und kann über SOAP-Nachrichten angesprochen werden Das UDDI-Verzeichnis enthält folgenden Informationen: White Pages: Register aller Webservice-Anbieter mit Detailangaben, wie Ansprechpartner, Kontaktinformationen, etc. Yellow Pages: ermöglicht Suche gemäß Kriterien wie Ort, Industriezweig, Produkte, Dienstleistungen des Anbieters, etc. Green Pages: enthält Dienst-Beschreibungen, Zugriffsinformationen und Verweis auf WSDL-Definitionen 49

50 Webservice-Interaktionen Service-Anbieter: stellt Dienste zur Verfügung und beschreibt diese mit WSDL UDDI-Registry: Ermöglicht das Registrieren und Auffinden von Webservices Service-Konsument: Findet Dienst in der Registry bindet den Dienst anhand seiner WSDL-Beschreibung ein und ruft ihn mittels SOAP auf 50

51 Eigenschaften von Webservices Vorteile: Plattform-, Programmiersprachen- und Protokoll-unabhängig Flexibel und Interoperabel durch Verwendung offener Standards Adressierung, Konfiguration und Integration zur Laufzeit möglich Unterstütztung asynchroner und synchroner Kommunikation Nachteile: Perfomanznachteile durch Nachrichtenhandling und XML-Verarbeitung Schutz sensibler Daten kann nur durch Einsatz weiterer Standards (XML-Encryption, WS-Security, etc.) gewährleistet werden 51

52 Business Process Execution Language (BPEL) XML-basierte Sprache zur Beschreibung von Geschäftsprozessen, deren Baussteine (Aktivitäten) durch Webservices implementiert sind definiert die Ausführungsreihenfolge (Orchestration) der Einzelschritte von Prozessen sowie Nebenbedingungen und Ausnahmebehandlung durch BPEL beschriebene Geschäftsprozesse stellen selbst Webservice dar Zielsetzung: Konfiguration der Prozesslogik anstatt Programmierung benötigt zur Ausführung eine BPEL-Laufzeitumgebung (z.b. ActiveBPEL) 52

53 Vorteile: keine Implementierung von Prozesslogik durch Service-Konsumenten basiert auf etablierten Standards ähnliche Mächtigkeit wie Petri-Netze bei Verfügbarkeit entsprechender Werkzeuge ist eine Modellierung komplexer Workflows ohne Programmierung möglich Nachteile: Eigenschaften von BPEL Beschreibung der Geschäftsprozesse semantisch unpräzise geringes Angebot an ausgereiften Modellierungswerkzeugen 53