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
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.
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.
The benefits of using URIs (from the HTTP scheme) are:
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.
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.
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.
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.
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.)
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.