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

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


Ü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


Basisblöcke

Unterteilung der EAI-Architektur in folgende 4 Basisblöcke

1. Kommunikationsmodel

2. Integrationsmethoden

4. Services

3. Middleware

Überblick


= Empfänger

Überblick 1. Kommunikationsmodel - Grundlagen

Receiver

Sender

Request = Anfrage Reply = Antwort


Überblick

1. Arten der Kommunikation

Kommunikation

Synchron Asynchron


Überblick

Synchrone Kommunikation

1. Request / Reply

Sender ReceiverRequest

BlocktBearbeitetRequest

Reply


Überblick


2. One-Way


Blockt

Empfangsbestätigung

BearbeitetRequest


Überblick


3. Synchrones Polling


Reply

BearbeitetRequest

Checks for ResponseFailure

Continues

Checks for ResponseSuccess

Stoppt polling


Überblick

Asynchrone Kommunikation

1. Message Passing

Sender ReceiverMessage Sent

continuesAccepts Message

+ continues


Überblick


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


Überblick


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


Überblick


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


Überblick


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


Überblick


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)


Ü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)


Überblick

4. Services

Erweiterung von Basiskommunikation und Middleware-Fähigkeiten.

- Directory- Lifecycle- Security

- Conversion and Transformation- Persistence- Notification- Workflow


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


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


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


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


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



• Transparenz

– Prozeduraufruf erscheint lokal– Übergabe an den entfernten Rechner ist nicht erkennbar

• Probleme– Parameterübergabe – Ortstransparenz – Fehlerfälle

Middleware



• Vorteile– Einfachheit des Mechanismus und Programmierung– Stabilität– kompatibel Client-Server-Architektur

• Nachteile– Hohes Maß an Verarbeitungsleistung– Netzwerkbelastung– Keine grossen Datenmengen


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


Einfaches Message Queuing MOM

M 5 M 4 M 3 M 2M 6 M 1

Message Queue Applikation

AApplikation

B

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

M 2 M 2

Message Queue Applikation

AApplikation

BMessage Queue

M 1 M 1

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

Middleware


Publish/subscribeMOM

Subscriber

Publisher

Subscriber

Subscriber

Message

Middleware


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


EigenschaftenMOM

• Message Translation

– Konvertierung in transportables Format

– Rückkonvertierung

– an Fixpunkten oder während des Routings

Middleware


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


Queue ManagementEigenschaftenMOM

Queue manager

Client 1

Client 2

Client 3

Client Anfragen

MessageQueue

a

Message Queue

b

Überwachen der Queues

Middleware


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


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


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



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



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


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


Distributed Objects

MACH_DAS() NEIN_DAS()

NEIN_DAS_HIER()

NETZWERK

kleine Applikationen, die Standard-Inter-

faces und Protokolle zur Kommunikation

untereinander benutzen

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

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

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

Middleware


CORBAORB

Interface Repository

Client

Dynamic Invocation

Client Stubs

ORBInterface

Object Request Broker Kern

Server

SkeletonObject

Adapter

CORBA ORB Architektur

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

Middleware


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


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


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


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


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


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


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


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


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


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


Middleware


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


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


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


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


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


Typ1-Treiber JDBC DOM

ODBC-Aufrufe

Datenprotokoll

JDBC-ODBC-Bridge Treiber (Abb. auf ODBC)

JDBC-Treiber Manager

DBVS


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



Zwei-Stufen Treiber (Abb. auf DBS-API)


DBVS


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


DBVS



Zwei-Stufen Treiber(vom Middlewarehersteller)


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



Zwei-Stufen-Treiber(Verwendung von Messages oder RPCs)

JDBC Treiber Manager

Java Anwendung

DBVS


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


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


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


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


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


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


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


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


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


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


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


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


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


Application ServerTOM

• 3-Schichten-Modell (Client-, Applikations-, Datenbankserverschicht)

DBMS

Webbrowser

Webbrowser

Webbrowser

GatewayWeb-Server

Applikations-Server Mainframe

Präsentationslogik Geschäftslogik Datenhaltung

Middleware


Web Application ServerTOM

Internet

DBMS

DBMS

Intranet

JavaApplication ServerWeb Server

JDBC/ODBC

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

Middleware


Legacy Application ServerTOM

Internet Intranet

JavaLegacy Application Server

TP Monitor

TP Monitor

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

Middleware


Enterprise Application ServerTOM

Internet

JavaWeb ServerInprise Application Server

Business ObjectInprise Application Server

TP Monitor

DBMS

Intranet

Middleware


Enterprise Application ServerTOM

• deckt beide Aufgabenbereiche ab

• webbasierte Anwendungen sowie Windows-Programme entwickelbar

• z Bsp: Inprise Application Server

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

Middleware


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


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


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


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


Komponenten MB

• Message Transformation

• Rules Processing

• Intelligentes Routing

• Message Warehousing

• Repository Services

• GUI

• Directory Services

• Management

• Adapter und APIs

• Topologien

Message Broker


Primärkomponenten MB

Intelligentes Routing

Regelwerk

Message TransformationEingangs-information

Ausgangs-information

Message Broker

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

Message Broker


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


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


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


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


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


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


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


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


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


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


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


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


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


Hub-and-spoke-Konfiguration Topologien MB

• Sterntopologie

Anwendung

Message Broker

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

Message Broker


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

Documents

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