Message - Datenbanken - Martin-Luther-Universität Halle
Werbung
Aufbau Integrierter Informationssysteme Überblick über Basistechnologien Christina Reuter, David Kaiser, Thomas Hoffmann Martin-Luther-Universität Halle-Wittenberg Hauptseminar - Halle - 21.11.2001 Gliederung 1. Überblick über Basistechnologien 2. Middleware 3. Message Broker © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 2 Überblick Überblick - Gliederung 1. Gliederung in 4 Basisblöcke 2. Kommunikationsmodel 1. 2. Synchrone Kommunikation Asynchrone Kommunikation 3. Integrationsmethoden 1. 2. 3. Messaging Interface Connectors 4. Middleware 1. 2. RPC MOM 5. Services © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 3 Überblick Basisblöcke Unterteilung der EAI-Architektur in folgende 4 Basisblöcke 1. Kommunikationsmodel 2. Integrationsmethoden 3. Middleware 4. Services © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 4 Überblick 1. Kommunikationsmodel - Grundlagen Sender Request = Anfrage Reply = Antwort Receiver © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg = Empfänger 5 Überblick 1. Arten der Kommunikation Kommunikation Synchron © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Asynchron 6 Überblick Synchrone Kommunikation 1. Request / Reply Bearbeitet Request Blockt Request Sender Reply © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Receiver 7 Überblick Synchrone Kommunikation 2. One-Way Bearbeitet Request Blockt Request Sender Empfangsbestätigung © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Receiver 8 Überblick Synchrone Kommunikation 3. Synchrones Polling Checks Success for Failure Stoppt Response polling Continues Sender Bearbeitet Request Request Reply © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Receiver 9 Überblick Asynchrone Kommunikation 1. Message Passing Accepts Message + continues continues Message Sent Sender © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Receiver 10 Überblick Asynchrone Kommunikation 2. Publish / Subscribe continues Sender Receiver Message A Sent Subscription List Accepts Message Continues Message A Sent Receiver Accepts Message Continues Receiver © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 11 Überblick Asynchrone Kommunikation 3. Broadcast Receiver weißt Nachricht zurück + continues Receiver Nimmt Nachricht an + continues Receiver Nimmt Nachricht an + continues continues Sender © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 12 Überblick 2. Messaging: Integrationsmethoden - 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 13 Überblick 2. Interface: Sender Integrationsmethoden - Definiert die Aktionen die aufgerufen werden können - gebrauchte Daten werden über das Interface versand - Definierten Aufruf mit Parametern erzeugen (z.B. Erzeuge_Kunden „Meier“) - Aufruf ausführen Interface Receiver - Aufruf und Parameter entgegennehmen - Aktion ausführen (Abhängig vom Interface) © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 14 Ü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) © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 15 Ü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) © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 16 Überblick 4. Services Erweiterung von Basiskommunikation und Middleware-Fähigkeiten. - Directory - Lifecycle - Security - Conversion and Transformation - Persistence - Notification - Workflow © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 17 MiddlewaretypenGliederung Middleware 2. Middlewaretypen 2.1 RPC 2.2 MOM 2.2.1 Einleitung 2.2.2 Message Queuing 2.2.3 Publish/Subscribe 2.2.4 Eigenschaften 2.3 Distributed Objects/ORB 2.3.1 Eigenschaften 2.3.2 CORBA 2.3.3 COM © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 18 MiddlewaretypenGliederung Middleware 2.4 Datenbankorientierte Middleware 2.4.1 CLIs 2.4.1.1 ODBC 2.4.1.2. JDBC 2.4.2 native DBorientierte Middleware 2.5 Transaktionale Middleware 2.5.1 Transaktionen 2.5.2 Eigenschaften 2.5.3 TP Monitor 2.5.4 Application Server 2.5.5 Enterprise Java Beans 2.5.6 Transactional COM+ © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 19 Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 20 Middleware EigenschaftenRemote 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 21 Middleware GrafikRemote Auftraggeber 6. Rückgabe Parameter 4. Rückgabe Parameter lokal Programm Procedure Call Auftragnehmer Programm 2. Nachricht mit Aufruf Stub Stub 1. Aufruf entfernte Prozedur 5. Nachricht mit Rückgabe © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 3. Aufruf lokale Prozedur 22 Middleware Remote Procedure Call • Transparenz – Prozeduraufruf erscheint lokal – Übergabe an den entfernten Rechner ist nicht erkennbar • Probleme – Parameterübergabe – Ortstransparenz – Fehlerfälle © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 23 Remote Procedure Call • Vorteile – Einfachheit des Mechanismus und Programmierung – Stabilität – kompatibel Client-Server-Architektur • Nachteile – Hohes Maß an Verarbeitungsleistung – Netzwerkbelastung – Keine grossen Datenmengen © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 24 Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 25 Middleware Einfaches Message Queuing MOM Message Queue Applikation A M5 M4 M3 M6 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Applikation B M2 M1 26 Middleware • Request/ReplyMessage 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 M1 M1 Message Queue Applikation A Applikation B Message Queue M2 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg M2 27 Middleware Publish/subsribeMOM • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 28 Middleware Publish/subscribeMOM Subscrib er Subscribe r Subscribe r Publisher Message © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 29 Publish/subscribeMOM Middleware Client n Subscription criteria messages Subscribe messagea Client n+10 Subscribe messageb Subscription Queue Publication Queue Subscribe messagec Client n+100 Pub-Sub Server Publish messagec © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Publication messagec Verbindung zu Informationsquellen 30 Middleware Eigenschaften MOM • Message Translation – Konvertierung in transportables Format – Rückkonvertierung – an Fixpunkten oder während des Routings © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 31 Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 32 Middleware Client 1 Client 2 Queue ManagementEigenschaften MOM Client Anfragen Queue manager Client 3 Überwachen der Queues Message Message Queue Queue a b © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 33 Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 34 Middleware Queue PersistenzEigenschaften Message Request message store message Message Server korrekter ReplyEmpfang Löschen aus Repository Request Queue Message Repository Requests Replies Message Message Message Message Message Message Message Message Reply message Message Reply Queue © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg MOM Message korrekter RequestEmpfang Löschen aus Repository Request message Message Server store message Reply message Message 35 Multiple Queuing RoutingEigenschaften 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 QueueVerfü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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 36 Multiple Queuing RoutingEigenschaften MOM Client A Message M-Typ Y Message Queue X Message M-Typ X Client B M-Typen Z+Y Queue Manager M-Typ Y Message Message Queue Y Message M-Typ Z M-Typ X Message Message Queue Z Message Client C Multiple Queues für multiple Message-Typen © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 37 Middleware Multiple Queuing RoutingEigenschaften Client n Client n+1 MOM Message Queue 1 Queue manager Message Queue 2 Queue ist voll Client n+100 Message Queue 3 Multiple Queues für eine grössere Bandbreite © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 38 Middleware 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) © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 39 Distributed Objects Middleware MACH_DAS() NEIN_DAS() NETZWERK NEIN_DAS_HIER() © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg kleine Applikationen, die Standard-Interfaces und Protokolle zur Kommunikation untereinander benutzen 40 ORB Middleware EIGENSCHAFTEN • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 41 Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 42 Distributed Objects/ORB Middleware • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 43 CORBAORB Middleware Server Client Interface Repository Skeleton Dynamic Client ORB Invocation Stubs Interface Object Adapter Object Request Broker Kern CORBA ORB Architektur © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 44 Middleware • 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 IDLspezifische Stubs • Stubs und Skeletons: – automatische Transformation zwischen CORBA IDL Definitionen und der Zielprogrammiersprache durch CORBA IDL Compiler © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 45 OLE/COM Middleware Frameworks Compound Document Management In-place-activation Custom Controls (OCX) OLE Automation 23 4567 8 ### Automation Controller Automation Server Object Services Interface Negotiation Uniform Data Transfer Naming and Binding Licensing Life Cycle Events Structured Storage ORB Component Object Model © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 46 OLE/COM Middleware • Management zusammengesetzter Dokumente: – – • OLE Automation: – – – • – 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: – – • Automation Server (zbsp: Tabellenverarbeitung) stellt seine Funktionalität dem Automation Controller zur Verfügung Scriptsprache oder Tool GUI nicht betroffen transparente Funktionalitätsherkunft OCX: – – • z Bsp Aktivierung der Funktionalität von Tabellen innerhalb eines Textdokuments (in-place-activation) OLE object linking and embedding 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 47 Middleware 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) © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 48 ODBCDOM Middleware • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 49 Middleware Treiber-ManagerODBCDOM • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 50 Middleware ODBC-TreiberODBCDOM • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 51 Middleware Ein-Stufen-TreiberODBC-TreiberODBC DOM Ein-Stufen-Treiber • Zugriff auf flache Dateien (ISAM Files, EXCEL Spreadsheets) • Transformation der SQL-Befehle durch AWP und TreiberManager zu geeigneten Befehlen für flache Dateien • Komplette SQL-Bearbeitung (Parsen, Optimierung, Bereitstellung des Ausführungsmoduls • häufig keine Mehrbenutzer-/TA-Unterstützung © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 52 Middleware Ein-Stufen-TreiberODBC-TreiberODBC Zugriff auf flache Dateien DOM Zugriff auf ISAM-Dateien Anwendung Anwendung Treiber Manager Treiber Manager Ein-Stufen-Treiber Ein-Stufen-Treiber ISAM-Aufrufe Datei-I/O-Aufrufe ISAM-Engine Datei-I/O-Aufrufe Dateisystem © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Dateisystem 53 Middleware • Zwei-Stufen-TreiberODBC-TreiberODBC 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 54 Middleware Zwei-Stufen-TreiberODBC-TreiberODBC Treiber Manager Zwei-Stufen-Treiber Treiber Manager (Abbildung von DBS-API) Zwei-Stufen-Treiber (Verwendung von Messages oder RPCs) Datenprotokoll DB-Laufzeitbibliothek Netzwerkbibliothek/ RPC-Laufzeitsystem DBVS Protokoll für Datenübertragung im Netzwerk © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Netzwerkbibliothek/ RPC-Laufzeitsystem Abbildung von ODBC-Fkt auf DBS-API Anwendung Anwendung Direkte Teilnahme am Datenprotokoll DOM DBVS 55 Middleware Zwei-Stufen-TreiberODBC-TreiberODBC DOM Einsatz von Middlewaretechnologien Anwendung Treiber Manager Zwei-Stufen-Treiber Datenprotokoll des Middlewareherstellers für Netzwerk 1 Netzwerkbibliothek/ RPC-Laufzeitsystem 1 Serveranwendung Netztransport 1 DBS-API 1 DBVS © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg : des Middlewareherstellers 56 Middleware Drei-Stufen-TreiberODBC-TreiberODBC 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 57 Middleware Drei-Stufen-TreiberODBC-TreiberODBC DOM Anwendung Treiber-Manager Client Drei-Stufen-Treiber Netzwerkbibliothek/RPC-Runtimesystem Datenprotokoll 1 (Verbindungs)Server Treiber-Manager Ein- oder Zwei-Stufen-Treiber Verbindungsrechner auf dem LAN weitere Komponenten Datenprotokoll 2 DBVS © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg DBVS-Server 58 JDBC DOM Middleware • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 59 Middleware ArchitekturenJDBC Zwei-Schichten-Architektur DOM Drei-Schichten-Architektur Client Java Applet (nur GUI) HTML-Browser Client Java-Applikation HTTP, CORBA,... JDBC proprietäres Protokoll Application Server (AnwendungsServer logik) JDBC Server DBMS DBMS © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 60 Middleware Typ1-Treiber Java Anwendung JDBC-Treiber Manager JDBC-ODBC-Bridge Treiber (Abb. auf ODBC) JDBC DOM JDBC-ODBC-Bridge in Verbindung mit einem ODBC Treiber: •ODBC Treiber verwendbar •Geringe Performance •Binärcode auf Client erforderlich ODBC-Aufrufe ODBC Treiber Manager + Treiber (Binärcode) Datenprotokoll Netzwerkbibliothek/ RPC-Laufzeitsystem DBVS Protokoll für Datenübertragung im Netzwerk © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 61 Middleware Typ2-Treiber Java Anwendung JDBC DOM Nutzung eines proprietären DatenbankAPIs mit Java Treiber: •vom Hersteller zu implementieren •Abbildung des JDBC Interface auf DB-API •Binärcode auf Client erforderlich JDBC-Treiber Manager Zwei-Stufen Treiber (Abb. auf DBS-API) DBS-API DB Laufzeitbibliothek (Binärcode) Datenprotokoll Netzwerkbibliothek/ RPC-Laufzeitsystem DBVS Protokoll für Datenübertragung im Netzwerk © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 62 Middleware Typ3-Treiber Java Anwendung JDBC DOM JDBC-Netzwerkprotokoll mit Pure JavaTreiber: JDBC-Treiber Manager •aufwendige Implementierung von Middleware •kein Binärcode auf Client erforderlich •sehr flexibel durch DBunabhängiges Netzwerkprotokoll Zwei-Stufen Treiber (vom Middlewarehersteller) Netzwerkbibliothek/ RPC-Laufzeitsystem Datenprotokoll des Middlewareherstellers für Netzwerk Serveranwendung DBS-API Binärcode auf Server DBVS © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 63 Middleware Typ4-Treiber Java Anwendung Datenbank-proprietäres Netzwerkprotokoll mit Pure Java Treiber: JDBC Treiber Manager Zwei-Stufen-Treiber (Verwendung von Messages oder RPCs) Datenprotokoll Netzwerkbibliothek/ RPC-Laufzeitsystem JDBC DOM • reine Javalösung • einfache, leistungsstarke Implementierung durch Hersteller möglich • kein Binärcode auf Client erforderlich • direkte Teilnahme am Datenbankprotokoll Protokoll für Datenübertragung im Netzwerk DBVS © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 64 Middleware Native Datenbank Middleware DOM 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 65 Middleware • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 66 Middleware 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 TADiensten , die durch den Client angesprochen werden. • wichtige Eigenschaften: – Database Multiplexing – Load Balancing – Fehlertoleranz © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 67 EigenschaftenTOM Middleware • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 68 EigenschaftenTOM Middleware • 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 lowpriority 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 69 EigenschaftenTOM Middleware • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 70 Middleware Eigenschaften TOM • 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 DBDaten und andere Betriebsmittel (Nachrichten, persistente Queues,Dateisysteme, MailService,...) • externe Koordination von Ressourcenänderungen durch 2PC-Protokoll • globaler TA-Schutz durch eine RM-Architektur begin Anwendung TA-Manager join requests prepare for commit/ commit RM RM ResourceRM Manager © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 71 Middleware EigenschaftenTOM • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 72 EigenschaftenTOM Middleware • 2PC-Protokoll: – 1. Phase: „voting phase“ – 2. Phase „commit phase“ 1 prepare 2 lokales Ergebnis 1. Phase (READY/FAILED) RM TA-Manager 3 globales Ergebnis (COMMIT/ROLLBACK/ABORT) 2. Phase 4 Quittierung (ACK) © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 73 TP-MonitorTOM Middleware – 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 74 Middleware Architektur eines TP-Monitor Frameworks TOM Benutzerschnittstelle auf Terminals, Desktops TP-Applikation TP-Applikation TP-Applikation TP-Applikation Tools TP-Monitor API TP Monitor Dienste TP-Monitor Framework Präsentation Daten: Masken SQL-Zugriff und Menüs Dateizugriff TA-Manager RPC Queuing Middlewaredienste Ressourcen: Datenbank, Datei, Queue © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 75 Application ServerTOM Middleware • Ähnlich dem TP-Monitoren • basiert auf modernen Sprachen wie Java • Bereitstellung der Verbindung zu Backend-Ressourcen (DB, ERPSysteme, Mainframe-Anwendungen) • Koordination vieler Ressourcenverbindungen • Mittler zwischen Datenbank und Anwendungen • Arten: – – – Web Application Server Legacy Application Server Enterprise Application Server © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 76 Middleware Application ServerTOM • 3-Schichten-Modell (Client-, Applikations-, Datenbankserverschicht) DBMS Webbrowser Web-Server Gateway Webbrowser Webbrowser Präsentationslogik ApplikationsServer Geschäftslogik © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg Mainframe Datenhaltung 77 Middleware Web Application ServerTOM Java Application Server Web Server DBMS Intranet Internet DBMS JDBC/ODBC © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 78 Middleware Web Application ServerTOM • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 79 Middleware Legacy Application ServerTOM Java Legacy Application Server Intranet Internet TP Monitor TP Monitor © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 80 Middleware Legacy Application ServerTOM • 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 81 Middleware Enterprise Application ServerTOM Java Web Server Inprise Application Server DBMS Intranet Internet Business Object Inprise Application Server © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg TP Monitor 82 Middleware Enterprise Application ServerTOM • deckt beide Aufgabenbereiche ab • webbasierte Anwendungen sowie Windows-Programme entwickelbar • z Bsp: Inprise Application Server © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 83 Middleware StandardsApplication 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 84 StandardsApplication Server TOM Middleware – 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 85 StandardsApplication Server TOM Middleware • 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 ACIDUnterstü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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 86 Zusammenfassung Middleware • 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) © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 87 Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 88 Message Broker Komponenten MB • Message Transformation • Rules Processing • Intelligentes Routing • Message Warehousing • Repository Services • GUI • Directory Services • Management • Adapter und APIs • Topologien © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 89 Message Broker Eingangsinformation Primärkomponenten Message Transformation Regelwerk MB Message Broker Intelligentes Routing Ausgangsinformation © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 90 Message Broker Message Transformations-Ebene MB • Versteht sämtliche Nachrichten • konvertiert und restrukturiert Daten zum Verständnis der ZielAnwendung(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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 91 Message Broker Schema ConversionMessage TransformationMB • Prozess der Umwandlung des Formats einer Nachricht in das des Zielsystems • Definition der Datentypen kann innerhalb der Rules-processingEbene erfolgen • obwohl jedes Schema in jedes andere übersetzt werden kann, sind außergewöhnliche Umstände möglich – z.B. Daten eines OODBS RDBS 21. November 2001 alphanumerisch 17 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 21/10/2001 alphanumerisch 10 92 Message Broker 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-upTabelle © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 93 Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 94 Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 95 Message Broker 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 Quell-System Ziel-System System D System A System E ............. System F © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg System B System C 96 Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 97 Repository Service Message Broker 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.ä. © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 98 Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 99 Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 100 Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 101 Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 102 Message Broker Thin Adapter Adapter MB • meist einfache APIWrapper oder Binder • bilden das Interface des Quell- oder Zielsystems auf ein gemeinsames, vom MB unterstütztes, Interface ab • Performanceverluste ohne Funktionalitätsgewinn Applikation oder Datenbank API Gemeinsames Interface Message Broker © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 103 Message Broker Thick Adapter Adapter MB • Aufsetzen einer zusätzlichen Abstraktionsebene auf das API • Nutzung des Repositories • erheblich mehr Funktionalität und Entwicklungsaufwand Applikation oder Datenbank API High-Level Business Events Message Broker © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 104 Message Broker Hub-and-spoke-Konfiguration Topologien MB • Sterntopologie Message Broker Anwendung © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 105 Message Broker Multi-Hub-Konfiguration Topologien MB • wenn mehr Anwendungen bestehen als ein Message Broker handeln kann • virtuell unbegrenzte Zahl von Applikationen integrierbar Message Broker Anwendung © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 106 Federated Konfiguration Message Broker Topologien MB • Interaktion mehrerer unabhängiger Message Broker über ein gemeinsames Austauschformat zur Integration einer Handelsgemeinschaft MB Unternehmen A XML/EDI MB MB Unternehmen C Unternehmen B © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 107
