[rabbitmq-discuss] method-like calls

[Philippe Kirsanov]

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
To: rabbitmq-discuss
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:

Alexis -

Funny you should ask now.  I've just resumed working on an AMQP
interface
after getting input from our team members and have been doing a lot of
design
work.  Our approach is to write our own code generator that writes code
to
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
methods and
parameters.  The code generator will be able to make code for any
language,
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
technology.
Messages are self-describing and verifiable.  We are leaning towards a
slightly
"heavier" transport that favors abstraction over speed.  I think that if
we have
situations where we need more speed, it will be situations like "we need
to get
4 GB of medical images from here to there", in which case we'll either
open
up a "raw" AMQP channel that does no formatting, or, even faster, open
up
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
and provides
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
design.  The
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
"epiphanies".  There
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
feel free
contact me directly.

Thanks,

- Jim

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>
wrote:

Jim

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.

Best wishes

alexis

RabbitMQ



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?
>
> Thanks,
>
> - 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
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>



_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100107/bf9362d7/attachment.htm