メッセージキューとWebサービス
Webサービスではなく、メッセージキューを介して通信するアプリを好む条件は何ですか（ここでは、特定のタイプではなく、XML、JSON、YAML、またはHTTP経由のものを意味します）。
ローカルネットワーク上の2つのアプリ間で話し合う必要があります。 1つはWebアプリであり、別のアプリでコマンドを要求する必要があります（異なるハードウェアで実行）。リクエストは、ユーザーの作成、ファイルの移動、ディレクトリの作成などです。どのような条件下で、メッセージキューを使用するよりもXML Webサービス（またはストレートTCPなど）を好むでしょうか。
WebアプリはRuby on Railsですが、質問はそれよりも幅広いと思います。
Webサービスを使用する場合、クライアントとサーバーがあります。
- サーバーに障害が発生した場合、クライアントはエラーを処理する責任があります。
- サーバーが再び動作しているとき、クライアントはそれを再送する責任があります。
- サーバーが呼び出しに応答し、クライアントが失敗すると、操作は失われます。
- 競合はありません。つまり、数百万のクライアントが1秒間に1つのサーバーでWebサービスを呼び出すと、おそらくサーバーがダウンします。
- サーバーからの即時応答を期待できますが、非同期呼び出しも処理できます。
RabbitMQ、Beanstalkd、ActiveMQ、IBM MQ Series、Tuxedoなどのメッセージキューを使用する場合、異なる耐障害性のある結果が期待されます。
- サーバーに障害が発生した場合、キューはメッセージを保持します（オプションで、マシンがシャットダウンした場合でも）。
- サーバーが再び動作している場合、サーバーは保留中のメッセージを受信します。
- サーバーが呼び出しに応答し、クライアントが失敗した場合、クライアントが応答を確認しなかった場合、メッセージは保持されます。
- 競合があり、サーバーが処理するリクエストの数を決定できます（代わりにワーカーと呼びます）。
- 即時の同期応答は期待していませんが、同期呼び出しを実装/シミュレートできます。
メッセージキューにはさらに多くの機能がありますが、これは、エラー状態を自分で処理するか、メッセージキューに残すかを決める経験則です。
REST HTTP呼び出しがメッセージキューの概念をどのように置き換えることができるかを検討する上で、かなりの量の最近の研究がありました。
リソースとしてプロセスとタスクの概念を導入すると、中間メッセージングレイヤーの必要性はなくなり始めます。
例：
POST /task/name
- Returns a 202 accepted status immediately
- Returns a resource url for the created task: /task/name/X
- Returns a resource url for the started process: /process/Y
GET /process/Y
- Returns status of ongoing process
タスクには初期化のための複数のステップがあり、プロセスはポーリング時にステータスを返すか、完了時にコールバックURLにPOSTを返すことができます。
これは非常に簡単で、実行中のすべてのプロセスとタスクのrss/atomフィードを中間層なしでサブスクライブできることに気付いたときに非常に強力になります。いずれにせよ、キューイングシステムには何らかのWebフロントエンドが必要であり、この概念にはカスタムコードの別のレイヤーなしで組み込まれています。
リソースは削除するまで存在します。つまり、プロセスとタスクが完了してからずっと後に履歴情報を表示できます。
複雑なプロトコルを追加することなく、複数のステップがあるタスクでも、サービスディスカバリを組み込みました。
GET /task/name
- returns form with required fields
POST (URL provided form's "action" attribute)
あなたのサービス発見は、HTML形式であり、人間が読める普遍的な形式です。
フロー全体は、一般的に受け入れられているツールを使用して、プログラムまたは人間が使用できます。クライアント駆動型であるため、RESTfulです。 Web用に作成されたすべてのツールは、ビジネスプロセスを推進できます。ログサーバーの個別の配列に非同期でPOSTを実行することにより、代替メッセージチャネルを引き続き使用できます。
しばらく検討してから、RESTがメッセージングキューとESBの必要性を完全になくすかもしれないことに気付き始めます。
メッセージキューは、処理に時間がかかる可能性がある要求に最適です。要求はキューに入れられ、クライアントをブロックせずにオフラインで処理できます。クライアントに完了を通知する必要がある場合は、クライアントがリクエストのステータスを定期的にチェックする方法を提供できます。
メッセージキューを使用すると、時間をかけてより適切にスケーリングすることもできます。実際の処理は時間をかけて分散できるため、大量のアクティビティのバーストを処理する能力が向上します。
メッセージキューとWebサービスは直交する概念であり、相互に排他的ではないことに注意してください。例えば。メッセージキューへのインターフェイスとして機能するXMLベースのWebサービスを使用できます。探している違いはメッセージキューとリクエスト/レスポンスの違いだと思います。後者はリクエストが同期的に処理される場合です。
メッセージキューは非同期であり、配信が失敗した場合は何度も再試行できます。リクエスターが応答を待つ必要がない場合は、メッセージキューを使用します。
「Webサービス」というフレーズは、HTTPを介した分散コンポーネントへの同期呼び出しを考えさせます。要求者が応答を返す必要がある場合は、Webサービスを使用します。
一般的に、ブロッキングタスクのWebサービス（コードを実行する前にこのタスクを完了する必要があります）と、非ブロッキングタスクのメッセージキュー（かなり時間がかかる可能性がありますが、それを待つ必要はありません）。