[rabbitmq-discuss] Implementing an RPC backend

[Ben Hood]

> 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