reliable-msgとの違い
- これ日記なん？ - ap4r と reliable-msgの違い？
さっそくお試しいただきありがとうございます。
...永続化層にreliable-msgを使っているとのことだが、正直reliable-msgとの違いがよくわからない。reliable-msgにもrails supportは含まれてるみたいだし。realiable-msgの上にレイヤーを作ってSOAP, XMLRPCサポートを追加したものなのかな？
ご指摘のとおり、reliable-msgにもRails supportは含まれており、キューやトピックをコントローラ上で簡単に扱えるようになっています。違いをはっきりさせるために、ここで処理Aと処理Bの連携を考えてみます。
1.処理Aを実行
2.キューへ（連携用の）メッセージの書き込み
3.キューからメッセージの取り出し
4.処理Bを実行
3.で誰かがキューからメッセージを取り出し、処理Bを実行する必要があるのですが、このトリガーがreliable-msgにはありません。cron等でたたくことを想定しているようです。
AP4Rではキューから指定されたメッセージを取り出し、Webサーバに再送するスレッドを加えることでこのトリガー部分を提供しています。結果、アプリケーションの開発者はトリガー部分を別途開発/意識する必要がなく、処理AとBを同じように開発できることになります。
Rindaで処理エージェントを複数待機させておいて、処理メッセージをいくつかtupplespaceに放り込むと、それこそえさに群がる池の鯉のように処理エージェントが処理しまくるので見てて楽しいのだけど、Rindaでつなぐとお互いのRubyとdrubyのバージョンをあわせないといけないから、こういうライブラリのほうがいいってことなのかな？
あまりRindaのことをよく分かっていないので間違っているかもしれませんが、、、
メッセージの配送保障がないと、トランザクショナルなデータのやりとりが困難です。AP4Rでは、Exactly once（すべてのメッセージが、必ず 1 回、重複なしに配信されること）を提供していく予定です。
バージョン0.1.0では、まだ十分な実装にはなっていませんが... （＾＾；
また非同期処理の多いシステムでは、メッセージの永続化部分がボトルネックになる可能性があります。Rindaの例だとひとつの池にえさが集中する感じです。鯉を増やせばなんとかなりそうですが、それも池のひろさ（コンピュータリソース？）に限界があります。そこで、池の数を増やしてスケールアウトが可能であれば、適切なえさの量と鯉の数を維持できそうです。AP4Rではこの思想のもと、メッセージをルーティングさせて複数AP4Rプロセス間で協調動作可能なようにもしています。
