Reliable Messaging in Ruby with AP4R

Shun'ichi Shinohara and Kiwamu Kato have been  working on bringing reliable messging to Ruby with their own API & protocol project, based on previous experiences designing a Java-based high volume messaging framework.   AP4R, Asynchronous Processing for Ruby, is an implementation of reliable asynchronous message processing, providing message queuing and message dispatching.  Shun'ichi and Kiwamu gave a presentation at RubyKaigi 2007(pdf slides) about their API emphasizing it's key design philosophies: Robustness and Lightweight.

The project is just a year old, and already supports:

1. Business logic can be implemented as simple Web apps or ruby code, whether it's called asynchronously or synchronously.
   
2. RBMS (MySQL) or file-based message persistance
   
3. Load balancing over multiple AP4R processes on single/multiple server(s) is supported.
   
4. Multiple protocol support: XML-RPC, SOAP, HTTP POST, and more.

Shun'ichi and Kiwamu had previously implemented their own Java-based API and protocol (called RtFA), which was used in a large app with 100 servers processing over 100 million messages a day. Shun'ichi and Kiwamu claim to have improved upon their previous work with AP4R, while also focusing on on the ease of use. AP4R comes with a comprehensive documentation.

Integrated into rails, a typical process flow for using AP4R is:

1. A client(e.g. a web browser) makes a request to a web server (Apache, Lighttpd, etc...).
   
2. A rails application is synchronously executed on mongrel via mod_proxy or something.
   
3. Rails app sends a message via AP4R APIs and can then immediatley respond to the client.
   
4. AP4R queues the message and requests it to the web server asynchronously.
   
5. The asynchronous business logic, implemented as usual rails action, is executed.
   

The focus for 0.3.x was Daemonization, URL-rewrite filter, DLQ / SAF recovery, and support for Stomp and HTTP has underlying protocols. Future versions will include support for Monitoring & management (e.g. thread status, web frontend), Coordination with Cacti, Nagios, etc, multi-process, Dynamic configurability, Automatic recovery, Blocking queues, and more.