[zeromq-dev] RPC design pattern

Joe Holloway jholloway7 at gmail.com
Thu Apr 29 19:57:19 CEST 2010


>> I think both could be desirable depending on what use cases you are
>> considering.  I am coming at it from the perspective of having a
>> "fluid service bus".  Let's say I have one node that is pushing
>> capacity and I need to bring another node online that offers the same
>> services to help out.  With a dynamic registration (e.g. DNS-SD),
>> clients could discover the new node and begin to load balance
>> immediately (again in a gentlemanly fashion).  Whereas, with a static
>> DNS model you are at the mercy of TTLs  and having the tools to
>> publish, which may be just fine for certain applications.
> Hm. I would assume that "worker" applications would connect rather than
> bind and thus won't need to register their addresses, no?

Well, perhaps I have been reading too much into the RPC cookbook
examples, but this is my current understanding...

To me, the "service provider" is what binds and once the client has
resolved that endpoint (either statically or dynamically) it would
send messages directly to the service provider.  If the service
provider has "workers" (that connect), that would be an implementation
detail hidden from view of the clients.

In the configuration I have in my mind, it's less of a problem for
such workers to discover that binding because I'd most likely
co-locate them in the same node/process as the service provider (bind)
and be able to infer/assume an ipc/inproc endpoint for them.

But if the workers are remote to the service provider, then that could
make it more difficult to infer the binding so you could have the same
discovery problem on that end as a client would have.

For a concrete RPC use case, let's say I have a Catalog service and an
Order service.  I have a client application that needs to query the
catalog and place orders in real time, maybe to support a call center
or something.  I want to be able to deploy the Catalog service and the
Order service independently of one another.  I also want them to be
fault tolerant such that I can distribute the services across physical
nodes.  Taking down one node that offers the Catalog service
shouldn't, in theory, affect the service level of the Catalog service
when I have other nodes offering it.

When I "bring up" a node offering either service, I would like the
client application to eventually learn of its availability and be able
to use it.  Maybe the client load balances, maybe it just looks for a
new service provider when it has lost its current one (perhaps it
timed out or stopped responding to a heartbeat message or something).

So back to my conceptual understanding, I could bind the Catalog
service on a couple of nodes and the Order service on a couple of
nodes.  My client application would query some registry for the
current endpoint(s) of the Catalog service and Order service.

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)


More information about the zeromq-dev mailing list