Web Application Messaging Protocol

WAMP is a WebSocket subprotocol registered at IANA,[1] specified[2] to offer routed RPC and PubSub. Its design goal[3] is to provide an open standard for soft real-time message exchange between application components and ease the creation of loosely coupled architectures based on microservices. Because of this, it is a suitable enterprise service bus (ESB),[4] fit for developing responsive Web applications or to coordinate multiple connected devices in the IoT.[5]

Characteristics

Structure

WAMP requires[6] a reliable, ordered, full-duplex message channel as a transport layer, and by default uses Websocket. However, implementations can use other transports matching these characteristics and communicate with WAMP over e.g. raw sockets,[7] Unix sockets or HTTP long poll.

Message serialization assumes[8] integers, strings and ordered sequences types are available, and defaults to JSON as the most common format offering these. Implementations often provide MessagePack as a faster alternative to JSON, but at the cost of an additional dependency.[9]

To identify remote procedures and PubSub topics without conflicts, WAMP also needs an ID space allowing global assignment and resolution. Because the protocol is Web native - WebSocket being the preferred transport - URIs are used.

Workflow

WAMP is architectured around client–client communications, with a central software, the router, dispatching messages between them. The typical data exchange workflow is:[10]

The clients send these messages using the two high-level primitives that are RPC and PUB/SUB, doing four core interactions:

This can have subtle variations depending of the underlying transport.[11] However, implementation details are hidden to the end-user who only programs with the two high-level primitives that are RPC and PubSub.

Security

As WAMP uses Websocket, connections can be wrapped in TLS for encryption. Even when full confidentiality is not established, several mechanisms are implemented to isolate components and avoid man-in-the-middle attacks. Default implementations ensure that trying to register an already registered procedure will fail.

Routers can define realms as administrative domains, and clients must specify which realm they want to join upon connection. Once joined, the realm will act as a namespace, preventing clients connected to one to be able to do RPC and PubSub using IDs defined in another. Realms also have permissions attached, and can limit the clients to one subset of the REGISTER/CALL/PubSub actions available.

Some realms can be only joined by authenticated clients, using various authentication methods such as using TLS certificate, cookies or a simple ticket.

Routed RPCs

Unlike with traditional RPCs, which are addressed directly from a caller to the entity offering the procedure (typically a server backend) and are strictly unidirectional (client-to-server), RPCs in WAMP are routed by a middleware and work bidirectionally.

Registration of RPCs is with the WAMP router, and calls to procedures are similarly issued to the WAMP router. This means first of all that a client can issue all RPCs via the single connection to the WAMP router, and does not need to have any knowledge what client is currently offering the procedure, where that client resides or how to address it. This can indeed change between calls, opening up the possibility for advanced features such as load-balancing or fail-over for procedure calls.

It additionally means that all WAMP clients are equal in that they can offer procedures for calling. This avoids the traditional distinction between clients and server backends, and allows architectures where browser clients call procedures on other browser clients, with an API that feels like peer to peer communication.

However, even with multi-tiers architectures, the router is still a single point of failure. For this reason, some router implementation roadmaps include clustering features.[12]

Implementations

Clients

As WAMP main targets are Web applications and the Internet of Things, the first client implementations are in languages well established in these industries (only WAMP v2 clients listed):

Client library Language
AngularWAMP JavaScript for the AngularJS framework
AutobahnCpp C++ 11
AutobahnJS JavaScript (browser and Node.js)
AutobahnPython Python
backbone.WAMP JavaScript for the Backbone.js library
CppWAMP C++ 11
Erwa Erlang
Jawampa Java
Loowy Lua
MDWamp Objective-C
Minion PHP
rx.wamp JavaScript for the React library
Thruway PHP
WAMP POCO C++
WampSharp C#
Wampy.js JavaScript (browser only)

The minimum requirements to build a WAMP client are the abilities to use sockets and to serialise to JSON. Thus, many modern languages already fulfill these requirements with their standard library. Additional features which would add dependencies, such as TLS encryptions or MessagePack serialization, are optional.

However, the persistent nature of WebSocket connections requires the use of non-blocking libraries and asynchronous APIs. In languages with one official mechanism such as JavaScript, Erlang or Go, this is not an issue. But for languages with several competing solutions for asynchronous programming, such as Python or PHP, it forces the client author to commit to a specific part of the ecosystem.

For the same reason, integrating legacy projects can also require work. As an example, most popular Web Python frameworks are using WSGI, a synchronous API, and running a WAMP clients inside a WSGI worker needs manual adapters such as crochet.

Routers

While routers can technically be embedded directly into the application code and some client libraries also provide a router, this architecture is discouraged by the specification.[13]

Since the router is a moving part, it is best used as a swappable black box just like one would consider Apache or Nginx for HTTP:

Router Language
Crossbar.io Python (CPython and PyPy)
Erwa Erlang
Jawampa Java
Thruway PHP
wamp.rt JavaScript (Node.js only)
WampSharp C#
Wiola Lua
Nightlife-Rabbit JavaScript (Node.js only)

Tavendo, the company from which originated the protocol, is also the author of Crossbar.io, the de facto router implementation.[14] As they are promoting micro-service-based architectures, Crossbar.io embeds a service manager for hosting and monitoring WAMP app components, a static file Web server, and a WSGI container. Being written with the Twisted library, it can be set up in production without a proxy, aiming to replace stacks such as Nginx associated with Supervisor and Gunicorn.

However, because Crossbar.io has Twisted as a dependency, it can only run on Python 2.7, which means one must install and manage two Python versions in parallel to use the router and a Python 3 client on the same system.

Use cases

Being a WebSocket sub-protocol, WAMP fits naturally anywhere one would use raw web sockets, as a way to synchronize clients such as Web browsers, push notifications to them and allow soft real-time collaboration between users.[15] It has also the same limitations, requiring client support, which is missing for Internet Explorer versions older than 10.[16] This is mitigated by the existence of polyfills[17] using more portable technologies such as Flash or the use of HTTP Longpoll as a fallback. In that sense, WAMP is a competitor to Meteor's DDP.

WAMP also targets the IoT, where it is used in the same way as MQTT[18] as a light and efficient medium to orchestrate clusters of connected objects. The implementations in various languages make it suitable to control and monitor small devices such as the Raspberry Pi (in Python) or the Tessel[19] (in JavaScript).

And last but not least, WAMP can act as an enterprise service bus, serving as the link between micro-services like one would do with Corba, ZeroMQ, Apache Thrift, SOAP or AMQP.

Evolution

WAMP is currently in version 2[20] which introduced routed RPC. The version 1 is now deprecated.[21] As of now, all routers are compatible with version 2. Some clients remains unported: Wamp.io, AutobahnAndroid and cljWAMP.

The version 2 of the specification is divided in two parts: the basic profile, including the router RPC and Pub/Sub, and the advanced profile, featuring trust levels, URI pattern matching and client listing. The basic profile is considered stable and is what current libraries are implementing while the advanced profile is still in evolution.

Comparison

The WAMP website claims[22] the following selling points for the technology:

On the other hand, WAMP does not try to achieve some goals of other protocols:

Nevertheless, numerous protocols share some characteristics with WAMP:

Technology PubSub RPC Routed RPC Web native Cross Language Open Standard
WAMP
AJAX
AMQP
Apache Thrift
Capn'n'Proto
Comet
OMG DDS
D-Bus
CORBA
DCOM
Java JMS
Java RMI
JSON-RPC
MQTT
REST
SOAP
Socket.io
SockJS
STOMP
XML-RPC
XMPP
ZeroMQ
DDP[23]

Although, it is important to note that while DDP does PUB/SUB under the hood to synchronize data sets, it does not expose PubSub primitives. It also is an open specification with several implementations, but not registered as a standard.

References

  1. IANA protocols listing page
  2. WAMP basic profile specifications
  3. "Using WAMP you can build distributed systems out of application components which are loosely coupled and communicate in (soft) real-time.".
  4. A few words about WAMP
  5. "In this chapter [...] you will learn about the Web Application Messaging Protocol [...] which provide tools and services for developping IoT solutions".
  6. Crossbar.io router transport
  7. "WAMP can run over Raw transports instead of WebSocket. Each message is prefixed with a uint32 (big endian) that provides the (serialized) length of the following WAMP message.".
  8. WAMP serialization
  9. "Wampy default serializer is JSON, but it also supports msgpack as serializer, but you need to include msgpack.js as dependency".
  10. WAMP internals bird view diagram
  11. "The Long-Poll Transport is able to transmit a WAMP session over plain old HTTP 1.0/1.1. This is realized by the Client issuing HTTP/POSTs requests, one for sending, and one for receiving".
  12. Crossbar node architecture
  13. "Brokers and Dealers are responsible for generic call and event routing and do not run application code.".
  14. "Crossbar.io is the name of the most full featured router".
  15. WAMP and AngularJS
  16. "Can is use websockets ?".
  17. Web socket polyfills
  18. "Moreover, we compared WAMP with other registered WebSocket subprotocols (MBWS, SOAP and STOMP) in terms of the related features; and with other potential protocols (CoAP and MQTT), in terms of the related practical deployments." (PDF).
  19. Tessel alarm app with Crossbar.io
  20. WAMP 2 specification menu
  21. WAMP 1 specification overview
  22. WAMP compared
  23. specs
This article is issued from Wikipedia - version of the Tuesday, March 29, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.