Christina Reuter, David Kaiser, Thomas Hoffmann

Präsentation zum Thema: "Christina Reuter, David Kaiser, Thomas Hoffmann"—  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 Gliederung Überblick über Basistechnologien Middleware Message Broker
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

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

5 Kommunikationsmodel - Grundlagen
Überblick Kommunikationsmodel - Grundlagen Sender Request = Anfrage Reply = Antwort = Empfänger Receiver © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

6 Arten der Kommunikation
Überblick Arten der Kommunikation Kommunikation Synchron Asynchron © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

7 Synchrone Kommunikation
Überblick Synchrone Kommunikation Request / Reply Bearbeitet Request Blockt Request Sender Receiver Reply © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

8 Synchrone Kommunikation
Überblick Synchrone Kommunikation 2. One-Way Bearbeitet Request Blockt Request Sender Receiver Empfangsbestätigung © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

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

10 Asynchrone Kommunikation
Überblick Asynchrone Kommunikation 1. Message Passing Accepts Message + continues continues Message Sent Sender Receiver © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

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

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

13 2. Integrationsmethoden
Ü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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

14 2. Integrationsmethoden
Ü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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

15 2. Integrationsmethoden
Ü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 © 2001 Monika Mustermann, MLU Halle-Wittenberg

16 Verwaltet Requests zwischen Softwarekomponenten.
Ü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 © 2001 Monika Mustermann, MLU Halle-Wittenberg

17 Erweiterung von Basiskommunikation und Middleware-Fähigkeiten.
Ü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 © 2001 Monika Mustermann, MLU Halle-Wittenberg

18 MiddlewaretypenGliederung
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

19 MiddlewaretypenGliederung
2.4 Datenbankorientierte Middleware 2.4.1 CLIs ODBC 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

20 Aufruf einer fremden Prozedur durch ein Programm
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 © 2001 Monika Mustermann, MLU Halle-Wittenberg

21 EigenschaftenRemote Procedure Call
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

23 Remote Procedure Call Transparenz Probleme
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

24 Remote Procedure Call Vorteile Nachteile
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

25 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

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

27 Request/ReplyMessage Queuing  MOM
Middleware 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 1 M 1 Message Queue Applikation A Applikation B Message Queue M 2 M 2 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

28 Publish/subsribeMOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

29 Publish/subscribeMOM
Middleware Publish/subscribeMOM Subscriber Subscriber Subscriber Publisher Message © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

31 Message Translation Konvertierung in transportables Format
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

32 Queue Management Verwaltung mehrerer Queues
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

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

34 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

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

36 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

38 Multiple Queuing RoutingEigenschaftenMOM
Middleware Multiple Queuing RoutingEigenschaftenMOM Queue manager Client n Message Queue 1 Client n+1 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

39 Distributed Objects/ORB
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

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

41 Schnittstelle des Serverobjekts muss definiert sein
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

42 2 Typen von „Betriebssystemen“ für DO:
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

43 Distributed Objects/ORB
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

45 CORBA Client: Server/Serverobjekte: Object Adapter:
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 IDL-spezifische 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

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

47 OLE/COM Management zusammengesetzter Dokumente: OLE Automation: OCX:
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

48 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

49 Bereitstellung einer Standardschnittstelle zum Zugriff auf DBs
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

50 Treiber-ManagerODBCDOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

51 ODBC-TreiberODBCDOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

52 Ein-Stufen-TreiberODBC-TreiberODBCDOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

53 Ein-Stufen-TreiberODBC-TreiberODBCDOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

54 Zwei-Stufen-TreiberODBC-TreiberODBCDOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

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

57 Drei-Stufen-TreiberODBC-TreiberODBC DOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

59 JDBC  DOM Java DataBase Connectivity
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

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

62 Typ2-Treiber  JDBC  DOM
Middleware Typ2-Treiber  JDBC  DOM Zwei-Stufen Treiber (Abb. auf DBS-API) JDBC-Treiber Manager DBVS Netzwerkbibliothek/ RPC-Laufzeitsystem Java Anwendung DB Laufzeitbibliothek (Binärcode) 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 DBS-API Datenprotokoll Protokoll für Daten- übertragung im Netzwerk © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

64 Typ4-Treiber  JDBC  DOM
Middleware Typ4-Treiber  JDBC  DOM 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 Java Anwendung JDBC Treiber Manager Zwei-Stufen-Treiber (Verwendung von Messages oder RPCs) Daten- protokoll Netzwerkbibliothek/ RPC-Laufzeitsystem Protokoll für Daten- übertragung im Netzwerk DBVS © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

65 Native Datenbank 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

66 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

67 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

68 Database Multiplexing
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

69 Load Balancing/ Lastausgleich:
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

70 EigenschaftenTOM Fehlertoleranz :
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

71 Transaktionsverarbeitungsmodell nach X/OPEN :
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 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 RM Anwendung TA-Manager Resource- Manager begin requests join prepare for commit/ commit © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

72 EigenschaftenTOM begin: join: prepare for commit:
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

73 globales Ergebnis (COMMIT/ROLLBACK/ABORT)
Middleware 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) 1 2 3 4 1. Phase 2. Phase prepare © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

74 Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

76 Application ServerTOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

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

79 Web Application ServerTOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

81 Legacy Application ServerTOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

83 Enterprise Application ServerTOM
Middleware Enterprise Application ServerTOM 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

84 StandardsApplication Server TOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

85 StandardsApplication Server TOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

86 StandardsApplication Server TOM
Middleware 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

87 Zusammenfassung RPC MOM Distributed Objects
Middleware 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) © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

88 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

89 Message Transformation Rules Processing Intelligentes Routing
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

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

91 Message Transformations-Ebene  MB
Message Broker 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 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

92 Schema ConversionMessage TransformationMB
Message Broker 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 21. November 2001 21/10/2001 alphanumerisch 17 alphanumerisch 10 © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

93 Data Conversion  Message Transformation  MB
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-up-Tabelle © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

94 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

95 Speicherung der Regeln im Repository oder in Textfiles
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

96 Intelligentes Routing  MB
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 System D System E System F Quell-System System A System B System C Ziel-System © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

97 Message Warehousing  MB
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

98 Repository Service  MB
Message Broker 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.ä. © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

99 Graphical User Interface  MB
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

100 Directory Services  MB
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

101 Administration und Management anzeigen wichtiger Statistiken
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

102 Schnittstelle zwischen Message Broker und Applikation
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

103 Thin Adapter  Adapter  MB
Message Broker 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 API Applikation oder Datenbank Gemeinsames Interface Message Broker © 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg

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

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

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

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