Backend communication

Rewritten-docs.md

@@ -714,9 +714,40 @@ interesting observations will be discussed in this chapter.
 
 ### General communication
 
-@todo: what type of communication within backend could be used, mention some
+Overall design of the project is discussed above. There are bunch of components
-frameworks, queue managers, protocols, which was considered - why we don't use
+with their own responsibility. Important thing to design is communication of
-CORBA, RabbitMQ and why is ZeroMQ great
+these components. All we can count with is that they are connected by network.
+
+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
+  ensure that it is received by target component
+- working over IP protocol
+- multi-platform and multi-language usage
+
+TCP/IP protocol meets these conditions, however it is quite low level and
+working with it usually requires working with platform dependent non-object API.
+Often way to reflect these reproaches is to use some framework which provides
+better abstraction and more suitable API. We decided to go this way, so the
+following options are considered:
+
+- CORBA -- Corba is a well known framework for remote object invocation. There
+  are multiple implementations for almost every known programming language. It
+  fits nicely into object oriented programming environment.
+- RabbitMQ -- RabbitMQ is a messaging framework written in Erlang. It has
+  bindings to huge number of languages and large community. Also, it is capable
+  of routing requests, which could be handy feature for job loadbalancing.
+- ZeroMQ -- ZeroMQ is another messaging framework, but instead of creating
+  separate service this is a small library which can be embedded into own
+  projects. It is written in C++ with huge number of bindings. 
+
+We like CORBA, but our system should be more loosely-coupled, so (asynchronous)
+messaging is better approach in our minds. RabbitMQ seems nice with great
+advantage of routing capability, but it is quite heavy service written in
+language no one from the team knows, so we do not like it much. ZeroMQ is the
+best option for us. However, all of the three options would have been possible
+to use.
 
 Frontend communication follows the choice, that ReCodEx should be primary a web
 application. The communication protocol has to reflect client-server