Kommunikation in verteilten Systemen (Middleware)

Ch. Thiele, 01IN, Oberseminar "Datenmanagement" SS05

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 TechnologieDienstleistung zur Vermittlung zwischen Anwendungen anErmöglicht Softwarekomponenten die Kommunikation untereinander


Aufgaben von Middleware (1)

Kommunikation einer Softwarekomponente über Netzwerke wird für diese transparent gemachtOrganisiert Transport komplexer Daten (Messaging)Stellt Software –Schnittstellen und – Dienste bereitStellt die Transaktionssicherheit über unabhängige Teilsysteme dar (Transaktions-Monitor)


Aufgaben von Middleware (2)

Stellt Dienste für Identifikation, Authentifizierung, Zugriffe oder Sicherheit zur VerfügungVerbirgt Unterschiede zwischen Hardwareplattformen, Programmiersprachen, Betriebssystemen und ÜbertragungsprotokollenVerschafft eine einheitliche SichtVerbirgt Komplexität der zugrunde liegenden Anwendungen und Infrastruktur


Vereinfachter AblaufSoftwarekomponente A nutzt Schnittstellen der Middleware um mit SK B zu Informationen auszutauschenMiddleware 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


MiddlewareNachteile: Größe und Schwerfälligkeit Wenig Optimierungsmöglichkeiten in der

LeistungsfähigkeitProdukte:

CICS von IBM NetWeaver von SAP Websphere von IBM


Kommunikation in verteilten Systemen

1. Nachrichten-basiert2. Remote Procedure Calls (RPC)3. Objekt-basiert4. Web-basiert5. Komponenten-basiert

Man unterscheidet: synchrone und asynchrone Kommunikation


1. Nachrichten-basiertEinfachste ÜbertragungsartAsynchron: Zwischenspeicherung (Pufferung) der Nachricht zwischen Sender und EmpfängerVerwendung von Pipes oder Queues

... ein Beispiel hierfür ist das Java Messaging Service

(JMS)


JMS (1)Asynchrone KommunikationBasis bildet ein Message Server (JMS Provider), der Nachrichten empfängt zentrale Speicherung der DatenAufbau 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ügungAblauf:

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 ComputingRPC-System der Firma SUNBesteht aus Routinen für RPCVerwendet neben TCP auch UDP als TransportprotokollBlockierende, asynchrone oder nicht blockierende RPC möglichAuch Broadcast-RPC möglich: Client sendet Broadcast und wartet auf mehrere Antworten


3. Objekt-basierte Kommunikation

Kommunikation und Koordination von Objekten auf verschiedenen RechnernJedes ‚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 VMAufrufe werden wie lokale Aufrufe abgebildetAusnahmebehandlung (z.b. bei Verbindungsabbruch) notwendig


DCOMVorgänger: COM (Component Object Model) und OLE (Object Linking and Embedding)DCOM-Objekte sind Softwarekomponenten mit ein oder mehreren SchnittstellenNachteile:

Bindung an Betriebssysteme von Microsoft Keine Mehrfachvererbung von Schnittstellen: Objekte

untereinander können keine Schnittstellen erben


4. Web-basierte Kommunikation

Nutzung vorhandener Internet-TechnologienTransfer via HTTPBasis bildet XMLEinsatz von Web-Services


Web-Services (1)WS sind über das Internet zugängliche Schnittstellen zu AnwendungsfunktionenNutzung von Standardtechniken des InternetsBasieren auf XML („XML-Web-Services“)

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


WS (2) - SOAPSimple Object Access ProtokollKommunikationsprotokoll zum Austausch strukturierter und typisierter DatenXML-basierter RPCAuch unabhängig von Web-Services, WSDL, ... einsetzbarNutzt HTTP, SMTP, FTP, ... Als ÜbertragungsprotokolleZiel: 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-ServicesBeschreibt Vorgehensweise, um Informationen über Web-Services zu publizieren und aufzufindenUDDI-Server: Datenbank, welche Beschreibungen der Web-Services als Einträge enthältEnthä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 notwendigprivate

liegt hinter einer Firewall für eine Intranet-Applikation

semi-private Registrierungsstelle zwischen vertrauenswürdigen Partnern


WS (5) - WSDLBeschreibungssprache der Schnittstelle für einen Web-ServiceGebunden an das Protokoll SOAPXML-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) - AblaufServices Requestor (Client) sucht gewünschten Dienst bei der UDDI-Service RegistryRegistry sendet URL des registrierten DienstesClient 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

KomponentenVorhandene 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 ObjekteFunktionalitäten werden über Schnittstelle bereit gestelltBeispiel: 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 FormatStandardisiert Akzeptanz am MarktTransformation 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 Einstellen in Message Queue


Beispiel einer XML-View


Oracle Streams AQ (1)AQ = Advanced QueuingAsynchrones, Datenbankinternes Message QueuingNutzung der Oracle-Datenbank zur PersistenzsicherungKommunikation 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 ZuweisungMessage Properties

LebensdauerEmpfängerException Queue einer Nachricht


Oracle Streams AQ (3)Nachrichten vom Client werden durch den Server verarbeitetAQ-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 SystemBPEL (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

Documents

Kommunikation in verteilten Systemen (Middleware)