I drew the following diagram for wso2con talk. Through the diagram, I am trying to explain “what is messaging” and “why should you care”? Here are some thoughts.
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)
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 [2]) and Publish/Subscribe (see [1]) 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.
References
- Eugster, Patrick Th, et al. "The many faces of publish/subscribe." ACM Computing Surveys (CSUR) 35.2 (2003): 114-131.
- Scalable Persistent Message Brokering with WSO2 Message Broker slide deck