Kommunikation in verteilten Systemen (Middleware)

Kommunikation in verteilten

Systemen (Middleware)

Agenda

Einleitung

 Begriff, Zielsetzung, Produkte

Kommunikation in verteilten Systemen Oracle - Messaging und Integration

 Oracle Streams AQ

 Oracle InterConnect („Hub and Spoke“) Orchestrierung von Web-Services: BPEL

anwendungsunabhängige Technologie

Dienstleistung zur

Vermittlung zwischen Anwendungen an

Ermöglicht

Softwarekomponenten die Kommunikation

untereinander

Aufgaben von Middleware (1)

Kommunikation einer Softwarekomponente über Netzwerke wird für diese transparent gemacht

Organisiert Transport komplexer Daten (Messaging) Stellt Software –Schnittstellen und – Dienste bereit Stellt die Transaktionssicherheit über unabhängige Teilsysteme dar (Transaktions-Monitor)

Aufgaben von Middleware (2)

Stellt Dienste für Identifikation, Authentifizierung, Zugriffe oder Sicherheit zur Verfügung

Verbirgt Unterschiede zwischen

Hardwareplattformen, Programmiersprachen, Betriebssystemen und Übertragungsprotokollen Verschafft eine einheitliche Sicht

Verbirgt Komplexität der zugrunde liegenden Anwendungen und Infrastruktur

Vereinfachter Ablauf

Softwarekomponente A nutzt Schnittstellen der Middleware um mit SK B zu Informationen

auszutauschen

Middleware reicht Aufruf über ein Netzwerk weiter (Einsatz von TCP/IP, darauf HTTP, SOAP)

Auf der Empfängerseite setzt die Middleware die

Anforderung in einen Funktionsaufruf an die Software B um

Middleware

Nachteile:

 Größe und Schwerfälligkeit

 Wenig Optimierungsmöglichkeiten in der Leistungsfähigkeit

Produkte:

 CICS von IBM

 NetWeaver von SAP

 Websphere von IBM

Kommunikation in verteilten Systemen

1.

2.

3.

4.

5.

Man unterscheidet: synchrone und asynchrone Kommunikation

1. Nachrichten-basiert

Einfachste Übertragungsart

Asynchron: Zwischenspeicherung (Pufferung) der Nachricht zwischen Sender und Empfänger

Verwendung von Pipes oder Queues

... ein Beispiel hierfür ist das Java Messaging Service (JMS)

JMS (1)

Asynchrone Kommunikation

Basis bildet ein Message Server (JMS Provider), der Nachrichten empfängt

 zentrale Speicherung der Daten Aufbau JMS-Architektur:

 JMS-Client: Java Applikation, Versendet und Empfängt Nachrichten

 JMS-Provider: Führt Nachrichtenversand durch, Persistenz durch Datenbankunterstützung (Java Application Server oder andere)

JMS (2)

Nachrichtenmodelle von JMS:

 Point to Point

 1:1 Kommunikation

 Verwendung einer Queue (Warteschlange)

 Über einen Queue-Browser kann Empfänger Nachricht prüfen und anschließend konsumieren

 publish/subscribe

 1:m Kommunikation

 Verwendung eines Topic (virtueller Kanal)

 Mehrere Empfänger bilden einen Topic und erhalten eine Kopie der Nachricht

2. Remote Procedure Calls (1)

Voraussetzung:

 Programm (Prozedur) kann entfernte Prozedur aufrufen

 Verschiedene Server stellen Schnittstellenprozeduren zur Verfügung

Ablauf:

 Prozess auf Maschine A ruft Prozess auf Maschine B auf

 Aufrufender Prozess wird angehalten

 Abarbeitung der aufgerufenen Prozedur findet auf B statt

 Informationen werden durch Parameter bzw. Ergebnis der Prozedur übertragen (analog lokale Prozesse)

2. Remote Procedure Calls (2)

Aufgaben eines RPC-Systems:

 Kodierung und Übertragung

 Übertragung komplexer Datenstrukturen

 Behandlung von Übertragungsfehlern und Rechnerausfällen

Ziel:

 Aufruf von nicht lokalen Prozeduren Transparent machen

Beispiel: Open Network Computing (ONC)

Open Network Computing

RPC-System der Firma SUN Besteht aus Routinen für RPC

Verwendet neben TCP auch UDP als Transportprotokoll

Blockierende, asynchrone oder nicht blockierende RPC möglich

Auch Broadcast-RPC möglich: Client sendet Broadcast und wartet auf mehrere Antworten

3. Objekt-basierte Kommunikation

Kommunikation und Koordination von Objekten auf verschiedenen Rechnern

Jedes ‚entfernte‘ Objekt spezifiziert ein Interface (Angabe von Methoden, welche durch Clients aufgerufen werden können)

Nutzung von dynamisch zugewiesenen Ports (Firewall- freundlicher)

Beispiele:

 RMI (Remote Method Invocation)

 CORBA

 DCOM (Microsoft)

Remote Method Invocation (RMI)

Aufruf einer Methode eines ‚entfernten‘ Java-Ojektes

‚Entfernt‘: Objekt befindet sich auf einer anderen VM Aufrufe werden wie lokale Aufrufe abgebildet

Ausnahmebehandlung (z.b. bei Verbindungsabbruch) notwendig

DCOM

Vorgänger: COM (Component Object Model) und OLE (Object Linking and Embedding)

DCOM-Objekte sind Softwarekomponenten mit ein oder mehreren Schnittstellen

Nachteile:

 Bindung an Betriebssysteme von Microsoft

 Keine Mehrfachvererbung von Schnittstellen: Objekte untereinander können keine Schnittstellen erben

4. Web-basierte Kommunikation

Nutzung vorhandener Internet-Technologien Transfer via HTTP

Basis bildet XML

Einsatz von Web-Services

Web-Services (1)

WS sind über das Internet zugängliche Schnittstellen zu Anwendungsfunktionen

Nutzung von Standardtechniken des Internets Basieren auf XML („XML-Web-Services“)

... die Übertragung der XML-Daten erfolgt durch SOAP

WS (2) - SOAP

Simple Object Access Protokoll

Kommunikationsprotokoll zum Austausch strukturierter und typisierter Daten

XML-basierter RPC

Auch unabhängig von Web-Services, WSDL, ...

einsetzbar

Nutzt HTTP, SMTP, FTP, ... Als Übertragungsprotokolle

Ziel: Interaktion mit externen Anwendungen über das Internet

WS (3) – Architektur nach W3C

Dienstanbieter (Service Provider)

 Stellt Dienst bereit

 Publiziert Dienst bei der Service Registry

Service Registry

 Stellt Beschreibungen für Dienste bereit

 Nutzung von WSDL (Web Service Description Language)

 UDDI (Universal Description Discovery and Integration) – Verzeichnisdienst: Spezifikation für eine weltweit-basierte Registrierungsstelle

WS (4) – UDDI (1)

Spezifikation für verteilte, web-basierte Registrierungsstellen für Web-Services

Beschreibt Vorgehensweise, um Informationen über Web-Services zu publizieren und aufzufinden

UDDI-Server: Datenbank, welche Beschreibungen der Web-Services als Einträge enthält

Enthält Meta-Daten der WS:

 White Pages (Adresse, Ansprechpartner, ...)

 Yellow Pages (Branchenbuch, kategorisiert) Green Pages (technische Spezifikation der WS)

WS (4) – UDDI (2)

UDDI-Registrierungsstellen:

public

 regelmäßige Synchronisation notwendig

private

 liegt hinter einer Firewall für eine Intranet-Applikation

semi-private

 Registrierungsstelle zwischen vertrauenswürdigen Partnern

WS (5) - WSDL

Beschreibungssprache der Schnittstelle für einen Web-Service

Gebunden an das Protokoll SOAP XML-basiert

Übersicht WSDL-Dokument:

 Was für ein Service? (Welche Funktionen werden angeboten?)

 Welche Protokolle werden verwendet?

 Wo befindet sich der Service? (URL, bei mehreren Funktionen mehrere URL)

WS (6) - Ablauf

Services Requestor (Client) sucht gewünschten Dienst bei der UDDI-Service Registry

Registry sendet URL des registrierten Dienstes

Client ruft Schnittstelle des Web Service mit Hilfe der URL bei der Registry ab (SOAP-Request)

Schnittstelle des Web-Services wird als WSDL-Datei an Client übermittelt (SOAP-Response)

Client ruft Web-Service beim Dienstanbieter auf (SOAP-Request) Ausführung des Web-Services beim Dienstanbieter

Übermittlung des Ergebnisses an Client (SOAP-Response)

Web-Services unter .Net (1)

Remoting-Services:

 Verteile Kommunikation durch .Net Remoting

 Kommunikation nur unter .Net Anwendungen

Enterprise Services:

 Zusammenspiel von COM+ -Diensten und .Net Komponenten

Vorhandene Web-Services:

 .Net Alerts

 .Net Passport

Web-Services unter .Net (2)

.Net Alerts

 sind geräte- und anwendungsunabhängige, zeitgesteuerte Benachrichtigungsservices, die von Providern an ihre Kunden ausgesandt werden. (Unabhängig vom Endgerät - Empfang auf Microsoft Messenger, PDA, Mobiltelefon, ...)

.Net Passport

 ist ein Service, über den der Anwender mit einer

Benutzerkennung (einer registrierten E-Mail-Adresse) und einem einzigen Kennwort problemlos mit nur einer

Anmeldung auf alle Passport-geschützten Services zugreifen kann

5. Komponenten-basierte Kommunikation

Komponenten enthalten mehrere Objekte

Funktionalitäten werden über Schnittstelle bereit gestellt Beispiel: EJB

 Standardisierte Komponenten innerhalb eines J2EE-Servers

 Entwicklung komplexer und mehrschichtiger Anwendungen mittels Java

 Message Driven Beans: asynchrone Verarbeitung von JMS- Nachrichten, Serverseitige Nachrichtenverarbeitung

Oracle – Messaging und Integration in verteilten Systemen

- Oracle Streams AQ (Advanced Queuing)

- Oracle InterConnect („Hub and

Spoke“ Topologie)

Warum XML als Austauschformat ? (WH)

Lesbares Format

Standardisiert  Akzeptanz am Markt Transformation in andere Formate

Über HTTP Zugriffe und Transformationen durch XSLT abrufbar und Darstellung in HTML o.a.

Erzeugen einer einheitlichen Sicht durch XML-Views:

 Zugriff per HTTP

 Einfach Datenaustausch

 Einfach Abruf

Beispiel einer XML-View

Oracle Streams AQ (1)

AQ = Advanced Queuing

Asynchrones, Datenbankinternes Message Queuing Nutzung der Oracle-Datenbank zur

Persistenzsicherung

Kommunikation per Point to Point, publish/subscribe

Oracle Streams AQ (2)

Point to Point und publish/subscribe auch über Rechnergrenzen hinweg möglich

Wichtige Bestandteile einer Nachricht:

Eindeutige MESSAGE_ID

Automatische Zuweisung

Message Properties

Lebensdauer Empfänger

Exception Queue einer Nachricht

Oracle Streams AQ (3)

Nachrichten vom Client werden durch den Server verarbeitet

AQ-Servlet stellt Kommunikation mit den Queues zur Verfügung

Bisher: BUS-Struktur mit Anbindung an eine Datenbank:

publish/subscribe-Prinzip: Informationen, die in einer Anwendung entstehen, werden auf einem

zentralen Bus (Message Queue) abgelegt (publish) Applikationen entscheiden, ob die jeweilige

Information für sie relevant ist, und nehmen sie ggf. auf (subscribe)

zentraler Ansatz  InterConnect von Oracle (basiert auf „Hub and Spoke“-Topologie)

„Hub and Spoke“ (1)

Verwendung eines Data Hub:

 zentraler Daten-Sammelpunkt

 Anwendungen und Systeme sind mit diesem gleichberechtigt verbunden

 gesamte Kommunikation der einzelnen Anwendungen findet über diesen Punkt (Hub) statt

 dieser steuert und überwacht den gesamten Datenverkehr zwischen den einzelnen Systemen

 Integration von Fremdanwendungen, z.B. SAP, Siebel, Peoplesoft, ...

„Hub and Spoke“ (2)

Zielsetzung: ‚Vermeidung‘ unnötiger Dienste von EAI- Firmen

Vorteile:

 Data Hub enthält alle Entscheidungsrelevanten Daten nur einmal  höhere Datenqualität

zentrale und redundanzfreie Prozessverwaltung

Orchestrierung von WS - BPEL

Orchestrierung: Zusammenführung von WS zu einem komplexen System

BPEL (Business Process Execution Language):

 Standard zur Durchführung von Geschäftsprozessen mittels Internet-Technologien

 XML-basiertes Format

 ermöglicht die Kombination

von (in WSDL modellierten) Web-Services

BPEL - Struktur

Open Source Engine: ActiveBPEL