.NET での通信オプションの選択
.NET Framework には、異なるアプリケーション ドメインにあるオブジェクトと通信する方法が何種類か用意されています。これらの方法は、専門的知識や柔軟性のさまざまなレベルに合わせてデザインされています。たとえば、インターネットの発達に伴って XML Web サービスが通信方法として注目されてきていますが、これは XML Web サービスが HTTP プロトコルや XML を使用する SOAP フォーマットなど、共通のインフラストラクチャの上に構築されているからです。これらは公的な標準規格なので、プロキシやファイアウォールの問題を考慮しなくても、現在の Web インフラストラクチャですぐに利用できます。
多くのアプリケーションが、ASP.NET を使用して作成された Web サービスではサポートされていない機能を必要とします。このため、アプリケーションの中には、ASP.NET Web サービスを使用できないものがあります。アプリケーションに必要な分散アプリケーション サポートの種類を決定するには、次のセクションを参考にしてください。
ASP.NET か、Enterprise Services か、.NET リモート処理か
ASP.NET、Enterprise Services、および .NET リモート処理は、プロセス間通信 (IPC) の実装です。ASP.NET は、インターネット インフォメーション サービス (IIS : Internet Information Services) によってホストされるインフラストラクチャを提供します。このインフラストラクチャは、基本的なタイプの処理に適し、いくつかの高度な Web サービス プロトコルをサポートしており (Web サービス拡張 (WSE : Web Service Extensions) と共に使用する場合)、Web アプリケーションの開発者にもよく知られています。Enterprise Services は、COM+ のマネージ実装であり、COM+ アーキテクチャのすべての柔軟性と豊富な機能を備えています。.NET リモート処理は、自己ホストすることも IIS でホストすることもでき、分散オブジェクト指向アプリケーションを開発および配置できる汎用および拡張可能な IPC システムです。.NET リモート処理のプラグ可能アーキテクチャでは、カスタム プロトコルおよびワイヤ形式を使用できます。
プログラミング モデルの選択は、ビジネス要件、統合の必要性、および習熟しているプログラミング モデルという 3 つの主要な基準に基づいて行ってください。さらに、次の基準 (優先度順の一覧) を、必要な分散アプリケーション テクノロジの種類の選択の参考にしてください。
セキュリティ上の必要性
3 つのプログラミング モデルのうち、Enterprise Services は最も豊富なセキュリティ機能を持ち、ほとんどのシナリオを満たすことができます。ASP.NET は、IIS による認証と SSL による暗号化を備えており、インターネット規模のアプリケーションのセキュリティの保護に便利です。.NET リモート処理のセキュリティは、.NET Framework の最新のリリースで高められました。前のバージョンの .NET リモート処理では、呼び出しを暗号化したりクライアントを認証したりする必要がある場合は、ASP.NET アプリケーションの場合でも、リモート処理アプリケーションの場合でも、IIS でホストされる HTTP ベースのアプリケーションを使用する必要がありました。現在のバージョンでは、TcpChannel および HttpChannel で SSPI 暗号化と統合 Windows 認証がサポートされています。IpcChannel では、Windows 認証および名前付きパイプでのアクセス制御リスト (ACL) の直接設定もサポートされています。インターネットを経由したリモート オブジェクトの使用は推奨されていないので、現在、HttpChannel を必要とするシナリオはほとんどありません。インターネットを経由して通信する必要がある場合、ASP.NET を使用して XML Web サービスを作成することをお勧めします。
.gif) メモ : |
|---|
セキュリティ上の理由から、リモート処理のエンドポイントはセキュリティで保護されたチャネルを通じて公開することを強くお勧めします。セキュリティで保護されていないリモート処理のエンドポイントをインターネットに公開しないでください。 |
相互運用
異なるオペレーティング システム間で相互運用する必要がある場合、ASP.NET で作成した XML Web サービスを使用する必要があります。ASP.NET ファイルには、SOAP 通信の形態とスタイルを定義するうえで .NET リモート処理よりもかなり高い柔軟性があります。この柔軟性によって、異なるプラットフォームとクライアントでの相互運用が簡単になります。.NET リモート処理は、.NET 以外のプラットフォームでの相互運用を意図していません。
.NET Framework リモート処理は Web サービスとの相互運用を意図していません。Web サービスとリモート処理の選択に関する詳細については、パフォーマンスに関するベスト プラクティスのページ (英語情報) の、Web サービス、リモート処理、および Enterprise Services の選択方法についてのトピック、および .NET アプリケーションのパフォーマンスとスケーラビリティの向上のページ (英語情報) の、Web サービス、Enterprise Services、および .NET リモート処理の選択方法のガイダンスについてのトピックを参照してください。
速度
速度が重要な要素である場合、分散アプリケーションに対しては Enterprise Services が最高のパフォーマンスを提供します。アプリケーションが実際の処理を必要とする時点で、.NET リモート処理と ASP.NET ファイルの間にパフォーマンス上の違いはほとんどありません。.NET リモート処理を使用する場合、TcpChannel と BinaryFormatter を使用すると、コンピュータ間で最高のパフォーマンスが得られます。同じコンピュータ上で、IpcChannel と BinaryFormatter を使用する必要があります。
スケーラビリティ
アプリケーションを IIS 内でホストすると、必要なスケーラビリティを得られます。.NET リモート処理を自己ホストするには、独自のスケーリング インフラストラクチャを構築する必要があります。.NET リモート処理で IIS を使用してスケーラビリティを獲得することを考慮している場合は、代わりに ASP.NET を使用して Web サービスを作成することを検討してください。
共通言語ランタイム機能の使用
Enterprise Services と .NET リモート処理はどちらも .NET クライアントを活用できるので、ASP.NET を使用して作成した XML Web サービスでは使用できない次のような .NET 機能をアプリケーションで使用できます。
インターフェイス
CallContext
プロパティ
インデクサ
C++
クライアント アプリケーションとサーバー アプリケーション間での型の整合性
これらの機能が重要な場合は、可能であれば Enterprise Services を選択し、次に .NET リモート処理を選択します。
オブジェクト指向のアプリケーション デザイン
Enterprise Services と .NET リモート処理オブジェクトはどちらもオブジェクトそのものであり、オブジェクトとして扱うことができます。したがって、ASP.NET では利用できない次のようなオブジェクト指向の機能をアプリケーションで使用できます。
リモート オブジェクトへのオブジェクト参照
いくつかのオブジェクト アクティベーション オプション
オブジェクト指向の状態管理
分散オブジェクトの有効期間の管理
これらの機能が重要な場合は、可能であれば Enterprise Services を選択し、次に .NET リモート処理を選択します。
カスタム トランスポートまたはワイヤ形式。カスタム トランスポート (たとえばユーザー データグラム プロトコル (UDP)) またはカスタム ワイヤ形式 (たとえば CSV) をサポートする必要がある場合、これらの必要性を満たすプラグ可能アーキテクチャは .NET リモート処理のみです。
アプリケーション ドメイン間通信。同じプロセス内で異なるアプリケーション ドメインにあるオブジェクト間の通信をサポートする必要がある場合、.NET リモート処理を使用する必要があります。
ASP.NET、System.Net 名前空間、Enterprise Services、および .NET リモート処理を使用して作成した XML Web サービスのいくつかの相違点についての要約を次のセクションに示します。
XML Web サービス
Microsoft Visual Studio. NET での強力なサポートも含め、Web アプリケーション モデルと ASP.NET HTTP ランタイムを使用して ASP (Active Server Pages) アプリケーションを構築した場合、ASP.NET で作成した XML Web サービスは適切に動作します。XML Web サービス インフラストラクチャでは、他のアプリケーションで使用するコンポーネントを簡単に作成したり、他のアプリケーションで Web ベースのアプリケーションに最も適したプロトコル、形式、およびデータ型を使用して作成されたコンポーネントを使用したりすることができます。複数の .NET コンピュータ間では、型の厳密性は完全にはサポートされていません。また、受け渡しできる引数の型にも制限があります。詳細については、「ASP.NET を使用して作成した XML Web サービスと XML Web サービス クライアント」を参照してください。
System.Net 名前空間
System.Net 名前空間のクラスを使用すると、通信の構造全体をソケット レベルから構築できます。また、System.Net のクラスを使用することにより、リモート処理アーキテクチャにプラグインできる通信プロトコルやシリアル化フォーマットを実装できます。詳細については、「ネットワーク プログラミング」を参照してください。
Enterprise Services
Enterprise Services は、.NET リモート処理インフラストラクチャ上に構築され、広範な分散トランザクションのサポートなど、COM+ 分散オブジェクト モデルのすべての豊富な機能と柔軟性を備えています。
.NET リモート処理
.NET リモート処理には、XML Web サービスを始めとする任意の数の包括的な通信を作成するためのツールが用意されています。.NET リモート処理を使用すると、次のことが可能になります。
アプリケーション ドメインがコンソール アプリケーション、Windows フォーム、IIS、XML Web サービス、Windows サービスのいずれであっても、そのアプリケーション ドメイン内のサービスを公開または利用できます。
バイナリ フォーマットの通信で、ジェネリック型のサポートを含む完全なマネージ コード型システムの厳密性を保持できます。
メモ :XML Web サービスでは SOAP フォーマッティングを使用しています。このフォーマッティングでは、一部の型について詳細が保持されない場合があります。
オブジェクトを参照渡しして、特定のアプリケーション ドメイン内の特定のオブジェクトに返すことができます。
アクティベーションの特性やオブジェクトの有効期間を直接制御できます。
サード パーティ製のチャネルやプロトコルを実装して使用することにより、通信を拡張して特別な要件を満たすことができます。
通信プロセスに直接参加して、必要な機能を作成できます。