Home Why? Implementations Specification FAQ

Frequently Asked Questions

General

What is RPC?

Remote Procedure Call (RPC) is a messaging pattern involving peers to two roles: client and server.

A server provides methods or procedure to call under well known endpoints.
A client calls remote methods or procedures by providing the method or procedure endpoint and any arguments for the call.
The server will execute the method or procedure using the supplied arguments to the call and return the result of the call to the client.

What is PubSub?

Publish & Subscribe (PubSub) is a messaging pattern involving peers of three roles: publisher, subscriber and broker.

A publisher sends (publishes) an event by providing a topic (aka channel) as the abstract address, not a specific peer.
A subscriber receives events by first providing topics (aka channels) he is interested. Subsequently, the subscriber will receive any events publishes to that topic.
The broker sits between publishers and subscribers and mediates messages publishes to subscribers. A broker will maintain lists of subscribers per topic so it can dispatch new published events to the appropriate subscribers.

A broker may also dispatch events on it's own, for example when the broker also acts as an RPC server and a method executed on the server should trigger a PubSub event.

In summary, PubSub decouples publishers and receivers via an intermediary, the broker.

Protocol

Why RPC and PubSub in one protocol?

Imagine the following situation: a client want to perform some action on a server. The client also wants to get notified when another clients performs the action.
For example, in a Web application for managing service tickets, a client 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 client would subscribe to the topic "OnTicketCreated", and perform it's actions by calling "createTicket". The server side implementation of "createTicket" would not only perform the action of creating a new ticket, but also dispatch a PubSub 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 one protocol for both RPC and PubSub.

Why does WAMP use URIs to identify RPC endpoints and PubSub topics?

The benefits of using URIs (from the HTTP scheme) are:

• well known hierarchical naming scheme
• an established global name registry / arbitration system (DNS)
• by virtue of the first two, ability to integrate apps from different vendors without naming conflicts
• as a potential feature in the future: have the ability to make those URIs derefencable for obtaining metadata

URIs are mandatory for topic and procedures. The current AutobahnXX implementations don't _yet_ enforce this, but will do so.

In your payloads (RPC args, PubSub event payload) you are free do to anything of course. We (at Tavendo) for our apps use URIs for anything which isn't a literal value, that is all ID like things, vocabulary (verbs, adj, ..) describing relations between entities .. everything.

Legal

What is the legal status of WAMP?

WAMP is free - both as in beer and as in speech. Do with it what you like. If WAMP fills your needs as it is, then the easiest thing is to just use it without any changes. The more compatible implementations, the better for interoperability. If your needs require modifications, or you want to start your own development based on WAMP, then you are also free to do so.
Whatever you do with WAMP - an announcement on the mailing list is always welcome.

Are there any requirements if I use WAMP for my project?

WAMP is free to use for anybody, be it as part of an open source or a commercial project. There are no strings attached here, no licenses to pay, and no known other intellectual property (such as patents).
If you do use WAMP for your project, then both a mention of this somewhere in your project, and an announcement on the mailing list would be welcome.

Why is WAMP trademarked?

The WAMP word- and desing mark are trademarked as a way to ensure that only proper use is made of them. This is especially the case in regard to assurances regarding compatibility. A trademark policy detailing correct use is in the works. For now, and for a quick overview of the base principles of the trademark policy, see the following question.

Who can use the WAMP word mark or the WAMP design mark?

The fact that WAMP is a word mark does not prevent factual use. If you e.g. announced that you were working on a WAMP implementation, or discussed details of your implementation work, or recommended this website, these are all, naturaly, entirely unproblematic uses.
For any use of the word mark which could imply a direct endorsement, or other official connection with the WAMP project, or when in doubt, please contact Tavendo. The same goes for any use of the design mark (i.e. the WAMP logo at the top of the project page).
We will take a look as quickly as possible, and try to arrange a license if this should be necessary. (And a license does not need to be a big deal.)

What does the CC copyright on this website mean?

The threshold for using WAMP should be as low as possible. This includes the documentation for what you are doing. The CC BY license simply means that you are free to use any materials on this website (with the exception of the WAMP word mark or WAMP design mark) for your project. You can copy & paste or edit anything you think useful to for e.g. your own project website or your documentation. This applies irrespective of whether your project is commercial or non-commercial.
The only requirement is that you attribute this use. In an internet context, this is most easily done by providing something like 'some materials copied/adapted from' + a link to the WAMP website.