>> It sounds like you may be suggesting that I'd have a more abstract
>> message queue in between the clients and workers and perhaps use some
>> detail of the application layer to dispatch the messages instead of
>> having a "direct" link between client and service provider?
>>
>> (I realize I'm probably overloading/misusing some terms so feel free
>> to correct me if it helps get on the same page)
>
> No, you are right. We were just speaking about different scenarios.
>
> You were speaking of the use case where client connect directly to the
> services while I had the case where there's a node (shared queue) in the
> middle.

Does either model offer any significant advantages over the other in
terms of using 0MQ as a RPC transport layer? I have seen RPC
implemented over direct socket connections and also implemented in
terms of a shared queue on top of an enterprise-y MQ product.

I see 0MQ as falling somewhere in between those two paradigms I'd be
interested to hear thoughts on pros/cons of either model.  Would a
general purpose RPC service container be advised to support both?
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to