How it Works
Since the project consists of building two practical implementations and the technologies to be used force the development of slightly different solutions, it was first necessary to develop a Platform Independent Model that would portray, in a generic way, the core components and services offered by the business logic.
(Click for larger view) The model can be divided into 5 distinct parts for better understanding:
-
Consensus Module: These are the classes represented in yellow, which have the function of managing the state of the algorithm, transitioning states if necessary, responding to requests from clients or other servers in the cluster, and also invoking requests to those servers. Besides that, it also manages the persisted state in the database.
-
Persistent state: These are the classes represented in bourbon, which define the access layer to persistent data that the algorithm needs to query, update and delete.
-
Communication: These are the classes represented in shades of green. These classes can be further divided into 3 parts, which are respectively, inbound communication, outbound communication, and the messages to be passed between servers. Inbound communication defines and manages the reception of data coming from other servers and delivers them properly to the consensus module. Outbound communication is responsible for managing the sending of messages to other servers, depending on the chosen strategy. Finally, the types of messages to be exchanged between servers define the content of each communication.
-
State Machine: These are the classes represented in salmon red, which have the function of notifying the objects responsible for applying the commands of the committed log entries to the state machine, when a new entry is committed. They also have the function of applying those same commands to the state machine depending on the strategy to be used.
-
Workers: These are the classes represented in blue that have different functions (i.e. they can be timers, they can be communication managers, etc), but they are the entities that ensure the good functioning of the algorithm. They are the "living" entities that execute functions.
This model was built taking into account some design patterns (i.e. State, Strategy and Observer), with the goal of making the solution as modular and generic as possible, decoupling some classes and behavior.
In the servlet architecture, there is the possibility to manage threads through Thread Pools, which is highly desirable for the implementation of the models proposed earlier, in this particular architecture.
(Click for larger view) The implemented solution is represented in the figure above, where the rounded blue rectangles represent the existing threads at each moment in the application, which in turn are managed by the Thread Pools represented by the orange rectangles. The Spring Threads and the MainPool are the only instances of the model that are managed directly by the framework.
Most of these Threads have to access the consensus module to execute some operation, so this module must be Thread-safe.