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.
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.
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.