WAMP compared¶
Below you’ll find a table comparing WAMP to other technologies according to six criteria:
PubSub Does it support Publish & Subscribe out of the box?
RPC Does it support Remote Procedure Calls out of the box?
Routed RPC Does it support routed (not only point-to-point) Remote Procedure Calls?
Web native Does it run natively on the Web (without tunneling or bridging)?
Cross Language Does it work from different programming languages and run-times?
Open Standard Is there an open, official specification implemented by different vendors?
See also: Web Technologies for the Internet of Things - A master thesis which contains a comparison of WAMP, MQTT, CoAP, REST, SOAP, STOMP and MBWS for IoT applications.
Technology |
PubSub |
RPC |
Routed RPC |
Web native |
Cross Language |
Open Standard |
WAMP |
✔ |
✔ |
✔ |
✔ |
✔ |
✔ |
- |
✔ |
- |
✔ |
✔ |
- |
|
✔ |
(✔) |
- |
- |
✔ |
✔ |
|
- |
✔ |
- |
- |
✔ |
- |
|
- |
✔ |
- |
- |
✔ |
- |
|
- |
- |
- |
✔ |
✔ |
- |
|
✔ |
- |
- |
- |
✔ |
✔ |
|
✔ |
✔ |
✔ |
- |
✔ |
✔ |
|
✔ |
✔ |
- |
- |
✔ |
✔ |
|
✔ |
✔ |
- |
- |
✔ |
- |
|
✔ |
- |
- |
- |
- |
✔ |
|
- |
✔ |
- |
- |
- |
✔ |
|
- |
✔ |
- |
✔ |
✔ |
✔ |
|
✔ |
- |
- |
- |
✔ |
✔ |
|
(✔) | ✔ |
- |
(✔) |
✔ |
✔ |
||
- |
✔ |
- |
✔ |
✔ |
- |
|
- |
✔ |
- |
✔ |
✔ |
✔ |
|
✔ |
- |
- |
✔ |
- |
- |
|
- |
- |
- |
✔ |
✔ |
- |
|
✔ |
- |
- |
✔ |
✔ |
✔ |
|
- |
✔ |
- |
✔ |
✔ |
✔ |
|
✔ |
- |
- |
✔ |
✔ |
✔ |
|
✔ |
- |
- |
- |
✔ |
- |
|
AJAX
AJAX is neither a protocol nor an API, but a programming pattern for JavaScript in browsers that uses HTTP requests to realize RPC-like communication between frontends (browsers) and backends.
AJAX being a programming practice, isn’t a complete RPC system either. You need to agree upon how calls, results and errors are formatted and serialized. See JSON-RPC and XML-RPC.
Even when you bake some RPC mechanism using AJAX techniques, this is point-to-point RPC: calls aren’t routed between different servers or application components, but strictly travel from point (browser) to point (server the browser is connected to).
Further, AJAX does not provide PubSub - in fact, it doesn’t address how to actively push any kind of information from server to client (however, see Comet).
Since AJAX uses plain HTTP for wrapping any kind of RPC-like messages, it suffers from the overhead and limitations intrinsic to HTTP. E.g. you cannot have more than 6-8 concurrent RPCs, as browsers will limit the number of HTTP connections to a single destination.
AMQP
AMQP is a …
Apache Thrift
Apache Thrift is a cross-language RPC system. It uses a statically typed approach where procedures first need to be described using an Interface Definition Language, and then code for language specific bindings needs to be generated.
Compared to WAMP, Apache Thrift only provides RPC as an application messaging pattern, not PubSub.
While Thrift uses a statically typed approach involving IDLs and code generation, WAMP follows a dynamic typing approach. There is no IDL and no code generation. Instead, WAMP will provide run-time reflection capabilities instead.
Different from WAMP, Thrift also (only) runs over raw TCP and cannot (natively) run over the Web, right into the browser. It is designed for communication within the data-center, between backend components.
Similar to WAMP, Apache Thrift features different serialization formats, and also is able to compress a transport (using zlib). WAMP currently offers two serializations (JSON and MsgPack) and can run over standard, compressed WebSocket (“permessage-deflate”) to further reduce wire traffic.
Apache Thrift currently has a lot more language bindings than WAMP and is used/pushed by Facebook.
Capn’n’Proto
Capn’n’Proto is a …
Comet
Comet is a …
OMG DDS
OMG’s Data Distribution Service is a …
D-Bus
D-Bus is a platform-neutral messaging service that runs by default in most Linux distributions. It offers the same two basic workflows as WAMP, but whereas WAMP is designed for use over a network, D-Bus is designed for inter-process communication (IPC) on a single host.
CORBA
CORBA is a … CORBA Notification Services
DCOM
DCOM is a … specification COM+ Event Service
Java Message Service (JMS)
Java Message Service (JMS) is a Java API specification for an (abstract) PubSub service. Programs are written in Java against the JMS API. JMS does not provide RPC (but see Java RMI).
JMS does not guarantee interoperability between implementations, and the JMS-compliant messaging system in use may need to be deployed on both client and server.
In contrast, WAMP is a wire-level protocol specification. Conforming WAMP implementations will be able to talk transparently to each other, and different implementations can be mixed and matched in one larger system.
Java RMI
Java RMI is a …
JSON-RPC
JSON-RPC is a …
MQTT
MQTT is a …
OPC-UA
OPC-UA is protocol and communication stack with roots in industrial automation. It’s an open standard with a complex and abstract set of specifications that have different conrete mappings or bindings, eg for the transport layer: there are two transport layer bindings defined.
OPC-UA / UA-TCP runs over port 4840 and carries payload in a binary encoded format. The binary format is proprietory to OPC-UA - it is not used anywhere else. When using OPC-UA with UA-TCP as a transport, the resulting protocol cannot traverse the Web and can’t be implemented eg in browsers. UA-TCP is a bandwidth efficient transport, and can transport binary payload natively without escaping.
OPC-UA / UA-SOAP is based on HTTP/SOAP, runs over ports 80/443 and carries XML enoded payload. When using OPC-UA with UA-SOAP as a transport, the resulting protocol can traverse the Web and can be implemented in browsers. UA-SOAP suffers from excessive verbosity and inefficient use of wire bandwidth. Binary payloads can only be transmitted in reencoded (escaped) form.
OPC-UA, both when using UA-TCP and UA-SOAP transports, suffer from open ports requirement: each and every device/machine, running an OPC-UA server, has to open a listening port for incoming OPC-UA client connections. This is a security issue, since the attack surface now is the whole collection of all devices and machines. It is also a networking issue, since OPC-UA servers need to be directly reachable from OPC-UA clients, and firewalls, NATs and proxies will hide OPC-UA servers. And finally, it’s a coupling issue, since the host names / IP addresses of all OPC-UA servers (machines/devices) need to be known to or discovered by OPC-UA clients, which introduces a coupling between application code and infrastructure/deployment artifacts (the hostnames / IP addresses).
OPC-UA servers can provide Notification services that are roughly modeled after a Publish & Subscribe model. However, OPC-UA clients have to poll for notifications and cannot receive events asynchronously and in real-time. Increasing the polling frequency reduces the latency between the occurence of an event in the machine (a change of a value in the node tree of an OPA-UA server) and the actual reception of the event in an OPC-UA client (via a response to a polling request on a subscription), but the tradeoff is an increase in the wire traffic as well (polling when no change occured).
REST
REST is neither a library, nor protocol or framework. It’s a software architecture style. REST stands for “Representational State Transfer” and assumes that data should be transfered over network in one of the standard formats like HTML, XML or JSON and follows an architecture based on 6 limitations:
Uniform Interface
Stateless
Cacheable
Client-Server
Layered System
Code on Demand (optional)
In a World Wide Web, RESTful systems use URL for an information unit address, and http status codes for corresponding CRUD operations.
It is difficult to compare the WAMP protocol and a software architecture paradigm. They both are multilayered and can use different data presentation format. But one of the clearest difference is that WAMP is bidirectional, while REST pattern is not. In RESTful applications only client acts as initiator for data manipulations, and there is no options about how server can send data to client. In contrast to this, WAMP workflow allows data to be transfered to and form server.
Another difference is that REST deliberately uses URLs from the HTTP scheme which serve a dual function of identifying and addressing resources. With WAMP, URIs are formed com.example.myprocedure and only identify, but NOT address the procedure to be called. This means, the implementation of the procedure can reside anywhere - it’s location is only known to the WAMP router. This provides location transparency for WAMP application components.
There is no problem to use WAMP and REST together. For example, you can make basic CRUD-operations over HTTP using GET/POST/PUT/DELETE methods, and in parallel, use WAMP PubSub service for notifications about changes, and WAMP RPC’s for making some explicit business logic operations (like sending SMS, or batch picture resizing and so on).
SOAP
SOAP is a …
Being based on XML Information Set and XML for serialization, SOAP is extremely verbose and inefficient on the wire. Any kind of binary application payload first needs to be encoded. Further, parsing and serialization with XML can produce significant CPU loads. For these reasons alone, SOAP is considered unsuitable for applications where wire level and battery efficiency come into play: IoT and mobile.
SOAP usually runs over HTTP (or SMTP) as a transport. Recently, Microsoft published a specification for running SOAP over WebSocket. This reduces the overhead induces by the HTTP protocol, allows for real bidirectional messaging but retains the vast inefficiency that comes from XML.
In contrast, WAMP provides all roles to any client. A WAMP client can act as a Caller, Callee, Publisher and Subscriber, all at the same time. This works with all WAMP transports. WAMP has built transport independent addressing and routing right into the protocol.
socket.io
socket.io is a client-server PubSub service implementation written in JavaScript. It uses node.js on server side, browser counter part and own communication protocol. Socket.IO uses WebSocket under the hood, when it’s possible, but also has a polyfill as fallback.
Comparing to WAMP, library allows you to subscribe to different topics, has a broadcast messages and message namespaces, which works like a realms in WAMP. Binary data transfer is possible, but that needs additional modules on both sides (socket.io-stream) and additional amount of work for developers. They need to program that explicitly.
Socket.IO does not provide remote procedure calls.
SockJS
SockJS is a WebSocket emulation/polyfill library and provides a transport for raw, bidirectional, message-based communication between two directly connected peers (a browser and a server).
The SockJS JavaScript client adds a WebSocket-like API for JavaScript in browsers lacking native WebSocket support. The bidirectional communication capabilities of WebSocket are emulated using various mechanism under the hood, including HTTP long-poll. The “emulation” protocol(s) must be implemented on the server-side (available server implementations include NodeJS, Ruby and Erlang).
Compared to WAMP, SockJS is lower level in that it is only concerned about the transport layer. It does not provide application messaging patterns like RPC or PubSub.
WAMP also provides a HTTP Long-poll transport as a fallback for browsers lacking native WebSocket support. There are fewer fallback variants for WAMP than SockJS currently specified (only “long-poll”), but this transport also supports binary messages and all WAMP serialization formats (JSON and MsgPack currently). I am unsure if SockJS supports binary messages at all.
STOMP
STOMP is a …
XML-RPC
XML-RPC is a …
XMPP
XMPP is a …
ZMQ
ZMQ is a light-weight, high-performance library for messaging between application components. It works without a server. http://zeromq.org/whitepapers:brokerless
While ZMQ has a request-response message exchange pattern (“REQ-REP sockets”), it does not support RPC out of the box. There exist libraries (e.g. ZeroRPC by Docker or ThriftZMQ) that layer on top of ZMQ to provide applications with first-class RPC services.