Web Application Messaging Protocol

Structure

WAMP requires ^{[6] a} reliable, ordered, duplex message channel as a communication method at the transport layer , and by default uses Websocket. However, implementations can use other communication methods at the transport level that correspond to these characteristics and communicate with WAMP software, for example, using raw sockets, ^[7] Unix domain sockets, or regular pull requests .

Message serialization is available if messages are composed of integers, strings, and ordered sequence types, ^[8] and by default JSON is used as the most common format. WAMP implementations often provide MessagePack as a faster alternative to JSON, but at the cost of additional dependency. ^[9]

To define remote procedures and non-conflicting PubSub sections, WAMP also needs an identifier space that allows global assignment and modification. Because the protocol is web native — WebSocket is the preferred transport protocol — in this case, URIs are used.

Working Principle

WAMP has a client-client interaction structure, with centralized software, a router sending messages to clients. Typical data exchange workflow: ^[10]

• Clients connect to the router using transport layer protocols, creating a session.
• The router identifies the clients and grants them permissions for the current session.
• Clients send messages to the router, which in turn sends them to recipients using attached URIs.

Clients send these messages using higher-level technologies: RPC and PUB / SUB, which perform four basic interactions:

• registration: the client provides the procedure for a remote call .
• call: the client asks the router for the results of the open procedure of another client .
• subscription: the client notifies you of interest in the topic .
• publication: the client publishes information about this topic .

Data exchange may have a different view, depending on the selected transport layer protocol. ^[11] However, implementation details are hidden for the end user who interacts with only two high-level design patterns — RPC and PubSub.

Security

Because WAMP uses the Websocket protocol, connections can use TLS for encryption. For cases where complete confidentiality is not established, the implementation of several mechanisms is provided to isolate components and prevent man-in-the-middle attacks. The default sub-protocol implementations ensure that an attempt to register an already registered procedure fails.

Routers can define areas as administrative domains, and clients must specify which area they want to connect to the connection. Once connected, the domain will act as a namespace , not allowing clients connected to the domain to use identifiers defined in another for RPC and PubSub. Regions also have permissions attached and can limit clients to one subset of the available REGISTER / CALL / PubSub actions.

Only authenticated clients can connect to certain areas using various authentication methods, such as using a TLS certificate , a cookie or a “simple ticket”.

RPC Routing

Unlike traditional RPCs, which are addressed directly from the caller to an entity that offers a procedure (usually a backend server) and strictly unidirectional (client-server), RPC in WAMP is routed by middleware and works in bidirectional mode.

RPC registration is performed with the WAMP router, and procedure calls are issued in the same way to the WAMP router. This means, first of all, that a client can issue all RPCs through a single connection to a WAMP router and does not need to know which client is currently proposing this procedure, where this client is located or how to determine it. RPC registration can indeed change between calls, opening up the possibility for advanced functions, such as load balancing or rejection when calling procedures.

In addition, this means that all WAMP clients are equal in that they can offer call procedures. This avoids the traditional distinction between clients and server backends and allows architectures, where browser clients call procedures for other browser clients, to use the API as if with a peer-to-peer connection

However, even with a multi-tier architecture, the router is still the only point of failure. For this reason, some route maps of the router include clustering features. ^[12]

Customers

Since the main tasks of WAMP are web applications and the Internet of things, clients are implemented in languages ​​that have worked well in these industries (only WAMP v2 clients are listed):

The minimum requirements for creating a WAMP client are the ability to use sockets and JSON serialization. Thus, many modern languages ​​already fulfill these requirements using standard libraries. Additional features that add dependencies to the project, such as TLS encryption or MessagePack serialization, are optional.

However, the persistent nature of WebSocket connections requires the use of lock-protected libraries and asynchronous APIs . In languages ​​with one official mechanism, such as JavaScript, Erlang or Go, this is not a problem. But languages ​​with several competing solutions for asynchronous programming, such as Python or PHP, force the client's author to fix a certain part of the ecosystem.

For the same reason, the integration of outdated projects may also require work. As an example, most of the popular Web Python frameworks using WSGI , a synchronous API, and launching a WAMP client within a working WSGI user need manual adapters, such as crochet .

Routers

Although routers can be embedded directly into the application code, and some client libraries also provide a router, this architecture is not welcomed by the specification. ^[13]

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

Tavendo, the company from which the protocol originated, is also the author of Crossbar.io, which promotes itself as a de facto implementation of the router. ^[14] As they promote microservice based architectures, Crossbar.io implements a service manager to host and monitor the components of the WAMP application, the static web file server and the WSGI container. Being written using the Twisted library, this is one of the implementations that can be created in a proxy-free production, in order to replace stacks, such as Nginx, associated with Supervisor and Gunicorn.

As a WebSocket subprotocol, WAMP is ideal for use as raw web sockets, as a way to synchronize clients such as web browsers, push notifications, and the ability for real-time soft collaboration between users. ^[15] It also has the same limitations that are required for customer support, which are not available for versions of Internet Explorer older than 10. ^[16] This is mitigated by the presence of polyfills ^[17] using more portable technologies like Flash or using HTTP Longpoll as backup copy. In this sense, WAMP is a competitor to DDP Meteor .

WAMP also targets IoT, where it is used in the same way as MQTT , ^[18] as an easy and effective carrier for organizing clusters of related objects. Implementations in different languages ​​make it suitable for monitoring and monitoring small devices, such as Raspberry Pi (in Python) or Tessel ^[19] (in JavaScript).

Last but not least, WAMP can act as a company service bus serving as a link between microservices, such as Corba , ZeroMQ , Apache Thrift , SOAP or AMQP .

WAMP is currently in version 2 ^[20] , which introduces routable RPC. Version 1 is now out of date. ^[21] At the moment all routers are compatible with version 2. Some clients remain unported: Wamp.io, AutobahnAndroid and cljWAMP.

Version 2 of the specification is divided into two parts: the base profile, including the RPC router and Pub / Sub, and the extended profile with levels of trust, URI mapping and client enumeration. The base profile is considered stable and is implemented in current libraries, while the extended profile is still in the process of evolution.