The simplest combination of components is to have a single micro broker with one or more clients connected to it.
The micro broker acts as a message hub for the clients connected to it, allowing them to send messages to each other. Clients can run in the same process (Virtual Machine (VM) that implements the Java specifications) as the micro broker, in a different process on the same computer, or even on a different computer, thus providing a powerful messaging infrastructure.
The applications do not need to know about each other and more importantly do not need to all be up and running at the same time.
A broker can act as a hub for multiple off board clients. For instance, a broker can act as a home message hub. There are a wide range of devices that could be connected to the hub. On the whole, most devices have their own interface. Adapters are used to map between the device interface and MQTT. In a home, you can imagine creating many different types of adapters. A good example is an X10 adapter that can be used for controlling X10-enabled devices such as lights, power sockets, and the heating system. Adapters can be created for home weather stations, alarm systems, and central heating control. The broker then provides a hub for monitoring and controlling of all the connected devices.
It can be used as a message hub in one process (VM). It may sound like a strange thing to use a message broker to allow Java applications in one process to communicate with each other, but there are a number of advantages that it brings:
- The applications are decoupled from each other.
- The programming model remains the same whether the application runs in the same process space as the broker or whether it is off board.
- It is a simple matter to move an application out of the process the broker is running in and either run it in a different process or different box. This requires either no change to the application or a simple change to specify the network address that the broker is using.
- If an application is not running when a message is sent, the broker can store messages and deliver them when the application starts.
Typically, a combination of the above connectivity patterns will be used. For instance, in the case of the home automation example, clients that directly interact with devices will be off-board, yet the monitoring and controlling application may be on-board with the micro broker.
Parent topic: Micro broker topologies: XPD622