This article is meant to give the reader an overview of the whole system . Specifically, we show the global architecture, it's building blocks (such as the Messaging Model), the modules we will be developing and the tools/framework we will use.
Our system is composed mainly of a two parts: a client and a "server"(or the actual middleware) as depicted by the following picture:
The client is used by enterprise applications to communicate with the middleware. The communication is done using Moza protocol which is part of the project. By that, I mean we will be designing this protocol for our specific usage. More on this later.
The middleware is the central component of the system. Its main role is to deliver received messages to there appropriate destination. However, the delivery process isn't unique: for example, the producer of the messages may want to send it to many consumers, or it may want it to be delivered to a specific consumer or even it may only care that the message get delivered to someone ignoring who may it be. The stated scenario bring up the problem of specifying a policy of message distribution: By which mean users will express their intent and choose their desired setup?
This issue is addressed by designing a coherent messaging model that captures the many aspects involved in the process of message delivery. To be more precise, using elements of the model, we can communicate to the middleware the way we are going to layout/organize message exchanges between the different applications in need for integration.
As we have seen, The messaging model plays an essential role in our system. The middleware need to be aware of the topology that the user designed for message circulation in order to do it's job. So beforehand, the user has to configure the instance of the server according to his problem. Part III speaks about this in more details.
Wither to send a message or to configure the middleware, we need a way to inform the addressed system. For this project, I decided to design a protocol specifically for these tasks(the configuration and the message delivery). It specifies the format, the rules of communication and the PDUs involved in this process. We will have an in-depth look into Moza in Part IV of this series.
During the analysis phase, I identified 4 modules:
a network module : responsible for network communication as it names suggest. We will use a framework for this rather then implementing our own solution.
an identity module : it manages the notion of identity used across all part of the code base.
a core module: this is where our messaging model lives. This is central to the MOM.
Moza module : here we implement our protocol.
Each module is covered in one of the next posts.
The Middleware is implemented using C++17. As for the compiler, I used gcc 8.1. In Addition to that, I used CMake along with conan for package management.
Relying on Seastar for the networking part was a huge boost for me: I learned a couple of new concepts and discovered an elegant code base. This is from an educational perspective. Another important point is the performance gained from using this piece of technology. Having said that, I couldn't take full advantage of it even though I had my idea on how I will do it. I was running out of time so I preferred to keep things simple, and improve things after I pass my end-year project. In the next post of the series, I will give a proper introduction to this framework.
When I started working on the project, I thought I will be implementing the protocol, for the client, and distribute libraries. However, due to time constrains, I fall back to a CLI that can configure the middleware and can simulate consumer and producer. Maybe in The future I will go with implementing libraries and documents the process but for now we have what we have: A CLI implemented with nodejs.
In the next part, we will start setting up the project and get to the concrete stuff.