Inspirel banner

Programming Distributed Systems with YAMI4

7.2 Message Broker

In one of the previous chapters devoted to common concepts of messaging with YAMI4, a lot of stress was put in defining YAMI4 as a peer-to-peer messaging system, where direct connections are considered to be a foundation for all communication scenarios. One of the advantages of YAMI4 is its simplicity and the ability to set up communication channels without relying on additional infrastructure components like message brokers. The ability to run without separate message brokers is further underlined by the fact that the high-level YAMI4 libraries offer a basic implementation of publish-subscribe messaging, where data producers can be to a large extent isolated from the administrative difficulties of managing the set of data subscribers.

Still, even though a separate message broker is not an obligatory part of a distributed system built with YAMI4, there are several valid reasons to consider such a component:

In order to properly address the above usage scenarios, the message broker needs to implement at least two basic commands:

A message broker that implements the above basic operations allows to set up a data flow from producers (publishers) to subscribers.

In the most trivial case the message broker is fully transparent and passes all incoming messages to all subscribers. This is a perfectly valid way of using the broker, but in a typical system there are well defined rules for message routing, as not all subscribers need to get all data from all publishers. Message brokers differ widely in their supported routing schemes and the YAMI4 broker offers a routing scheme that can be described as multi-way hierarchic tag matching.

Another important feature of the broker is its ability to specify expected behaviour in case of overflow. In a badly dimensioned system publishers can produce new message faster than the subscribers can consume them - clearly it is not possible for the broker to deliver them all, if there is a mismatch between processing speeds on producer and consumer sides. In order to solve this problem the message broker allows to specify the intended behaviour for the case of queue overflow - this is explained in further subsection on configuration parameters.

Last but not least, the YAMI4 message broker was intentionally built with small resource consumption in mind, as this approach allows both lean deployments in constrained environments as well as customized clustered installations.

Further subsections describe message routing scheme in YAMI4 broker, its messaging "API", the strategies for clustered installations and configuration parameters.

7.2.1 Message Routing Based On Tag Matching

7.2.2 Clustered Installations And Forwarding

7.2.3 Publish

7.2.4 Confirmed Publish

7.2.5 Subscribe

7.2.6 Get Statistics

7.2.7 Startup and Configuration