1. jWebSocket – The Real-time Communication and Messaging Framework
jWebSocket as Enterprise Middleware
jWebSocket – The Real-time Communication and Messaging Framework
Alexander Schulze
Founder jWebSocket
CEO Innotrade GmbH Herzogenrath, Germany
Herzlich Willkommen zur Session „jWebSocket als Middleware“
Ich bin Alexander Schulze,
hab‘ im Jahr 2010 das jWebSocket framework ins Leben gerufen
Heute Themen WebSockets, Messaging, Middleware“ näher bringen
Middleware: Ein großes Buzzword
Frage: Wozu brauche ich das - was bringt mir das?
Versuch, einige Antworten zu geben.
DWX Developer Week
June, 25th 2013
NCC Ost, Nürnberg

2. jWebSocket as Enterprise Middleware
Today‘s Session
Agenda
jWebSocket as Middleware, Communication and Messaging
Architectures and Integration
Security and Performance
Demos (ExtJS, jQuery Mobile)
Discussion, Questions and Answers
Middleware: Nur etwas für riesige Unternehmens Applikationen oder auch interessant für kleine Apps?
Womit beschäftigen wir uns in der heutigen Session?
Aktuellen Stand der Web Kommunikation und was können Messaging Frameworks für uns tun.
Dann geht es um Architektur und die Integration der verschiedenen Komponenten unserer Apps
(Clients, Server, Datenbanken, Filesysteme, Services etc.)
Thema Sicherheit und Performance - Skalierung, Verfügbarkeit
Demos: ExtJS, jQuery
Abschluss: Diskussion und Ihre Fragen
jWebSocket as Enterprise Middleware

3. jWebSocket as Enterprise Middleware
Message Oriented Middleware (MOM)
Separate Software-Level, Decoupling of Apps and Services
Intermediate and Support for Distributed Applications
Service Oriented Architectures
Message Queue, Transactions, Persistence and Durability
Middleware – was ist das eigentlich?
Keine Datenbank, keine Anwendungslogik und auch kein Server im klassischen Sinne.
Es ist eine separate Ebene in komplexen Software-Systemen, die zwischen den verschiedenen Komponenten – neutral „Endpunkten“ - vermittelt.
Middleware dient der Entkopplung der verschiedenen Komponenten Ihrer Applikationen, stationnäre/mobile Clients, serverseitiger Business-Logik oder jeglicher Art Services in Ihrer Architektur.
Middleware ist also ein Dienstleister, hier in unserem Fall ein Vermittler für Nachrichten. Eine sogenannte „Message Oriented Middleware“.
Eine Nachrichten Message Middleware enthält keine Anwendungslogiik. sondern sie bietet Schnittstellen.
Es ist eine zentrale Instanz, die Nachrichten in Queues verwaltet, für Punkt-zu-Punkt-Verbindungen oder in sogenannten Topics nach dem Publish/Subscribe Modell.
Damit wird eine Middleware zur Grundlage für verteilte Applikationen und SOA.
Aber: Middleware steht auch massgeblich für die Zuverlässigkeit Anwendungen.
Nachrichten können persistiert werden, sie gehen also nicht einfach verloren - und Sie überleben auch den Neustart von Komponenten.
Es gibt eine Gültigkeitsdauer für Nachrichten, Transkationen, Empfangsbestätigungen und sogar Zustellgarantien. Middleware ist also nicht nur etwas für komplexe Systeme.
Auch für kleine Apps trägt eine Middleware maßgeblich zur Stabilität und Skalierbarkeit bei.
Und dass das zudem gar nicht kompliziert sein muss, dass möchte ich heute einmal aufzeigen.
jWebSocket as Enterprise Middleware

4. Communication & Messaging
Java
Perl
.NET
Browser
Browser
Android
iOS
Java
JMS
STOMP
AMQP
WebSocket
WebSocket
WebSocket
WebSocket
WebSocket
OpenWire
STOMP
AMQP
WebSocket
jWebSocket Server
Message Broker ( ActiveMQ )
Filesys.
JDBC
SMTP
Application
Ein Bild sagt mehr als Tausend Worte...
In der oberen Reihe sehen wir verschiedene „Clients“, im Sinne von Message oriented Middleware auch einfach „Endpunkte“.
In der Mitte befindet sich die Middleware und im unteren Bereich sehen Sie verschiedene Applikationen und Services.
Die Clients können über die unterschiedlichsten Protokolle und Schnittstellen mit der Middleware kommunizieren.
Sie können Nachrichten mit den Services austauchen - aber auch untereinander – und zwar bidirektional und völlig unabhäging vom verwendeten Protokoll.
Beispiele: Ich kann von einem .NET Client eine Mail versenden, von einem Browser auf ein ERP System zugreifen oder von einer Perl Applikation auf eine JDBC Datenquelle.
Aber: Und das der Punkt hier für den Mobile Track der Konferenz – ich kann auch ein iPhone mit einem Android Phone verbinden oder auch die Grids zweier ExtJS Applikationen.
Das werden wir auch gleich ziegen...
Bevor wir jetzt in die Details gehen, schauen wir noch mal kurz zurück...
ERP System
Message Persistence DB
Service Host
File Server
Database Server
Mail Server
jWebSocket as Enterprise Middleware

5. Status of Web Communication
HTTP Protocol
Designed for document transmission
Cumbersome, nearly real-time tricks
Polling, Long-Polling
Reverse-AJAX, Comet etc.
Ultimately non-standardized hacks
Remains a Request/Response mechanism
Was hatten wir bisher? HTTP…
Designed für Dokumenten-Übertragung, für C/S.
D.h. für bidirektionale Kommunikation zwischen Endpunkten umständlich.
Klar viele Tricks… für “Beinahe Echtzeit Kommunikation”
Polling: Regelmäßige Anfragen mit direkten Antworten, viele Verbindungen, Volumen, niedriige Effizienz, gerade bei niedrigen Datenraten.
Long-Polling: Zwar weniger Verbindungen, kürzere Antwortzeiten, aber Buffering Probleme, immer noch hoher Protokoll overhead, gerade bei hohen Datenraten.
Reverse-Ajax und Comet: Wieder etwas besser, aber immer noch zwei Kanäle, und proprietärer Implementationsaufwand. Weil nie wirklich standardisiert.
Vergangenheit: Nicht Standardisierte Hacks => teuer!
Also: HTTP ist und bleibt ein spezifikationsgemäß ein Anfrage/Antwort Mechanismus, d.h. prinzipiell ungeeignet für bidirektionale Echtzeit-Kommunikation!
Aber: Jetzt haben wir WebSockets - eine Alternative?
jWebSocket as Enterprise Middleware

6. WebSocket Protocol WebSockets - Technology
Permanent TCP connections, bidirectional, full-duplex oo times less overhead ⅓ of latency
Standardized in HTML5 by W3C and IETF protects investments
Single TCP Port saves 50% server resources
Was ist anders an WebSockets?
1. Die Verbindungen sind permanent, nicht beendet nach jeder Anfrage, explizit beenden, kontinuierlicher Auf/Abbau entfällt.
2. Die Verbindungen sind Full-Duplex, d.h. Nachrichten gleichzeitig in beide Richtungen, http nur Halb-Duplex, inkl. Delay.
3. TCP Verbindungen, HTTP header entfällt komplett, konnte groß sein. Bis zu 400x geringerer Overhead
=> Besseres Protokoll/Nutzdaten Verhältnis => beschleunigt die Applikationen und senkt die Transferkosten.
4. Keine Zeiten für Verbindungsauf/abbau, reduziert Latenz auf 1/3
=> Applikationen reaktionsfreudiger – verbessert User-Experience
5. Im Gegensatz zu HTTP mechanismen standardisiert durch IETF (Protokoll) und W3C (Browser API).
=> Keine proprietäre Entwicklung, sondern Standards => spart Kosten, sichert Investitonen.
6. Eigenschaft: WebSockets: 1 TCP Kanal.
HTTP: 2 Kanäle erforderlich, Empfang und Senderichtung, spart 50% der serverseitigen Resourcen.
Nicht nur effiizienter, sondern freut auch den Administrator
jWebSocket as Enterprise Middleware

7. WebSocket Protocol WebSockets - Technology
No Rules for Content Text/Binary Frames, Chunking/Compression Encryption (SSL/TLS)
No Limits for Formats/Sub-Protocols JSON, XML, CSV, Map, Object…
No Restrictions for Processing Responsible for Logic, Security
Und freut uns auch als Entwickler?
Maximaler Freiheitgrad:
Keine Regeln für Inhalte, Texte, binäre Daten, Chunking und Compression, Multiplexing
Natürlich auch SSL.
Keine Grenzen für Datenformate, JSON, XML, CSV, Maps, Objects....
Keine Vorgaben für die Verarbeitung, ausschließlich Messages.
Aber:
Keine Kommandos á la Request/Response (kein GetFile).
Businesslogik selber implementieren
Selbst verantwortlich für Sicheheit.
jWebSocket as Enterprise Middleware

8. quicker cheaper more portable Compared with HTTP
WebSockets - Technology
Compared with HTTP
quicker
cheaper
more portable
Unterm Strich und auf den Punkt gebracht:
WebSockets sind einfach...
schneller
billger
vielseitiger und flexibler!
jWebSocket as Enterprise Middleware

9. http://jwebsocket.org/dwx_sw jWebSocket - Online Collaboration
Experience the Performance! Share a Whiteboard live in this Session!
Click our Demo
Viel geredet! Kommen wir zur Praxis.
Demo basiert auf jQuery!
Läuft Auf einer 15€ VM!
jWebSocket as Enterprise Middleware

10. Technology-State? WebSockets - Technology
Available on all Browsers (RFC 6455), Fallbacks for older ones
Available on all Platforms, continuously extended
Java, C# and Python
New: STOMP over WebSockets & jWebSocket JMS Gateway
Stand der Technologie?
Seit Dezember 2011 mit dem RFC 6455 final verabschiedet – also realer Internet Standard.
Mittlerweile in allen modernen Browsern implementiert.
IE & ältere Browser, Fallbacks, Flash oder Comet, bei älteren Proxies,
egal weil transparent, automatisch genutzt sobald verfügbar.
Auch für native Apps gibt es mittlerweile Clients
In jWebSocket selbst für Android, Java, CSharp unter .NET oder Python.
Jetzt ganz neu:
Alle Client´s können jetzt auch via STOMP over WebSockets kommunizieren.
Damit verbinden wir jetzt Java Messaging Services (JMS) mit WebSocket Technologie!
Später eine separate Slide dazu.
jWebSocket as Enterprise Middleware

11. jWebSocket - Integration
Tool-Support?
Closed Integration into existing Frameworks
Und wie weit sind WebSockets schon supported?
Selbst wenn Sie schon mit einem der etablierten Web oder Mobile Frameworks arbeiten,
- was wahrscheinlich der größte Teil von Ihnen tut -
Mit jWebSocket sind großen Frameworks bereits integriert.
jWebSocket as Enterprise Middleware 11

12. http://jwebsocket.org/dwx_ej jWebSocket - Integration
Integration of Realtime-Comm. into Sencha ExtJS Check out our Demo
Gerade hatten wir schon Demo mit jQuery.
Jetzt ein kleines Beispiel auf Basis von Sencha ExtJS – aus dem Bereich Online Collaboration
Sencha ExtJS Demo.
jWebSocket as Enterprise Middleware 12

13. Sencha/ExtJS Integration
jWebSocket - Integration
Sencha/ExtJS Integration
Integration of WebSockets into existing Sencha/ExtJS-Applications
Replaces AJAX/XHR-Proxy by jWebSocket-Proxy
Worldwide Data Synchronization in Realtime
jWebSocket and Sencha/ExtJS as Basis for Online-Collaboration
So, was haben wir hier gesehen?
WebSockets sind voll integriert in Sencha/ExtJS Applikationen.
Und was wir hier im Browser gesehen haben kann mit Sencha/Touch
natürlich ebenso auch mobilen Devices implementiert werden.
Aber wie haben wir das hier implementiert?
In ExtJS haben wir einfach den bestehenden XHR Proxy durch einen jWebSocket Proxy ersetzt.
Der große Vorteil dabei ist, dass sie einfach all Ihren Sencha Code weiter benutzen können in der gleichen Weise wie vorher.
Was wir moch gesehen haben, ist wie Daten in Grids und Formularen in Echtzeit synchronisiert werden.
jWebSocket und Sencha/ExtJS sind also eine gute Grundlage für viele Arten von Online-Collaboration-Tools.
jWebSocket as Enterprise Middleware 13

14. jWebSocket as Enterprise Middleware
jWebSocket - Plug-ins
jWebSocket Plug-ins (Open Source, Apache 2 Licence)
Models: Channels, Events, JMS, MQ with STOMP, AMQP
Interfaces: JDBC, SMTP, SMS, CGI, Scripting (JavaScript)
Security: Quota, Captcha, Filters, Spring Auth, SSO, SSL/TLS
Remote Procedure Calls: C2S-, S2C- and C2C-RPCs
Sharing: Data Persistence/Synchronization and Filesharing
Social: Chat, Twitter, Instant Messaging (XMPP)
Administration: JMX, Logging, Statistics, Monitoring, Reporting, Clustering
Das ist aber noch nicht alles.
jWebSocket kommt mit einer Vielzahl von Out-Of-The-Box Services.
Neben der JMS Gateway, auf die ich gleich noch genauer eingehe,
haben wir Services integriert zum Zugriff auf Datenbanken und Filesysteme,
Wir können Mails und SMS versenden
Wir haben eine Vielzahl von Security Mechanismen und Provider integriert
Und vieles mehr.
Wenn Sie Lust haben: Der Download ist frei und jWebSocket kommt als Open Source unter der Apache Lizenz.
jWebSocket as Enterprise Middleware

15. WebSocket Summary WebSockets - Technology
Designed for highly interactive Web Applications, high level of freedom
Supports stationary & mobile, browser based & native apps
Not just a protocol, but a new paradigm Request/Response Real-Time Comm.
Perfect Basis for Low-Latency Community and Enterprise Middleware
Fassen wir das Thema WebSockets kurz zusammen:
WebSockets von Anfang an designed für interaktive Applikationen
Maximale Freiheitsgrade
WebSockets sind verfügbar, stationär/mobile, webbasiert/nativ und standardisiert.
Nicht nur Protookoll, neues Kommunikationsparadigma, Req/Resp => Bidirektionale Echtzeitkommunikation.
All das: perfekte Basis für eine Community and Enterprise Middleware.
jWebSocket as Enterprise Middleware

16. jWebSocket as Enterprise Middleware
Middleware - Goals
Demand from Developers, Providers and Users
Compatibility Interoperability
Independency Integratability
Reliability Security
Anforderungen? Konkrete Ziele? Herausforderungen? Lösungen?
Ist: unterschiedlche Browser, stationäre, mobile Geräte, Betriebssysteme. Entwicklungsumgebungen.
Aufgabe: Kompatibilität und Interoperabilität
Lösung: WebSockets standard Protokoll, plattform-übergreifend, bringen User zusammen.
Ist: betreiben bereits verschiedene Server, etablierte Umgebungen, nicht einfach ersetzbar.
Aufgabe: Unabhängig von der Technologie, leichte Integrierbarkeit in bestehende Umgebungen.
Lösung: Abstraktion um bestehende Services zu nutzen, leichtes Embedding, um bestehende Anwendungen um neue Feature zu erweitern
Ist: Im echten Leben: Proxies, Rouuters or Firewalls, in mobilen Netzen niedrige Bandbreite, schwache Funknetze oder einfach schlechtes Wetter.
Höchster Anspruch: Sicherheit und der Schutz der Privatsphäre unserer User.
MQ’s bieten Persistenz, Clustering, Failover-Mechanismen, Empfangsbestätigungen und Zustellgarantie, keine Nachricht geht verloren!
Bei großen Datenmengen: Chunking und Compression.
Mit jWebSocket kommen: Automatischer Re-connect, Prüfsummen, und natürlich mit SSL, Filter, Validierung, Transformationen etc.
Thema Sicherheit auf separater Folie…
jWebSocket as Enterprise Middleware

17. jWebSocket as Enterprise Middleware
Middleware - Goals
Demand from Developers, Providers and Users
Availability Scalability
Extendability Flexability
Simplicity Maintainability
Was noch?
Ist: User erwarten: Services immer verfügbar, schnelles Antwortverhalten, sind an der Auslastung Ihrer Systeme nicht interessiert.
Aufgabe: Verfügbarkeit und Skalierbarkeit sind elementare Anforderungen.
Lösung: Clustering, fast unbegrenzte Zahl an gleichzeitugen Usern. Praktisch 100% Verfügbarkeit durch verteilte Server, Zuverlässigkeit durch Messaging Backbone
Separates Thema: Hot-Deployment.
Ist: Server müssen leicht erweiterbar sein, Services ergänzen, öffentlich zugänglich machen, natürlich zur Laufzeit.
Aufgabe: Auf der anderen Seite: Unternehmen IP-Schutz, Zugriffskontrolle auf Services, Sicherheit später.
Lösung: WebSockets und Messaging Server, keine Regeln für Daten-Formate, Inhalte oder Verarbeitung.
Kombination WebSockets und Message Queuing = unschlagbare Flexibilität
Ist: Als Entwickler erwarten Sie: Einfaches Verständnis, Kurze Lernkurve, Wartbarkeit
Aufgabe: Die Implementierung muss einfach sein.
Lösung: jWebSocket kommt mit: vielen Demos, direkt nutzbaren Features, Services und Schnittstellen.
Und: OpenSource, total transparent, nachvollziehbar und von einer Community gepflegt. Sie haben also direkten Einfluss auf die Entwicklung.
WebSocket und Messaging Technologien können Schritt für Schritt eingeführt werden, zu klar kalkuierbaren Kosten.
jWebSocket as Enterprise Middleware

18. jWebSocket Middleware
Combining Real-Time Communication with Message Queuing
Integration: Web Frameworks, Devices, Clients, Servers, Services
Abstraction: Tokens, Plug-Ins, Apps
Decoupling: Interfaces
Security: Roles, Filters, Quotas, Encryption
Wie muss man sich jWebSocket nun als Middleware vorstellen?
Zum einen verbinden wir die Real-time Kommunications Technologie mit den Konzepten des Message Queuing,
Dann geht es uns darum die großen Web Frameworka zu integrieren,
um die Entwicklung so schnelll und effizient wie möglich zu machen.
Dann geht um Abstraktion, wie schaffe ich, dass alle Beteiligten sich unterhalten können?
Aber auch wie schaffe ich es die Applikationen sauber zu entkoppeln, um Service Orientierte Strukturen zu schaffen?
Und letztlich müssen wir uns natürlich auch intensiv mit dem Thema Sicherheit auseinandersetzen.
jWebSocket as Enterprise Middleware

19. Middleware - Queues/Topics
Queues and Topics
Queues for Point-2-Point Connections
Topics for Publish/Subscribe Environments
Producer
Consumer
Producer
Consumer
Queue
Producer
Consumer
Producer
Consumer
Producer
Consumer
Wer hat schon mal mit MessageQueues gearbeitet?
Unterschied Queue und Topic => erklären
Queue für Punkt-zu-Punkt Verbindungen
Genauer: Eine einzelne Nachricht wird nur zu genau einem Empfänger versendet.
Allerdings: Es können sich mehrere Empfänger anmelden.
Was passiert dann? Der nächste Empfänger empfängt die nächste Nachricht, Wird ein Empfänger geschlossen, wird die Nachricht einfach an den nächsten Empfänger gesendet.
Also: Jeder Empfänger erhält jeweils nächste Nachricht aus der Queue, sobald er die vorherige abgearbeitet hat.
Und? Queues sind damit automatisch bereits hervorragende Load Balancer.
Topics für Publish/Subscribe Modelle
Eine einzelne Nachricht wird zu mehreren Empfängern versendet.
Mehrere Producer können Messages versenden und mehrere interessierte Consumer können hören.
Wenn ein Client sich abmeldet, gilt er nicht mehr als interessiert und die Messages werden gelöscht.
Vergleichen kann man dies auch mit broadcasts. Man kann Messages zwar ignorieren, aber viellieicht will man bestimmte gar nicht erst erhalten (Transportaufwand).
Um nur auf bestimmte Nachrichtern zu hören gibt es Message Selektoren.
Producer
Consumer
Topic
Producer
Consumer
Producer
Consumer
jWebSocket as Enterprise Middleware

20. Middleware - Selectors/Advisory
Message Selectors
Source-Id und Target-Id (z.B. targetId = “JDBCService“)
Advisory Topics
Connect / Disconnect (Service Availability)
Message Expiration
No Cosumer Listening
Further Destination Policies
Producer sourceId = 1
Consumer targetId = 1
Producer sourceId = 2
Consumer targetId = 2
Topic
Producer sourceId = 3
Consumer
targetId = 3
Message with sourceId = 3 and targetId = 2
Producer sourceId = 4
Consumer targetId = 4
Was genau sind Selektoren:
Selektoren sind Filter für Messages (SQL Syntax), Filterregeln angewendet auf den Header
Möglich Messages auch innerhalb eines Topics an nur einen oder bestimmte Empfänger zu versenden.
Unteres Bild:
Middleware keine Server/Client Struktur, nur Endpunkte. Jeder Endpunkt kann Producer und Consumer haben.
Mit Hilfe eines einzelnen Topics leicht eine beliebige Kommunikations-Infrastruktur. Genau wie bei WebSockets, P2P als auch Broadcasts.
targetId "*“.
Eine ganz tolle Sache: Advisory Topics
Informieren Consumer über Aktivitäten in Queue und Topics
Z.B. wenn sich ein Consumer oder Producer an- oder abmeldet.
Z.B: um die Verfügbarkeit von Services zu verwalten.
Nachrichten können verfallen => hier wollen wir vielleicht benachrichtigt werden.
Auch, wenn wir eine Nachricht verschicken, ohne das ein Consumer zuhört.
Destination Policies: OnConsumed, OnDelivered,
langsame consumer oder schnelle producer (Stau Prävention)
OnFull, viele mehr, aber das geht ein bisschen tief.
EndPoint endPointId = 1 P P
EndPoint endPointd = 3 C C
Topic
EndPoint endPointId = 2 P P
EndPoint endPointId = 4 C C
jWebSocket as Enterprise Middleware

21. Middleware - Persistence/Durability
Message Persistence & Durability
Acknowledge & Auto Acknowledge
Expiration Option Notification via Advisory-Topic
Persistence: „Survive a Broker Restart“
Durable Subscriptions „Survive a Endpoint Restart“
Bevor wir die noch eine weiterer Demo zeigen,
Noch kurz zu ein paar wichtigen Aspekten bezüglich Persistenz.
Prinzipiell werden Nachrichten erst gelöscht nachdem sie bestätigt wurden (Acknowledge)
Das kann entweder explizit durch den Consumer geschehen, nach er die Nachricht empfangen hat
oder automatisch, wenn z.B. keine besondere Validierung erfolgen muss.
Dann können Nachrichten auch verfallen nach einer bestimmten Zeit.
Optional kann der Sender über die Advisory Topic über den Verfall informiert werden.
Der Message-Broker übernimmt also bereits das gesamte Timeout Management für uns!
So kann also leicht auch ein Service einmal neu gestartet werden, ohne dass Nachrichten verloren gehen.
Oder auch der Producer vor dem Consumer hochgefahren werden.
jWebSocket as Enterprise Middleware

22. Middleware - Persistence/Durability
Message Persistence & Durability
Acknowledge & Auto Acknowledge
Expiration Option Notification via Advisory-Topic
Persistence: „Survive a Broker Restart“
Durable Subscriptions „Survive a Endpoint Restart“
Dann, ein wichtiger Unterschied, Nachrichten Persistenz und dauerhaften Empfängern
Persistenz: bedeutet, dass Nachrichten nicht im Speicher des Message Brokers verwaltet werden, sondern bspw in einer Datenbank.
Falls der Broker also einmal abstürzen sollte, überleben die Nachrichten also den Neustart.
=> Persitenz geht natürlich auf die Performance, schafft aber Sicherheit!
Allerdings: Wird sich aber Consumer beendet, verfallen die Nachricht genauso in der Datenbank wie auch zuvor im Memory.
Für einfache Message Konsumenten ist das prima, für permant verfügbare Services brauche ich aber dauerhafte Empflänger (sog. Durable Subscribers)
Üblicherweise werden Nachrichten nur ge-queued, wenn auch ein Empfänger vorhanden ist.
Ist ein dauerhafter Subscriber registriert, werden Nachrichten ge-queed auch (noch) kein Empfänger registriert ist.
D.h. Zum Einen kann ein Service neu gestartet werden, ohne Nachrichten Verlust.
Und es macht auch nichts, wenn in einer Architektur der Producer vor dem Consumer hochgefahren wird.
jWebSocket as Enterprise Middleware

23. Middleware - Messaging Demo
Live Slideshow
A typical Topic Messaging Application
One or multiple Producers: „The Presenters“
Many Consumers: „The Audience“
Eine Menge Messaging Theorie, nun wenig Praxis zwischendurch.
Eine typische Anwendung für Topics ist eine Slideshow.
Wir haben einen oder vielleicht mehrere Message Producer, die Presenter und
Eine beliebige Anzahl von Message Consumern.
Einladen...
jWebSocket as Enterprise Middleware

24. jWebSocket - JMS Gateway
Web-Browser
Java
Perl/Ruby/..
.NET App
Web-Browser
JavaScript
JMS
STOMP
AMQP
JavaScript
WebSocket ws://host:8787
OpenWire tcp://host:61616
STOMP stomp://host:61613
AMQP stomp://host:5672
STOMP over WebSockets ws://host:61614
Message Broker (Active MQ)
JMS Gateway
jWebSocket Server
So, wie funktioniert dass jetzt alles?
Im oberen Bereich sehen Sie erstmal die ganzen Clients.
Die Browser in unserem Fall können wahlweise direkt mit dem jWebSocket Server verbunden werden,
Oder auch per STOMP via WebSockets mit dem Message Broker sprechen. Rein funktional fast egal.
Entscheidend ist, das wir hier Producer haben, die Nachrichten in den zentralen Topic einstellen (Wechsel der Slides)
Und dass wir Consumer haben, die die Nachrichten aus dem Topic zugestellt bekommen (Aktualisierung der Slides).
Im unteren Bereich sehen wir jetzt noch einige jWebSocket Plug-ins (z.B. Zugriff auf das Filesystem, auf Datenbanken via JDBC oder für Mailservices).
Alle Services sind vom jedem Client oder Message Endpoint ansprechbar.
Filesys.
JDBC
SMTP
...
File Server
Database Server
Mail Server
jWebSocket as Enterprise Middleware

25. Tokens (Abstraction) jWebSocket - Abstraction Endpoints are stupid
Common language to understand messages
Dataformats JSON, XML or CSV
Solution: Abstract Data Objects, in jWebSocket Token
Endpoint
Endpoint
Browser
Native Client
STOMP
JMS
WebSocket
WebSocket
CSV
JSON
JSON
XML
JMS Gateway
jWebSocket Engines
CSV
JSON
JSON
XML
Message Abstraction Layer ( Token-Processors, extendable )
Token
Dann ein ganz wichtiges Thema beim Einsatz von Middleware: Abstraktion
Weder das WebSocket Protokoll noch der Message Broker geben uns ein bestimmtes Datenformat vor.
Aber: Um eine Nachricht von einem Punkt zum Anderen zu routen, muss der Server die Nachricht verstehen,
Nicht nur für Routing, auch für Validierungen oder Authorisierungen.
Aber: Prinzipiell sind die einzelnen Endpunkte sind zunächst einmal dumm. Und es kommt noch schlimmer...
In heterogenen Umgebungen wollen die Clients ihre Daten vielleicht auch noch in unterschiedlichen Formaten austauschen,
Browser Apps mögen vielleicht lieber JSON, während Java Apps vielleicht lieber XML sprechen wollen.
STOMP is reiner Text, vielleicht wollen die CSV, oder sonst was.
Der Schlüssel hier sind so genannte abstrakte Tokens, im Prinzip einfach nur Datenobjekte,
die über Serialisierung in den gewünschten Formate hin und her transformiert werden.
Auf dem jWebSocket Server verarbeiten die Plug-ins und die Apps lediglich diese Tokens,
Und genau das macht die Applikation vollkommen unabhängig vom Datenformat!
So können sich sogar Clients mit völlig unterschiedlichen Datenformaten miteinander unterhalten.
Im Prinzip also eine Abstraktionsebene innerhalb des jWebSocket Frameworks, die für beliebige Formate – auch kundenspezifische – erweitert werden kann.
Message Security Layer ( Token-Filters, extendable )
jWebSocket Core
App
App
App
Plug-in
Plug-in
Plug-in
jWebSocket as Enterprise Middleware

26. Simple Text Oriented Messaging Protocol
STOMP over WebSockets
Simple Text Oriented Messaging Protocol
Clients for... Ruby, Perl, C, C++, C#, .Net, Flash, Delphi, Java, Objective C, Python, PHP, JavaScript
STOMP over WebSockets Thanks to Jeff Mesnil and Jeff Lindsay
jWebSocket
Perl
Browser
JMS Gateway
STOMP
WebSocket
OpenWire/JMS tcp://host:61616
STOMP stomp://host:61613
STOMP over WebSockets ws://host:61614
JMS
AMQP
STOMP
WebSocket
Active MQ
Jetzt haben wir schon sooft über STOMP gesprochen. Hier nun nochmal kurz ein Diagram dazu.
STOMP steht für Simple Text Oriented Messaging Protokoll.
Im Prinzip lediglich ein Interface um Nachrichten wie beschrieben in den Broker einzustellen und von dort zu erhalten.
Ein Einschränkung im Vergleich zum JMS Standard: Es können lediglich Textnachrichten ausgetauscht werden.
Aber großer Vorteil, es existiert eine Vielzahl von STOMP Clients für die verschiedensten Programmiersprachen.
Und das macht es interessant, denn über die jWebSocket JMS Gateway kann so jeder Service aus jeder Umgebung genutzt werden.
Spannend ist STOMP over WebSocket weil so der Browser auch direkt mit dem Broker sprechen kann.
Vielen Dank für diese nette Implementierung an die beiden Entwickler.
Message Persistence DB
jWebSocket as Enterprise Middleware

27. jWebSocket as Enterprise Middleware
Middleware - Security
Security Instances
Encryption Transport encryption via SSL/TLS
Authentication Against the Broker, many sources (LDAP, JAAS, JDBC, XML … )
Authorization for Queue Roles for Read, Write and Administration
Message Level Authorization Routing Permissons, Validation of Content MessageAuthorizationPolicy, isAllowedToConsume
More sophisticated mechanims via plug-ins Security Instances decoupled from Applications
Zum Abschluss noch zu einigen Security Aspekten:
Zum Einen: Transport Verschlüsselung (nicht die Nachricht selber).
Authentifizierung: Gegenüber dem Broker (LDAP, JAAS, JDBC, XML, properties files...)
Wenn authentifiziert: Authorisierung pro Queue und Topic. Lesen, schreiben, administrieren.
Authorisierung auf Message Ebene.
Hierzu schreibt man kleine Java Klassen (als jar ins lib)
MessageAuthorizationPolicy interface implementieren und die isAllowedToConsume Methode überschreiben.
Wem das nicht reicht: Für komplexere Sicherheitsanforderungen erlaubt ActiveMQ, eigene Plugins zum Broker hinzuzufügen.
jWebSocket as Enterprise Middleware

28. jWebSocket Security jWebSocket - Security Encryption SSL/TLS
ws:// and wss://
Inbound/Outbound Filter
Role based Authentication and Authorization with Spring Security
Quotas and Captchas
WebSocket Client / JMS Endpoint
Token
In Custom-/Admin Filter Out
Administrator
In System-Filter Out
Das war Security im Messaging Bereich, was gibt’s noch in jWebSocket?
Zum einen unterstützen WebSockets natürlich die Verschlüsselung mittels SSL/TLS.
Da ändert sich wie bei http einfach das Schema ws:// zu wss://.
Die vorhandenen Zertifikate können im Übrigen weiterverwendet werden.
Ein ganz wichtiges Feature sind die ein- und ausgehenden Tokenfilter:
Damit können Sie Nachrichten validieren oder auch Virenscanner einbinden.
Weitere Möglichkeiten sind Spam-Schutz oder Banning, verdächtige Nachrichten können auch einfach zurückgewiesen werden.
Übrigens Filter sind völliig autark, d.h. ein Administrator kann diese unabhängig von der Applikation verwalten.
Dann gibt’s auf der Serverseite natürlich neben der Authentifizierung auch ein Rollen basiertes Autorisierungssystem.
Technisch basiert dieses auf Spring, so dass verschiedenste Authentifizierungs-Instanzen genutzt werden können.
Dann gibt’s noch Quotas, um Zugriffe einzuschränken und Captchas, um reale Personen zu identifizieren und automatische Skripte abzuweisen.
Insgesamt kann man also sagen, dass man schon so ziemlich jede verbotene Tür sicher schließen kann.
Plug-ins (Chain)
jWebSocket Server
Authentication
& Authorization
jWebSocket as Enterprise Middleware

29. Middleware Scaling Middleware - Scaling JMS Service JMS Client
failover (tcp:host1,tcp:host2)
failover (tcp:host1,tcp:host2)
JMS Service
JMS Client
Active MQ
Active MQ
Cluster
Gateway
JMS Queues/Topics
Message Persistence Database Cluster
Dann noch ganz kurz zum Abschluss: Skalierung und Clustering...
Message Broker sind von Natur aus sichere Nachrichten Manager.
Von daher ist es natürlich ein Leichtes mehrere Broker zur verbinden.
An einen Broker können fast beliebig viele Service Endpoints angeschlossen werden.
Und wir haben gesehen, dass Queues bereits perfekte Load Balancer sind.
Wenn wir mehr Leistung für einen bestimmten Service benötogen: Ja dann hängen wir einen weiteren rein.
Dann jWebSocket. Natürlich tauschen alle jWebSocket-Server Ihre Nachrichten untereinander auch über die Message Broker aus.
Im Prinzip sind das ja auch nur Endpoints in der großen Messaging Infrastruktur.
Ich will es gar nicht schön reden, natürlich gibt es viele kleine Details zu beachten, aus denen man eine eigene Session gestalten könnte,
aber: Im Vergleich zu vielen anderen Ansätzen: Es könnte kaum einfacher gehen.
Web Client
jWebSocket
jWebSocket
File Server
Mail Server
Database
Server/Cluster
jWebSocket as Enterprise Middleware

30. Middleware Solution for Community & Enterprises
jWebSocket as Middleware
Summary
WebSocket replaces HTTP Higher Speed & User Experience
jWebSocket integrates Web Frameworks Simple & Rapid Implementation
Messaging for Reliability & Scalability Higher Availability & Security for Services
Middleware Solution for Community & Enterprises
Was ist das Fazit?
WebSockets ersetzen HTTP, sicher – nicht alles, aber in vielen Bereichen. Massive Vorteile für fast alle Arten von Applikationen.
Denken wir an unsere User: Höhere Geschwindigkeit und damit höhere Zufriedenheit.
Dann: jWebSocket integriert die wichtigsten Web Frameworks (Sencha ExtJS/Touch, jQuery/mobile)
Das heißt: Auch für uns Entwickler, einfache und schnelle Implementierung.
Dann: Die Messaging Komponente: Die sorgt für Zuverlässigkeit und wirkliich einfache Skalierbarkeit,
Genau diese Integration macht jWebSocket zur Middleware Lösung –
und zwar von kleinen Apps bis hin zur komplexen Unternehmensapplikation.
jWebSocket as Enterprise Middleware

31. Questions & Answers Thank you for your attention!
Alexander Schulze
Forum & Download: @jWebSocket
Ich hoffe, dass ich Ihnen die Themen
WebSockets, Messaging und jWebSocket als Middleware
etwas näher bringen konnte, dass die Demos sie ein wenig angesprochen haben.
Für Fragen...
Vielen Dank....
jWebSocket as Enterprise Middleware