aufbau integrierter informationssysteme Überblick über basistechnologien christina reuter, david...
TRANSCRIPT
Aufbau Integrierter Informationssysteme
Überblick über Basistechnologien
Christina Reuter, David Kaiser, Thomas Hoffmann
Martin-Luther-Universität Halle-Wittenberg
Hauptseminar - Halle - 21.11.2001
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 2
Gliederung
1. Überblick über Basistechnologien
2. Middleware
3. Message Broker
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 3
Überblick - Gliederung
1. Gliederung in 4 Basisblöcke
2. Kommunikationsmodel1. Synchrone Kommunikation2. Asynchrone Kommunikation
3. Integrationsmethoden1. Messaging2. Interface3. Connectors
4. Middleware1. RPC2. MOM
5. Services
Überblick
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 4
Basisblöcke
Unterteilung der EAI-Architektur in folgende 4 Basisblöcke
1. Kommunikationsmodel
2. Integrationsmethoden
4. Services
3. Middleware
Überblick
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 5
= Empfänger
Überblick 1. Kommunikationsmodel - Grundlagen
Receiver
Sender
Request = Anfrage Reply = Antwort
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 6
Überblick
1. Arten der Kommunikation
Kommunikation
Synchron Asynchron
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 7
Überblick
Synchrone Kommunikation
1. Request / Reply
Sender ReceiverRequest
BlocktBearbeitetRequest
Reply
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 8
Überblick
Synchrone Kommunikation
2. One-Way
Sender ReceiverRequest
Blockt
Empfangsbestätigung
BearbeitetRequest
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 9
Überblick
Synchrone Kommunikation
3. Synchrones Polling
Sender ReceiverRequest
Reply
BearbeitetRequest
Checks for ResponseFailure
Continues
Checks for ResponseSuccess
Stoppt polling
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 10
Überblick
Asynchrone Kommunikation
1. Message Passing
Sender ReceiverMessage Sent
continuesAccepts Message
+ continues
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 11
Überblick
Asynchrone Kommunikation
2. Publish / Subscribe
Sender Receiver
Receiver
Receiver
SubscriptionList
Subscribe to
Message B
Subscribe to Message ASubscribe to Message A
Message A Sent
continues
Message A Sent
Message A Sent
Accepts Message Continues
Accepts Message Continues
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 12
Überblick
Asynchrone Kommunikation
3. Broadcast
Sender
Receiver
Receiver
Receiver
Message A Sent
Message A SentMessage A Sent
continues
weißt Nachricht zurück
+ continues
Nimmt Nachricht an+ continues
Nimmt Nachricht an+ continues
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 13
Ü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 14
Ü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 15
Ü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 16
Ü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 17
Ü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 18
MiddlewaretypenGliederung
2. Middlewaretypen2.1 RPC2.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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 19
MiddlewaretypenGliederung
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 Middleware2.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+
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 20
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 21
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 22
GrafikRemote Procedure Call
Auftraggeber Auftragnehmer
Programm Programm
Stub Stub
1. Aufruf entfernte Prozedur
6. Rückgabe Parameter
5. Nachricht mit Rückgabe
2. Nachricht mit Aufruf
4. RückgabeParameter
lokal
3. Aufruf lokale
Prozedur
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 23
Remote Procedure Call
• Transparenz
– Prozeduraufruf erscheint lokal– Übergabe an den entfernten Rechner ist nicht erkennbar
• Probleme– Parameterübergabe – Ortstransparenz – Fehlerfälle
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 24
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 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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 26
Einfaches Message Queuing MOM
M 5 M 4 M 3 M 2M 6 M 1
Message Queue Applikation
AApplikation
B
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 27
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
M 2 M 2
Message Queue Applikation
AApplikation
BMessage Queue
M 1 M 1
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 28
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 29
Publish/subscribeMOM
Subscriber
Publisher
Subscriber
Subscriber
Message
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 30
Publish/subscribeMOM
Client n+10
Client n
Client n+100
Subscription Queue
Publication Queue
Pub-Sub Server
Verbindung zu Informations-
quellenPublish messagec
Subscribe messagea
Subscribe messagec
Subscribe messageb
Subscriptioncriteria
messages
Publicationmessagec
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 31
EigenschaftenMOM
• Message Translation
– Konvertierung in transportables Format
– Rückkonvertierung
– an Fixpunkten oder während des Routings
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 32
EigenschaftenMOM
• 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 33
Queue ManagementEigenschaftenMOM
Queue manager
Client 1
Client 2
Client 3
Client Anfragen
MessageQueue
a
Message Queue
b
Überwachen der Queues
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 34
EigenschaftenMOM
• 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 35
Queue PersistenzEigenschaftenMOM
Request Queue
Message Server
Message Server
Reply Queue
Message Repository
RepliesRequests
Message
Message
Message
Message
Message
Message
Message
Message
Message
Message Message
Message
Request message
Reply message
store message
store message
Reply message
Request messagekorrekter
Request-Empfang
Löschen aus
Repository
korrekterReply-
Empfang Löschen
aus Repository
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 36
Multiple Queuing RoutingEigenschaftenMOM
• 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 RoutingEigenschaftenMOM
Message Queue ZMessage Message
Message Queue YMessage Message
Message Queue XMessage Message
Client B
QueueManager
Client A
Client C
M-Typ X
M-Typ ZM-Typ Y
M-Typ Y
M-Typen Z + Y
M-Typ X
Multiple Queues für multiple Message-Typen
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 38
Multiple Queuing RoutingEigenschaftenMOM
Queuemanager
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 39
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 40
Distributed Objects
MACH_DAS() NEIN_DAS()
NEIN_DAS_HIER()
NETZWERK
kleine Applikationen, die Standard-Inter-
faces und Protokolle zur Kommunikation
untereinander benutzen
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 41
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 42
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 43
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 44
CORBAORB
Interface Repository
Client
Dynamic Invocation
Client Stubs
ORBInterface
Object Request Broker Kern
Server
SkeletonObject
Adapter
CORBA ORB Architektur
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 45
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 46
OLE/COM
Interface Negotiation Uniform Data Transfer Naming and BindingLicensing Life Cycle Events Structured Storage
Component Object Model
Compound Document Management
In-place-activationCustom Controls (OCX)
###
Frameworks
Object Services
ORB
OLE Automation
AutomationController
AutomationServer
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 47
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
© 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)
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 49
ODBCDOM
• 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 50
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 51
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 52
Ein-Stufen-TreiberODBC-TreiberODBCDOM
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 53
Ein-Stufen-TreiberODBC-TreiberODBCDOM
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 54
Zwei-Stufen-TreiberODBC-TreiberODBCDOM
• 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 55
Zwei-Stufen-TreiberODBC-TreiberODBC DOMD
irekt
e Te
ilnah
me
am D
aten
prot
okol
l
Datenprotokoll
Protokollfür Daten-
übertragung im Netzwerk
Zwei-Stufen-Treiber(Abbildung von DBS-API)
Treiber Manager
DB-Laufzeitbibliothek
DBVS
Netzwerkbibliothek/ RPC-Laufzeitsystem
Abbildung von O
DB
C-Fkt auf D
BS-A
PI
Anwendung
Zwei-Stufen-Treiber(Verwendung von Messages oder RPCs)
Treiber Manager
Anwendung
DBVS
Netzwerkbibliothek/ RPC-Laufzeitsystem
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 56
Zwei-Stufen-TreiberODBC-TreiberODBC DOM
Zwei-Stufen-Treiber 1
Treiber Manager
Serveranwendung 1
DBVS
Netzwerkbibliothek/ RPC-Laufzeitsystem 1
Einsatz von Middlewaretechnologien
Anwendung
DBS-API
NetztransportDatenprotokoll des Middlewareherstellers
für Netzwerk
1 : des Middleware- herstellers
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 57
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 58
Drei-Stufen-TreiberODBC-TreiberODBC DOM
AnwendungTreiber-Manager
Drei-Stufen-TreiberNetzwerkbibliothek/RPC-Runtimesystem
DBVS
(Verbindungs)ServerTreiber-Manager
Ein- oder Zwei-Stufen-Treiberweitere Komponenten
Datenprotokoll 2
Datenprotokoll 1
Client
Verbindungs-rechner auf dem LAN
DBVS-Server
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 59
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 60
ArchitekturenJDBC DOM
Client
Server
Client(nur GUI)
Server(Anwendungs-
logik)
DBMS
Java AppletHTML-Browser
Application ServerJDBC
proprietäres Protokoll
HTTP, CORBA,...
Java-Applikation
JDBC
DBMS
Zwei-Schichten-Architektur Drei-Schichten-Architektur
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 61
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 62
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 63
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 64
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 65
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 DOMMiddleware
© 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
Middleware
© 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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 68
EigenschaftenTOM
• 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 69
EigenschaftenTOM
• 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 70
EigenschaftenTOM
• 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 71
Eigenschaften TOM
RMRMRM
Anwendung
TA-Manager
Resource-Manager
begin
requests
joinprepare 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 72
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 73
EigenschaftenTOM
• 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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 74
TP-MonitorTOM– 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 75
Architektur eines TP-Monitor Frameworks TOM
TP-ApplikationTP-ApplikationTP-ApplikationTP-Applikation
TP-Monitor API
Tools
TP Monitor Dienste
PräsentationMasken
und Menüs
Daten:SQL-ZugriffDateizugriff
RPC Queuing
TA-Manager
Benutzerschnittstelle auf Terminals, Desktops
TP-Monitor Framework
Middleware-dienste
Ressourcen: Datenbank, Datei, Queue
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 76
Application ServerTOM
• Ä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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 77
Application ServerTOM
• 3-Schichten-Modell (Client-, Applikations-, Datenbankserverschicht)
DBMS
Webbrowser
Webbrowser
Webbrowser
GatewayWeb-Server
Applikations-Server Mainframe
Präsentationslogik Geschäftslogik Datenhaltung
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 78
Web Application ServerTOM
Internet
DBMS
DBMS
Intranet
JavaApplication ServerWeb Server
JDBC/ODBC
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 79
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 80
Legacy Application ServerTOM
Internet Intranet
JavaLegacy Application Server
TP Monitor
TP Monitor
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 81
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 82
Enterprise Application ServerTOM
Internet
JavaWeb ServerInprise Application Server
Business ObjectInprise Application Server
TP Monitor
DBMS
Intranet
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 83
Enterprise Application ServerTOM
• deckt beide Aufgabenbereiche ab
• webbasierte Anwendungen sowie Windows-Programme entwickelbar
• z Bsp: Inprise Application Server
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 84
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
Middleware
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 85
StandardsApplication 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 86
StandardsApplication 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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 87
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 88
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 89
Komponenten MB
• Message Transformation
• Rules Processing
• Intelligentes Routing
• Message Warehousing
• Repository Services
• GUI
• Directory Services
• Management
• Adapter und APIs
• Topologien
Message Broker
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 90
Primärkomponenten MB
Intelligentes Routing
Regelwerk
Message TransformationEingangs-information
Ausgangs-information
Message Broker
Message Broker
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 91
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 92
Schema ConversionMessage TransformationMB
• 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 2001 21/10/2001
alphanumerisch 17 alphanumerisch 10
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 93
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 94
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 95
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 96
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 97
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 98
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 99
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 100
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 101
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 102
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 103
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 104
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
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 105
Hub-and-spoke-Konfiguration Topologien MB
• Sterntopologie
Anwendung
Message Broker
Message Broker
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 106
Multi-Hub-Konfiguration Topologien MB
• wenn mehr Anwendungen bestehen als ein Message Broker handeln kann
• virtuell unbegrenzte Zahl von Applikationen integrierbar
Anwendung
Message Broker
Message Broker
© 2001 Christina Reuter, David Kaiser, Thomas Hoffmann MLU Halle-Wittenberg 107
Federated Konfiguration Topologien MB
• Interaktion mehrerer unabhängiger Message Broker über ein gemeinsames Austauschformat zur Integration einer Handels-gemeinschaft
MB
Unternehmen B
MB
Unternehmen AMB
Unternehmen C
XML/EDI
Message Broker