.NET での通信オプションの選択
.NET Framework 3.0 と Windows Communication Foundation (WCF) の導入により、さまざまなテクノロジが統合プログラミング モデルにまとめられました。WCF は、Enterprise Services、ASMX Web サービス、WSE、MSMQ、および .NET リモート処理の次期バージョンとして機能します。次のトピックは、.NET Framework 2.0 に適用されます。WCF および .NET Framework 3.0 の詳細については、「Windows Communication Foundation」を参照してください。
.NET Framework には、さまざまなアプリケーション ドメインのオブジェクトと通信する方法が何種類か用意されています。これらの方法は、それぞれ特定レベルの専門的技術や柔軟性を考慮してデザインされています。たとえば、インターネットの発達によって XML Web サービスが通信方法として注目されていますが、これは XML Web サービスが XML を使用する SOAP 形式と HTTP プロトコルという共通のインフラストラクチャを基盤に構築されているためです。これらは公的な標準規格であり、プロキシやファイアウォールの問題を考慮しなくても、現在の 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 リモート処理は、拡張可能な汎用 IPC システムです。この IPC システムを自己ホスト型にするか、IIS でホストすることによって、分散オブジェクト指向アプリケーションを開発して配置できます。.NET リモート処理のアーキテクチャでは、カスタム プロトコルとワイヤ形式を使用できます。
プログラミング モデルの選択は、ビジネス要件、統合の必要性、および習熟しているプログラミング モデルという 3 つの主要な基準に基づいて行ってください。さらに、次の基準 (優先度順の一覧) を、適切な分散アプリケーション テクノロジの種類の選択の参考にしてください。
セキュリティ要件
3 つのプログラミング モデルのうち、Enterprise Services は最も豊富な一連のセキュリティ機能を備えており、ほとんどのシナリオで機能します。ASP.NET は、IIS による認証と SSL による暗号化を備えており、インターネット規模のアプリケーションのセキュリティの保護に便利です。.NET Framework の最新リリースでは、.NET リモート処理のセキュリティが向上しています。前のバージョンの .NET リモート処理では、呼び出しの暗号化やクライアントの認証が必要であれば、ASP.NET アプリケーションの場合でも、リモート処理アプリケーションの場合でも、IIS でホストされる HTTP ベースのアプリケーションを使用する必要がありました。現在のバージョンでは、TcpChannel および HttpChannel で SSPI 暗号化と Windows 統合認証がサポートされています。IpcChannel では、Windows 認証および名前付きパイプでのアクセス制御リスト (ACL) の直接設定もサポートされています。インターネットを経由したリモート オブジェクトの使用は推奨されていないため、現在は、HttpChannel を必要とするシナリオはほとんどありません。インターネットを経由して通信する必要がある場合、ASP.NET を使用して XML Web サービスを作成することをお勧めします。
.gif "8119f66k.note(ja-jp,VS.100).gif")
注 :セキュリティ上の理由から、リモート処理の各エンドポイントは、セキュリティで保護されたチャネルを介して使用できるようにすることを強くお勧めします。セキュリティで保護されていないリモート処理のエンドポイントをインターネットに公開しないでください。 相互運用
異なるオペレーティング システム間で相互運用する必要がある場合、ASP.NET で作成した XML Web サービスを使用する必要があります。ASP.NET ファイルを使用すると、.NET リモート処理よりもかなり柔軟に、SOAP 通信の形態とスタイルを定義できます。この柔軟性によって、異なるプラットフォームとクライアントでの相互運用が容易になります。.NET リモート処理は、.NET 以外のプラットフォームとの相互運用を目的としたものではありません。
.NET Framework リモート処理は、Web サービスとの相互運用を意図したものではありません。Web サービスとリモート処理の選択の詳細については、「パフォーマンスに関するベスト プラクティス一覧」の「Web サービス、リモート処理、および Enterprise Services の選択方法」、および「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 ベースのアプリケーションに最も適したプロトコル、形式、およびデータ型を使用して他のアプリケーションで作成されたコンポーネントを容易に使用することもできます。複数のコンピューター間での型の厳密な忠実さはサポートされていません。また、受け渡しできる引数の型にも制限があります。詳細については「ASP.NET と XML Web サービス クライアントを使用して作成した XML Web サービス」を参照してください。
System.Net 名前空間
System.Net 名前空間のクラスを使用すると、通信の構造全体をソケット レベルから構築できます。また、System.Net のクラスを使用することにより、リモート処理アーキテクチャにプラグインできる通信プロトコルやシリアル化フォーマットを実装できます。詳細については「Network Programming」を参照してください。
Enterprise Services
Enterprise Services は、.NET リモート処理インフラストラクチャ上に構築され、広範な分散トランザクションのサポートなど、COM+ 分散オブジェクト モデルのすべての豊富な機能と柔軟性を備えています。
.NET リモート処理
.NET リモート処理には、XML Web サービスを含む多数の包括的な通信シナリオに対応するツールが用意されています。.NET リモート処理を使用すると、次のことが可能になります。
アプリケーション ドメインがコンソール アプリケーション、Windows フォーム、IIS、XML Web サービス、または Windows サービスのいずれであっても、ドメイン内でサービスを公開したり、サービスにアクセスしたりできます。
バイナリ形式の通信で、ジェネリック型のサポートを含む完全なマネージ コード型システムの忠実性を保持できます。
注 :XML Web サービスでは SOAP 形式を使用しています。この形式では、一部の型について詳細が保持されない場合があります。 オブジェクトを参照によって渡し、特定のアプリケーション ドメイン内の特定のオブジェクトに返すことができます。
アクティベーションの特性やオブジェクトの有効期間を直接制御できます。
サード パーティのチャネルやプロトコルを実装して使用することにより、通信を拡張して特別な要件を満たすことができます。
通信プロセスに直接参加して、必要な機能を作成できます。
参照
その他のリソース
.NET リモート処理
.NET Framework リモート処理の概要
リモート処理の例
高度なリモート処理
Windows Communication Foundation