サービス指向アーキテクチャーのゲートウェイサービス

Question

私は、自分のシングルエントリーポイント「ゲートウェイ」を実装して2つのことをするアイデアに夢中になります。

最初に、SOAサーバーによって処理された要求の数を記録し、次の要求を最も利用可能なサーバーに循環させます。ロード・バランシング・ロジックに対する完全な制御が魅力的です。

第2に、この「ゲートウェイ」はセキュリティを含むすべてのサービスに対する単一の連絡先になります。クライアントがユーザー名とパスワードの組み合わせを送信すると、セキュリティサービスに渡され、成功した認証でトークンが付与されます。クライアントがトークンを送信すると、ゲートウェイはセキュリティ・サービスによってこのトークンを実行し、コーシャーの場合はその要求をビジネス・サービスの1つに渡します。ゲートウェイ以外のすべてのサービスを隠すかカプセル化することが望ましいと思われます。

私の質問は次のとおりです。「これは正しい方法ではない」という理由はありますか？私が上記のことをしているフレームワークがすでに存在する時に、私はその輪を改革していますか？私のスタックは.NETとWCFです。

Answer 1

良い質問ですが、sweetfaのコメントに同意する必要があります.99％のケースでは、既製のロードバランサが最適なオプションになります。オプションのより完全なリスト：

1. ハードウェアロードバランサ/ゲートウェイ（たとえば、IBM XMLゲートウェイ） - 非常にスケーラブルかつ高価
2. は、サービス・バスのソフトウェア（例えばOracle Service Busは）として、セキュリティとロードバランシングを行いますよく構成可能で高価です。ハードウェアソリューションよりスケーラビリティが低い
3. オープンソースのロードバランサソフトウェア（Apache HTTPDプロキシモジュールなど）には、フォーラムを介してセットアップする際に役立つ多数のユーザーがいます。ソリューションの多くはかなりスケーラブルで堅牢ですが、オプション1と2よりも複雑な設定方法があります。サービスリクエスターがすべての呼び出しでプロバイダURIを参照すると、サービスレジストリ（UDDI v3）に基づいたロードバランシング
4. 。レジストリは、異なるURIを返すことによって要求の負荷を分散します。このソリューションはセキュリティゲートウェイとしては機能せず、コンシューマはアドバンスドな適応型ロードバランシングアルゴリズムが必要な場合、または非標準のセキュリティレイヤーが必要な場合は、自分でビルドすることができます。
5. 非標準のセキュリティを忘れてしまいましょう。それはまれなことですが、適応型ロードバランシングが望ましい場合があります。オプション1〜3は、応答時間に基づいてラウンドロビンまたは重み付きラウンドロビンまたは適応ラウンドロビンを行い、応答しないインスタンスを検出します。オプション1と3は、HTTPセッションのスティッキー性も実装するのが難しいが、SOAPやRESTサービスには必要ない。