Frequently Asked Questions

Frequently Asked Questions

General

What is RPC?

Remote Procedure Call (RPC) is a messaging pattern involving peers of three roles:

  1. Caller
  2. Callee
  3. Dealer

A Caller issues calls to remote procedures by providing the procedure URI and any arguments for the call. The Callee will execute the procedure using the supplied arguments to the call and return the result of the call to the Caller.

Callees register procedures they provide with Dealers. Callers initiate procedure calls first to Dealers. Dealers route calls incoming from Callers to Callees implementing the procedure called, and route call results back from Callees to Callers.

The Caller and Callee will usually run application code, while the Dealer works as a generic router for remote procedure calls decoupling Callers and Callees.

to top

What is PubSub?

Publish & Subscribe (PubSub) is a messaging pattern involving peers of three roles:

  1. Publisher
  2. Subscriber
  3. Broker

A Publishers publishes events to topics by providing the topic URI and any payload for the event. Subscribers of the topic will receive the event together with the event payload.

Subscribers subscribe to topics they are interested in with Brokers. Publishers initiate publication first at Brokers. Brokers route events incoming from Publishers to Subscribers that are subscribed to respective topics.

The Publisher and Subscriber will usually run application code, while the Broker works as a generic router for events decoupling Publishers from Subscribers.

Read more: Publish / Subscribe Systems: Design and Principles, by Sasu Tarkoma.

to top

Why RPC and PubSub in one protocol?

Imagine the following situation: an application frontend wants to perform some action on an application backend. The frontend also wants to get notified when another frontend performs the respective action on the backend.
For example, in a Web application for managing service tickets, a frontend might perform the action “create new ticket”, and get notified via events of “new ticket created”.
A natural approach to realize above would use RPC for performing actions, and PubSub for notifications.
With the service ticket Web app, the frontend would subscribe to the topic “OnTicketCreated”, and perform it’s actions by calling “createTicket”. The backends implementation of “createTicket” would not only perform the action of creating a new ticket, but also publish a event on the topic “OnTicketCreated” with the details of the new ticket.

Now, a protocol suitable for realizing above will naturally need to provide both RPC and PubSub messaging patterns. WAMP was designed exactly with above in mind, so it provides you with a unified protocol for both RPC and PubSub.

For more about the reasoning behind WAMP, see this explanation.

to top

Why is it called WAMP and how do I use it?

WAMP is an acronym, and the term “Web Application Messaging Protocol” is a quite precise description of what the protocol provides.

WAMP is pronounced /wa:mp/, as in swamp or chomp.

Note that there is another technology also abbreviated WAMP: the Web technology stack “Windows + Apache + MySQL + PHP”. I.e. Wikipedia has a corresponding disambiguation page.

Because of this potential ambiguity, here is what we recommend for authors/implementors:

  1. Use “WAMP” in text and speech
  2. The first occurrence in text should read: “WAMP (Web Application Messaging Protocol)”
  3. Add the hashtag/keyword “wampws” to the contents metadata

And here is what we recommend for users:

  1. Use the terms “wamp” and “protocol” combined when using Web search engines
  2. Use the hashtag/keyword “wampws” when search on Web platform like Twitter or StackOverflow

to top

What is WebSocket?

WebSocket is a protocol providing full-dupley communcations channels over a single TCP connection. It started out in the Web world, where it was created to replace things like Comet, and to allow true bi-directional, low-latency connections between browser and server. It’s standardized by the IETF and the W3C. Usage is not limited to the browser, with implementations available for all major programming languages. For more details see this introductory blog post.

to top

Is WebSocket necessary for WAMP?

WAMP started out as the WebSocket Application Messaging Protocol. WebSocket is still the preferred transport in many cases, but the transport layer is fully decoupled. Any bi-directional, reliable, message-based and ordered transport works. Transports like Unix Domain Sockets or Unix Pipes are being used in implementations.
Additionally, a transport for WAMP transports can be implemented on top of other transports which lack some of the requirements, e.g. using longpoll bi-directionality can be built on top of HTTP.

to top