Message Queue対Webサービス？[閉まっている]

どのような状況で、ウェブサービスではなくメッセージキューを介して話すアプリを好むでしょうか（ここでは、XML、JSON、YAML、またはHTTPを介したもので、特定のタイプではありません）。

ローカルネットワーク上の2つのアプリ間で会話する必要があります。1つはWebアプリであり、別のアプリ（異なるハードウェアで実行）でコマンドを要求する必要があります。リクエストには、ユーザーの作成、ファイルの移動、ディレクトリの作成などがあります。メッセージキューを使用するよりも、どのような状況でXML Webサービス（または単純なTCPなど）を使用しますか？

WebアプリはRuby on Railsですが、問題はそれよりも広いと思います。

Webサービスを使用すると、クライアントとサーバーがあります。

1. サーバーに障害が発生した場合、クライアントは責任を持ってエラーを処理する必要があります。
2. サーバーが再び動作しているとき、クライアントはサーバーを再送信する責任があります。
3. サーバーが呼び出しに応答し、クライアントが失敗した場合、操作は失われます。
4. 競合はありません。つまり、数百万のクライアントが1つのサーバーのWebサービスを1秒間に呼び出すと、おそらくサーバーがダウンします。
5. サーバーからの即時応答を期待できますが、非同期呼び出しも処理できます。

RabbitMQ、Beanstalkd、ActiveMQ、IBM MQシリーズ、Tuxedoなどのメッセージキューを使用すると、さまざまなフォールトトレラントな結果が期待できます。

1. サーバーに障害が発生した場合、キューはメッセージを保持します（オプションで、マシンがシャットダウンした場合でも）。
2. サーバーが再び稼働すると、保留中のメッセージを受信します。
3. サーバーが呼び出しに応答し、クライアントが失敗した場合、クライアントが応答を確認しなかった場合、メッセージは保持されます。
4. 競合が発生し、サーバーが処理するリクエストの数を決定できます（代わりにワーカーと呼びます）。
5. 即時の同期応答を期待していませんが、同期呼び出しを実装/シミュレートできます。

メッセージキューにはさらに多くの機能がありますが、これは、エラー条件を自分で処理するか、メッセージキューに任せるかを決定するための経験則です。

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の必要性を完全に排除できることを理解し始めます。

http://www.infoq.com/presentations/BPM-with-REST

メッセージキューは、処理に時間がかかる可能性のあるリクエストに最適です。リクエストはキューに入れられ、クライアントをブロックせずにオフラインで処理できます。クライアントに完了を通知する必要がある場合は、クライアントがリクエストのステータスを定期的に確認する方法を提供できます。

メッセージキューを使用すると、時間をかけてより適切にスケーリングすることもできます。実際の処理を時間全体に分散できるため、重いアクティビティのバーストを処理する能力が向上します。

メッセージキューとWebサービスは直交する概念です。つまり、相互に排他的ではありません。たとえば、メッセージキューへのインターフェイスとして機能するXMLベースのWebサービスを使用できます。あなたが探している違いは、メッセージキューと要求/応答です。後者は、要求が同期的に処理されるときです。

メッセージキューは非同期であり、配信が失敗した場合は何度も再試行できます。リクエスタが応答を待つ必要がない場合は、メッセージキューを使用します。

「Webサービス」というフレーズは、HTTPを介した分散コンポーネントへの同期呼び出しを思い起こさせます。要求者が応答を返す必要がある場合は、Webサービスを使用します。

一般的に、ブロッキングタスク用のWebサービス（コードを実行する前にこのタスクを完了する必要があります）と非ブロッキングタスク用のメッセージキュー（かなり時間がかかる可能性がありますが、それを待つ必要はありません）。