Combinations of micro brokers, clients and bridges can be linked together in a number of ways. This section describes some of the common topologies that are used when linking components together.
The simplest combination of components is to have a single micro broker with one or more clients connected to it. The broker acts as a message hub for clients connected to it. These clients can send messages to each other. Clients can run in the same process (JVM) as the micro broker, in a different process on the same box or even a different box providing a powerful messaging infrastructure.
There are a limited number of examples particularly when talking about an enterprise domain that run small stand alone message hubs. Typically an enterprise will have a main message hub/backbone that is fed either by messaging clients, by smaller message hubs in the enterprise or by other businesses.
Micro broker allows small message hubs to be created in locations where enterprise servers are not possible or not cost effective. For instance a hub can be created in a gas station, an RFID edge controller, an electricity sub station or pumping station. Clients connected to the hub then have a message infrastructure that continues to run if there are problems with connectivity to the enterprise. It also brings with it the benefit that messages can now flow more directly between devices and applications without having to be routed back to the enterprise server, and increasing response times.
It is worth noting that the enterprise may consist of more than three tiers. For instance, the bridge connects to a server and that server then connects to another server in the main enterprise network making four tiers. As far as the micro broker is concerned it only needs to know about the point at which it connects into the enterprise.
Peer to Peer
As far as the bridge is concerned a micro broker looks just like an enterprise broker. This enables networks of interconnected micro brokers to be setup and messages to flow between them.
For example, a set of micro brokers can be run used in an RFID solution in a store. Each micro broker handles messages from a number of RFID readers. Due to the nature of RFID, a tag may be read not only on the reader that it passes through but also on other readers, hence the tag will be fed to multiple micro brokers. Linking micro brokers together allows RFID tag messages to be correlated across brokers.
Bringing it all together
Extrapolating the previous connectivity topologies, it is possible to link these topologies together to produce ever more sophisticated networks of messaging components. For example, the diagram below shows a set of micro brokers linked together as peers, some of which are linked to the enterprise.
Even though this is possible, it is good practice to keep the messaging network as simple as possible. The more complex the system, the harder it is to diagnose problems and to extend in the future.
The previous topologies show how a combination of micro brokers, clients and the enterprise can be linked together. Another way to view the set of connected components is as a message bus.
Basically the set of inter-linked messaging components can be thought of as a message bus with a set of points where messages can be put on the bus and a set of destinations where messages are removed from the bus. Typically a message client, like a JMS or MQTT client, are using to put messages onto and take messages off of the bus. When a message is put onto the bus it is tagged with its destination. It is the role of the underlying messaging components to deliver the message to its destination.
Between the entry point to the bus and destination various things may happen to the message:
- First the destination may not be a single point, in the case of a publish/subscribe system; the message may end up at multiple points.
- Rather than be delivered to the recipient that originator thought it was going to, the message can be rerouted to a different destination. Also, the message itself can be discarded in some situations based on business logic, hence giving a flexibility of filtering the messages (content-based routing).
- The message could be routed both to the intended destination but also to additional destinations.
- The message can be transformed between the entry point and destination. For instance a message that has been optimized for size due to memory limitations may be transformed into XML when it reaches the enterprise.
- Different servers handle different message protocols. Micro broker handles MQTT whereas the WebSphere Message Broker brokers handle multiple protocols including MQ, MQRT, MQTT, MQe. Between originator and destination multiple protocols may be used, this is known as crossing the streams.
The capabilities of the message bus are spread across the different components. In the case of enterprise servers, they provide all of the capabilities discussed above. Due to the nature of micro broker and the environments in which it runs, the capabilities are not as rich. For instance, the bridge allows basic transformation to a message, but leaves more sophisticated transformation tasks to the customer application. Whereas, the enterprise brokers provide a rich assortment of tools to help transform messages.
This split of capabilities is very deliberate as the goal of micro broker and its enterprise counterparts are different. At a high level, the micro broker should be thought of as lean and mean, running on a large array of constrained environments. Enterprise brokers can be thought of as feature rich running on powerful machines capable of performing heavyweight tasks.