The project is just a year old, and already supports:
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.
- Business logic can be implemented as simple Web apps or ruby code, whether it's called asynchronously or synchronously.
- RBMS (MySQL) or file-based message persistance
- Load balancing over multiple AP4R processes on single/multiple server(s) is supported.
- Multiple protocol support: XML-RPC, SOAP, HTTP POST, and more.
Integrated into rails, a typical process flow for using AP4R is:
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.
- A client(e.g. a web browser) makes a request to a web server (Apache, Lighttpd, etc...).
- A rails application is synchronously executed on mongrel via mod_proxy or something.
- Rails app sends a message via AP4R APIs and can then immediatley respond to the client.
- AP4R queues the message and requests it to the web server asynchronously.
- The asynchronous business logic, implemented as usual rails action, is executed.