Aufbau Integrierter Informationssysteme Nachrichtenbasierte Kommunikation Michael Schmidt, Jens Dietrich, Marco Schopp, Sven Dammann Martin-Luther-Universität.

Aufbau Integrierter Informationssysteme

Nachrichtenbasierte Kommunikation

Michael Schmidt, Jens Dietrich, Marco Schopp, Sven Dammann

Martin-Luther-Universität Halle-Wittenberg

Hauptseminar - Halle - 26.04.23

© 2001 Sven Dammann, Jens Dietrich, Michael Schmidt, Marco Schopp 2

Gliederung

1. Message Queuing

2. Entwurfsmuster für MQS

3. Oracle Advanced Queuing

4. JavaMessagingService


Einleitung

• Middleware bildet zusätzliche Sicht zwischen Hardware/Betriebssystem und Anwendungssicht

• Aufgabe:– Verbergen der Unterschiede der einzelnen Plattformen– System aus Anwendungssicht homogen erscheinen zu lassen

• Ansatz ist Message Queuing Systeme (MQS)

Message Queuing Entwurfsmuster Oracle Advanced Queuing JavaMessagingService


Nachrichtenaustausch mit Queues

• Kommunikation zwischen Anwendungen über Austausch von Nachrichten (Messages), die in Queue gestellt bzw. entnommen werden

• Programme kommunizieren über ein Netzwerk ohne private und logische Verbindung




Einwegkommunikation:




Zweiwegkommunikation:



• weiteres Merkmal:

– asynchrone Kommunikation

• 4 Queues sind notwendig für Client-Server-Anwendungen:

– Request-Queue– Reply-Queue– Dead-Letter-Queue (clientseitig)– Dead-Letter-Queue (serverseitig)




• Zwei Modelle beim Einsatz von MQS

– Point-to-Point– Publish-and-Subscribe




Netzwerkhandling

• Netzwerkhandling wir vor den Anwendungen versteckt

• MQS:

- regelt Kommunikation über das Netz

- kann auf auftretende Fehler reagieren



Kommunikationsablauf im Detail



Queue Manager und Message Queuing Interface

• mindestens ein Queue Manager (QM)pro Rechner bzw. Netzwerkknoten

• bei einzelnen Knoten

- „normalen“ Rechner

- „thin clients“ Rechner



Queue Manager und Message Queuing Interface

• Message Queuing Interface(MQI) für die Kommunikation zwischen Anwendung und QM

• besteht aus einer Menge von „Calls“ (Aufrufen)



Transaktionsunterstützung

• drei Stufen der Transaktionsunterstützung:

- interne Transaktionen

- Unterstützung externe Transaktionmanager

- Rolle eines Transaction Coordinators



Vergleich MessageQueuing mit anderen Middlewaretechnologien

CORBA

•verbreitete Technik – ohne grossen Aufwand einsetzbar•problematisch bei Auftreten eines Fehlers

Verteilte Transaktionsverarbeitung

•auftretende Fehler werden automatisch korrigiert•hohe Kosten und schmales Spektrum der unterstützenden Systeme

MQS

• „ die goldene Mitte“• übernimmt das Netzwerkhandling• Entkopplung der Anwendungen• problematisch bei stark zeitbezogenen Systemen



Vorteile von Messaging und Queuing

• freie Kapazitäten entstehen

• einfache Verwendung des Interface

• keine Beschränkung der Anwendungsarchitektur



Möglichkeiten des Message Queuing

A

Q1

DCB

Q2

Q3

E F


RQ2

RQ1

• Keine logische Verbindung zwischen E und F• E schreibt Message in Queue (put)• F nimmt Message aus Queue (get)• Point-to-Point Kommunikation

One-to-one Relationship

• E sammelt die Ergebnisse von B, C und D • B, C, D können z.B. Client von Server- programm E sein (Subscriber)• Messagebearbeitung nach FIFO oder Prioritäten

Many-to-one Relationship

• A verteilt Arbeit auf B, C und D • B, C, D können parallel arbeiten (load balancing)• schnellere Bearbeitung bei sequen- tieller Abfolge• Publish & Subscribe

One-to-many Relationship

• E sendet nur Request an F • keine Rückmeldung des Program- mes, daß die Message aus der Queue nimmt• Bsp.: Fire-and-Forget

One-way Communication

• C veranlasst E zur Rückmeldung (Reply)• können Ergebnisse einer Operation sein oder Bestätigungen

Two-way CommunicationFlexibles Systemdesign

• Keine Einschränkungen in der Applikationsstruktur


MessageAufbau einer Message

Message Describtor

Application Data

Message Identifier (24 Byte String)

Correlation Identifier (24 Byte String)

• Eigentliche Nachricht• 4 MB – 100 MB

Queues• Target Queue• Reply Queue (opt.)


Attribute• date• time• priority• persistance• expiry date


Attribute einer Queue

Queue

• Name • Max. Anzahl von Messages• Max. Messagegröße• Voreingestellte Art der Messages (persistent oder transient)

Eindeutige Identifizierung der Queue durch andere Komponenten des Systems

Einschränkungen / Vorein-stellungen für Programme, die auf Queue zugreifen



LQ

QMB

TQA

TQC

Arten von Queues

LQ

QMA

TQB

TQC

N E T Z W E R K

Applikation A Applikation B Applikation C

LQ

QMC

TQA

TQB

DQ AQ IQ

Applikation D

DLQ


Local Queues• alle Queues, die dem QM zugeordnet sind auf den die App. zugreift• App. schreibt in LQ• App. Liest aus LQ

Remote Queues• alle Queues, die nicht lokal sind• App. weiß phys Ort nicht• QM übernimmt Zustellung

Transmission Queues• Zwischenqueue beim Senden • Je 1 TQ für jeden remote QM• Remote QM liest aus TQ und schreibt in seine LQ

Dynamic Queues• autom. Beendigung beim Progr.ende • dynamische Erzeu- gung - permanent (überle- ben QM restart) - temporär

Alias Queues• dieselbe physische Queue • mehrere Programme Zugriff auf dieselbe Queue• Aufruf über versch. Namen (Definitionen)

Initiation Queues• QM schreibt in IQ wenn Bed. Einer LQ erfüllt ist • IQ triggert neue Applikation• App. handelt das auslösende Event

Dead-Letter Queues• Queue für unzustell- bare Nachrichten• Jeder QM hat DLQ• Gründe: - Zielqueue voll - Zielqueue ex. nicht - ...


Client Server

Entwurfsmuster

Sende Anfrage

Erwarte Antwort

Lese Anfrage

Sende Ergebnis

Führe aus

Daten

Pseudosynchronous Inquiry

Request Message

Q1

Reply Message

Q2


Kommunikation asynchron

• Client kann nicht weiterarbeiten bis Reply-Message eingetroffen• nur lesender Zugriff

Anfragen idempotent• wiederholt sich die Anfrage ändert sich das Ergebnis nicht• bei timeout: Wiederholung• einfaches Error-handling Reply Message:

Nicht persistentReply Queue:

Temporary Dynamic Queue

Request Queue:Standard Queue

Request Message:Nicht persistent Problem: Orphans


Entwurfsmuster (2)

Client Server

Lese Anfrage

Sende Ergebnis

Führe aus

Daten

Asynchronous Inquiry

Request Message

Q1

Reply Message

Q2

Sende Anfrage

Arbeite weiter

Erhalte Antwort

Problem: Wie erfährt Client vom Eintreffen

der Reply-Message ?


Kommunikation asynchron

• Client kann weiterarbeiten und muss nicht blockierend auf Reply- Message warten

Request ist Anfrage

• Daten des Servers bleiben unan- getastet• bei Fehler: Wiederholung


Entwurfsmuster (3)

Client ServerSende Auftrag Lese Auftrag

Führe aus

Daten

Fire-and-forget Update

Request Message

Q1


Änderung von Daten• Ankunft der Nachricht muss garan- tiert werden• keine Bestätigung der ausge- führten Änderungen

Anfragen nicht-idempotent

• evtl. Sicherstellung daß Nachricht nur einmal gesendet wird


Request Message:Persistent (exactly one o.

at least one)


Entwurfsmuster (4)

Client Server

Sende Auftrag

Erwarte Bestätigung

Lese Auftrag

Sende Ergebnis

Führe aus

Daten

Pseudosynchronous Update

Request Message

Q1

Reply Message

Q2

Problem: Bei Ausbleiben der Bestätigungkeine Info ob Update erfolgreich

verarbeite

Daten


Anfragen sind Updates • Modifizierung von Daten• Client kann nicht weiterarbeiten bis Bestätigung eingetroffen

Anfragen nicht-idempotent

• Vermeidung unbeabsichtigter Wiederholungen ein und derselben Anfrage


Entwurfsmuster (5)

Client Server

Lese Auftrag

Sende Ergebnis

Führe aus

Daten

Request Message

Q1

Reply Message

Q2

Sende Auftrag

Arbeite weiter

Bearbeite Bestätigung

Asynchronous Update with Acknowledgement


Manipulation von Daten• Client erwartet Bestätigung• Asynchrone KommunikationAnfragen nicht-idempotent

• evtl. Sicherstellung daß Nach- richt nur einmal gesendet wird• durch Persistenz garantierte Nachrichtenübermittlung Reply Message:

Persistent (exactly one o. at least one)

Reply Queue:Permanent Dynamic

Queue


Request Message:Persistent (exactly one o.

at least one)


Beispiel: Oracle8i Advanced Queuing

• Oracle8i ist ein message-orientiertes System

• System hat Queues (Warteschlangen) implementiert

• Queues ermöglichen eine asynchrone Kommunikation

• Oracle8i stellt mit der Advanced Queuing Technologie eine message-queuing-Infrastruktur zur Verfügung, die vollständig in die Datenbank integriert ist



Vorteile der Advanced Queuing Technologie

• Backup/Recovery

• Unbegrenzte Messageanzahl

• Möglichkeit des Aufbaus eines Message-Warehouse



Nachrichtenverarbeitung

• Anwendung stellt die Nachricht mit der Enqueue-Operation in eine Warteschlange (Queue)

• berechtigte Anwendungen können nun zeitlich unabhängig mit einer Dequeue-Operation diese Nachricht entnehmen und verarbeiten

DEQUEUEENQUEUE

Message

QUEUE



Vorteile duch Benutzungvon Queues

• fehlertolerantere Systeme

• Anwendungen können nach Bereitstellung der Nachricht gleich weiterarbeiten

• Möglichkeit der Integration unterschiedlicher Anwendungssysteme



Queues in der Datenbank (1)

1. Single-Consumer-Queue

• jede Nachricht ist nur für eine Anwendung (Verbraucher) bestimmt




2. Multi-Consumer-Queue

• jede Nachricht kann für beliebig viele Verbraucheranwendungen bestimmt sein




3. Queue-to-Queue

• Message kann auch von einer Queue in eine andere Queue übertragen werden >> Propagation



Komponenten eines Oracle8i-AQ Systems

• System besteht aus 3 Komponenten

QT

Message-KopfMessage-Payload(Daten)

I. Queue-Tabellen

II. Queues

III. Messages



I. Queue-Tabellen• Speicherorte der Queues

Charakteristische Eigenschaften:

• Art der Datenstruktur, die eine Message besitzen kann

• Sortierung der Messages innerhalb der Queues

• Art der Queues, die innerhalb der Queue-Tabelle definierbar sind

• Gruppierung aller Nachrichten einer Transaktion

Erzeugt durch den Befehl:

DBMS_AQADM.CREATE_QUEUE_TABLE



II. Queues• Speicherorte für die einzelnen Nachrichten

Charakteristische Eigenschaften:

• Art der Queue (Normal, Exception, Non-Persistent)

• Maximale Anzahl von ´dequeue´-Wiederholungen im Fehlerfall

• Speicherzeit der Messages (nachdem eine Message verbraucht wurde)

Erzeugt durch den Befehl:

DBMS_AQADM.CREATE_QUEUE



III. Message

• Träger der relevanten Informationen, die über das Message-System übermittelt werden sollen

Besteht aus 2 Teilen

• Message-Kopf

>> enthält Informationen über die Nachricht

• Message-Payload

>> der Datenteil, in dem sich die Daten befinden



Operationen mit Queues (1)

ENQUEUE

• stellt eine Nachricht in die Warteschlange

Syntax:

DBMS_AQ.ENQUEUE (Queue_namePayload

Beispiel

DBMS_AQ.ENQUEUE (Queue_name => ´q1´,Payload => nachricht);




DEQUEUE

• Operation, über die alle Benutzer eine Message aus einer Queue entnehmen können

Für eine ´dequeue´-Operation wird angegeben:

• die Queue, aus der die Message entnommen werden soll

• die ´dequeue´-Optionen

• Message-Eigenschaften

• der Datenbereich (payload)

• Message-Identifikation (message_id)




BEISPIEL EINER DEQUEUE-OPERATION

DBMS_AQ.DEQUEUE (

QUEUE_NAME => ´q_1´,

DEQUEUE_OPTIONS => dequeue_opts,

MESSAGE_PROPERTIES => m_p,

PAYLOAD => nachricht,

MESSAGE_HANDLE => msg_h );




DEQUEUE-OPTIONS

• Steuern der ´deque´-Operation

• wird angegeben welche Message verarbeitet werden soll

• wie eine Message verarbeitet werden soll

Remove-Mode

Browse-Mode

Locked-Mode




DEQUEUE-OPTIONS (2)

• die Zugriffsposition innerhalb der Queue

First_message

Next_message

Next_transaction

• ob und wie lange eine ´dequeue´-Operation auf eine Message warten soll, falls diese in der Queue nicht vorhanden ist



Der Java Message Service



Java Message Service (JMS)

• Programmiersprachenbasierte MOM

• Unterstützt beide Kommunikationsmodelle

Publish/Subscript

Client1

Publishes

Msg

Client2

SubscribesDelivers

Msg

Topic

Client3

SubscribesDelivers

Msg-- Peer to Peer --

Client1 Client2

Queue Sends Consumes

Acknowledges

Msg Msg

DomainMessage Consumption

•Synchron•Asynchron



JMS API Architecture

Administrative Tool

JMS Client JMS Provider

JNDI Namespace

DCFBind

Lookup

Logical Connection



The JMS API Programming ModelConnection Factory

•Verbindungskonfigurations-parameter

•Client benutzt CF, um Verbindung zu JMS Provider zu kreieren

Connection• aktive Verbindung von Client zu JMS Provider•Authentität des Clients überprüft•Eindeutiger Client Identifier•Liefert ConnectionMetaDaten

Session•Produktion/Verbrauch von Nachrichten•Definiert Ordnungsrelation•Behält konsumierte Nachrichten, bis zur Bestätigung

Session(2)•Message Listener•Transcation

•Transacted Session•Non-transacted Session•Bsp.:Onlineshopping

Message Producer• zum Senden von Nachrichten an eine Destination

Message Consumer• zum Empfangen von Nachrichten einer Destination•Message Listener•Message Selector

Message• Format ist einfach, jedoch sehr flexibel •Für jedes Format auf jeder Plattform •3 Teile: Header

PropertiesBody

ConnectionFactory

Connection

Creates

MessageProducer Creates

Session

Creates

Destination

Sends To

Destination

Receives From

Message

Creates

MessageConsumerCreates

Administrative Objekte

Objekte im Programm



MessagesMessage

• Format ist einfach, jedoch sehr flexibel •Für jedes Format auf jeder Plattform •3 Teile: Header

PropertiesBody

HeaderPropertiesBody

Header Field Set ByJMSDestination send or publish method

JMSDeliveryMode send or publish method

JMSExpiration send or publish method

JMSPriority send or publish method

JMSMessageID send or publish method

JMSTimestamp send or publish method

JMSCorrelationID Client

JMSReplyTo Client

JMSType Client

JMSRedelivered JMS provider

------ Header -----

JMSMessageID• identifiziert Nachricht eindeutigJMSDestination• Queue/TopicAndere Felder enthalten z.B. Zeitstempel oder Prioritäten



MessagesMessage


PropertiesBody

Header Properties Body

------ Properties -----

•Beschreibende Felder einer Nachricht read only• zusätzliche Informationen über Daten / Prozess, der sie kreiert hat•Syntax: property name: property value

•Optimierung der Kommunikation mit Queue/Topic (z.B. Selektionskriterien)



MessagesMessage


PropertiesBody

HeaderPropertiesBody

------ Body -----

Message Type

TextMessageMapMessage

BytesMessageStreamMessag

eObjectMessage

Message

•Java Zeichenkette: java.lang.String

•Grund der Aufnahme: String Messages werden extensiv benutzt (XML basierte Nachrichten)

•<Name-Wert> Paar• Name – String Werte Java Basistypen• Sequenziell o. zufälligerZugriff über Namen• Reihenfolge ist nicht definiert

• Uninterpretierte Bytes• Universell einsetzbar

• Stream von Java Basistypen•Sequentiell gelesen• Serialisiertes Java Objekt

• Nichts• besteht aus Header und Properties• Nützlich wenn der Body nicht benötigt wird

Body Contains:



Übersicht zum BeispielprogrammInitialisierungsteil

Starten des JMS Providers

Kreieren der JMS adiministr-

ativen Objekte

Sender-Client-Programm

ConnectionFactory

Kreieren der

Connection

Kreieren der

Session

Kreieren der

Message

Schliessen der

Connection

Empfänger-Client-Programm

ConnectionFactory

Kreieren der

Connection

Kreieren der

Session

Empfangender

Message

Schliessen der

Connection

Kreieren des

MsgProd

Kreieren des

MsgCons

Beenden

Löschen der Queues



Beispielprogramm (Starten des Providers)

Beim Einsatz von J3EE 1.3 SDK, wird JMS im SDK mitgelifert



Beispielprogramm (Kreieren der JMS administrierten Objekte)

•Warteschlange muss zu erst im JNDI registriert werden•Geschieht mit dem J2EE Administrations Tool, oder einem Batch Skript auf dem Server



Beispielprogramm (Überprüfung der administrierten Objekte)

•Warteschlange muss zu erst im JNDI registriert werden•Geschieht mit dem J2EE Administrations Tool, oder einem Batch Skript auf dem Serverl



Sende-Client-Programm

Variablen Deklaration

•JNID InitialContext•jndi.properties



Sender-Client-ConnectionFactory

•QueueConnectionFactory ist als Standardfactory vorhanden

•Erstellung weitere Factorys mit Admintools:

•j2eeadmin -addJmsFactory jndi_name •queue j2eeadmin -addJmsFactory jndi_name topic



Sender-Client: Connection / Session

•Kreieren der Connection

•Kreieren der Session •MessageProducer wird erstellt



Sender-Client: Message kreieren

•Interface des MessageProducers•Senden einer non-text control message zeigt Ende der Messages an



Sender-Client: Connection schliessen

•Das Ende – Connection geschlossen



Empfänger-Client: Connection/Session starten

•MessageConsumer wird erstellt



Empfänger-Client: Message empfangen

•Nach der start Methode kann die receive Methode jederzeit benutzt werden



Löschen einer Queue

•Administrative Objekt „meineWarteschlange“ sollte nach Abschluss wieder aus dem Enterpriseserver entfernt werdenen



Was haben wir gelernt?!


Fazit

Not every DAD

(Distributed Application Development)

needs a MOM.

But many...


NavigationZurück zu:Connection

Factory

Connection

Creates

MessageProducer Creates

Session

Creates

MessageConsumerCreates

Destination

Sends To

Destination

Receives From

Message

Creates

CFMessageC/S (S)C/S (E)


Administrative Tool

JMS Client JMS Provider

JNDI Namespace

DCFBind

Lookup

Logical Connection

CF


Nachteile MoM

• Kein echter Standard für die Programmierung mittels MoM

• Applikations-Daten einer Nachricht müssen vom Programmierer ein- und ausgepackt werden

• MQS kennt meist den Inhalt der Nachricht nicht, kann darauf keine Filter anwenden

• Schwer einsetzbar bei Programmen, die synchronen Ablauf haben

• MoM verbirgt die Kommunikation nicht


Vorteile MoM

Asynchron Ereignisgesteuert

• MoM fügt sich fließend in Programme mit asynchronen oder ereignisgesteuerten Ablauf ein

Skalierbarkeit / Verfügbarkeit

MoM skaliert sehr gut und führt zu einer höheren Ver- fügbarkeit des Gesamtsystems

Orts- / Migrationstransparent

• Dienste können während der Lebenszeit des Gesamt- systems ihren Ort verändern

Dynamisch

• Dienste können während der Lebenszeit des Gesamt- systems hinzugefügt werden

Quality of Service

• MoM bietet über Quality of Services u.a. die garantierte Auslieferung von Nachrichten

Aufbau Integrierter Informationssysteme Nachrichtenbasierte Kommunikation Michael Schmidt, Jens Dietrich, Marco Schopp, Sven Dammann Martin-Luther-Universität.

Documents

jens dietrich

sven dammannmartin

marco schoppqueue manager

kommunikation ber

anwendungen ber austausch

queue manager qmpro

anwendungen verstecktmqs

einzelnen plattformensystem