Überblick Wintersemester 2014/2015 Prof. Dr. Peter Mandl

Prof. Dr. Peter Mandl Seite: 1 Verteilte Systeme

Überblick Wintersemester 2014/2015

Prof. Dr. Peter Mandl

Verteilte Systeme

Einführung und Überblick

Zeitsynchronisation

Wahl und Übereinstimmung

RPC, verteilte Objekte und Dienste

Verteilte Transaktionen

Message Passing

Middlewareplattformen

Verteilte Architekturen

Gruppenkommunikation

Replikation

Wechselseitiger Ausschluss


Zielsetzung

Zielsetzung der Vorlesung ist es,

- den Message-Passing-Ansatz zu verstehen und nutzen zu

können,

- Message-Queueing-Systeme einordnen können und

- entscheiden zu können, wann man diese Technik benötigt.


Überblick

1. Grundlagen zum Message Passing

2. Fallstudie JMS

3. Cloud-Ansätze


Einführung

In verschiedenen Anwendungsszenarien sind nicht nur entfernte Aufrufe, sondern auch andere Kommunikationsbeziehungen möglich:

- Gleichberechtige Kommunikationspartner (symmetrische Rollenverteilung) P2P-Kommunikation

- Producer-Consumer-Problemstellungen

- Ereignisgesteuerte Bearbeitung

- Empfänger ist nicht immer verfügbar

Dazu benötigt man neben Remote Procedure Calls und deren Ableitungen noch andere Kommunikationstechniken

Verteilte Systeme Seite: 4


Meldungsorientierte, eng gekoppelte Kommunikation

Varianten meldungsorientierer Kommunikation

- Datagrammstil

- Rendezvous

Enge Kopplung zwischen den Partnern

Partner 2

sendreceive send

Blockierung

receive

Datagramm Rendezvous

Empfänger blockiert, Sender nicht

Synchronisierung, da auch Sender blockiert bis Quittung da ist

Partner 1 Partner 2Partner 1


Entkoppelte Kommunikation

Wenn die Partner nicht immer verfügbar sind,

- müssen Nachrichten ggf. zwischengepuffert werden,

- der Sender muss weiterarbeiten können und

- die Nachrichten können dann später vom Empfänger abgeholt werden

Transiente oder persistente Speicherung der Nachrichten?

Verarbeitung: in der Regel nach FIFO

Sender Empfänger Puffer


Entkoppelte Kommunikation Publish-Subscribe-Modell

Themenbezogene Ordnung: Topics

Ein Subscriber registriert sich für ein oder mehrere Topics

Subscriber können zur Laufzeit hinzukommen

Topics können transient oder persistent sein

Publisher 2 Topic

Subscriber 1

Subscriber m

…

Publisher 1

Publisher n

Subscriber 2

…


Entkoppelte Kommunikation Point-to-Point-Modell mit Queues

Warteschlangen-Modell: Queues

Subscriber können zur Laufzeit hinzukommen

Queues können transient oder persistent sein

Sender 2

Empfänger 1

Empfänger m

…

Sender 1

Sender n

Empfänger 2

…

Queue


Persistente versus transiente Speicherung

Transient gespeicherte Nachrichten in Topics oder Queues werden im Fehlerfall verworfen

Persistente Speicherung ist auch möglich, Nachrichten überleben Fehlerfall

Welche Fehler sind verkraftbar?

Sender Empfänger

Persistente Queue

Prof. Dr. Peter Mandl Seite: 10 Verteilte Systeme Verteilte Systeme

Transaktionssicherheit

Was bedeutet Transaktionssicherheit im Message Passing?

Einstellen und Entnehmen von Nachrichten in/aus Queue bzw. Topic in einer ACID-Transaktion

Provider muss entsprechende Vorkehrungen für die Sicherung der Logs und Daten vornehmen

Aber keine Ende-zu-Ende-Transaktionssicherheit

Das würde dem Entkoppelungsgedanken widersprechen

Transaktionssicherheit nur für das Einstellen von Nachrichten in die Queue oder in das Topic und separat für das Auslesen


Persistentes Message-Queuing-System notwendig

Praktisch erprobt

Entkopplung der Systeme

ACID-Eigenschaften?

Praktischer Ansatz: Simulation über DB-Tabellen möglich

Anwendung 1

Queue 1

Message-Queuing-System

Queue 2

Anwendung 2

Anwendung 3

...

Queued Transactions


Aufbau eines Message-Queueing-Systems mit Routing

Applikation

Applikation

Applikation

Applikation

R2

R1

Router

Empfänger B

Sender A

Nachricht

Sende-

Warteschlange

Empfangs-

Warte-

Schlange

C

D

R3


Anwendungsszenario: Online-Banking

Kontobuchungen über Online-Banking müssen in ein zentrales Kontoführungssystem übertragen werden

Mögliche Varianten für die Umsetzung:

- Dateiübertragung

- Direkte Diensteschnittstelle (etwa über RPC oder Webservices) des Kontoführungssystems nutzen

- Message-Passing

Online- Banking

Konto- führung

Buchungen/Umsätze


Überblick


2. Fallstudie JMS

3. Cloud-Ansätze


JMS-Architekturüberblick: Session-Modell (1)

Anwendung 1 Anwendung 2

JMS-Provider

JMS-Interfaces JMS-Interfaces

JMS-Consumer

Session Session

Connection

zum Provider

Connection

zum Provider

Connection und Session als Basis für Kommunikation

- Sessions sind unabhängig voneinander

- Jede Anwendung baut eine Session mit dem JMS-

Provider auf


JMS-Architekturüberblick: Session-Modell (2)

JMS-

Clientanwendung

JMS-

Clientanwendung

JMS-Provider

(JMS-Server,

MOM-Server)

JMS-SAP

(JMS-Interface)

Session

JMS

Connection

Session

JMS

Connection

Transportsystem (TCP)

Unabhängige

Verbindungen

Schicht 5-7

Schicht 1-4

TSAP

(Socketzugriff) TSAP TSAP

Connection: Kommunikationskanal zum JMS-Provider

Session repräsentiert einen Kontext für Sender, Empfänger und Nachrichten


JMS-Architekturüberblick: Point-to-Point-Modell


JMS-Provider

Queues Queues


JMS-Consumer

Baut Session auf

TopicTopic

Baut Session auf

Provider-Produkte: JBoss MQ, Websphere Message Queue (MQ), Apache ActiveMQ,

TIBCO EMS, Oracle Advanced Queueing, Oracle BEA WebLogic, …

Provider verwaltet Queues und Topics (administrative Objekte)

Destinations

Prof. Dr. Peter Mandl Verteilte Systeme Seite: 18

JMS-Kommunikation

Producer-Anwendung

ConnectionFactory besorgen

Destination besorgen

JMS Provider

Consumer-Anwendung

Queue/Topic einrichten

Connection erzeugen

Session erzeugen

MessageProducer erzeugen

Message erzeugen

Message senden

JNDIConnectionFactory besorgen

Destination besorgen

Connection erzeugen

Session erzeugen

MessageConsumer erzeugen

Message empfangen

Message bearbeiten

Administrator

...Topic oder Auftragsqueue

Close Session und Connection Close Session und Connection

...

onMessage()-Methode als Callback implementieren


JMS: Message-Aufbau

JMS-Message-Header und JMS-Properties

Message-Body

- Unterschiedliche Typen: TextMessage, ByteMessage, ObjectMessage,...

Properties

- JMSX-Properties : vordefiniert (siehe JMS-Spezifikation)

- Individuell: (name, value), verschiedene Typen möglich (boolean, byte, long,

String,…, Objects)

Interface Message

- getPropertyNames() liefert alle Properties

- clearBody() löscht ganzen Body

- clearProperties() löscht alle Properties einer Nachricht

- getJMSPriority(), setJMSProperty(…)

- getStringProperty(), setStringProperty(…)

- …

Message-Body

JMS-Message- Headerfelder

Vordefinierte JMSX-Properties

Frei definierte Properties

Header


JMS: Message-Header-Felder

Header-Feld Bedeutung Wird belegt

JMSDestination Ziel-Topic oder -Queue Implizit beim Senden

JMSDeliveryMode nicht-persistenter und persistenten Mode Implizit beim Senden

JMSMessageID Eindeutige Nachrichten-ID (String) Implizit beim Senden

JMSTimeStamp Zeitpunkt der Übergabe an den JMS-Provider)

Implizit beim Senden

JMSRedelivered Hinweis, dass möglicherweise schon ausgeliefert wurde

JMS-Provider

JMSExpiration Angabe, wie lange eine Nachricht leben soll Implizit beim Senden

JMSPriority Prioritäten, 0-4 = normal, 5-9 = hoch Implizit beim Senden

JMSCorrelationID Verlinken von Nachrichten möglich JMS-Client

JMSReplyTo Destination (Topic, Queue), zu der die Antwort geschickt werden soll

JMS-Client

JMSType Frei vergebener Typ der Nachricht (Client vergibt)

JMS-Client

JMS-Message-Header-Felder können gelesen und gesetzt werden

(get/set-Methoden)


JMS: JMSX-Properties

JMSX-Properties sind vordefinierte Properties, die in der JMS-Spezifikation vorgegeben sind:

- JMSXUserid: Eindeutiger String zur Identifikation eines JMS-Clients,

wird vom Provider beim Senden gesetzt

- JMSXApplId: Identifiziert die Anwendung, wird vom Provider beim Senden gesetzt

- …

Nutzung in Message-Selektoren möglich


JMS-Einstellmöglichkeiten (1)

Delivery-Modus: (regelt Providerausfall)

- Persistent: Nachrichten werden dauerhaft in einen Speicher

gelegt, auch bei JMS-Providerausfall werden Nachrichten

zugestellt

- Nicht-persistent: Nachrichten werden nach einen JMS-Provider-

Ausfall nicht mehr zugestellt

Abonnement-Modus: (regelt Konsumentenausfall)

- Dauerhaft: Nachrichten an nicht verfügbare Konsumenten

werden zu einem späteren Zeitpunkt zugestellt

- Nicht-dauerhaft: Keine Zustellung für nicht verfügbare

Konsumenten


JMS-Einstellmöglichkeiten (2)

Acknowledgement-Modus: (bezieht sich auf die Bestätigung

einer Nachricht):

- Auto_Ack: Automatische Bestätigung nachdem die Nachricht

angekommen ist und verarbeitet wurde

Einmalige Lieferung und keine Duplikate garantiert (at-

most-once)

- Dups_Ok_Ack: Empfangsbestätigung automatisch nach dem

Empfang und der Verarbeitung von n Nachrichten, wobei n vom

JMS Provider abhängt

keine Duplikatsprüfung (nur at-least-once).

- Client_Ack: Keine automatische Bestätigung, sondern explizit

durch JMS-Empfänger-Anwendung, über Methode acknowledge()

Angabe bei der Session-Erzeugung: createSession(false, Session.Auto_Ack); false no transaction


JMS-Beispielnutzung: Durable Subscriber

JMS-Subscriber JMS-Publisher

JMS-Provider

Session.

createDurableSubscriber(…)

Topic

Session

Topic

SessionTopic

Session

Session.

createProducer(…)

Abo-Modus: Dauerhaftes Abo überlebt auch ein Abmelden

eines Subscribers, Nachrichten bleiben erhalten

Identifikation bei erneuter Anmeldung über:

- Gleiche Connection

- Gleiche Destination und Subscription

- Gleicher Message Selector


JMS-Beispielnutzung: Filterungsmöglichkeiten (1)

Wie kann man Nachrichten für Topics filtern?

- Beispiel hier mit Topics

- Mehrere Topics

- Filter setzen im Client mit Message-Selektoren

Publisher

Topic1

Topic2

Topic3

Subscriber 1

Subscriber 2

Subscriber 3

Subscriber 4

Subscriber 5

Subscriber 6

Publisher Topic

Subscriber 1

Subscriber 2

Subscriber 3

Subscriber 4

Subscriber 5

Subscriber 6

Ein Topic + weiteren Filtermechanismus (Selektor in SQL93-ähnlicher Notation)

Filterung nur über Topics


JMS-Beispielnutzung: Filterungsmöglichkeiten (2)

Beispiel

- Eigenes Message-Property für die Selektion nutzen

Quelle: JMS-Spezifikation

String stockData; /* Stock information as a String */ TextMessage message; /* Set the message’s text to be the stockData string */ message = session.createTextMessage(); message.setText(stockData); /* Set the message property ‘StockSector’ */ message.setStringProperty("StockSector", "Technology");

Producer

String selector; selector = new String("(StockSector = ’Technology’)"); /* This string is specified when the MessageConsumer is created*/ MessageConsumer receiver; receiver = session.createConsumer(stockQueue, selector);

Consumer


Message Driven Bean: Ein asynchroner Mechanismus in JEE App Servern

EJB-Container

6: Delegiert die JMS-Nachricht an

eine Bean-Instanz, die einer

Queue oder einem Topic

zugeordnet ist.

Container erzeugt Bean-Instanz

selbstständig

JMS

Provider

2: Registriert sich als

Listener für Queue/Topic

5: Sendet JMS-Nachricht an Queue/Topic

1. Topic/Queue wird angelegt

(administrativer Vorgang)

JNDI Naming

Service

Client

Applikationsserver

JNDI

3: Holt Referenz

auf Queue/Topic

4: Liefert Referenz

auf Queue/Topic

Bean-

Instanz

onMessage()


Fallbeispiel für JMS-Topics: Chat-Programm

DataAccessService

Chat

ClientAdmin

WebClient

Admin

.NETClient

Monitoring

Client

Chat-Kernel

IDataAccessService

IChatClient

IAdminClient

IChatMessage

IMessageSender

IChatSystem

IMonitoringClient

IClient

JBoss

Application

Server

Raum

Topic

Update

TopicMonitoring

Topic

BusinessLogic

AdminClient

WS

Database (MySQL)Category

ChatRoomChatUser Role

ChatUser

LoggedIn

Unterstützte Interfaces:

Chat-Anwendung mit EJB und JMS realisiert

Architekturübersicht: Topics zum Verteilen der Chat-Nachrichten

JBoss EJB

JBoss MQ

3 Topics


Einschub: Interoperabilität von JMS-Providern

JMS ist keine Protokollspezifikation, sondern eine API-

Spezifikation

Weiterer (mittlerweile) OASIS-Standard

- Advanced Message Queuing Protocol (AMQP) der AMQP-Working-

Group als Protokollstandard für Message-Queuing-Systeme (http://amqp.org/, Stand: September 2013)


JBOSS

MQ


JMS-Consumer

Session

Connection

zum Provider

Connection

zum Provider

Websphere

MQ

SessionProtokoll?

http://amqp.org/


JMS 2.0 in Java EE 7 und SE

Erstes JMS-Release 1998, letzte Änderung JMS 1.1 war in 2003

JSR 343 JMS 2.0: Finally released im Mai 2013

Im Wesentlichen Vereinfachungen:

Vereinfachte API: JMSContext als zusammengefasstes Objekt

für Connection und Session

...

„Classic API“ (JMS 1.1) bleibt bestehen


Message Passing Diskussion

Message Passing als Alternative zu Client-Server, aber auch als

Ergänzung denkbar

JMS ist heute ein verbreiteter Standard, aber es gibt viele

proprietäre Ansätze

Message Driven Beans dienen der Einbettung von Message

Passing in die EJB-Umgebung

Diskussion:

- Persistenz in Queues – sichere Sache oder doch besser

Datenbanken nutzen?

- Wird ein Standardprotokoll wirklich genutzt?


Überblick


2. Fallstudie JMS

3. Cloud-Ansätze


Queuing-Dienste aus der Cloud: Überblick

Message-Queuing-Dienste kann man heute auch

schon aus der Cloud beziehen

Beispiele:

Windows Azure Queue

Amazon Simple Queue Service (SQS)

Linxter Internet Service Bus (Out of Service seit Okt. 2012)

Prof. Dr. Peter Mandl Seite: 34

Windows Azure Queue: Überblick

Modelle: Queues und Publish-Subscribe

Auslieferungsgarantie: At-least-once

Keine Ordnungsgarantie, auch kein FIFO

Maximale Nachrichtenlänge: 64 KB

REST API für Zugriff

Quelle: Martina Kerndl Studienarbeit: Untersuchung der Cloud-basierten Messaging-Lösung Mircosoft Azure Queue und Erprobung anhand eines Szenarios , Wintersemester 12/13, Hochschule München; Grafiken übernommen aus: http://msdn.microsoft.com/en-us/library/ff803372.aspx (letzter Zugriff am 23.08.2013)

Verteilte Systeme

http://msdn.microsoft.com/en-us/library/ff803372.aspx





Amazon SQS: Überblick

Modell: Queues, kein Publish-Subscribe

Auslieferungsgarantie: At-least-once

Einfache Java-API und auch andere Sprachen, siehe Amazon

Simple Queue Service, Developer Guide

Maximale Nachrichtenlänge: 64 KB

Löschen der Nachrichten bei Nichtabholen nach standardmäßig

14 Tagen, ganze Queues nach 30 Tagen

Quelle: Simon Effenberg: Studienarbeit: Amazon Simple Queue Service Benchmark, Wintersemester 12/13, Hochschule München

Verteilte Systeme


Amazon SQS: Speicherung der Nachrichten

Redundante Speicherung der Nachrichten, nach

Zufallsalgorithmus

Keine FIFO-Garantie

Quelle: Stefan Burgmair: Studienarbeit: Untersuchung der Cloud-basierten Messaging-Lösung Amazon Simple Queue Service bezüglich der Architektur, Zuverlässigkeit, Transaktionsfähigkeit und Skalierbarkeit, Wintersemester 12/13, Hochschule München; Grafik übernommen aus Amazon Simple Queue Service, Developer Guide

Verteilte Systeme


Amazon SQS: Besonderheit: Visibility

Nach dem Abholen einer Nachricht wird nicht automatisch gelöscht,

sondern die Nachricht wird zunächst unsichtbar für andere gemacht

Wenn innerhalb einer Zeitspanne (Visibility-Timeout) kein Löschen

erfolgt, wird die Nachricht wieder für andere sichtbar

Timeout-Einstellung (Sichtbarkeit) kann je Queue und/oder je

Nachricht erfolgen

Folgen: Kein garantiertes FIFO und evtl. doppelte Bearbeitung, aber

Fehlersemantik At-mostly-once

Übernommen aus: Amazon Simple Queue Service, Developer Guide

Verteilte Systeme


Amazon SQS: Eigene Benchmarks (1)

Eigene Benchmarks wurden durchgeführt

Resümee: Noch Vorsicht bei großer Last!


Betriebssystem RAM (GB) CPU Internet

Windows 8 Pro

(64-Bit)

4 GB Intel Core 2

Quad CPU -

2,5 GHz

Ethernet:

Telekom

V-DSL 50

Betriebssystem RAM (GB) CPU Internet

Windows 7 8 GB Intel i5 3,3

GHz

Ethernet:

Telekom

V-DSL 50 Rechner B - Server

Verteilte Systeme



Konfiguration an der AWS Console SQS

Weitgehend Standardeinstellungen verwendet


https://console.aws.amazon.com/sqs/

Verteilte Systeme



Seite: 40


Kommunikationsszenario

Verteilte Systeme


Amazon SQS: Eigene Benchmarks (4): Variation der Anzahl Clients

Seite: 41


Verteilte Systeme


Amazon SQS: Eigene Benchmarks (5): Variation der Nachrichtenlänge

Seite: 42


Verteilte Systeme


Vergleich aktueller Cloud-Messaging-Dienste

Amazon

SQS

Windows

Azure Queue

Linxter (Basic)

Preismodell Nutzungsabhängig Nutzungsabhängig Monatlicher Festpreis

Maximale Größe der Nachrichten (in KB)

64 64 1024

(+1024 KB je Anhang)

Maximale Lebensdauer der Nachrichten (in Tagen)

14 7 4

Zustellungssemantik At-Least-Once At-Least-Once Exactly-Once

Kommunikation (APIs) - SDK’s

- REST

- SDK‘s

- REST

- SDK‘s

Garantiertes FIFO Nein Nein Ja

Nachrichtenformat Textbasiert

Stand: 12/12


Zusammenfassung

Fragen?

Grundlagen zum Message Passing

Fallstudie JMS

Cloud-Ansätze

Documents

Überblick Wintersemester 2014/2015 Prof. Dr. Peter Mandl