Skip to main content


Showing posts from May 24, 2020

Message Broker

When we are building systems with multiple components, we need a way to communicate between components. One failed attempt will be direct communication between components. In this solution, components are higly depending on each other. A better solution will be to use a centralized middleman. All necessary components register with middleman. Middleman recieve all the requests where it find corresponding service to send it. A broker can: Register, unregister services. Locate services. Recieve and send messages. Error handling. Products There are many broker systems available. These are just few of them. Apache ActiveMQ, Apache Kafka, RabbitMQ, Websphere ESB, JBoss ESB, Amazon MQ Advantages Loose coupling between components. Scalable and maintainable as long as the interface remain the same. Components are reusable. Disadvantages Introduce single point of failure. Degrade performance due to additional routing.

Pipes and Filters Architecture

In Linux, when we want to combine results of varies commands to filer out our desired result we use pipe. We feed output of one program as the input of the next. This is fine example of Pipes and Filters pattern. $ ps aux | grep java Pipes and filters is a very helpful architectural design pattern for stream of data. Also, it is helpfull when there are data transformations through the sequence. Source code for the example application . It consists of number of components called Filters that transform data before handing over to next Filter via connectros called Pipes. Filter - transforms or filters data it receives via the pipe. Pipe - is the connector that passes data from and to filters. Pump - is the data producer. Sink - is the end consumer of the target data. A pipeline consists of a chain of processing elements, arranged so that the output of each element is the input of the next (Wikipedia). Filter can be a small class as well as a big component. Input, output can be decided by