[zeromq-dev] If not Majordomo for asynchronous workers, then what?

[Paul Colomiets]

Hi Ivan,

On Sat, Jul 28, 2012 at 5:34 PM, Ivan <ivan at blackpx.com> wrote:
>> Modifying MDP and the implementations will be simpler than writing
>> your own from scratch.
>
> Right. I believe what I describe above is the correct modification to the
> Broker. I have to understand the magic by which the broker knows how to route a
> message back to the client. It would be a great addition to MDP if I could call
> a function that, given a message, would break the multipart message for me. This
> way I could hash the route to the client based on some key, in my case, OrderID.
>

There are actually two schools here:

First, proposes to modify the broker, as you described.

Second, requires to decompose the communication into patterns. In your
case it's as follows:

1. You have two connections: requrest/reply, and pub/sub
2. Before doing request, you create and OrderID, and you subscribe on
that OrderID in pub/sub
3. Than you do the request. There is no reply until the whole order is processed
4. The order status updates are sent by pub/sub
5. When everything is done, you receive final reply on request

I usually choose the latter approach, for the following reasons:

1. The solution consists of two clearly defined patterns
2. It leverages zeromq ability to introduce intermediate nodes (as it
uses bare patterns)
3. It allows to run brokerless when setup is small (e.g. for development)
4. It allows to use simple request-reply for clients which do not need
intermediate statuses
5. It allows another peer/application to follow intermediate statuses
(so gives more flexibility to the client)


-- 
Paul