[rabbitmq-discuss] Implementing an RPC backend

Ben Hood 0x6e6562 at gmail.com
Mon Jul 9 15:07:08 BST 2007


> How are you getting on with RPC?  Along with 'reply to', it's a hot
> topic for the AMQP 0-10 spec, so your thoughts on this would be very
> useful.  What use cases do you think are interesting here?

I've got a complete RPC end to end working using Hessian as a
serialization mechanism. The client is the RpcClient taking a hessian
encoded byte array to the primitiveCall method. On the server side
what I did was to adapt the rabbit_management module to implement my
own gen_server module. The server is started by an OTP supervisor
(I've created an OTP app using rabbit as dependency) and the module
just contains the bare bones gen_server behaviour callbacks as well as
the business logic. I refactored the exchange initialization, message
parsing, hessian decoding, function invocation, reply encoding and
sending to an external rpc utility module for more generic reuse (for
example if I want to have other servers that implement different
business logic).

As for the spec, I think that using the replyTo field as a routing key
is quite inituitive, so for my part, I think that rabbit's behaviour
is the correct one in this case. I don't know if I can think of any
funky use cases, because what I am currently doing in this use case is
plain old RPC, with the benefit that it's executed asynchronously. If
I understand you correctly, whether or not the RPC mechanism should be
more explicity defined in the spec is a matter of convenience on the
client side, IMHO. When it comes to spec design, I think it's a matter
of opinion as to whether you have a reduced instruction set or not. I
would opt for a reduced instruction set to keep the spec as small as
possible, ease uptake, ease version upgrades and to keep the server
side implementations as simple as possible.

HTH,

Ben




More information about the rabbitmq-discuss mailing list