From cf867f2906ad907caeedb8cf8f2b957a98b3ed66 Mon Sep 17 00:00:00 2001 From: Teyras Date: Thu, 19 Jan 2017 23:56:04 +0100 Subject: [PATCH] better MQ analysis --- Rewritten-docs.md | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/Rewritten-docs.md b/Rewritten-docs.md index 81a37a6..e0ec113 100644 --- a/Rewritten-docs.md +++ b/Rewritten-docs.md @@ -902,10 +902,11 @@ following options are considered: remote procedure calls. 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 a large number of languages and large community. Also, it is - capable of routing requests, which could be handy feature for job - load-balancing. +- RabbitMQ -- RabbitMQ is a messaging framework written in Erlang. It features a + message broker, to which nodes connect and declare the message queues they + work with. It is also capable of routing requests, which could be a useful + feature for job load-balancing. Bindings exist for a large number of languages + and there is a large community supporting the project. - ZeroMQ -- ZeroMQ is another messaging framework, which is different from RabbitMQ and others (such as ActiveMQ) because it features a "brokerless design". This means there is no need to launch a message broker service to @@ -917,12 +918,20 @@ following options are considered: CORBA is a large framework that would satisfy all our needs, but we are aiming towards a more loosely-coupled system, and asynchronous messaging seems better -for this approach than RPC. RabbitMQ seems nice with great advantage of routing -capability, but it is a 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, even -with the drawback of having to implement a load balancer ourselves (which could -also be seen as a benefit). However, all of the three options would have been -possible to use. +for this approach than RPC. Moreover, we rarely need to receive replies to our +requests immediately. + +RabbitMQ seems well suited for many use cases, but implementing a job routing +mechanism between heterogenous workers would be complicated -- we would probably +have to create a separate load balancing service, which cancels the advantage of +a message broker already being provided by the framework. It is also written in +Erlang, which nobody from our team understands. + +ZeroMQ is the best option for us, even with the drawback of having to implement +a load balancer ourselves (which could also be seen as a benefit and there is a +notable chance we would have to do the same with RabbitMQ). It also gives us +complete control over the transmitted messages and communication patterns. +However, all of the three options would have been possible to use. ### Frontend - backend communication