SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Web Application Messaging Protocol
By Ryan Edge
Traditionally, web applications have been built to mirror static print.
➔ Pages and HTML always have a snapshotted state
➔ Users must request a new snapshot to retrieve more up to date information
➔ As soon as the request is met, the information returned can be outdated.
The problem here is that in a digital age, information is no longer static; it’s
dynamic and fluid and can be updated on the fly.
The future of the web is real-time. Just looking at the applications we use
personally as conclusive evidence. It’s no longer acceptable for our apps to
passively wait for users to refresh. Instead, we must build our apps to keep
themselves up to date.
Remote Procedure Calls vs. Publisher/Subscriber
Remote Procedure Calls
Call based, “request/reply” routing
“As Needed” Connection
Good for sync/async
Event based, “fire and forget” routing
“Always Listening” Connection
There are few cases in which you would not need to both send and request
data as well as receive automatic updates.
This leads to using 2 technologies for your app’s messaging and has clear
● You need 2 tech stacks, possibly including 2 servers (or 2 tech stacks on a
single server) always synced.
● The app needs separate connections for the 2 messaging patterns,
requiring more server resources. Both require their own auth, increasing
● Front-end concerns are similar: establishing and handling 2 connections
and dealing w/ 2 separate APIs.
What is WAMP?
You mean Windows, Apache, MySQL, and PHP? NO!!!
WAMP is an open standard WebSocket sub-protocol that provides 2
application messaging patterns in 1 unified protocol: RPC + PubSub
➔ Unified Application Routing supports event based routing & call based
Using WAMP you can build distributed systems out of application components
that are loosely coupled and communicate in “soft” real-time.
You have a single library, connection, and API. It will handle all of your app’s
messaging between the browser front-end and the application back-end.
RPC + PubSub = WAMP
Remote Procedure Calls PubSub
To achieve the same decoupling as PubSub, WAMP introduces the Dealer as an
Like the PubSub broker, the dealer routes calls from the Caller to the Callee and back.
Router Broker Broker
WAMP Doesn’t Discriminate
WAMP - Under the Covers
WAMP runs on top of WebSockets, a Web protocol that
provides bidirectional, real-time communication.
➔ Builds up WebSockets by providing high level
messaging patterns: RPC + PubSub
➔ Uses JSON as its messaging format
➔ Can also use MessagePack or any bidirectional, reliable
● Router is crossbar.io
● Backend Clients: Node server
● Front End Clients: static site using Polymer, LoDash, and Promise Polyfill
● Read a JSON list of bugs
● Create Bugs
● Move Bugs to Open, Working, or Done states
● Broadcast creates/updates/deletes
Notables Using WAMP
Kadecot - A Home Automation product developed by Sony
Computer Science Lab
Record-Evolution - An advanced Data-Warehouse and
Business Intelligence solution
Kitware - A 3D scientific visualization solution
WAMP is awesome…
...because it allows you to decouple your application
...because it is language agnostic
...because it allows for RPC + PubSub messaging under one protocol
...because it allows for RPC + PubSub messaging under one tech stack
Why AJAX isn’t enough
A Few Words about WAMP