Tavendo WebMQ - Web Message Broker
Werbung
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
