[rabbitmq-discuss] Return message? [Was: Re: Sample code for python?]

Mon Jul 6 16:54:15 BST 2009

> > In our case, the back-end machines will be .net or possibly Java.  The front 
> end web-UI will be python. (Likely TurboGears 2)
> > 
> > As it stands now, the front end machines will be calling specific functions on 
> the back-end boxes via a basic HTTP/XML API.  For instance:  "Place order for 
> customer X"
> > 
> > The back-end machines do whatever processing they need and reply with a result 
> code.  (Success, No Stock Left, System Busy, etc.)
> > 
> > My idea was to use RabbitMQ for the request transport instread of HTTP.  Is 
> this a resonaable idea? Can/Should RabbitMQ be used in this sort of environment?
> 
> 
> In this case I have been writing the tool that you might need:
> 
> http://bitbucket.org/adroll/quebert/overview/
> 
> This is also written in Python but doesn't require Python anywhere else
> and deployment is easy.
> 
> Most of the things I wrote in an old email to this list are still true:
> http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-June/004273.html
> 
> Although the API changed a bit for the better.
> 
> Essentially just using a mediator like this:
> http://bitbucket.org/adroll/quebert/src/tip/examples/med.py
> 
> and starting it using (just one example):
> twistd --pidfile=/var/run/quebert.pid --logfile=/var/log/quebert.log quebert 
> --config=med.main --with_syslog_prefix=quebert
> Would give you a system that for any message that gets in routes it to any
> available HTTP server that knows how to process it (and you can do this
> through a load balancer or directly sending the message).
> 
> The actual example code can be used as a configuration file without
> changing it.
> 
> You can then easily add more features through hooks or on the point
> of execution. I've essentially designed the system to answer your very
> same concerns :).
> 

I am not at all familiar with the twisted system, but does this mean that RabbitMQ/AMQP does not, on it's own, provide any method for a message sender to ascertain the success or failure of a task embodied by a message?

That is to say: The backed system (job receiver) has no way of signaling to the front-end (job-sender) any details about the job the front-end is waiting on?

Is this true?