For our laboratory we will go with a selection of two Enterprise Integration Patterns. We chose "remote procedure call" and "idempotent consumer".
Remote procedure call: As already explained this is the one developers mostly think in. There are some points you must be aware by using rpc:
​
-
You bind your client to the server. If the server is not here - the client has to handle the situation.
-
Depending on the experience of the developer he could think it is an in-memory call. It is not! It goes over the wire! So exception handling is an issue here.
Idempotent receiver: I preferably call it also "idempotent consumer". Why? It is more inline to the terminology used by RabbitMq. The idea behind this pattern:
​
-
As far as your queues are persistent you de-couple the client from the server. If the server is not there, messages are preserved by the broker. As soon the server is ready again, the messages get processed.
-
Idempotent means you can send the same message over and over again. The state is just modified once in your system. Remark: Do not rely on FIFO principles by a broker. Things can go wrong. Your application design must ensure idempotent behaviour here.
​
I would say with these two patterns you are already prepared to a good start with a messaging broker. In fact, I have seen applications just using more or less these two patterns.