Web Application Messaging Protocol

Last updated • 7 min readFrom Wikipedia, The Free Encyclopedia

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 coordinating multiple connected IoT devices. [5]

Contents

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 sequence types are available, and defaults to JSON as the most common format offering these. Implementations often provide MessagePack as a faster alternative to JSON at the cost of an additional dependency. [9]

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 on 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 a realm from using IDs defined in another for RPC and PubSub. Realms also have permissions attached and can limit the clients to one subset of the REGISTER/CALL/PubSub actions available.

Some realms can only be 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 libraryLanguage
AngularWAMP JavaScript for the AngularJS framework
AutobahnCpp C++ 11
wamplv LabVIEW (G)
AutobahnJS JavaScript (browser and Node.js)
AutobahnPython Python
wampy Python
Net::WAMP Perl
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++
wampcc C++
WampSharp C#
Wampy.js JavaScript (browser only)
nexus Go

The minimum requirements to build a WAMP client are the abilities to use sockets and to serialize 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 client 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[ according to whom? ] as a swappable black box just like one would consider Apache or Nginx for HTTP:

RouterLanguage
Bondy Archived 2019-12-30 at the Wayback Machine Erlang
Crossbar.io Archived 2015-01-12 at the Wayback Machine Python (CPython and PyPy)
Erwa Erlang
wampcc C++
Jawampa Java
Thruway PHP
wamp.rt JavaScript (Node.js only)
WampSharp C#
Wiola Lua
Nightlife-Rabbit JavaScript (Node.js only)
nexus Go

Tavendo, the company from which originated the protocol, is also the author of Crossbar.io, which promotes itself as the de facto router implementation. [14] As they are promoting microservice-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 is one of the implementations that can be set up in production without a proxy, aiming to replace stacks such as Nginx associated with Supervisor and Gunicorn.

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 microservices like one would do with CORBA, ZeroMQ, Apache Thrift, SOAP or AMQP.

Evolution

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

The version 2 of the specification is divided into 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 [21] 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:

TechnologyPubSubRPCRouted RPCWeb nativeCross LanguageOpen Standard
WAMPYes check.svgYes check.svgYes check.svgYes check.svgYes check.svgYes check.svg
AJAX Yes check.svgYes check.svgYes check.svg
AMQP Yes check.svgYes check.svgYes check.svgYes check.svg
Apache ThriftYes check.svgYes check.svg
Capn'n'Proto Yes check.svgYes check.svg
Comet Yes check.svgYes check.svg
OMG DDS Yes check.svgYes check.svgYes check.svg
D-Bus Yes check.svg
CORBAYes check.svgYes check.svgYes check.svgYes check.svg
DCOM Yes check.svgYes check.svgYes check.svg
Java JMS Yes check.svgYes check.svg
Java RMI Yes check.svgYes check.svg
JSON-RPC Yes check.svgYes check.svgYes check.svgYes check.svg
MQTT Yes check.svgYes check.svgYes check.svgYes check.svg
REST Yes check.svgYes check.svgYes check.svg
SOAPYes check.svgYes check.svgYes check.svgYes check.svg
Socket.io Yes check.svgYes check.svg
SockJS Yes check.svgYes check.svg
STOMP Yes check.svgYes check.svgYes check.svgYes check.svg
XML-RPC Yes check.svgYes check.svgYes check.svgYes check.svg
XMPP Yes check.svgYes check.svgYes check.svgYes check.svgYes check.svg
ZeroMQ Yes check.svgYes check.svg
DDP [22] Yes check.svgYes check.svgYes check.svgYes check.svg

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.

Related Research Articles

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space, which is written as if it were a normal (local) procedure call, without the programmer explicitly writing the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client–server interaction, typically implemented via a request–response message passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually, they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important.

In computing, serialization is the process of translating a data structure or object state into a format that can be stored or transmitted and reconstructed later. When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of objects does not include any of their associated methods with which they were previously linked.

<span class="mw-page-title-main">SOAP</span> Messaging protocol for web services

SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP), although some legacy systems communicate over Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism.

A web service (WS) is either:

In the seven-layer OSI model of computer networking, the session layer is layer 5.

<span class="mw-page-title-main">Inter-process communication</span> How computer operating systems enable data sharing

In computer science, inter-process communication (IPC), also spelled interprocess communication, are the mechanisms provided by an operating system for processes to manage shared data. Typically, applications can use IPC, categorized as clients and servers, where the client requests data and the server responds to client requests. Many applications are both clients and servers, as commonly seen in distributed computing.

<span class="mw-page-title-main">Interface description language</span> Computer language used to describe a software components interface

An interface description language or interface definition language (IDL) is a generic term for a language that lets a program or object written in one language communicate with another program written in an unknown language. IDLs are usually used to describe data types and interfaces in a language-independent way, for example, between those written in C++ and those written in Java.

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.

<span class="mw-page-title-main">JSON</span> Open standard file format and data interchange

JSON is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of attribute–value pairs and arrays. It is a commonly used data format with diverse uses in electronic data interchange, including that of web applications with servers.

JSON-RPC is a remote procedure call (RPC) protocol encoded in JSON. It is similar to the XML-RPC protocol, defining only a few data types and commands. JSON-RPC allows for notifications and for multiple calls to be sent to the server which may be answered asynchronously.

In software architecture, a messaging pattern is an architectural pattern which describes how two different parts of an application, or different systems connect and communicate with each other. There are many aspects to the concept of messaging which can be divided in the following categories: hardware device messaging and software data exchange. Despite the difference in the context, both categories exhibit common traits for data exchange.

The Spring Framework is an application framework and inversion of control container for the Java platform. The framework's core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE platform. The framework does not impose any specific programming model.. The framework has become popular in the Java community as an addition to the Enterprise JavaBeans (EJB) model. The Spring Framework is free and open source software.

<span class="mw-page-title-main">Message broker</span> Computer program module

A message broker is an intermediary computer program module that translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver. Message brokers are elements in telecommunication or computer networks where software applications communicate by exchanging formally-defined messages. Message brokers are a building block of message-oriented middleware (MOM) but are typically not a replacement for traditional middleware like MOM and remote procedure call (RPC).

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

<span class="mw-page-title-main">Apache Avro</span> Open-source remote procedure call framework

Avro is a row-oriented remote procedure call and data serialization framework developed within Apache's Hadoop project. It uses JSON for defining data types and protocols, and serializes data in a compact binary format. Its primary use is in Apache Hadoop, where it can provide both a serialization format for persistent data, and a wire format for communication between Hadoop nodes, and from client programs to the Hadoop services. Avro uses a schema to structure the data that is being encoded. It has two different types of schema languages: one for human editing and another which is more machine-readable based on JSON.

gRPC is a cross-platform open source high performance remote procedure call (RPC) framework. gRPC was initially created by Google, which used a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across its data centers from about 2001. In March 2015, Google decided to build the next version of Stubby and make it open source. The result was gRPC, which is now used in many organizations aside from Google for use cases from microservices to the "last mile" of computing. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts. It generates cross-platform client and server bindings for many languages. Most common usage scenarios include connecting services in a microservices style architecture, or connecting mobile device clients to backend services.

<span class="mw-page-title-main">Thing Description</span>

The Thing Description (TD) (or W3C WoT Thing Description (TD)) is a royalty-free, open information model with a JSON based representation format for the Internet of Things (IoT). A TD provides a unified way to describe the capabilities of an IoT device or service with its offered data model and functions, protocol usage, and further metadata. Using Thing Descriptions help reduce the complexity of integrating IoT devices and their capabilities into IoT applications.

Cap’n Proto is a data serialization format and Remote Procedure Call (RPC) framework for exchanging data between computer programs. The high-level design focuses on speed and security, making it suitable for network as well as inter-process communication. Cap'n Proto was created by the former maintainer of Google's popular Protocol Buffers framework and was designed to avoid some of its perceived shortcomings.

The Asynchronous Server Gateway Interface (ASGI) is a calling convention for web servers to forward requests to asynchronous-capable Python frameworks, and applications. It is built as a successor to the Web Server Gateway Interface (WSGI).

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. Bahga, Arshdeep; Madisetti, Vijay (9 August 2014). In this chapter [...] you will learn about the Web Application Messaging Protocol [...] which provide tools and services for developing IoT solutions. ISBN   9780996025515.
  6. "Crossbar.io router transport". Archived from the original on 2015-01-12. Retrieved 2015-01-12.
  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". GitHub .
  8. WAMP serialization
  9. "Wampy default serializer is JSON, but it also supports msgpack as a 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". GitHub .
  12. "Crossbar node architecture". Archived from the original on 2015-01-12. Retrieved 2015-04-20.
  13. "Brokers and Dealers are responsible for generic call and event routing and do not run application code". GitHub .
  14. "Crossbar.io is the name of the most full-featured router". 26 December 2014.
  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). Archived from the original (PDF) on 2016-05-13. Retrieved 2015-01-12.
  19. Tessel alarm app with Crossbar.io
  20. WAMP 2 specification menu
  21. WAMP compared
  22. DDP specs