SOA vsクライアントサーバーディスパッチャーvsブローカー
タイトルに記載されている3つのアーキテクチャパターンについていくつか質問があります。そのうちの1つ、特に最初の2つに対する利点を理解するのに少し苦労しています。
だから私はそれぞれがこれまでに理解したことの説明から始めて、それから私は以下に質問をします
サービス指向アーキテクチャー
- クライアント、サービスディレクトリ、および単一のサービスを含みます
- サービスはサービスディレクトリに登録します
- クライアントは、ディレクトリにサービス仕様を提供することでサービスを要求できます。サービスディレクトリは一致するサービスを見つけてクライアントとサービスを接続し、直接通信できるようにします
クライアントサーバーディスパッチャー
ここが私の悩みの始まりです。私が理解しているように、それは基本的にSOAと同じです。サーバーはDispatcherで登録し、クライアントは接続を要求し、Dispatcherはサーバーとクライアントを接続します。
SOAまたは他の方法と比べて、どのような違いと利点がありますか？唯一の違いはコンポーネントの物理的な分布ですか？
ブローカ
このパターンでは、クライアントはブローカーとのみ通信します。クライアントはブローカーにリクエストを送信します。ブローカーは、各要求を処理できるコンポーネントを認識し、その結果をクライアントに返します。これは、分散コンポーネントを備えたシステムでのファサードデザインパターンとほとんど同じように機能すると思います。これはふさわしいアナロジーですか？
これらのパターンを紹介した講義では、ブローカーが単一障害点になる可能性があることを具体的に説明しました。これはSOAのサービスディレクトリでは言及されていませんが、SPoFでもありませんか？ Dispatcherについても同じように考えていましたが、システムに複数のDispatcherが存在する可能性があるとの記述がありました。これはブローカーとサービスディレクトリには当てはまらないのですか、それとも私のUniがこれについて言及し忘れただけですか？
ブローカ
ブローカーパターンは、ここで分離する最も簡単なパターン/アーキテクチャです。ブローカーコンポーネントは、他のコンポーネント間の通信の調整を担当する分散システム内のコンポーネントです。システム全体は、同期（応答を待機する要求）または非同期（後で応答を受信するか、まったく受信しないメッセージ）にすることができます。ブローカーパターンは、ブローカーを使用して通信を調整するシステムです。一般に、これらのタイプのシステムでは、クライアント-サーバーではなく、プロデューサー-コンシューマーという用語を使用しません。ほとんどの場合、これは非同期環境、またはプロデューサー（メッセージを送信するもの）がコンシューマーの署名について何も知らないシステム、またはプロデューサーが多くのコンシューマーにファンアウトする必要がある場合に実装されます。
クライアントサーバーディスパッチャー
クライアントサーバーディスパッチャーパターンには3つの主要コンポーネントがあります。クライアントは要求のソースと考えることができ、サーバーは宛先です。クライアントとサーバーの間には、サーバーにナビゲートする要求のためのチャネルを作成するディスパッチャーがあります。このようにして、サーバーエンドポイントの物理的な場所を抽象化できます。これはほとんど常にリクエストレスポンスモデルであり、これが最も頻繁に実装される理由は、パフォーマンス上の理由で物理エンドポイントを他のエンドポイントにスワップアウトする機能を維持したり、バージョニングやAPIエンドポイントを許可したりするためです。
サービス指向アーキテクチャー
他の2つとは異なり、サービス指向アーキテクチャーはパターンではなく、アーキテクチャーです。大規模なSOA環境には、クライアントサーバーディスパッチャーパターンとブローカーまたはパブサブパターン、あるいはその両方が含まれる可能性があります。SOAでは、サービスは単一のビジネスアクティビティを表すと想定されています。クライアント（サービス署名を除く）は自己完結型ですが、他の基礎となるサービスで構成されている場合があります。
これはもう少し抽象的なので、ユースケースを紹介します。
SOA私が使用する環境では、会社の地理的な位置に基づいて、営業担当者に承認されるクレジットを割り当てるビジネスプロセスがあります。作業を割り当てるワークフロープロセスには、両方の機能があります。会社のセールスマンですが、地理的な場所です。代わりに、完全に別のサーバーにあるenterprise service busがあります。この*サービスバス "は、現在の負荷に基づく同じサービスバス。
このようにして、ワークフローがクライアントであり、リバースプロキシがディスパッチャーであり、最終的なサービスバスがサーバーであるクライアントサーバーディスパッチャーモデルを使用していることになるでしょう。ただし、リクエストが最終的な宛先に到達すると、数百の小さな個々の「アプリケーション」（またはサービス）の1つにルーティングされます。この場合、サービスは会社IDを受け取り、セールスマンを返します。
サービスに到達すると、そのサービスはさまざまなWebサービス（erpシステム、SugarCRMシステムなど）に到達し、セールスマンのユーザー名を返します。クライアントはサービスのロジックについて何も知りませんし、さらにサービスが存在することさえ本当に知りません。この「キー」を使用してこのデータを送信することのみを認識し、応答を取得して、応答の値が何であれ、作業単位を割り当てます。同様に、サービスは、クライアントがこの情報を使用して何をしているか、またはクライアントが存在することさえ知りません。
この点で、非常に疎結合です。クライアントとサービスは、複数のレベルの抽象化によって抽象化されます。このサービスは、クライアントがすぐに応答を期待している（最も遅い応答）か、それともpubサブか何かであるかを気にしません。