AMQP (any MOM, in fact) provides the ability to communicate processes without having to take into account the actual IP addresses, communication security, routing, among other problems. This does not necessarily mean that any process can trust or even have any information about the processes with which it exchanges.
Message queues decide half the process: how to get to the remote service. But they do not solve the other half: what service is right for me. In other words, which service:
- has the resources I need
- can be trusted (located on a reliable server, has a satisfactory implementation of the service, located in a country where local laws are compatible with your requirements, etc.).
- charges you what you want to pay (although people rarely discuss cost when it comes to microservices)
- will be present throughout the window of time required to process your service - keep in mind that servers are becoming increasingly unstable. Some servers are actually containers that can last a couple of minutes.
These two problems are almost linearly independent. To solve the second type of problems, you have the resources of brokers in grid computing. There is also a distribution of resources to make sure that the last element above is correct.
There are several alternative strategies, such as multicasting intent to use the service and waiting for replies with suggestions. For example, you may have a reverse auction in such a case.
In short, the rule of thumb is that if you do not have a priori knowledge of which service you are going to use (hard-coded or in some configuration file), your agent will have to negotiate, including dynamic service discovery.
Akira source share