次の方法で共有

チャネル

  • [アーティクル]

このトピックの対象は、既存のアプリケーションとの下位互換性のために残されているレガシ テクノロジに特定されています。新規の開発には、このトピックを適用しないでください。分散アプリケーションは、現在は Windows Communication Foundation (WCF) を使用して開発する必要があります。

チャネルは、アプリケーション ドメイン、プロセス、コンピューターなどのリモート処理境界を越えて、アプリケーション間でメッセージを転送するオブジェクトです。チャネルは、片方のエンドポイントで着信メッセージを待機したり、別のエンドポイントへ発信メッセージを送信したり、この両方を行ったりできます。これによって、共通言語ランタイムがチャネルのもう片方のエンドポイントにない場合でも、広範なプロトコルを組み込むことができます。

チャネルは、ChannelName や ChannelPriority などの情報プロパティを提供する IChannel インターフェイスを実装する必要があります。特定のポートで特定のプロトコルを待機するようにデザインされたチャネルは IChannelReceiver を実装し、情報を送信するようにデザインされたチャネルは IChannelSender を実装します。TcpChannel オブジェクトおよび HttpChannel オブジェクトは、これらのインターフェイスを両方とも実装するため、情報の送信および受信に使用できます。

チャネルをリモート処理インフラストラクチャに登録するには、次の方法があります。

  • リモート処理可能オブジェクトを公開する場合は、サーバー オブジェクトを登録する前に ChannelServices.RegisterChannel を呼び出します。

  • リモート処理可能オブジェクトの機能を利用する場合は、サーバー オブジェクトのインスタンスを作成する前に RegisterChannel を呼び出します。

チャネルは、リモート処理構成ファイルから読み込むこともできます。詳細については、「構成」を参照してください。

クライアント側では、メッセージはクライアント コンテキスト チェーンを通過した後、クライアント チャネル シンク チェーンに渡されます。通常、最初のチャネル シンクは、メッセージをストリームにシリアル化するフォーマッタ シンクです。このストリームは、チャネル シンク チェーンからクライアント転送シンクに渡されます。その後、クライアント転送シンクは、このストリームをネットワークに送出します。

サーバー側では、サーバー転送シンクがネットワークから要求を読み取り、要求ストリームをサーバー チャネル シンク チェーンに渡します。このチェーンの終端にあるサーバー フォーマッタ シンクは、要求をメッセージに逆シリアル化します。次に、このメッセージをリモート処理インフラストラクチャに渡します。チャネル シンクの詳細については、「シンクとシンク チェーン」を参照してください。

チャネルの規則

クライアントがリモート オブジェクトのメソッドを呼び出すと、パラメーターが、呼び出しに関連するその他の詳細情報と共に、チャネルを通じてリモート オブジェクトに転送されます。呼び出しからの結果も同じ方法で返されます。クライアントはリモート オブジェクトと通信するために、サーバーで登録されているチャネルをどれでも選択できます。それにより開発者は、目的に最も適したチャネルを選択できます。また、既存のチャネルをカスタマイズしたり、別の通信プロトコルを使用する新しいチャネルを構築したりできます。チャネル選択は、次の規則に従います。

  • リモート オブジェクトを呼び出す前に、少なくとも 1 つのチャネルがサーバー上のリモート処理システムに登録されている必要があります。チャネルは、オブジェクトが登録される前に登録されている必要があります。クライアント上でチャネルが登録されていない場合、リモート処理システムは送信呼び出しを行うために、チャネルを選択または作成します。

    dkfd3wha.note(ja-jp,VS.100).gif注 :
    クライアントがコールバック関数を予期している場合は、待機するチャネルがクライアント上で登録され、サーバーが互換チャネルを使用するように構成されている必要があります。

  • チャネルは、アプリケーション ドメインごとに登録されます。1 つのプロセスに複数のアプリケーション ドメインを含めることができます。プロセスが終了すると、そのプロセスによって登録されたすべてのチャネルは自動的に破棄されます。

  • チャネル名は、アプリケーション ドメイン内で一意であることが必要です。たとえば、既定のチャネルには名前が付けられているため、1 つのアプリケーション ドメインに 2 つの HttpChannel オブジェクトを登録するには、その前にチャネルの名前を変更しておく必要があります。名前を変更して登録する C# のコード例を次に示します。

    IDictionary prop = new Hashtable();
prop["name"] = "http1";
prop["port"] = "9001";
ChannelServices.RegisterChannel(new HttpChannel(prop, null, null));

  • 特定のポートで待機するチャネルを 2 回以上登録することはできません。チャネルはアプリケーション ドメインごとに登録されますが、同じコンピューター上の異なるアプリケーション ドメインは、同じポートで待機する同じチャネルを登録できません。

  • ポートが使用できるかどうか不明な場合、チャネルのポートを 0 (ゼロ) に構成すると、リモート処理システムが使用可能なポートを自動的に選択します。

  • クライアントは、登録されている任意のチャネルを使用して、リモート オブジェクトと通信できます。リモート処理システムは、クライアントがリモート オブジェクトへの接続を試行したときに、そのオブジェクトが正しいチャネルに接続されるようにします。クライアントは、リモート オブジェクトとの通信を試みる前に、ChannelServices.RegisterChannel を呼び出す必要があります。オブジェクトがコールバック関数を使用するときは、クライアントはチャネルとポートを登録する必要があります。

クライアントがプロキシのメソッドを呼び出すと、その呼び出しは受け取られてメッセージにバンドルされ、RealProxy クラスのインスタンスに渡されます。RealProxy クラスは、そのメッセージを処理するためにメッセージ シンクに転送します。メッセージ シンクは、リモート オブジェクトによって登録されたチャネルとの接続を確立し、そのチャネルを通じてメッセージを本来のアプリケーション ドメインにディスパッチします。そのアプリケーション ドメインで、メッセージはマーシャリング解除され、リモート オブジェクト自身に対する呼び出しが行われます。

リモート処理がクライアントのドメインでリモート オブジェクトに対するプロキシを初期化すると、選択したチャネル上で IChannelSender.CreateMessageSink を呼び出すことにより、そのリモート オブジェクトと通信できるメッセージ シンクが、クライアントによって構成されたチャネルから取得されます。

リモート処理システムのわかりにくい面の 1 つに、リモート オブジェクトとチャネルの関係があります。たとえば、呼び出しが着信したときだけオブジェクトがアクティブ化される場合、WellKnownObjectMode.SingleCall リモート オブジェクトは接続するクライアントをどのようにして待機するのでしょうか。

これが可能な理由の 1 つは、リモート オブジェクトがチャネルを共有していることです。つまり、リモート オブジェクトは専用のチャネルを持ちません。リモート オブジェクトをホストするサーバー アプリケーションは、公開するオブジェクトだけでなく、必要とするチャネルをリモート処理システムに登録する必要があります。チャネルは、登録されると、指定されたポートで自動的にクライアント要求の待機を開始します。同期呼び出しの場合、クライアントからの接続はメッセージ呼び出しの存続期間にわたって維持されます。各クライアント接続はそれ自身のスレッドで処理されるため、1 つのチャネルで複数のクライアントを同時に処理できます。

参照

リファレンス

HttpChannel
TcpChannel

概念

チャネルの選択
シリアル化フォーマッタ
シンクとシンク チェーン

その他のリソース

.NET Framework リモート処理の概要