[rabbitmq-discuss] method-like calls
pkirsanov at 38studios.com
Thu Jan 7 20:00:46 GMT 2010
We're using protocol buffers to encode/decode packets and use AMQP as
RPC transport with RPC interface specified in protocol buffers.
Also we have REST frontend that translates REST requests into protocol
buffers RPC calls.
From: rabbitmq-discuss-bounces at lists.rabbitmq.com
[mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of vishnu
Sent: Thursday, January 07, 2010 14:53
Subject: Re: [rabbitmq-discuss] method-like calls
if this is not meant to be consumed by the outside world, aren't thrift
or protocol buffers also good options?
On Fri, Jan 8, 2010 at 1:01 AM, Jim Irrer <irrer at umich.edu> wrote:
Funny you should ask now. I've just resumed working on an AMQP
after getting input from our team members and have been doing a lot of
work. Our approach is to write our own code generator that writes code
do the serialization and de-serialization. The interface is specified
as a Java
interface, and then we will be using Java introspection to get the
parameters. The code generator will be able to make code for any
but all I can see happening for the short term is Java and C++.
The transport is in XML. We use XML a lot and are comfortable with the
Messages are self-describing and verifiable. We are leaning towards a
"heavier" transport that favors abstraction over speed. I think that if
situations where we need more speed, it will be situations like "we need
4 GB of medical images from here to there", in which case we'll either
up a "raw" AMQP channel that does no formatting, or, even faster, open
a socket connection.
I had written an initial version of a library to interface to AMQP that
I am mostly
discarding in favor of a re-write that makes implementing servers easier
more flexibility (for example: server classes that support messages
where some must be replied
to and others that are not, direct messages, and fanout messages).
I've got chunks of code written but am still working on the lower level
architecture is pretty much done. Lots more coding to do.
I've thought about this (very fun) problem a lot, and have had a few
is a lot more details I'm not mentioning because there is so much. I
would be happy
to answer any questions or trade ideas.
PS: I don't always examine every rabbitmq-discuss message, so please
contact me directly.
Jim Irrer irrer at umich.edu (734) 647-4409
University of Michigan Hospital Radiation Oncology
519 W. William St. Ann Arbor, MI 48103
On Thu, Jan 7, 2010 at 12:24 PM, Alexis Richardson <alexis at rabbitmq.com>
Please can I ask how you are getting on with this?
I have a potential customer doing a mega project with Smartgrid who is
facing the issues you describe below. They are based in Michigan and
were keen to hear any success stories and meet people locally who
could help them find RabbitMQ development skills.
On Tue, Aug 18, 2009 at 1:57 PM, Jim Irrer <irrer at umich.edu> wrote:
> Hi -
> We are replacing much of our SOAP infrastructure with AMQP, and
> one problem we are looking at is how to wrap an AMQP call so that
> it has a nice programming interface. Basically we want to serialize
> an object on one side and de-serialize on the other side, and do it
> in a language independent way (we use Java C#, and C++).
> I am looking at REST (Representational State Transfer), XML-RPC,
> and possibly JSON-RPC. Ideally we would like something that
> automatically does the serialization/de-serialization or generates
> code that does it.
> Has anyone found a technology that they like?
> - Jim
> Jim Irrer irrer at umich.edu (734) 647-4409
> University of Michigan Hospital Radiation Oncology
> 519 W. William St. Ann Arbor, MI 48103
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss