Bidirectional Messaging Queue -
this seems question belonging faq, cannot phrase question find answered.
anyway, investigating message queues (glossed on zeromq, rabbitmq tutorials) , think mqs fit nicely transformational dataflow - listen on q1 messages in format f1, transform f2 , put transformed message on q2. natural question arises of happens if transformation inherently bidirectional , there no defined consumer , producer, e.g. yaml<->json converter?
as far understand message queues inherently unidirectional , bidirectional messaging see 2 "solutions":
- have 2 distinct input output queues, translates 4 in example: json.in, json.out, yaml.in, yaml.out;
- connect converter both ends of json queue, distinguish between raw json , converted yaml, wrap messages in messages specifying whether incoming or outgoing message. consequence, converter gets ton of messages has parse , reinsert queue - sounds hellishly inefficient.
former solution sounds way go, unless latter delegated mq broker in form (e.g. consumer/producer ids: json.out, id = connect_produce("json", null); json.in = connect_consume("json", id);
) , broker figures out not send message consumer if message produced same entity. fas understand kind of filtering boil down message tagging (topic exchange in rabbitmq), requires multiple queues.
so question how done in practice? sticking multiple queues or frameworks implement bidirectional queues? or maybe i'm missing obvious here?
using queues translating message formats seems overkill. sounds hellishly inefficient, if choose message translation way, you're down wrong path , can choose option like, they're bad.
in terms of picking queue design, independently of you're doing it, logically bidirectional queue same 2 one-way queues. go whichever natural queue implementation use.
Comments
Post a Comment