サーバー コンポーネントを使用して、既存のアプリケーション (SQL Server を使用した .NET) を拡張しています。このコンポーネントは 2 つの役割を果たします。バックグラウンド タスク (長時間実行される計算、および cron ジョブのようなタスク) を実行し、ローカル ネットワークで実行されているアプリケーションに API を提供することでアプリケーション サーバーとして機能します。
問題は、アプリケーション サーバー ビットを実装するために (.NET の世界で) どのテクノロジを使用するかということです。要件は次のとおりです。
- 依存関係がほとんどなく、インストールが簡単なはずです。
- サーバーとのすべての通信は、信頼性が高く、暗号化され、サーバーとクライアントが認証されている必要があります。
- スループットは応答時間ほど重要ではありません (1 秒あたり 100 回未満の呼び出し)。各要求は遅滞なく応答する必要があります (TCP 接続を介して SELECT 1 を使用して SQL サーバーにクエリを実行する場合など)。これは、リクエストを送受信するテクノロジーによるオーバーヘッドをできるだけ少なくすることを意味すると思います。
- 多くの呼び出しには重いバイナリ ペイロードがあります (基本的に、クライアントはファイルを要求または送信します。主に 1 ～ 5 MB です)。
- 拡張可能で将来性のあるものであること。
- 将来のある時点で API を「パブリック」にする機能を備えているため、別のサーバー コンポーネントを追加する必要なく (さらにファイアウォールで別のポートを開く必要なく)、サード パーティ アプリケーション (SOA スタイル) で API を使用できます。 ）。
実際、このアプリケーション サーバーの (現時点での) 最大のタスクは、ファイルを提供し、これらのファイルのリビジョンをアップロードできるようにすることです。
私はかなりの時間をネットで調べて、可能なアプローチ/技術の次のリストを思いつきました:
- 上に独自のプロトコルを持つ純粋な TCP。(私の場合、この方法はお決まりの反応です。) 利点: 将来性があり、柔軟性があり、効率的であり、SSL は追加が適度に簡単であり (ここで説明されています)、接続指向 (つまり、アプリケーションの開始時に TCP ソケットを開きます) 、アプリケーションの終了時に閉じる、SSLハンドシェイクと認証は1回のみ実行されます)。欠点: サードパーティが簡単に統合できる標準がなく、原始的な開発モデル。
- ASMX ウェブサービス. 利点: WSDL/Soap に基づく標準インターフェース、SSL の追加が容易、コード生成により煩雑な実装の詳細が隠されます。欠点: 将来性がない、SOAP over HTTP のみ、ファイル転送に非効率 (XML の base64)、ホスティングに IIS が必要 (したがって、インストールが容易ではない)。
- Windows コミュニケーション ファンデーション (WCF)。利点: サポートされている多くのバインディング (そのうちのいくつかは WSDL/Soap のようなオープン スタンダード)、複数のインターフェースを同時に公開する可能性、SSL の追加が容易、コード生成、任意の .NET プロセスでホスト可能 (したがってインストールが容易)、 NetTcpBinding WCF は非常に効率的であるように見えます (ただし、サードパーティはまったく使用できません)。欠点: 学習曲線。
- ASP.NET Web API . 欠点: ホスティングには IIS が必要ですが、REST/HTTP のみが必要です。REST はファイルを提供するのに最適かもしれませんが、他のいくつかの機能にはよりリッチなインターフェイスが必要です。
- .NET リモーティング. WCF に置き換えられました。
これに基づいて、WCF が進むべき道であるかのように見えます。
質問 1:上記のリストには、いくつかの重要なテクノロジ/欠点/利点がありませんか?
質問 2:この分野の専門家は、WCF が上記の要件を達成する方法であることに同意しますか?
質問 3: WCF の効率性について教えてください。このような質問を見ると、接続指向でないことがパフォーマンスの問題にならないのではないかと思います。この投稿では、一定時間非アクティブになった後、応答時間が数百ミリ秒のオーダーに増加する方法について説明しています。さらに、リクエストごとに SSL ハンドシェイクを作成するのは非常に非効率的です。