October 5, 2018

Web Application Messaging Protocol

In the last Fiction2Science Hackathon, I learned to apply the Web Application Messaging Protocol (WAMP) for communication of services in the cloud. In this article, I will describe the protocol a little bit more detailed and refer to the implementation of Crossbar.io.

The idea of the Web Application Messaging Protocol (WAMP)

Web Application Messaging Protocol (WAMP) helps cloud computing services to communicate.Lots of people might know Representational State Transfer (REST) APIs. This architectural style sets a group of constraints that allow services on the web to communicate. A caller calls a certain URL and passes some information to the callee. Afterwards, the caller of the URL would receive an answer from the callee. As long as multiple callers know the URL of the API, it could be called by multiple services. However, multiple callees are not possible. This is known as a Remote Procedure Call (RPC).

Remote Procedure Call (RPC)

The WAMP includes RPCs. But the main difference between WAMP and REST is, though, that the callee is not called directly and the caller does not have to know his/her/its correct address.

Diagram describing a Remote Procedure Call
Remote Procedure Call

WAMP has a router which receives calls. After the router receives a call, the router forwards this call to the related callee. This callee processes the received information and sends the results back to the router who forwards them directly to the caller. For telling the router the address of the callee, a remote procedure must be registered. Like this, neither the callers nor the callee have to know the address of the other party; the router has a list of all registered remote procedures.

Publish-Subscribe Pattern (Pub/Sub)

In addition to RPCs known from REST, WAMP includes Pub/Sub as well.

Diagram describing the Publish-Subscribe Pattern
Publish-Subscribe Pattern

At least one service subscribes to a topic; each subscriber would receive updates when any news with these topic are published. On the other side, you could publish on a topic. Then, each subscriber would receive the information published. It is important to know that Pub/Sub only works from publisher to subscriber. It does not work in the other direction. There could be a random number of subscribers as well as publishers for a topic. Both parties do not have to know the addresses of the other party because each subscription is registered at the router. When any information to a topic gets published, it is also published to the router.

Comparison of RPC and Pub/Sub

RPC Pub/Sub
Messages from multiple callers accepted from a specific callee n publishers send to m subscribers
Callers requests information which are send back by a specific callee Publishers send information to all subscribers

Implementation of WAMP

A network using WAMP usually consists of several (micro-)services and a server operating as a router. Each of them could be written in a different programming language as long as they send and receive their messages via WAMP.

The website of WAMP lists several implementations for different programming languages. At first, you have to run a router. Then, you could start developing your clients using one of the libraries.

Crossbar.io offers implementations for both a router and client libraries for a bunch of programming languages (e.g. Python, C++, Java, JavaScript). In this article I show how to start a local WAMP router.

If you want to see some brief examples of how I implemented some microservices, have a look in my f2s-cloud-hackathon repository.

Posted in General, WAMPTaggs: