WAMP is a WebSocket subprotocol registered at IANA, specified to offer routed RPC and PubSub. Its design goal 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), fit for developing responsive web applications or coordinating multiple connected IoT devices.
Characteristics
Structure WAMP requires 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, Unix sockets, or HTTP long poll. Message serialization assumes 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.
Workflow WAMP is architectured around client–client communications with a central software, the router, dispatching messages between them. The typical data exchange workflow is:
Clients connect to the router using a transport, establishing a session. The router identifies the clients and gives them permissions for the current session. Clients send messages to the router which dispatches them to the proper targets using the attached URIs. The clients send these messages using the two high-level primitives that are RPC and PUB/SUB, doing four core interactions:
register: a client exposes a procedure to be called remotely. call: a client asks the router to get the result of an exposed procedure from another client. subscribe: a client notifies its interest in a topic. publish: a client publishes information about this topic. This can have subtle variations depending on the underlying transport. 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.
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):
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 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. 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:
Tavendo, the company from which originated the protocol, is also the author of Crossbar.io, which promotes itself as the de facto router implementation. 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.
… excerpt ends here. Continue reading the full article.
