STOMP vs. WAMP Server Push Messaging Technology

Server push technology is a style of e-based communication whether a request for a transaction is initiated by a central server otherwise known as the publisher. In regards to this technology, an event is the creation, update, deletion or undeletion of a record; and a notification is a message in response to an event

STOMP

STOMP simply stands for Simple Text-Oriented Messaging Protocol and it is designed for asynchronous message passing between clients via mediating servers. This protocol provides and interoperable wire format so that every STOMP client can communicate with any STOMP message broker to provide easy and widespread messaging interoperability among many languages, brokers, and platforms. Since STOMP is a frame based protocol with the frames modelled on HTTP, the server side of STOMP may be a little hard to implement well, but it is very easy to write a client to get you connected. Generally, it is a very simple and easy to implement protocol.

A frame consists of a command, a set of optional headers and an optional body. STOMP is text oriented but also allows for the transmission of binary messages and the default encoding for STOMP is UTF-8, but it also supports the specification of alternative encoding for message bodies. Servers can be creative with the semantics that they can support with STOMP as STOMP does not define what the delivery semantics of destinations should be. The STOMP protocol treats destinations as opaque strings with their syntax being server implementation specific.

A STOMP client is a user-agent which can acts in two modes simultaneously:

• As a producer, sending messages to a destination on the server via a SEND frame
• As a consumer, sending a SUBSCRIBE frame for a given destination and receiving messages from the server as MESSAGE frames.

[See Also: Introducing Crossbar.io as a Microservices Framework]

WAMP

WAMP is an open standard WebSocket sub-protocol that provides two application messaging pattern in one unified protocol:

Remote Procedure Calls (RPC) + Publish & Subscribe (PUB/SUB)
It enables different technologies, processes, and machines to communicate with each other, in real time. Each piece of code using WAMP is a client, needing a dedicated library to perform. You need a central server between all clients. These server and libraries are free, available now and ready to be used, you only need to code the clients, with one of the Autobahn libraries. They are security features such as permissions and encryptions.

RPC: Asynchronous, fast and simple pattern that allows calling a function from another code remotely via a websocket. Parameters and return values can be arrays, mappings, numbers, and strings. It works between different languages and between local processes or across the Internet.

PUB/SUB: Here, a client subscribes to a topic while another client publishes a message about this topic. All subscribers interested in this topic receive a message. PUB/SUB is not much different from RPC, just that you cannot get a return value; however, you can send messages to 0 or N clients and not just 1.

[See Also: Introducing Tavendo – WAMP + Autobahn + Crossbar.io]

‍

In the PUB/SUB model, a Publisher submits information to an abstract topic and subscribers only receive information indirectly by announcing their interest on a respective topic without both knowing each other as opposed to the RPC model where the “Caller” needs to have knowledge about where the “Callee” resides and how to reach it.

The Publisher and Subscriber are decoupled via the “topic” via an intermediary called the Broker. A broker keeps a book of subscriptions who is currently subscribed to which topic. In the RPC mode, a Callee registers a procedure at a “Dealer” under an abstract name: which is a URL identifying the procedure. This URL is all the Callee gives the Dealer when he wants to call a remote procedure and the Dealer will look up the procedure to be invoked. This way, Callers and Callees are decoupled and applications can use RPC and still benefit from loose coupling as in the PUB/SUB model.

A Router is a combination of both a Broker and a Dealer. A router is capable of routing both calls and events and therefore, can support flexible, decoupled architectures that use both RPC and PUB/SUB.

‍

Everything you need to know about outsourcing technology development and application modernization services

Access a special Introduction Package with everything you want to know about outsourcing your technology development. How should you evaluate a partner? What components of your solution that are suitable to be handed off to a partner? These answers and more below.

‍