Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Aufbau Integrierter Informationssysteme Überblick über Basistechnologien Christina Reuter, David Kaiser, Thomas Hoffmann Martin-Luther-Universität Halle-Wittenberg.

Ähnliche Präsentationen


Präsentation zum Thema: "Aufbau Integrierter Informationssysteme Überblick über Basistechnologien Christina Reuter, David Kaiser, Thomas Hoffmann Martin-Luther-Universität Halle-Wittenberg."—  Präsentation transkript:

1 Aufbau Integrierter Informationssysteme Überblick über Basistechnologien Christina Reuter, David Kaiser, Thomas Hoffmann Martin-Luther-Universität Halle-Wittenberg Hauptseminar - Halle

2 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg2 Gliederung 1.Überblick über Basistechnologien 2.Middleware 3.Message Broker

3 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg3 Überblick - Gliederung 1.Gliederung in 4 Basisblöcke 2.Kommunikationsmodel 1.Synchrone Kommunikation 2.Asynchrone Kommunikation 3.Integrationsmethoden 1.Messaging 2.Interface 3.Connectors 4.Middleware 1.RPC 2.MOM 5.Services Überblick

4 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg4 Basisblöcke Unterteilung der EAI-Architektur in folgende 4 Basisblöcke 1.Kommunikationsmodel 2.Integrationsmethoden 4.Services 3.Middleware Überblick

5 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg5 = Empfänger Überblick 1.Kommunikationsmodel - Grundlagen Receiver Sender Request = AnfrageReply = Antwort

6 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg6 Überblick 1.Arten der Kommunikation Kommunikation SynchronAsynchron

7 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg7 Überblick Synchrone Kommunikation 1.Request / Reply SenderReceiver Request Blockt Bearbeitet Request Reply

8 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg8 Überblick Synchrone Kommunikation 2.One-Way SenderReceiver Request Blockt Empfangsbestätigung Bearbeitet Request

9 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg9 Überblick Synchrone Kommunikation 3.Synchrones Polling SenderReceiver Request Reply Bearbeitet Request Checks for Response Failure Continues Checks for Response Success Stoppt polling

10 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg10 Überblick Asynchrone Kommunikation 1.Message Passing SenderReceiver Message Sent continues Accepts Message + continues

11 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg11 Überblick Asynchrone Kommunikation 2.Publish / Subscribe Sender Receiver Subscription List Subscribe to Message B Subscribe to Message A Message A Sent continues Message A Sent Accepts Message Continues

12 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg12 Überblick Asynchrone Kommunikation 3.Broadcast Sender Receiver Message A Sent continues weißt Nachricht zurück + continues Nimmt Nachricht an + continues Nimmt Nachricht an + continues

13 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg13 Überblick 2.Integrationsmethoden Messaging: - Message enthält Informationen über gewünschte Aktion und Daten die für das ausführen gebraucht werden Sender - Nachricht im passenden Format erzeugen (z.B. Sender,Receiver,AccountNr.,AccountAction, Value) - Nachricht ins Kommunikationssystem weitergeben Receiver - Nachricht vom Kommunikationssystem empfangen - Die Nachricht in Kontrollinformation und Daten aufteilen - Bestimmen was zu tun ist

14 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg14 Überblick 2.Integrationsmethoden Interface: - Definiert die Aktionen die aufgerufen werden können - gebrauchte Daten werden über das Interface versand Sender - Definierten Aufruf mit Parametern erzeugen (z.B. Erzeuge_Kunden „Meier“) - Aufruf ausführen Receiver - Aufruf und Parameter entgegennehmen - Aktion ausführen (Abhängig vom Interface) Interface

15 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg15 Überblick 2.Integrationsmethoden Connectors: - Interface mit erweiterten Funktionen - Fehlerbehandlung, Gültigkeitsscheck - Marshalling, Unmarshalling - Konvertierung und Transformation von Daten (EBCDIC to UNICODE, DOLLAR to YEN) - Zustandsinformationen verwalten (Garantierte Übertragung,Wiederherstellung)

16 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg16 Überblick 3.Middleware Verwaltet Requests zwischen Softwarekomponenten. 5 Basistypen: - Remote Procedure Calls (RPC) - Database Acces Middleware - Message Oriented Middleware (MOM) - Distributed Object Technology (DOT) - Transaction Processing Monitors (TPMs)

17 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg17 Überblick 4.Services Erweiterung von Basiskommunikation und Middleware-Fähigkeiten. - Directory - Lifecycle - Security - Conversion and Transformation - Persistence - Notification - Workflow

18 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg18 Middlewaretypen  Gliederung 2. Middlewaretypen 2.1 RPC 2.2 MOM Einleitung Message Queuing Publish/Subscribe Eigenschaften 2.3 Distributed Objects/ORB Eigenschaften CORBA COM Middleware

19 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg19 Middlewaretypen  Gliederung 2.4 Datenbankorientierte Middleware CLIs ODBC JDBC native DBorientierte Middleware 2.5 Transaktionale Middleware Transaktionen Eigenschaften TP Monitor Application Server Enterprise Java Beans Transactional COM+ Middleware

20 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg20 Remote Procedure Call Aufruf einer fremden Prozedur durch ein Programm 2 Nachrichtenübertragungen: – Sender übergibt Prozedurnamen und notwendige Parameter –Empfänger sendet den Rückgabewert zurück Middleware

21 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg21 Eigenschaften  Remote Procedure Call Umsetzung des Aufrufs durch Stubs Kenntnis über Schnittstelle der betroffenen Prozedur Deklaration der Schnittstelle, um die Stubs zu generieren üblicherweise synchron –Stoppen der Sender-Anwendung bis der Rückgabewert von der Empfänger-Applikation gesendet wurde –Rückgabewert ist relevant für die weitere Abarbeitung des Programms auch asynchrone Ansätze –Sender kann nebenläufig weiterarbeiten –keine Antwort notwendig –Koordination der Rückläufe von Antworten bei mehreren asynchronen RPCs Middleware

22 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg22 Grafik  Remote Procedure Call Auftraggeber Auftragnehmer Programm Stub 1. Aufruf entfernte Prozedur 6. Rückgabe Parameter 5. Nachricht mit Rückgabe 2. Nachricht mit Aufruf 4. Rückgabe Parameter lokal 3. Aufruf lokale Prozedur Middleware

23 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg23 Remote Procedure Call Transparenz – Prozeduraufruf erscheint lokal –Übergabe an den entfernten Rechner ist nicht erkennbar Probleme –Parameterübergabe –Ortstransparenz –Fehlerfälle Middleware

24 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg24 Remote Procedure Call Vorteile –Einfachheit des Mechanismus und Programmierung –Stabilität –kompatibel Client-Server-Architektur Nachteile –Hohes Maß an Verarbeitungsleistung –Netzwerkbelastung –Keine grossen Datenmengen

25 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg25 Message oriented Middleware ereignisorientiert Nachrichtenübertragung zur Kommunikation zwischen Anwendungen Asynchrone Verarbeitung –aufrufende Applikation setzt mit ihrer Arbeit fort kann mit anderen Middlewaretypen verknüpft werden („Middleware, die Middleware verwendet“) –z Bsp: Message Broker (siehe 3. Teil der Vorlesung) 2 Kopplungsmodelle –Message Queuing –Message Grouping Middleware

26 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg26 Einfaches Message Queuing  MOM M 5M 4M 3M 2 M 6M 1 Message Queue Applikation A Applikation B Middleware

27 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg27 Request/Reply  Message Queuing  MOM Request/Reply –intelligente MOM-Variante –point-to-point-messaging –Synchroner Charakter –Anfrage und Antwort in einer Transaktion –Verarbeitung der Messages nach FIFO oder speziell festgelegten Prioritäten –erfordert eine Queue für jede Antwort M 2 Message Queue Applikation A Applikation B Message Queue M 1 Middleware

28 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg28 Publish/subsribe  MOM Gruppenkommunikation (publish/subscribe) 2 Gruppen: –Abonnenten Abbonieren eines bestimmten Ereignis, das durch spezielle Kriterien identifiziert wird –Herausgeber Freisetzen eines Ereignisses, das vom Kommunikationsdienst zum entsprechenden Abonnenten geleitet wird Verbreitung zu allen Clients möglich Middleware

29 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg29 Publish/subscribe  MOM Subscrib er Publisher Subscribe r Message Middleware

30 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg30 Publish/subscribe  MOM Client n+10 Client n Client n+100 Subscription Queue Publication Queue Pub-Sub Server Verbindung zu Informations- quellen Publish message c Subscribe message a Subscribe message c Subscribe message b Subscription criteria messages Publication message c Middleware

31 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg31 Eigenschaften  MOM Message Translation –Konvertierung in transportables Format –Rückkonvertierung –an Fixpunkten oder während des Routings Middleware

32 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg32 Eigenschaften  MOM Queue Management –Verwaltung mehrerer Queues –Verwaltung/Behandlung kritischer Aspekte wie Synchronisation, Antwortzeit, Message Inhalt, Message Grösse, Message Priorität, Queue Kapazität, Queue Timeouts, Queue Persistenz, Queue Priorität Middleware

33 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg33 Queue Management  Eigenschaften  MOM Queue manager Client 1 Client 2 Client 3 Client Anfragen Message Queue a Message Queue b Überwachen der Queues Middleware

34 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg34 Eigenschaften  MOM Queue Persistenz –Gewährleistung des Wiederauffindens von Messages bei Fehlern wie Queue Errors, Message beschädigungen, Serverfehlern –Message Repository enthält alle Request und Replies bis zum erfolgreichen Empfang durch den Server Middleware

35 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg35 Queue Persistenz  Eigenschaften  MOM Request Queue Message Server Reply Queue Message Repository Replies Requests Message Request message Reply message store message Reply message Request message korrekter Request- Empfang  Löschen aus Repository korrekter Reply- Empfang  Löschen aus Repository Middleware

36 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg36 Multiple Queuing Routing  Eigenschaften  MOM Multiple Queuing and Routing –Multiple Queues um Performance zu verbessern –Dienst, der festlegt in welche Queue die Message geschleust werden soll, abhängig vom Message-Inhalt oder der Queue- Verfügbarkeit z Bsp eine Queue für einen bestimmten Messagetyp –Vorraussetzung: Queue Manager oder Queue Router  d.h. der Client kennt lediglich den Ort der Manager Software, die den Router oder den Namen der Queue enthält

37 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg37 Multiple Queuing Routing  Eigenschaften  MOM Message Queue Z Message Message Queue Y Message Message Queue X Message Client B Queue Manager Client A Client C M-Typ X M-Typ Z M-Typ Y M-Typen Z + Y M-Typ X Multiple Queues für multiple Message-Typen

38 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg38 Multiple Queuing Routing  Eigenschaften  MOM Queue manager Client n Client n+1 Client n+100 Message Queue 3 Message Queue 2 Message Queue 1 Queue ist voll Multiple Queues für eine grössere Bandbreite Middleware

39 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg39 Distributed Objects/ORB ähnlich dem synchronen RPC basiert auf dem objektorientierten Paradigma Mechanismen zur transparenten Interaktion zwischen verteilten Objekten über verschiedene Netzwerke und Plattformen (ORB) Middleware

40 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg40 Distributed Objects MACH_DAS() NEIN_DAS() NEIN_DAS_HIER() NETZWERK kleine Applikationen, die Standard-Inter- faces und Protokolle zur Kommunikation untereinander benutzen Middleware

41 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg41 EIGENSCHAFTEN  ORB Schnittstelle des Serverobjekts muss definiert sein  Generierung der Stubs durch IDL-Interface Spezifikation Object Adapter - spezielle Laufzeitumgebung für Serverobjekte statisches Kommunizieren mit Stubs –(d.h. Serverobjekte zur Kompilierzeit bekannt) Interface Repository – zur Bestimmung der Serverobjekte zur Runtime Objekte können auf lokale Dienste des ORB zugreifen –Naming Service, Trading Service mögliche Entkopplung zur asynchronen Publish/Subscribe Verbindung durch Event Service Middleware

42 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg42 CORBA + OLE/COM  DO 2 Typen von „Betriebssystemen“ für DO: CORBA (common object request broker architecture) COM (component object model) Ziel  Standard für Systemintegration auf Basis der verteilten Objektorientierung etablieren Middleware

43 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg43 Distributed Objects/ORB CORBA von OMG –Standard –Spezifikation der Regeln, um ein CORBA Objekt zu entwickeln –heterogen, auf den meisten Plattformen erreichbar –basiert auf klassischem Objektmodell (multiple Vererbung, Verkapselung, Polymorphismus) COM –Standard von Microsoft –„rules of the road“ für den Entwickler –Interface-Standards und Kommunikationsprotokolle –erlaubt keine Vererbung von Klassen –homogen, für Win-Oberflächen Middleware

44 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg44 CORBA  ORB Interface Repository Client Dynamic Invocation Client Stubs ORB Interface Object Request Broker Kern Server Skeleton Object Adapter CORBA ORB Architektur Middleware

45 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg45 CORBA Client: –Programmeinheit, dass eine Operation eines anderen Objekts anstößt –Forderung nach Transparenz Server/Serverobjekte: –Eigentümer der aufgerufenen Methoden/Operationen Object Adapter: –Unterstützung der Anfrageübergabe zum Objekt und dessen Aktivierung –Verbindung Objektimplementierung mit dem ORB Interface Repository: –Information über die Schnittstellen für Laufzeitunterstützung und Design Dynamic Invocation: –erlaubt dynamischen Zugriff auf den Server ohne implementierte IDL- spezifische Stubs Stubs und Skeletons: –automatische Transformation zwischen CORBA IDL Definitionen und der Zielprogrammiersprache durch CORBA IDL Compiler Middleware

46 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg46 OLE/COM Interface Negotiation Uniform Data Transfer Naming and Binding Licensing Life Cycle Events Structured Storage Component Object Model Compound Document Management In-place-activation Custom Controls (OCX)   ###  Frameworks Object Services ORB OLE Automation Automation Controller Automation Server Middleware

47 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg47 OLE/COM Management zusammengesetzter Dokumente : –z Bsp Aktivierung der Funktionalität von Tabellen innerhalb eines Textdokuments (in-place-activation) –OLE  object linking and embedding OLE Automation: –Automation Server (zbsp: Tabellenverarbeitung) stellt seine Funktionalität dem Automation Controller zur Verfügung –Scriptsprache oder Tool –GUI nicht betroffen  transparente Funktionalitätsherkunft OCX: –vorgefertigte Komponente mit definierten Schnittstellen –kann mit Hilfe des Automation Servers in ein zusammengesetzes Dokument eingebunden werden –Zbsp: Mausklick auf bestimmte Dokumentenstelle und als Ereignis weitergeleitet und nach vorgeg. Regeln behandelt Network OLE: –höhere Version des bis dahin nur LOKAL funktionierenden OLE 2.0 –Ermöglicht Verteilung der Komponeten COM: –hat die Aufgaben eines ORB –Ergänzt durch eine Reihe von Diensten für die Zusammenarbeit mit Komponenten Middleware

48 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg48 Database oriented Middleware Ermöglichung der Kommunikation mit einer DB Extrahieren von Information aus einer lokalen oder entfernte DB Datenanfrage und –bewegung über Netzwerke 2 Typen: –ursprüngliche DB-Middleware und Call Level Interfaces (CLIs: zbsp ODBC,JDBC) Middleware

49 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg49 ODBC  DOM Bereitstellung einer Standardschnittstelle zum Zugriff auf DBs für relationale DBs Treiber: –zum Ausgleich der Heterogenität der einzelnen DBs Unterstützung von simultanen Mehrfachzugriff ODBC: – 4 Komponenten: Anwendungsprogramm Datenquelle Treiber-Manager ODBC-Treiber Middleware

50 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg50 Treiber-Manager  ODBC  DOM Code Bibliothek mit dem das AWP kommuniziert Laden und Löschen der einzelnen Treiber Kann mit mehreren DB-Treibern arbeiten Verbindungsherstellung mit den DB-Treibern zur Befehlsabarbeitung Middleware

51 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg51 ODBC-Treiber  ODBC  DOM Bibliotheken zur Gewährleistung der Interaktion mit einer DB Treiber muss für jede einzelne verwendete DB verfügbar sein laufen auf demselben Rechner der DB oder auf einem mit ihr verbundenen Weiterleitung der SQL-Anfragen an Datenquellen Verbergen der Heterogenität unterschiedlicher Datenquellen Ggf. Ausführung von SQL-Anfragen/SQL-Dialekt/Datentypumwandlung durch Veröffentlichung der DB-API  einfaches Entwickeln des zugehörigen Treibers möglich 3 Arten: –Ein-Stufen-Treiber –Zwei-Stufen-Treiber –Drei-Stufen-Treiber Middleware

52 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg52 Ein-Stufen-Treiber  ODBC-Treiber  ODBC  DOM Ein-Stufen-Treiber Zugriff auf flache Dateien (ISAM Files, EXCEL Spreadsheets) Transformation der SQL-Befehle durch AWP und Treiber- Manager zu geeigneten Befehlen für flache Dateien Komplette SQL-Bearbeitung (Parsen, Optimierung, Bereitstellung des Ausführungsmoduls häufig keine Mehrbenutzer-/TA-Unterstützung Middleware

53 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg53 Ein-Stufen-Treiber  ODBC-Treiber  ODBC  DOM Anwendung Ein-Stufen-Treiber Treiber Manager Dateisystem Datei-I/O-Aufrufe Zugriff auf flache Dateien Anwendung Ein-Stufen-Treiber Treiber Manager Dateisystem Datei-I/O-Aufrufe Zugriff auf ISAM-Dateien ISAM-Engine ISAM-Aufrufe Middleware

54 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg54 Zwei-Stufen-Treiber  ODBC-Treiber  ODBC  DOM Direkter Zugriff auf SQL geeignete DQ  Keine Wiederaufbereitung der SQL-Befehle 2-Schichten : Client- und Server-Schicht, können auf einem einzigen oder 2 Rechnern liegen Treiber übernimmt Client-Rolle im Datenprotokoll mit dem DBVS Unterschiedliche Realisierungsmöglichkeiten: Direkte Teilnahme am Datenprotokoll Abbildung von ODBC-Funktion auf DBS-API Einsatz von Middlewaretechnologien Middleware

55 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg55 Zwei-Stufen-Treiber  ODBC-Treiber  ODBC  DOM Direkte Teilnahme am Datenprotokoll Datenprotokoll Protokoll für Daten- übertragung im Netzwerk Zwei-Stufen-Treiber (Abbildung von DBS-API) Treiber Manager DB-Laufzeitbibliothek DBVS Netzwerkbibliothek/ RPC-Laufzeitsystem Abbildung von ODBC-Fkt auf DBS-API Anwendung Zwei-Stufen-Treiber (Verwendung von Messages oder RPCs) Treiber Manager Anwendung DBVS Netzwerkbibliothek/ RPC-Laufzeitsystem Middleware

56 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg56 Zwei-Stufen-Treiber  ODBC-Treiber  ODBC  DOM Zwei-Stufen-Treiber 1 Treiber Manager Serveranwendung 1 DBVS Netzwerkbibliothek/ RPC-Laufzeitsystem 1 Einsatz von Middlewaretechnologien Anwendung DBS-API Netztransport Datenprotokoll des Middlewareherstellers für Netzwerk 1 : des Middleware- herstellers Middleware

57 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg57 Drei-Stufen-Treiber  ODBC-Treiber  ODBC  DOM Treiber-Manager und Datenbank-Treiber auf separaten Rechner (Verbindungsserver) 3 Rechner involviert: Client, Gateway Server, Datenbankserver Komplexitätsverlagerung auf den Verbindungsserver theoret. beliebig viele Verbindungsstufen implementierbar Middleware

58 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg58 Drei-Stufen-Treiber  ODBC-Treiber  ODBC  DOM Anwendung Treiber-Manager Drei-Stufen-Treiber Netzwerkbibliothek/RPC-Runtimesystem DBVS (Verbindungs)Server Treiber-Manager Ein- oder Zwei-Stufen-Treiber weitere Komponenten Datenprotokoll 2 Datenprotokoll 1 Client Verbindungs- rechner auf dem LAN DBVS-Server Middleware

59 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg59 JDBC  DOM Java DataBase Connectivity Interface Standard, ähnlich dem ODBC (dieselben 4 Komponenten) Menge von Java-Methoden zum Zugriff auf multiple DBs DB-unabhängiges Programmieren in Java mit jeder SQL-DB und als darüberliegende Schicht auf ODBC verwendbar unterstützt Features der Programmiersprache Java »(Netzwerkbewusstsein, Sicherheitsaspekte, oo-Charakteristik) 2 Architekturen: 2-Schichten oder 3-Schichten-Architektur 4 Typen JDBC Treiber : –JDBC-ODBC-Bridge in Verbindung mit einem ODBC Treiber ; –Nutzung eines proprietären Datenbank-APIs mit Java Treiber; –JDBC-Netzwerkprotokoll mit Pure Java-Treiber; – Datenbank-proprietäres Netzwerk-protokoll mit Pure Java Treiber Middleware

60 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg60 Architekturen  JDBC  DOM Client Server Client (nur GUI) Server (Anwendungs- logik) DBMS Java Applet HTML-Browser Application Server JDBC proprietäres Protokoll HTTP, CORBA,... Java-Applikation JDBC DBMS Zwei-Schichten-Architektur Drei-Schichten-Architektur Middleware

61 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg61 Typ1-Treiber  JDBC  DOM ODBC-Aufrufe Datenprotokoll JDBC-ODBC-Bridge Treiber (Abb. auf ODBC) JDBC-Treiber Manager DBVS Netzwerkbibliothek/ RPC-Laufzeitsystem Java Anwendung ODBC Treiber Manager + Treiber (Binärcode) JDBC-ODBC-Bridge in Verbindung mit einem ODBC Treiber: ODBC Treiber verwendbar Geringe Performance Binärcode auf Client erforderlich Protokoll für Daten- übertragung im Netzwerk Middleware

62 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg62 Typ2-Treiber  JDBC  DOM Zwei-Stufen Treiber (Abb. auf DBS-API) JDBC-Treiber Manager DBVS Netzwerkbibliothek/ RPC-Laufzeitsystem Java Anwendung DB Laufzeitbibliothek (Binärcode) DBS-API Datenprotokoll Protokoll für Daten- übertragung im Netzwerk Nutzung eines proprietären Datenbank- APIs mit Java Treiber: vom Hersteller zu implementieren Abbildung des JDBC Interface auf DB-API Binärcode auf Client erforderlich Middleware

63 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg63 DBVS Netzwerkbibliothek/ RPC-Laufzeitsystem Typ3-Treiber  JDBC  DOM Zwei-Stufen Treiber (vom Middlewarehersteller) JDBC-Treiber Manager Serveranwendung Java Anwendung DBS-API Datenprotokoll des Middleware- herstellers für Netzwerk JDBC-Netzwerkprotokoll mit Pure Java- Treiber: aufwendige Implementierung von Middleware kein Binärcode auf Client erforderlich sehr flexibel durch DB- unabhängiges Netzwerkprotokoll Binärcode auf Server Middleware

64 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg64 Typ4-Treiber  JDBC  DOM Zwei-Stufen-Treiber (Verwendung von Messages oder RPCs) JDBC Treiber Manager Java Anwendung DBVS Netzwerkbibliothek/ RPC-Laufzeitsystem Daten- protokoll Protokoll für Daten- übertragung im Netzwerk Datenbank-proprietäres Netzwerk- protokoll mit Pure Java Treiber: reine Javalösung einfache, leistungsstarke Implementierung durch Hersteller möglich kein Binärcode auf Client erforderlich direkte Teilnahme am Datenbankprotokoll Middleware

65 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg65 Native Datenbank Middleware Zugriff auf Features und Funktionen einer einzelnen DB Beschränkung auf nur einen DB-Typ alle Features der DB nutzbar Höhere Performance Native Datenbank Middleware  DOM Middleware

66 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg66 Transaction oriented Middleware Was ist eine Transaktion? –Menge von logisch zusammenhängenden (DML)Operationen, die eine Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand überführt. Innerhalb der TA können Inkonsistenzen auftreten. ACID Eigenschaften der TA: –A: Atomicity („Alles oder Nichts“) –C: Constistency („in sich Geschlossenheit“) – I : Isolation ( mehrere TAs laufen voneinander isoliert ab, TAs sehen keine inkonstistenten zustände anderer TAs) –D: Durability ( Gewährleistung der Persistenz von Änderungen von erfolgreichen TAs) Komplexe Anwendungen werden in diese Einheiten (TA) gespalten Kontrolle der TA von ihrem Anfang bis zu ihrem Ende Middleware

67 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg67 Transaction oriented Middleware TA-Verarbeitung im Auftrag eines Client oder Knotens Schleusen der TA durch unterschiedlichste Systeme Raum für Anwendungslogik, Anwendungsobjekte, und Funktionsaustausch Durchführung der Geschäftsprozesslogik Erhaltung der Datenintegrität Entwicklung von Gesamt-Anwendungen durch Erstellung von TA- Diensten, die durch den Client angesprochen werden. wichtige Eigenschaften: –Database Multiplexing –Load Balancing –Fehlertoleranz Middleware

68 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg68 Eigenschaften  TOM Database Multiplexing –Multiplexen und Verwalten von TAs Übertragung von Nachrichten und Anfragen auf denselben Rechner Reduzierung der Anzahl von Verbindungen und Verarbeitungslast, die größere Systeme auf die DB einnehmen Erhöhung der Anzahl von Clients ohne die Größe des DB-Servers ändern zu müssen –„Trichtern“von Client-Anfragen Keine 1-Prozess-pro-Client-Anforderung die TA-Dienste, die vom Client angesprochen werden, können sich dieselbe DB-Server-Verbindung teilen nur bei vollständiger Auslastung wir eine neue Verbindung gestartet Middleware

69 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg69 Eigenschaften  TOM Load Balancing/ Lastausgleich: –bei Überschreitung der Anzahl der Client-Anfragen mit der Anzahl der gleichzeitg ausführbaren Prozesse werden automatisch neue Prozesse gestartet –dynamisches Verteilen der Prozesslast über mehrere Server zur gleichen zeit oder Verteilung der Verarbeitung in mehrere hintereinanderlaufende Prozesse –Definieren von Arbeitsklassen nach Prioritätenfestlegung high-priority server classes für kurze wichtige Funktionen oder low- priority server classes für Stapelprozesse Weitere Kriterien definierbar wie Anwendungstyp, Antwortzeit, Fehlertoleranz einer TA –Festlegen einer Menge von Parametern zur Kontrolle der Anzahl der Prozesse und Threads, die für jede TA verfügbar ist Middleware

70 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg70 Eigenschaften  TOM Fehlertoleranz : –Gewährleistung der Recovery bei Auftreten jedes systemabhängigen Problems –z Bsp : redundante Systeme » hohe Verfügbarkeit »Dynamisches Switching, um die TA an Server- oder Netzwerkproblemen vorbeizuschleusen –Sicherung: der vollständigen Beendigung der TA der Änderungen erfolgreicher TAs bei Fehlerauftreten der konsistenten Zustände der heterogenen Ressourcen –bei Auftreten eines Fehlers werden alle Teilnehmer der TA informiert, um Änderungen dieser fehlgeschlagenen TA vollständig rückgängig zu machen –oft Entwicklung von TAs, die sich nach einem Fehler automatisch rückmelden Middleware

71 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg71 Eigenschaften  TOM RM Anwendung TA-Manager Resource- Manager begin requests join prepare for commit/ commit Transaktionsverarbeitungsmodell nach X/OPEN : –Art und Weise wie heterogene Softwarekomponenten miteinander kombiniert werden, um TAs zu verarbeiten –Ressource Manager (RMs): Systemkomponenten zur Sicherung des Transaktionsschutzes für DB- Daten und andere Betriebsmittel (Nachrichten, persistente Queues,Dateisysteme, MailService,...) externe Koordination von Ressourcenänderungen durch 2PC-Protokoll globaler TA-Schutz durch eine RM-Architektur Middleware

72 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg72 Eigenschaften  TOM begin: –starten einer neuen TA beim lokalen TA-Manager join: –wenn Anwendung auf die Ressource zugreift, wird der zugehörige RM an der TA-Verarbeitung beteiligt prepare for commit: –TA-Manager leitet den Wunsch nach commit an die entsprechenden RMs weiter –RM führen dann lokale Commit/Abort-Aktionen durch und melden den Vollzug dem TA-Manager Middleware

73 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg73 Eigenschaften  TOM 2PC-Protokoll: – 1. Phase: „voting phase“ – 2. Phase „commit phase“ TA-Manager RM lokales Ergebnis (READY/FAILED) globales Ergebnis (COMMIT/ROLLBACK/ABORT) Quittierung (ACK) Phase 2. Phase prepare Middleware

74 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg74 TP-Monitor  TOM –Ermöglichung der Kommunikation zwischen 2 oder mehreren Applikationen –Bereitstellung von Anwendungslogik –Umgebung für die Entwicklung und Betrieb von TP-Systemen –Koordination und Organisation der Benutzeranfragen an die Applikationen, welche wiederum auf Ressourcen zugreifen – Bereitstellung von speziellen Diensten auf die die Applikationen zugreifen können TA-Managementdienst  Koordination der TA-Abwicklung (TA-Integrität, Ressource Management) Masken Menüs zum Zugriff auf Ressourcen Kommunikationsmechanismen (RPC) Queue-Management –Dienste werden selbst implementiert oder auf „fremde“ Middlewaredienste aufgesetzt –verschiedene Services unter einheitlicher Schnittstelle integriert –Basiert auf prozeduralen Sprachen wie C oder Cobol Middleware

75 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg75 Architektur eines TP-Monitor Frameworks  TOM TP-Applikation TP-Monitor API Tools TP Monitor Dienste Präsentation Masken und Menüs Daten: SQL-Zugriff Dateizugriff RPC Queuing TA-Manager Benutzerschnittstelle auf Terminals, Desktops TP-Monitor Framework Middleware- dienste Ressourcen: Datenbank, Datei, Queue Middleware

76 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg76 Application Server  TOM Ähnlich dem TP-Monitoren basiert auf modernen Sprachen wie Java Bereitstellung der Verbindung zu Backend-Ressourcen (DB, ERP- Systeme, Mainframe-Anwendungen) Koordination vieler Ressourcenverbindungen Mittler zwischen Datenbank und Anwendungen Arten: –Web Application Server –Legacy Application Server –Enterprise Application Server Middleware

77 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg77 Application Server  TOM 3-Schichten-Modell (Client-, Applikations-, Datenbankserverschicht) DBMS Webbrowser Gateway Web-Server Applikations- Server Mainframe PräsentationslogikGeschäftslogikDatenhaltung Middleware

78 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg78 Web Application Server  TOM Internet DBMS Intranet Java Application Server Web Server JDBC/ODBC Middleware

79 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg79 Web Application Server  TOM Entwicklungsumgebung für webbasierte Anwendungen (HTML authoring) Application Server neben herkömmlichen WebServer Meist javaorientiert Unterstützung von Enterprise Java Beans für serverseitige Komponententwicklung Nicht geeignet für Entwicklung von Unternehmensapplikationen weniger gute Performance einfache Managementtools oft keine Einbindung herkömmlicher Programmierumgebungen z Bsp: ColdFusion, Netscape Application Server, WebLogic Middleware

80 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg80 Legacy Application Server  TOM Internet Intranet Java Legacy Application Server TP Monitor Middleware

81 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg81 Legacy Application Server  TOM Bereitstellung der Infrastruktur für geschäftskritische Anwendungsstrukturen TA-Management, Load Balancer, Sicherheitsfunktionen Integration von TP-Monitoren meist Lademechanismen, um verteilte Objekte in die Client/Server-Architektur einzubinden sichere etablierte Entwicklungsumgebungen hohe Komplexität nicht geeignet für Entwicklung webbasierter Anwendungen z Bsp: BEA M3, IBM Component Broker Middleware

82 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg82 Enterprise Application Server  TOM Internet Java Web Server Inprise Application Server Business Object Inprise Application Server TP Monitor DBMS Intranet Middleware

83 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg83 Enterprise Application Server  TOM deckt beide Aufgabenbereiche ab webbasierte Anwendungen sowie Windows-Programme entwickelbar z Bsp: Inprise Application Server Middleware

84 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg84 Standards  Application Server  TOM Enterprise Java Beans (EJB) –Java-enabled Middleware –Spezifikation zur Definition von serverseitigem Komponentenmodell für Java Beans –repräsentieren spezialisierte Java Beans, die auf einem entfernten Server laufen (EJB Container) –ähnlich den verteilten Objekten (COM, CORBA) –Nutzung derselben Architektur wie Java Beans –Gruppierung zu einer verteilten Anwendung, um die Verarbeitung innerhalb der Java Beans zu koordinieren –Verarbeitung der Java Beans als transaktionale Komponenten Middleware

85 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg85 Standards  Application Server  TOM –EJB Modell: Keine Notwendigkeit die TA genau abzugrenzen Automatisches Verwalten der TA auf Anfrage der EJB Definition der Beziehung zwischen EJB Komponenten und EJB Container System kein spezielles Containersystem erforderlich EJB Container kann jedes Anwendungssystem sein, das den EJB Standard unterstützt (z Bsp: Application Server) –mit Diensten wie: Persistenzmanagement, Sicherheitsdienste, TA-Kontrolle EJB Server: –EJB-Verarbeitungssystem mit einer Menge von Diensten zur Unterstützung von EJB-Komponenten –Zugriff auf TA-Management Mechanismus Middleware

86 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg86 Standards  Application Server  TOM Transactional COM+ (unter Benutzung von AppCenter) COM+ ( COM und Microsoft Transaction Server) –Komponenten-Standard –mehrere Schnittstellen pro Komponente – verschachtelte TAs –keine Persistenzunterstützung –Ereignisdienste –nur auf Windowsplattformen AppCenter: –Umgebung zur Verarbeitung von COM+ Komponenten mit ACID- Unterstützung, DB-Zugriff, Recovery-Fähigkeit –TA-Server für TA-Support –Microsoft Message Queue Server für Message Queuing Support –Router, der durch die kritische Komponente Antwortzeit, den am wenigsten beschäftigten Server findet, der die COM+ Komponenten verarbeitet –Komponenten-dynamische Last-Balancierung (Win 2000) Unterstützt bis zu 8 verbundene Application Servers Fähigkeit ein o. mehrere COM+ Komponenten im Cluster zu verarbeiten Middleware

87 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg87 Zusammenfassung RPC –einfacher synchroner Mechanismus MOM –asynchrone Kommunikation durch Messages Distributed Objects –„objektorientierte RPC“ –Modelle: CORBA, COM Database oriented Middleware –CLIs: ODBC JDBC OLE DB Transaktionale Middleware –ACID –TP Monitore –Applicationserver: Arten Standards (EJB, COM+ feat. AppServer) Middleware

88 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg88 Message Broker koordiniert Zusammenarbeit zwischen Vielzahl von Systemen: –Anwendungen –Middleware –Datenbanken baut auf bestehenden Middleware-Technologien auf asynchrone Kommunikation store-and-forward messaging skalierbar plattformunabhängig ähneln dem Ablauf von Geschäftsprozessen Message Broker

89 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg89 Komponenten  MB Message Transformation Rules Processing Intelligentes Routing Message Warehousing Repository Services GUI Directory Services Management Adapter und APIs Topologien Message Broker

90 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg90 Primärkomponenten  MB Intelligentes Routing Regelwerk Message Transformation Eingangs- information Ausgangs- information Message Broker

91 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg91 Message Transformations-Ebene  MB Versteht sämtliche Nachrichten konvertiert und restrukturiert Daten zum Verständnis der Ziel- Anwendung(en) Wörterbuch (  repository) mit Beziehung jeglicher Informationen, die die Anwendungen zur Kommunikation nutzen Parsing- und Pattern-matching-Methoden feste, unbegrenzte und variable Nachrichten sichert Konsistenz zwischen Applikationen Message Broker

92 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg92 Schema Conversion  Message Transformation  MB Prozess der Umwandlung des Formats einer Nachricht in das des Zielsystems Definition der Datentypen kann innerhalb der Rules-processing- Ebene erfolgen obwohl jedes Schema in jedes andere übersetzt werden kann, sind außergewöhnliche Umstände möglich –z.B. Daten eines OODBS  RDBS Message Broker 21. November /10/2001 alphanumerisch 17alphanumerisch 10

93 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg93 Data Conversion  Message Transformation  MB Umwandlung der Werte innerhalb der Nachrichten Feststellen der Formate der Quell- und Zielapplikation(en) Bewerten ihrer Unterschiede Transformation (falls nötig) mittels Regel(n) oder Look-up- Tabelle Message Broker

94 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg94 Rules Processing  MB Erzeugen von Regeln zur Kontrolle der Verarbeitung und Verteilung von Nachrichten Programm, das spezielle Anforderungen der zu integrierten Anwendungen anspricht m.H. dieser Rules-Processing-Maschinen realisieren Message Broker Transformation und intelligentes Routing Fähigkeiten reichen von einfachem Information-Sharing bis fast zu denen eines Anwendungs-Servers Anbieter setzen meist auf Skriptsprachen und Interpreter bei der Abarbeitung Message Broker

95 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg95 Rules Processing  MB Erzeugen und Verknüpfen der Regeln mit Aktionen meist mit Boolean-Logik in Hochsprachen Regel-Editor, Wizard Speicherung der Regeln im Repository oder in Textfiles Message Broker

96 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg96 Intelligentes Routing  MB baut auf Fähigkeiten der Message-Transformations-Ebene und dem Regelwerk auf identifizieren der Quell- und Zielapplikation(en) übersetzen (falls nötig), ausführen und weiterleiten System D System E System F Quell-System System A System B System C Ziel-System Message Broker

97 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg97 Message Warehousing  MB Datenbank zur Speicherung von Nachrichten Message mining: –meist unverändert, selten aggregiert –Erstellung von entscheidungsunterstützenden Informationen Message-Integrität –nach Prinzip des persistenten Message-Queuing der MOM –Puffer Message-Archivierung: –längerfristige Speicherung für Analysezwecke Auditing: –Prüfung, ob die Integrations-Lösung in der Lage ist, die übertragenen Aufgaben anforderungsgerecht erledigt –z.B. Formatänderungen, Anzahl erforderlicher Transformationen Message Broker

98 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg98 Repository Service  MB Vorrangige Datenbank mit für Integration notwendigen Informationen über Quell- und Zielanwendungen: –Sicherheitsparameter –Nachrichtenformate –Metadaten –Konvertierungsinformationen –Regeln und Logik für Message-Processing –Geschäftsprozesse –Systemeigner –Verzeichnis des Systems –Objekte –Netzwerk-Adressen, Informationen über Fehlercodetransformation u.ä. Message Broker

99 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg99 Graphical User Interface  MB Graphische Benutzerschnittstelle Darstellungen von Strukturen nutzerfreundliche Definitionen der meisten Informationen im Repsitory Wizards Administation –Anzeige des Nachrichtenaufkommens –Performance –Status verbundener Systeme Message Broker

100 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg100 Directory Services  MB Verzeichnis, um Netzwerk-Ressourcen in verteilten Systemen zu lokalisieren, zu identifizieren und zu nutzen bietet Anwendungen und Middleware eine zentrale Anlaufstelle Umleitung wenn Ressourcen umkonfiguriert, verschoben oder gelöscht wurden Message Broker

101 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg101 Management  MB Administration und Management anzeigen wichtiger Statistiken –Performance –Nachrichten-Integrität –generelle Integrationsprobleme anzeigen von Nachrichtenbewegungen Alarmfunktionen bei Überlastungen und Nichtverfügbarkeit von Systemen Message Broker

102 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg102 Adapter  MB Schnittstelle zwischen Message Broker und Applikation nicht standardisiert verlagern der Komplexität zweier Interfaces in einen Adapter Adapter für verschiedene –Applikationen (SAP R/3, Baan,...) –Datenbanken (Oracle, DB2,...) –Typen von Middleware zunehmend intelligenter Typen: Thin Adapter, Thick Adapter deren Verhalten kann dynamisch oder statisch sein Message Broker

103 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg103 Thin Adapter  Adapter  MB meist einfache API- Wrapper oder Binder bilden das Interface des Quell- oder Zielsystems auf ein gemeinsames, vom MB unterstütztes, Interface ab Performanceverluste ohne Funktionalitätsgewinn Message Broker API Applikation oder Datenbank Gemeinsames Interface Message Broker

104 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg104 Thick Adapter  Adapter  MB Aufsetzen einer zusätzlichen Abstraktionsebene auf das API Nutzung des Repositories erheblich mehr Funktionalität und Entwicklungsaufwand Message Broker API Applikation oder Datenbank Message Broker High-Level Business Events

105 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg105 Hub-and-spoke-Konfiguration  Topologien  MB Sterntopologie Anwendung Message Broker

106 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg106 Multi-Hub-Konfiguration  Topologien  MB wenn mehr Anwendungen bestehen als ein Message Broker handeln kann virtuell unbegrenzte Zahl von Applikationen integrierbar Anwendung Message Broker

107 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg107 Federated Konfiguration  Topologien  MB Interaktion mehrerer unabhängiger Message Broker über ein gemeinsames Austauschformat zur Integration einer Handels- gemeinschaft MB Unternehmen B MB Unternehmen A MB Unternehmen C XML/EDI Message Broker


Herunterladen ppt "Aufbau Integrierter Informationssysteme Überblick über Basistechnologien Christina Reuter, David Kaiser, Thomas Hoffmann Martin-Luther-Universität Halle-Wittenberg."

Ähnliche Präsentationen


Google-Anzeigen