Tavendo WebMQ - Web Message Broker

T
Ein Tavendo Whitepaper
Juli 2012
Tavendo WebMQ – Web Message Broker
Eine Einführung für IT Architekten
in Einsatzszenarien und Technologie von Tavendo WebMQ
T
Zusammenfassung
Tavendo WebMQ ist ein Web Message Broker der als Vermittlungsstelle für die
Kommunikation in modernen Webanwendungen agiert.
Tavendo WebMQ bietet eine breite Palette an flexiblen Integrationsmöglichkeiten, die
sorgfältig für verschiedene Einsatzszenarien konzipiert wurden. Er basiert auf
Technologie die auf Robustheit, Interoperabilität und Skalierbarkeit optimiert wurde
und bietet umfassende Administrations- und Sicherheitseigenschaften speziell für den
Einsatz in Unternehmen.
Dieses Whitepaper bietet einen Überblick über verschiedene Einsatzszenarien für
WebMQ, und beschreibt die WebMQ zugrunde liegende Technologie.
Inhalt
1
Einsatzszenarien ......................................................................................................... 2
1.1 Erweiterung bestehender Web Applikationen um Push ......................................... 2
1.1.1
Von HTTP zu WebSocket ................................................................................ 2
1.1.2
Probleme bestehender Plattformen mit WebSocket..................................... 2
1.1.3
Tavendo WebMQ – Push ohne Plattformwechsel ......................................... 3
1.2 HTML5 Frontends in einer service-orientierten Architektur ................................... 4
1.2.1
Von Multi- zu Single-Page .............................................................................. 4
1.2.2
Anbindung von APIs über WebSocket............................................................ 5
1.3 HTML5 Frontends für Oracle Anwendungen ........................................................... 6
2
Technologie ................................................................................................................ 7
2.1 WebSocket ............................................................................................................... 7
2.2 WebSocket Application Messaging Protokoll .......................................................... 8
1
T
1 Einsatzszenarien
1.1
Erweiterung bestehender Web Applikationen um Push
Webanwendungen haben heute in der Regel keine Möglichkeit aktiv Informationen an
Browser-Frontends zu verteilen. Änderungen an Backend-Daten, Backend-Ereignisse
oder Aktionen anderer Benutzer können nicht vom Webserver an den Browser gepusht
werden. Benutzer bekommen solche Informationen bestenfalls nach einem Reload der
Seite angezeigt.
1.1.1
Von HTTP zu WebSocket
Durch die Verwendung von HTTP unterliegen Webanwendungen den Einschränkungen
einer strikten Request/Response Kommunikation:



keine bidirektionale Kommunikation
hohe Latenzzeiten
hoher Overhead für jeden Request/Response
Über die Jahre wurden verschiedene Workarounds entwickelt, die versuchen die
Auswirkungen dieser Beschränkungen von HTTP zu verringern. Von diesen funktioniert
keiner wirklich zufriedenstellend, und alle bringen ihre eigenen zusätzlichen Probleme
mit sich.
Mit WebSocket existiert seit kurzer Zeit erstmals ein standardisiertes (IETF), offenes
Web-Protokoll, das obige Einschränkungen eliminiert. WebSocket


ermöglicht bidirektionales Messaging mit sehr geringen Latenzen und
Overhead
ist in allen modernen Browsern bereits eingebaut
Eine kurze Einführung in WebSocket findet sich hier:
1.
2.
1.1.2
http://www.slideshare.net/pmoskovi/building-living-web-applications-with-html5-websockets
https://speakerdeck.com/embed/4fa18705843f27001f013c31#
Probleme bestehender Plattformen mit WebSocket
Moderne Browser unterstützen WebSocket nativ. Auf der Server-Seite ist jedoch
ebenfalls eine geeignete Plattform nötig:


der Netzwerk-Stack muss für eine große Anzahl langlebiger Verbindungen
gebaut sein
die asynchrone Verarbeitung von Nachrichten erfordert ein entsprechendes
Programmiermodell
2
T
Klassische Plattformen für Web Applikationen wie z.B.



Apache/PHP
Tomcat/JSF
ASP.NET
erfüllen diese Anforderungen nicht.
Eine Migration oder Neuentwicklung einer bestehenden Webanwendungen auf eine
geeignete Plattform ist mit hohen Kosten, Risiken und Zeitaufwand verbunden.
Weiter ist Know-how in der Anwendungsentwicklung für dies Plattformen nötig, die
alle auf einem asynchronen, Ereignis-getriebenen Programmiermodell basieren.
1.1.3
Tavendo WebMQ – Push ohne Plattformwechsel
Hier setzt Tavendo WebMQ an. Tavendo WebMQ erlaubt es existierende
Webanwendungen schnell, einfach und ohne Austausch der Anwendungsplattform um
Echtzeit-Eigenschaften und Push zu ergänzen. Es ist kein spezielles Know-how nötig.
Tavendo WebMQ wird neben den existierenden Webserver gestellt. WebMQ hält auf
der Client-Seite WebSocket-Verbindungen zu den Browsern, und hat auf der BackendSeite eine REST API, die es dem bestehenden Webserver erlaubt, mit einem HTTP/POST
Informationen an alle Browser zu verteilen. Die Interaktion zwischen Browser und dem
Webserver bleibt unverändert.
Das Absetzen von HTTP-Requests aus Webservern heraus ist auf so gut wie allen
Plattformen sehr einfach und mit wenigen Zeilen Code möglich.
Da die WebSocket Kommunikation komplett von Tavendo WebMQ durchgeführt wird
besteht keine Notwendigkeit, die Anwendungsplattform auszutauschen oder die
Anwendung zu migrieren bzw. neu zu implementieren.
3
T
1.2 HTML5 Frontends in einer service-orientierten Architektur
Mit HTML5 rollt eine technologische Revolution auf die Industrie zu, deren
Auswirkungen und Bedeutung bereits jetzt zu sehen sind. Abzulesen ist dies
exemplarisch an jüngsten strategischen Entscheidungen von Adobe und Microsoft:


Adobe hat das Ende der Entwicklung für Flash/Mobile angekündigt
Mit Windows 8 schwenkt Microsoft von .NET/Silverlight auf HTML5 um
Beide Firmen haben langjährig und in beträchtlichem Maße in die nun aufs Abstellgleis
beförderten Technologien investiert. Der Hintergrund für derart weitreichende
Neuausrichtungen ist jedoch eindeutig:
Mit HTML5 wird der Browser erstmals zu einer Anwendungs-Runtime die
konkurrenzfähig mit nativen Desktop-Anwendungen, Flash und Silverlight ist (oder
diese hinter sich lässt), aber plattformübergreifend und offen standardisiert verfügbar
ist. Mit HTML5 wird das Versprechen von „write once, run anywhere“ tatsächlich
eingelöst.
Dieser Wechsel hin zu HTML5 wird auf breiter Front Auswirkungen und Veränderungen
anstoßen, auch was die Anwendungsarchitektur und Rollenverteilung über
Anwendungsschichten hinweg betrifft.
1.2.1
Von Multi- zu Single-Page
Die klassische Architektur von Webanwendungen ist dreischichtig:
Hierbei ist der Web-Anwendungsserver u.a. zuständig für das rendern von Webseiten
und die Anwendung besteht aus einer größeren Anzahl von Seiten.
Mit HTML5 werden jedoch Anwendungen, die ein desktopähnliches Benutzererlebnis
bieten, anders gebaut: statt vieler einzelnen Webseiten besteht das Frontend aus nur
einer Seite, in der mittels JavaScript alle Logik für das Benutzerinterface enthalten ist.
Aus dieser JavaScript-Logik heraus wird dann die Darstellung der Seite verändert, ohne
dass hierfür Daten vom Server geladen werden.
4
T
Bekannte Beispiele für solche „Single-Page Web Apps“ sind


Google Gmail
Google Docs
In einer solchen Anwendung ist die mittlere Schicht nicht mehr für das Rendern von
Seiten zuständig. Ihr bleibt die Rolle als Service-Schicht, die vom Frontend
angesprochen wird.
1.2.2
Anbindung von APIs über WebSocket
Anwendungsserver in einer Service-orientierten Architektur stellen heute ihre Dienste
üblicherweise als Web-Services über ein HTTP-basiertes Protokoll zur Verfügung, wie
z.B.



SOAP
REST
Ext.Direct
Diese APIs können aus HTML5-Anwendungen direkt über HTTP genutzt werden.
Tavendo WebMQ erlaubt die Anbindung von HTML5 Frontends an die Service-API von
Anwendungsservern über WebSocket anstelle von HTTP.
Hierbei wird der Aufruf der Service-API durch den Browser von Tavendo WebMQ über
eine WebSocket-Verbindung entgegengenommen. WebMQ vermittelt dann diesen
Aufruf an den eigentlichen Zielserver über HTTP (SOAP, REST oder Ext.Direct) weiter.
Dies hat gegenüber dem direkten Aufruf eine Reihe von Vorteilen:
1.
2.
3.
4.
5.
nur ein Protokoll auf Seite des Clients
nur eine Browser-Server Verbindung
verminderter Netzwerkverkehr, insb. für Mobile Clients
wirklich asynchron: langsame API-Aufrufe blockieren keine nachfolgenden
Aufruf von Service APIs verschiedener Server (keine Cross-Domain Probleme)
Wenn ein Push vom Webserver zum Browser über WebMQ implementiert ist, dann
erfolgt dieser ebenfalls über die gleiche WebSocket-Verbindung zum Browser.
5
T
Eine Übersicht über die möglichen Integrations- und Kommunikationsmuster die von
Tavendo WebMQ unterstützt werden findet sich hier:
http://www.tavendo.de/webmq/resources/integration
Zusammenfassend bietet Tavendo WebMQ eine universelle Kommunikationsplattform
für moderne HTML5-Frontends, sowohl für Aufrufe von Web-Services als auch für
Server-Push und Browser-to-Browser Kommunikation.
1.3
HTML5 Frontends für Oracle Anwendungen
In vielen Szenarien ist die Implementierung einer service-orientierten Schicht bereits in
Oracle sinnvoll.
Geschäftslogik und Datenmanagement können in der Datenbank zentralisiert werden
und sind dann anwendungsübegreifend und konsistent verfügbar. Die Ausführung von
Geschäftslogik innerhalb der Datenbank nahe an den eigentlichen Daten hat
signifikante Performanz- und Sicherheitsvorteile gegenüber eine Implementierung auf
einem Anwendungsserver in der mittleren Schicht.
Mit HTML5 wird die Benutzeroberfläche und sämtliche oberflächen-orientierte Logik in
den Browser verlagert. In Kombination mit einer service-orientierten Schicht in der
Datenbank stellt sich die Frage, was dann eigentlich die Rolle und Funktion der
mittleren Schicht ist.
Tavendo WebMQ „Oracle Edition“ ermöglicht die Anbindung von HTML5-basierten
Web-Frontends direkt an Oracle, schnell und einfach, und ohne Anwendungs-/ServiceProgrammierung auf der mittleren Schicht.
Tavendo WebMQ „Oracle Edition“ agiert hierbei als reine Vermittlungsstelle für die
Kommunikation zwischen HTML5-Frontends und Oracle Backend-Datenbanken und
ermöglicht:
1. Aufruf von Oracle Stored Procedures aus HTML5/JavaScript-Frontends
2. Push von Daten direkt aus Oracle Stored Procedures oder Triggern
Es ist damit kein Anwendungsserver auf der mittleren Schicht mehr notwendig.
6
T
Da keine Programmierung auf der mittleren Schicht notwendig ist, wird kein Know-How
für die Entwicklung in Java, .NET, PHP, Ruby, Python o.ä. benötigt. Erforderlich sind
nurmehr zwei Entwicklerprofile:


Oracle SQL und PL/SQL
HTML5/CSS/JavaScript
Das Wegfallen von Programmierung auf der mittleren Schicht und eine saubere,
service-orientierte Schnittstelle zwischen Front- und Backend verringern die
Komplexität und Wartbarkeit der Anwendung, und erlauben eine schnellere
Umsetzung.
Tavendo WebMQ „Oracle Edition“ befindet sich momentan in Entwicklung und ist für
Q4 2012 als Beta geplant.
2 Technologie
2.1
WebSocket
Tavendo hat frühzeitig in die neue Basistechnologie WebSocket investiert und
umfassendes Know-How gewonnen.
Tavendo bietet mit Autobahn WebSocket TestSuite (http://autobahn.ws/testsuite) eine
freie WebSocket Protokoll-Testsuite an, welche von mehr als zwei Dutzend Projekten
und Firmen eingesetzt wird (Google, Mozilla, Microsoft, Tomcat usw.) und sich zum
Quasi-Standard entwickelt hat, was das Testen von WebSocket Implementierungen
angeht. Tavendo WebMQ profitiert von der hierbei gewonnenen Erfahrung bezüglich
seiner Robustheit und Interoperabilität.
Mit Autobahn WebSocket (http://autobahn.ws/) bietet Tavendo eine Reihe von
WebSocket Client- und Server-Implementierungen für verschiedene Plattformen als
Open-Source an. Auf der Server-Seite nutzt Tavendo WebMQ die skalierbare und
performante Basis von AutobahnPython. Auf der Client-Seite erlaubt AutobahnJS es,
HTML5-Anwendungen mit Tavendo WebMQ zu verbinden. Darüber hinaus besteht
über AutobahnAndroid die Möglichkeit, auch native Android-Clients zu integrieren.
7
T
2.2
WebSocket Application Messaging Protokoll
WebSocket als solches bietet zwar bidirektionale Kommunikation mit geringem
Overhead und Latenzzeiten, ist aber sehr systemnah. Was Webanwendungen in der
Regel benötigen sind Kommunikationsmuster für


Publish & Subscribe (PubSub) - http://en.wikipedia.org/wiki/PubSub
Remote Procedure Calls (RPC) - http://en.wikipedia.org/wiki/Remote_procedure_call
So werden z.B. in einer Web-Anwendung für Kinokarten-Verkäufe die
Verkaufsvorgänge von den einzelnen Verkaufsterminals per RPC an den Server
gemeldet.
Alle andere Terminals, an denen die aktuelle Verfügbarkeit von Sitzen angezeigt wird,
sind auf das Ereignis „Sitz belegt“ abonniert, und erhalten die Meldung über neu
belegte Sitze als PubSub-Nachricht.
Die gesamte Kommunikation wird hier idealerweise über ein einziges Protokoll
abgewickelt, welches sowohl PubSub als auch RPC ermöglicht.
Tavendo hat die Notwendigkeit für ein derartige Lösung erkannt und ein offen
standardisiertes, WebSocket-basiertes Protokoll entwickelt:
„The WebSocket Application Messaging Protocol“ (WAMP)
http://wamp.ws/
Die Kommunikation zwischen Tavendo WebMQ und dem Browser basiert vollständig
auf WAMP.
Mit der Kombination aus WebSocket und WAMP steht Tavendo WebMQ auf einer
robusten, flexiblen und zukunftssicheren technischen Basis.
Weitere Informationen zu Tavendo WebMQ finden sich unter
http://tavendo.de/webmq
8
T
Whitepaper erstellt von:
Tavendo GmbH
Waldstraße 18
91054 Erlangen
Germany
Email
[email protected]
Copyright 2012. Tavendo GmbH. Alle Rechte vorbehalten. Dieses Dokument wird rein zur
Informationszwecken zur Verfügung gestellt, und der Inhalt kann sich jederzeit ohne weiteren Hinweis
ändern. Es wird keine Garantie dafür übernommen, dass dieses Dokument fehlerfrei ist, noch andere
Garantien. Es erfolgt ein ausdrücklicher Ausschluss jeglicher Haftung im Hinblick auf Verwendung dieses
Dokumentes. Durch dieses Dokument wird weder direkt noch indirekt ein Vertragsverhältnis egal welcher
Art begründet.
Tavendo ist ein registriertes Warenzeichen der Tavendo GmbH. WebMQ ist ein Warenzeichen der Tavendo
GmbH. Andere hier verwendete Namen können Warenzeichen ihrer jeweiligen Eigentümer sein.
9