|
|
@ -781,19 +781,6 @@ approaches are equally good, final decision depends on actual case.
|
|
|
|
|
|
|
|
|
|
|
|
## Structure of the project
|
|
|
|
## Structure of the project
|
|
|
|
|
|
|
|
|
|
|
|
There are numerous ways how to divide some sort of system into separated
|
|
|
|
|
|
|
|
services, from one single component to many and many single-purpose components.
|
|
|
|
|
|
|
|
Having only one big service is not feasible, not scalable enough and mainly it
|
|
|
|
|
|
|
|
would be one big blob of code which somehow works and is very complex, so this
|
|
|
|
|
|
|
|
is not the way. The quite opposite, having a lot of single-purpose components is
|
|
|
|
|
|
|
|
also somehow impractical. It is scalable by default and all services would have
|
|
|
|
|
|
|
|
quite simple code but on the other hand communication requirements for such
|
|
|
|
|
|
|
|
solution would be insane. So there has to be chosen approach which is somehow in
|
|
|
|
|
|
|
|
the middle, that means services have to communicate in manner which will not
|
|
|
|
|
|
|
|
bring network down, code basis should be reasonable and the whole system has to
|
|
|
|
|
|
|
|
be scalable enough. With this being said there can be discussion over particular
|
|
|
|
|
|
|
|
division for ReCodEx system.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The ReCodEx project is divided into two logical parts – the *backend* and the
|
|
|
|
The ReCodEx project is divided into two logical parts – the *backend* and the
|
|
|
|
*frontend* – which interact which each other and which cover the whole area of
|
|
|
|
*frontend* – which interact which each other and which cover the whole area of
|
|
|
|
code examination. Both of these logical parts are independent of each other in
|
|
|
|
code examination. Both of these logical parts are independent of each other in
|
|
|
@ -817,8 +804,8 @@ progress of processing of the queued jobs and the results of the evaluations can
|
|
|
|
be queried after the job processing is finished. The backend produces a log of
|
|
|
|
be queried after the job processing is finished. The backend produces a log of
|
|
|
|
the evaluation and scores the solution based on the job configuration document.
|
|
|
|
the evaluation and scores the solution based on the job configuration document.
|
|
|
|
|
|
|
|
|
|
|
|
From the scalable point of view there are two necessary components, the one
|
|
|
|
To make the backend scalable, there are two necessary components -- the one
|
|
|
|
which will execute jobs and component which will distribute jobs to the
|
|
|
|
which will execute jobs and the other which will distribute jobs to the
|
|
|
|
instances of the first one. This ensures scalability in manner of parallel
|
|
|
|
instances of the first one. This ensures scalability in manner of parallel
|
|
|
|
execution of numerous jobs which is exactly what is needed. Implementation of
|
|
|
|
execution of numerous jobs which is exactly what is needed. Implementation of
|
|
|
|
these services are called **broker** and **worker**, first one handles
|
|
|
|
these services are called **broker** and **worker**, first one handles
|
|
|
@ -885,20 +872,15 @@ protocol between these two logical parts will be described as well.
|
|
|
|
|
|
|
|
|
|
|
|
## Implementation analysis
|
|
|
|
## Implementation analysis
|
|
|
|
|
|
|
|
|
|
|
|
When developing a project like ReCodEx there has to be some discussion over
|
|
|
|
Some of the most important implementation problems or interesting observations
|
|
|
|
implementation details and how to solve some particular problems properly. This
|
|
|
|
will be discussed in this chapter.
|
|
|
|
discussion is a never ending story which goes on through the whole development
|
|
|
|
|
|
|
|
process. Some of the most important implementation problems or interesting
|
|
|
|
|
|
|
|
observations will be discussed in this chapter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### General communication
|
|
|
|
### General communication
|
|
|
|
|
|
|
|
|
|
|
|
Overall design of the project is discussed above. There are bunch of components
|
|
|
|
Overall design of the project is discussed above. There are bunch of components
|
|
|
|
with their own responsibility. Important thing to design is communication of
|
|
|
|
with their own responsibility. Important thing to design is communication of
|
|
|
|
these components. All we can count with is that they are connected by network.
|
|
|
|
these components. To choose a suitable protocol, there are some additional
|
|
|
|
|
|
|
|
requirements that should be met:
|
|
|
|
To choose a suitable protocol, there are some additional requirements that
|
|
|
|
|
|
|
|
should be met:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- reliability -- if a message is sent between components, the protocol has to
|
|
|
|
- reliability -- if a message is sent between components, the protocol has to
|
|
|
|
ensure that it is received by target component
|
|
|
|
ensure that it is received by target component
|
|
|
|