When we build systems, often we use some form of RPC: like UNIX RPC, RMI, Web Services and Thrift etc. Yes, each has its unique traits, yet fundamentally all let users invoke a procedure call living in a remote server and has three properties.
- Request/response (a.k.a. two way messaging)
- Synchronous (client wait for the server to return)
- Transient (message is not stored)
Although, we often take these properties as granted, there is a flip side to each. For example, there are one-way interactions, asynchronous interactions, and persistent interactions.
As shown by the figure, those properties can be combined into eight possibilities, and RPC is just one of the eight. We use messaging to mean a superset of RPC interactions that allow users the flexibility of choosing above properties. Messaging systems (e.g. JMS) support Distributed Queues (see ) and Publish/Subscribe (see ) models.
Messaging may provide all or some of the following advantages.
- Reliability – via transactions or persistence
- Performance – enable us to do SEDA like event driven non-blocking architecture that can provide higher throughput than blocking architectures.
- Loose coupling – participants joining the interaction may loosely coupled in one of the following three dimensions (read the paper “Many faces of Publish Subscribe” for more information. )
- Space – server and client do not need to know each other.
- Time – server and client do not have to be online at the same time.
- Synchronization –client does not have to wait for the message to be delivered.