[rabbitmq-discuss] Implementing an RPC backend

Mon Jul 9 16:43:44 BST 2007

Ben

It does help thanks.

A reduced instruction set is seen as essential by the AMQP Working
Group, because not everyone needs to use more than a few base cases.
Watch this space over the next few months for some ideas on that.

ReplyTo is where things are heading as a core enabler for RPC.  I was
in fact curious as to whether you might be trying to replicate some of
what goes on with JMS, since that is a requirement driving some of the
RPC and addressing work in AMQP - we want to get interop right
obviously.

alexis

On 7/9/07, Ben Hood <0x6e6562 at gmail.com> wrote:
> > 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
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

-- 
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)