From *.com
When you use a web service you have a client and a server:
- If the server fails the client must take responsibility to handle the error.
- When the server is working again the client is responsible of resending it.
- If the server gives a response to the call and the client fails the operation is lost.
- You don't have contention, that is: if million of clients call a web service on one server in a second, most probably your server will go down.
- You can expect an immediate response from the server, but you can handle asynchronous calls too.
When you use a message queue like RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo you expect different and more fault tolerant results:
- If the server fails, the queue persist the message (optionally, even if the machine shutdown).
- When the server is working again, it receives the pending message.
- If the server gives a response to the call and the client fails, if the client didn't acknowledge the response the message is persisted.
- You have contention, you can decide how many requests are handled by the server (call it worker instead).
- You don't expect an immediate synchronous response, but you can implement/simulate synchronous calls.
Message Queues has a lot more features but this is some rule of thumb to decide if you want to handle error conditions yourself or leave them to the message queue.