.NET リモート処理構成ファイルの形式

 

ピート・オーバーマイヤーとジョナサン・ホーキンス
Microsoft Corporation

2001 年 9 月
更新日: 2002 年 3 月

概要: この記事では、リモート処理構成ファイルで使用されるスキーマの詳細について説明します。 (26ページ印刷)

Contents

概要 リモート アプリケーションをホストする理由 チャネル 登録する理由 オブジェクト設定スキーマを登録する 理由

はじめに

クライアントがリモート 処理フレームワークにアクセスするには、すべてのリモート オブジェクトをリモート処理フレームワークに登録する必要があります。 この登録プロセスでは、オブジェクトの有効期間をアクティブ化および管理するために必要なすべての情報がフレームワークに提供されます。 登録に必要な最も重要な情報は、オブジェクトの種類、展開される URI、オブジェクトの有効期間を管理するためのアクティブ化要件、およびこのオブジェクトへの接続に使用できるチャネルです。

プログラムによる登録は簡単なプロセスですが、企業ネットワーク上で多数のリモート オブジェクトを管理する必要がある実際のアプリケーションに使用することは常に望ましいとは限りません。 リモート処理の構成では、構成ファイルを使用してオブジェクトを登録するための簡単なメカニズムを提供することで、この問題を解決できます。これにより、管理者はアプリケーションやサービスを再コンパイルせずにリモート処理の設定を "微調整" できます。 この記事では、リモート処理構成を使用する方法について詳しく説明し、構成ファイルの要素について説明します。

リモート アプリケーションのホスト

オブジェクトの登録は通常、起動し、1 つ以上のチャネルを ChannelServices に登録し、1 つ以上のリモート オブジェクト を RemotingServices に登録し、終了するまで待機するホスティング アプリケーションによって行われます。 登録されたチャネルとオブジェクトは、登録されたプロセスが有効な間のみ使用可能であることに注意してください。 プロセスが終了すると、そのプロセスによって登録されたすべてのチャネルとオブジェクトが、登録されたリモート処理サービスから自動的に削除されます。 構成ファイルを使用してオブジェクトを構成するには、RemortingConfigurationConfigure メソッドを呼び出す必要があります。 これは、次のように簡単に実現できます。

using System;
using System.IO;
using System.Runtime.Remoting;

public class MyHost {
  public static void Main(String[] args)
  {
    if (args.Length == 0) {
      // Perform a default configuration, throw an exception 
      // or display usage information to the user
    }
    else {
      RemotingConfiguration.Configure (args[0]);
    }
    // The program should pause here till the
    // registered objects are no longer required
  }

構成 では、構成ファイルをメモリに読み込み、内容を解析し、関連するメソッドを呼び出して、ファイルに記述されているチャネルとオブジェクトを登録します。 Configure 呼び出しに関する特別な情報はありません。どのホストでも、構成ファイルを読み込んで解析し、必要な情報を抽出し、オブジェクトを登録できます。 リモート処理は、アプリケーションの起動時に構成ファイルが読み込まれるときに構成されないことに注意してください。

チャネルを登録する理由

チャネル インスタンスがフレームワークに登録されると、チャネル インスタンスは、それが設計されたプロトコルでクライアント要求のリッスンを開始します。 チャネルは特定のリモート オブジェクトに属していないことに注意してください。 同じチャネルで、任意の数のリモート オブジェクトにサービスを提供できます。

オブジェクトの登録中に、リモート オブジェクトがマーシャリングされ、リモート オブジェクトのアクティブ化と通信に必要なすべての関連情報を格納する ObjRef が生成されます。 ObjRef は、アンマースホール中に TransparentProxy を生成するために使用されるため、クライアントが使用できるサーバー プロトコルを使用してリモート オブジェクトに対してメソッド呼び出しを行えるようにするには、使用可能なすべてのチャネルに関する知識が必要です。 オブジェクトの登録時に登録されたすべてのチャネルは、クライアントで使用できます。

オブジェクトを登録する理由

リモート処理フレームワークは、リモート オブジェクトをアクティブ化し、その有効期間を管理する役割を担います。 これを行うために、オブジェクト URI でキー付けされたすべての登録済みオブジェクトの一覧が格納されます。 クライアントがプロキシでメソッドを呼び出すと、メソッド呼び出しはメッセージに変換され、関連するチャネルを介して、クライアントによって指定された URL で指定されたアプリケーション ドメインに転送されます。 呼び出しがサーバー (オブジェクトがホストされているアプリケーション ドメイン) に到着すると、フレームワークは ObjectUri を 使用して ID テーブル内のオブジェクトの ObjRef を検索します。 ObjRef が見つかった場合、フレームワークは必要に応じて オブジェクトをアクティブ化し、メソッド呼び出しを オブジェクトに転送します。

サーバーでアクティブ化されたオブジェクトには、次の 2 種類があります。

  • SingleCall 型の既知のオブジェクトは、メソッド呼び出し間で状態を維持しません。 オブジェクトに対して行われたメソッド呼び出しごとに、 オブジェクトの新しいインスタンスが作成されます。 呼び出しが完了すると、オプションの結果が呼び出し元に返され、オブジェクトがリサイクルされます。
  • シングルトン オブジェクトは、メソッド呼び出し間で状態を維持します。 オブジェクトが登録されると、フレームワークは オブジェクトの 1 つのインスタンスをインスタンス化します。 このオブジェクトに対して行われたすべてのメソッド呼び出しは、作成された単一のインスタンスにルーティングされます。 シングルトン オブジェクトがマルチスレッド環境で機能するように適切に保護されるようにするのは開発者の責任です。

既知のオブジェクトは、作成された AppDomain でのみパブリッシュ/マーシャリングできます。

コンテキスト バインド オブジェクトを作成する場合は、互換性のあるコンテキストが必要です。 最初に、現在のコンテキストがオブジェクトのコンテキスト プロパティ要件との互換性をチェックされます。失敗した場合は、オブジェクトのコンテキスト プロパティ要件を満たす一致するコンテキストが作成されます。 詳細については、コンテキストに関するセクションを参照してください。

サーバー オブジェクトがマーシャリングされると、オブジェクトにつながるサーバー オブジェクト シンク チェーンが構築されます。 スタック ビルダー シンクは、サーバー オブジェクト チェーン内の最後のシンクであり、サーバー オブジェクトと直接通信します。 スタック ビルダー シンクは、リモート処理インフラストラクチャによって提供されます。 コンテキスト バインドされたサーバー オブジェクトがマーシャリングされると、オブジェクトが作成されたコンテキストへの参照が ID テーブルのエントリに格納されます。

着信呼び出しが到着すると、サーバー オブジェクトにディスパッチされます。 ID テーブルは、オブジェクト、コンテキスト、およびメッセージ シンク チェーン マッピングへの URI を提供します。

設定スキーマ

リモート処理アプリケーションの構成ファイルに、カスタム設定を含めるために使用するタグについて説明します。

要素 説明
<構成> これは、構成ファイル内のすべての要素のルートです
<system.runtime.remoting> すべてのリモート処理構成は、このタグ内に配置する必要があります。 これらの要素の 1 つだけが許可されます。
<application> すべてのアプリケーション固有の情報は、このタグ内に配置する必要があります。 これらの要素の 1 つだけが許可されます。
<lifetime> アプリケーション タグの下に配置する<必要があります。> この有効期間は、サービスとして提供されるすべてのクライアントでアクティブ化されたオブジェクトとシングルトンに適用されます。 これらの要素の 1 つだけが許可されます。
<チャネル> (テンプレート) <チャネル> ノードは、.config ファイル内の他の場所で参照できるチャネル テンプレートを提供するために使用されます。 既定のチャネル実装は machine.config ファイルで提供されるため、ユーザーは既定の http チャネルと tcp チャネルのテンプレートを設定することに関心を持つ必要はありません。 これらの要素の 1 つだけが許可されます。
<チャネル> (テンプレート) チャネル ノードを system.runtime.remoting> タグ内に<配置して、チャネル テンプレートのコンテナーを提供できます。<> これらの要素の 1 つだけが許可されます。
<チャネル> (アプリケーション) チャネル> ノードは<、アプリケーション> タグ内に配置して、<チャネル テンプレートで宣言されたチャネルを<構成したり、新しいチャネル>を宣言したりできます。 これらの要素の 1 つだけが許可されます
<チャネル> (アプリケーション) アプリケーション チャネル ノード内に 0 個以上 <のチャネル> タグを配置して、個々のチャネルを構成できます。 チャネルに配置された属性は、リモート処理によってではなく、チャネルによって決定されます。 たとえば、このドキュメントで説明する属性を必要としないまったく新しいチャネルを誰かが構築できます。
<channelSinkProviders> このタグの下にシンク プロバイダー情報が指定されています。 ここで指定したチャネル シンク プロバイダーは、チャネル シンク プロバイダーが登録されている可能性がある任意の場所で参照できます。 これらの要素の 1 つだけが許可されます。
<serverProviders> ここでサーバー側で使用するシンク プロバイダーを指定します。 machine.config ファイルの既定のエントリでは、バイナリフォーマッタと SOAP フォーマッタと WsdlChannelSinkProvider を指定します。 <serverProviders> タグをチャネル> タグ内に<配置して、channelSinkProviders> で<指定されたプロバイダーを構成することもできます。

これらの要素の 1 つだけが許可されます。

<clientProviders> ここでクライアント側で使用するシンク プロバイダーを指定します。 machine.config ファイルの既定のエントリは、SOAP フォーマッタとバイナリ フォーマッタを指定します。 <clientProviders> タグは、チャネル> タグ内<に配置して、channelSinkProviders> で<指定されたプロバイダーを構成することもできます。

これらの要素の 1 つだけが許可されます。

<プロバイダー> チャネル シンク チェインに挿入されるチャネル シンクのチャネル シンク プロバイダーを指定します。 このタグは、serverProvider または clientProvider> の下<に配置できます。>< これらの要素の 0 個以上を使用できます。
<フォーマッタ> チャネル シンク チェーンに挿入されるフォーマッタ シンクのチャネル シンク プロバイダーを指定します。 このタグは、serverProvider または clientProvider> の下<に配置できます。>< これらのタグは 0 個以上使用できます。
<service> アプリケーションで 0 個以上のサービス タグを<指定できます。> ホストされるすべてのオブジェクトがここに一覧表示されます。 リモート処理には、ダイレクトと IIS の 2 種類のホスティングがあります。 直接ホスティングの場合、.config ファイルは通常、ホスティング アプリケーションと共に格納されます。 IIS でホストする場合は、.config ファイルを web.config呼び出し、vroot に配置する必要があります。 サービスを含む DLL は、vroot の直下にある bin ディレクトリに配置されます。

アプリケーションが、他のアプリケーション ドメインまたはアプリケーション コンテキストに公開するオブジェクトを指定します。

<wellknown> アプリケーションが公開する、サーバー側でアクティブ化される既知のオブジェクトに関する情報を指定します。 これらの要素の 0 個以上をサービス> タグまたはクライアント タグの下に<配置できます。><
<アクティブ化済み> アプリケーションが公開する、クライアント側でアクティブ化されるオブジェクトに関する情報を指定します。 これらの要素の 0 個以上をサービス> タグまたはクライアント タグの下に<配置できます。><
<client> アプリケーション>で< 0 個以上のクライアント タグを指定できます。 アプリケーションが使用するオブジェクトを指定します。
<soapInterop> SOAP で使用する型の割り当てを指定します。
<interopXmlType> 要素名を変更できない場合に、共通言語ランタイム型と XML 要素と XML 名前空間の間に双方向マップを作成します。 これらの要素の 1 つだけが許可されます。
<interopXmlElement> 共通言語ランタイム型と XML 要素と XML 名前空間の間に双方向マップを作成します。 1 回以上発生する可能性があります。
<プリロード> SoapAttribute を拡張するすべてのクラスのマッピングを読み込みます。 1 回以上発生する可能性があります。
<デバッグ> アプリケーションの起動時に、構成ファイル内に指定されている型を読み込んでおくかどうかを指定します。 構成ファイルに web.configという名前が付けられ、リモートの種類が IIS でホストされている場合、この要素を指定できません。

<構成>

Parent 要素:

なし

説明:

これは、構成ファイル内のすべての要素のルートです。

子要素:

system.runtime.remoting

必須の属性:

なし

省略可能な属性:

なし

<system.runtime.remoting>

Parent 要素:

configuration

説明:

すべてのリモート処理構成は、このタグ内に配置する必要があります。 これらの要素の 1 つだけが許可されます。

子要素:

application, channelSinkProviders, チャネル, デバッグ

必須の属性:

なし

省略可能な属性:

バージョン: System.runtime.remoting の後に、オプションのバージョン番号を付けることができます。 現在許可されているバージョンは v1 のみです。 これは次のように指定されます。

<system.runtime.remoting version="1.0">

このバージョン番号はアセンブリのバージョンではなく、構成ファイル リーダーのバージョンであることに注意してください。 この属性により、将来構成ファイル形式が変更された場合に下位互換性のあるリーダーを提供できるようになります。

<application>

Parent 要素:

system.runtime.remoting

説明:

すべてのアプリケーション固有の情報は、このタグ内に配置する必要があります。 これらの要素の 1 つだけが許可されます。

子要素:

lifetime, service, client, channels, soapInterop

必須の属性:

なし

省略可能な属性:

名前: アプリケーション タグの後に省略可能な名前を付けることができます。 これは次のように指定されます。

<application name="RemotingHello">

サービス側で名前が指定されている場合、 objectURI が名前に追加され、エンドポイント クライアントの接続先が決定されます。 たとえば、名前が RemotingHello で、オブジェクト URI が HelloService.soap の場合、クライアントは次のようにサービスに接続する必要があります。

http://someMachine/RemotingHello/HelloService.soap

アプリケーション名が使用されていない場合、クライアントは次に接続する必要があります。

http://someMachine/HelloService.soap

<lifetime>

Parent 要素:

application

説明:

この有効期間は、サービスとして提供されるすべてのクライアント アクティブ化オブジェクトとシングルトンに適用されます。 これらの要素の 1 つだけが許可されます。

子要素:

なし

必須の属性:

なし

省略可能な属性:

leaseTime: アプリケーションのリース時間です。 既定値は[5 分]です。

sponsorTimeout: リースの有効期限が切れたことを通知されたときに、リース マネージャーがスポンサーの応答を待機する時間です。 スポンサーが指定された時間内に応答しない場合、リモート オブジェクトはガベージ コレクションされます。 既定値は 2 分です。

renewOnCallTime: はオブジェクトのリース時間であり、オブジェクトで呼び出されるすべてのメソッドで拡張されます。 既定値は 2 分です。

leaseManagerPollTime: リース マネージャーが期限切れのリースを確認した後にスリープ状態になる時間です。 既定値は 10 秒です。

有効期間は次のように指定できます。

<lifetime leaseTime="20ms" sponsorshipTimeOut="20ms" 
renewOnCallTime="20ms" />

この有効期間は、クライアントでアクティブ化されたすべてのオブジェクトと、サービスとして提供されるシングルトンに適用されます。 無効ではありませんが、サービスのみを使用するアプリケーションの構成ファイルに追加した場合、有効期間は影響しません。つまり、サービス オブジェクトにのみ適用されます。

有効な時間単位は、 日の場合は D 、時間の 場合は H 、分の 場合は M 、秒の 場合は S 、ミリ秒の 場合は MS です。 単位が指定されていない場合、指定された時間は秒単位であると見なされます。

<service>

Parent 要素:

application

説明:

0 個以上の要素を使用できます。 ホストされるすべてのオブジェクトは、このタグの下に一覧表示されます。 リモート処理には、ダイレクトと IIS 経由の 2 種類のホスティングがあります。 直接ホスティングの場合、通常、構成ファイルはホスティング アプリケーションと共に格納されます。 IIS でホストする場合は、構成ファイルを web.config呼び出し、vroot に配置する必要があります。 サービスを含む DLL は、vroot のすぐ下の bin ディレクトリに配置されるか、GAC で公開されます。

子要素:

wellknown、アクティブ化

必須の属性:

なし

省略可能な属性:

なし

<client>

Parent 要素:

application

説明:

アプリケーションで 0 個以上のクライアント タグを<指定できます。> アプリケーションが使用するオブジェクトを指定します。

子要素:

wellknown、アクティブ化

必須の属性:

url: は、クライアントでアクティブ化された型にのみ必要です。 属性のアクティベーターの検索に使用する URL を指定します。

省略可能な属性:

displayName: は、構成ファイルに複数のクライアント タグが存在する場合にユーザーが一覧表示されるさまざまなオブジェクトを区別できるようにするために、管理 ツールによってのみ使用されます。

<wellknown>

Parent 要素:

サービス、クライアント

説明:

サービスによって提供されるサーバーでアクティブ化されたオブジェクトまたは既知のオブジェクトを指定します。 これらの要素の 0 個以上を指定できます。

子要素:

なし

必須の属性:

mode: は、サーバーでアクティブ化されたオブジェクトの種類です。 この属性の有効な値は、SイングルトンSingleCall です

type: は、オブジェクトの完全な型名 (型、アセンブリ) です。

objectUri: 接続する "エンドポイント" リモート オブジェクトの名前であるリモート オブジェクトの URI を指定します。 この属性は、サービス> タグでのみ<使用できます。 オブジェクトに IIS 経由でアクセスする場合は、 .soap 拡張機能が必要です。 この拡張機能では、大文字と小文字は区別されません。

url: サービスへの接続に使用する URL を指定します。 この属性は、クライアント> タグでのみ使用<できます。

省略可能な属性:

displayName: (クライアント タグ内に<) 存在する場合は、構成ファイルのクライアント> セクションに複数の既知のオブジェクトが一覧表示されている場合に、ユーザーが一覧表示されるさまざまなオブジェクトを区別できるように、管理 ツールで<>使用されます。

例:

次の例は、既知のサービスを定義するときにこの要素を使用する方法を示しています。

<configuration>
  <system.runtime.remoting>
    <application>
      <service>
        <wellknown mode="SingleCall" type="Hello.HelloService, Hello" 
objectUri="HelloService.soap" />
      </service>
    </application>
  </system.runtime.remoting>
</configuration>

次の例は、この要素がクライアント> タグでどのように使用されるかを<示しています。

<configuration>
  <system.runtime.remoting>
    <application>
      <client>
        <wellknown type="Hello.HelloService, Hello" 
url="https://localhost:8000/HelloService.soap" />
      </client>
    </application>
  </system.runtime.remoting>
</configuration>

<アクティブ化済み>

Parent 要素:

サービス、クライアント

説明:

アプリケーションが発行するクライアントでアクティブ化されたオブジェクトを指定します。 これらの要素の 0 個以上をサービス> タグまたはクライアント タグの下に<配置できます。><

子要素:

なし

必須の属性:

type: は、オブジェクトの完全な型名 (型、アセンブリ) です。 このタグは、サービス>とクライアント タグで<使用できます。><

省略可能な属性:

なし

例:

次の例は、クライアントでアクティブ化されたサービスを定義するときにこの要素を使用する方法を示しています。

<configuration>
  <system.runtime.remoting>
    <application>
      <service>
        <activated type="Hello.AddService, Hello"/>
      </service>
    </application>
  </system.runtime.remoting>
</configuration>

次の例は、この要素がクライアント> タグでどのように使用されるかを<示しています。

<configuration>
  <system.runtime.remoting>
    <application>
      <client url="https://localhost:8000>
        <activated type="Hello.AddService, Hello"/>
      </client>
    </application>
  </system.runtime.remoting>
</configuration>

<チャンネル>

Parent 要素:

system.runtime.remoting, アプリケーション

説明:

この要素がアプリケーション> タグ内に<配置されると、system.runtime.remoting> で<定義されている既存のチャネルを構成するために使用されます。 新しいチャネルを定義するには、system.runtime.remoting の直下に< channels タグを>配置<します。> 既定のチャネルはmachine.config ファイルで定義されるため、新しいチャネルを登録しない限り、このレベルでチャネルを定義する必要はありません。

子要素:

channel

必須の属性:

なし

省略可能な属性:

なし

例:

<configuration>
  <system.runtime.remoting>
    <application>
      <channels>
      </channels>
    </application>
    <channels>
    </channels>
  </system.runtime.remoting>
</configuration>

<チャネル>

Parent 要素:

[チャネル] セクションで前述した <チャネル> タグのいずれか。

説明:

アプリケーション チャネル ノード内に 0 個以上 <のチャネル> タグを配置して、個々のチャネルを構成できます。 チャネルに配置される属性は、リモート処理ではなく、チャネルによって決定されます。 たとえば、このドキュメントで説明する属性を必要としないまったく新しいチャネルを誰かが構築できます。

子要素:

<チャネル> タグが system.runtime.remoting> の下<に配置されている場合、子要素は clientProviders と serverProviders にすることができます。 親がアプリケーション タグの下に<配置されている場合は、既に宣言されているチャネルのみを参照できます。>

必須の属性:

チャネル テンプレートを宣言する場合は、次の属性が必要です。 <channels> タグは system.runtime.remoting> の下<に配置されます。 また、アプリケーション セクションでチャネルを宣言し、この宣言の一部としてチャネルのすべての属性を指定することもできます。

id: 参照時に使用できるチャネルの名前を指定します。 たとえば、チャネルに "tcp" という名前を付けた場合は、アプリケーション チャネル タグの下でそれを参照できます。 重複 ID は許可されず、重複が検出された場合、パーサーは例外をスローしません。最後に見つかったのは、チャネルに関連付けられている ID です。

type: は、読み込まれるチャネルの完全な型名です。

ref: は、参照されるチャネル テンプレートです。 この属性に指定された値は、マシン レベルで指定されたチャネル ID と一致することによって参照されているチャネルを検索するために使用されます。 チャネルは通常、チャネル属性に値を提供するために参照されます。 たとえば、ポート 8000 のmachine.config ファイルで定義されている TCP チャネルを使用する必要がある場合は、アプリケーション セクションでチャネルを簡単に参照し、ポート番号を指定します。 テンプレート セクションから既存のチャネル テンプレートを参照できないことに注意してください。

省略可能な属性:

チャネル テンプレートを宣言するときに、次の省略可能な属性を使用できます。

name: チャネルの名前を指定します。 同じチャネルを複数回構成することが必要な場合があります。 たとえば、TCP チャネルがポート 8000 と 9000 の両方でリッスンする必要があるとします。 同じチャネルを複数回参照し、それぞれに異なるチャネル番号を指定しようとすると、同じチャネルを複数回登録できないため、例外がスローされます。 これを行う適切な方法は、各チャネル参照に "name" 属性を追加し、それぞれに異なる名前を指定することです (以下の例を参照してください)。

priority: サービスへの接続を行う方法を決定するときに必要なチャネルの基本設定を指定します。 リモート オブジェクトに接続しようとすると、リモート処理は URL で指定された情報を使用して、要求を処理できるチャネルを検索します。 要求を処理できることを示す最初のチャネルは、使用されるチャネルです。 この属性を使用すると、チャネル選択で優先設定を表すことができます。 SDK で提供されるすべての既定のチャネルは、既定値は優先度 1 です。 数値が大きいほど、優先度が高くなります (負の数値を使用できます)。 優先順位の高いチャネルは、クライアント側のオブジェクトに接続する最初の機会を得ます。サーバー チャネルとして機能する場合、そのチャネル データは最初に確認されます。

displayName: チャネル情報をユーザーに表示するために、管理 ツールによって使用されます。 この属性は、テンプレート セクションでのみ使用されます。

delayLoadAsClientChannel: クライアントがアプリケーションのチャネルを登録しない場合に、このチャネルを読み込む必要があるかどうかを指定します。 この値は Boolean 値で、クライアントの動作にだけ影響します。 値 true は、リモート アクティブ化 URL で指定された特定のプロトコル スキームを使用してクライアント接続をサポートしているかどうかを確認するために、実行時に .NET リモート処理でこのチャネルをテストする必要があることを示します。 値が指定されない場合の既定値は false です。

customChannelProperty: チャネル属性の名前 /.value ペアを指定します。 チャネル プロパティはリモート処理によって指定されません。各チャネルの実装には独自の要件があります。 customChannelProperty という用語は、ここではディスカッション目的でのみ使用されます。

<channel id="CustomChannel" type="Namespace.CustomChannel, CustomChannels" myProperty="myValue"/>

アプリケーション チャネルには、次の属性を使用できます。

http チャネルの構成:

http チャネルには、次の追加の省略可能な属性があります。

port: は任意の有効なポート番号です。 チャネルがリッスンするポート。

clientConnectionLimit: 特定のサーバーに対して同時に開くことができる接続の数を指定します。 既定値は 2 です。 これは、net クラスの ServicePoint の接続制限とまったく同じです。

proxyName: プロキシ サーバーで使用するチャネルを構成できます。 プロキシ サーバーの名前は、こちらを参照してください

proxyPort: プロキシ サーバーで使用するチャネルを構成できます。 使用するポート番号は、こちらを参照してください。

listen: アクティブ化中にチャネルで IChannelReceiverHook.WantsToListen を呼び出す場合は、ここで true を指定します。 リッスン チャネルがない場合は、リモート処理によって独自のチャネルのいずれかが登録されます。 ポート番号を設定すると、この属性は false に設定されます。

suppressChannelData: チャネルが ObjRef に ChannelData を提供しない場合は、この値を false に設定します。

useIpAddress: URL で IP アドレスまたはコンピューター名が使用されているかどうかを判断できます。 この属性はサーバー側でのみ使用され、既定値は true です。

bindTo: マシンに複数の NIC がインストールされている場合にバインドする NIC の IP アドレスを指定します。 この属性は、サーバー側でのみ使用できます。

machineName: チャネル データで使用されるマシン名をオーバーライドします。 この属性は 、useIpAddress をオーバーライドします

TCP チャネルの構成:

TCP チャネルには、次の追加の省略可能な属性があります。

port: 任意の有効なポート番号。 チャネルがリッスンするポート。

suppressChannelData: チャネルが ObjRef に ChannelData を提供しない場合は、この値を false に設定します。

useIpAddress: URL で IP アドレスまたはコンピューター名が使用されているかどうかを判断できます。 この属性はサーバー側でのみ使用され、既定値は true です。

rejectRemoteRequests: 他の マシンからの接続を拒否します。 この属性が true に設定されている場合、クロスプロセス接続のみが許可されます。

bindTo: マシンに複数の NIC がインストールされている場合にバインドする NIC の IP アドレスを指定します。 この属性は、サーバー側でのみ使用できます。

次の例は、アプリケーション セクションでチャネルを宣言する方法を示しています。

<configuration>
  <system.runtime.remoting>
    <application name="RemotingHello">
      <lifetime leaseTime="20ms" sponsorshipTimeOut="20ms" 
renewOnCallTime="20ms" />  
      <service>
        <wellknown mode="SingleCall" type="Hello.HelloService, MyHello, 
Version=1.0.0.0, PublicKeyToken=bef6d8db915d3112,Culture=Neutral" 
objectUri="HelloService.soap" />
        <activated type="Hello.AddService, MyHello"/>
      </service>
      <channels>
        <channel pipename="mypipe" 
type="Microsoft.Samples. Runtime.Remoting.Channels.Pipe.PipeChannel, 
Microsoft.Samples.Runtime.Remoting.Pipe">
         </channel>  
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

次の例では、テンプレート セクションでチャネルを宣言し、それをアプリケーション セクションから参照する方法を示します。

<configuration>
  <system.runtime.remoting>
    <application name="RemotingHello">
      <lifetime leaseTime="20ms" sponsorshipTimeOut="20ms" 
renewOnCallTime="20ms" />  
      <service>
        <wellknown mode="SingleCall" type="Hello.HelloService, MyHello, 
Version=1.0.0.0, PublicKeyToken=bef6d8db915d3112,Culture=Neutral" 
objectUri="HelloService.soap" />
        <activated type="Hello.AddService, MyHello"/>
      </service>
      <channels>
        <channel ref="pipe1" name="foo1" pipename="mypipe" />
      </channels>
    </application>
    <channels>
      <channel id="pipe1" 
type="Microsoft.Samples.Runtime.Remoting.Channels.Pipe.PipeChannel, 
Microsoft.Samples.Runtime.Remoting.Pipe">
       </channel> 
    </channels>
  </system.runtime.remoting>
</configuration>

<channelSinkProviders>

Parent 要素:

system.runtime.remoting

説明:

すべてのチャネル シンク関連のタグは、このタグの下に配置する必要があります。 これらの要素の 1 つだけが許可されます。

子要素:

clientProviders、serverProviders

必須の属性:

なし

省略可能な属性:

なし

<serverProviders>

Parent 要素:

system.runtime.remoting, channel

説明:

この要素がチャネル> タグ内に<配置されると、system.runtime.remoting> で<定義されている既存のシンク プロバイダーを構成するために使用されます。 この要素は、チャネル> タグ (テンプレートまたはアプリケーション内のテンプレート) の<下に配置できます。 新しいシンク プロバイダーを定義するには、system.runtime.remoting の直下に serverProviders> タグを<>配置します。< また、machine.config ファイルで既定のシンク プロバイダーを定義するため、新しいシンク プロバイダーを登録しない限り、このレベルでプロバイダーを定義する必要はありません。 これらの要素の 1 つだけが許可されます。

子要素:

フォーマッタ、プロバイダー

必須の属性:

なし

省略可能な属性:

なし

備考:

この要素がチャネル要素でフォーマッタまたはプロバイダーを参照または宣言する場合、チャネルのすべての既定のプロバイダー<>またはフォーマッタがオーバーライドされることを認識することが重要です。 この場合は、チャネルで使用するすべてのプロバイダーとフォーマッタを指定する必要があります。 プロバイダーとフォーマッタが一覧表示される順序は、シンク チェーンがアセンブルされる順序です。 たとえば、クライアント側でフォーマッタの前にプロバイダーを追加すると、プロバイダーがフォーマッタに必要なインターフェイスを実装していない場合、例外がスローされます。

<clientProviders>

Parent 要素:

system.runtime.remoting, channel

説明:

この要素がチャネル> タグ内に<配置されると、system.runtime.remoting> で<定義されている既存のシンク プロバイダーを構成するために使用されます。 新しいシンク プロバイダーを定義するには、system.runtime.remoting の直下に clientProviders> タグを<>配置します。< 既定のシンク プロバイダーはmachine.config ファイルで定義されているため、新しいシンク プロバイダーを登録しない限り、このレベルでプロバイダーを定義する必要はありません。 これらの要素の 1 つだけが許可されます。

子要素:

フォーマッタ、プロバイダー

必須の属性:

なし

省略可能な属性:

なし

備考:

この要素がチャネル要素でフォーマッタまたはプロバイダーを参照または宣言する場合、チャネルのすべての既定のプロバイダー<>またはフォーマッタがオーバーライドされることを認識することが重要です。 この場合は、チャネルで使用するすべてのプロバイダーとフォーマッタを指定する必要があります。 プロバイダーとフォーマッタが一覧表示される順序は、シンク チェーンがアセンブルされる順序です。 たとえば、クライアント側でフォーマッタの前にプロバイダーを追加すると、プロバイダーがフォーマッタに必要なインターフェイスを実装していない場合、例外がスローされます。

<プロバイダー>

Parent 要素:

clientProviders、serverProviders

説明:

チャネル シンク チェーンに挿入されるチャネル シンクの指定されたチャネル シンク プロバイダー。 このタグは、serverProvider または clientProvider> の下<に配置できます。>< これらの要素の 0 個以上を使用できます。

子要素:

なし

必須の属性:

id: id は、プロバイダーを参照するためにアプリケーション セクションで使用する名前を指定します。

type: 型は、このプロバイダーのインスタンス化が必要なクラス/アセンブリを指定します。

ref: チャネルで使用するプロバイダー テンプレートの ID を指定します。 この属性は、プロバイダー テンプレート自体では使用できません。

省略可能な属性:

プロパティ: プロバイダーの追加のプロパティを指定します。 指定するプロパティは、プロバイダー自体によって決まります。 ノードの下のすべてのデータが DOM 構造体として渡されるため、XML タグの名前は重要ではありません。

ノード上のすべての XML 属性と、プロバイダー ノードの下にある XML セクションは"パッケージ化" され、リモート処理によって構成ファイルで指定されたプロバイダーが作成されるときに、プロバイダーのコンストラクターに渡されます。 構成ファイルで指定されるすべてのプロバイダーには、IDictionary と ICollection をパラメーターとして受け取るコンストラクターが必要です。 ディクショナリには、プロバイダー ノードで指定された XML 属性が含まれます。 コレクションは常に、サブノードの DOM 構造である SinkProviderData のコレクションです。

例:

<configuration>
<system.runtime.remoting>
<application name="MyFoo">
  <service>
    <wellknown type="Foo, common" objectUri="Foo.soap" mode="Singleton" 
/>
  </service>
  <channels>
    <channel ref="http server" name="MyHttpChannel" port="9000">
      <serverProviders>        
        <provider ref="ip filter" mode="accept">
          <filter mask="255.255.255.255" ip="127.0.0.1" />          
        </provider>
        <formatter ref="soap" />
      </serverProviders>
    </channel>
  </channels>
</application>
<channelSinkProviders>
  <serverProviders>
    <provider id="ip filter" 
type="IPFilter.IPFilterChannelSinkProvider, IPFilterSink" />
  </serverProviders>
</channelSinkProviders></system.runtime.remoting>
</configuration>

<フォーマッタ>

Parent 要素:

clientProviders、serverProviders

説明:

チャネル シンク チェーンに挿入されるフォーマッタを指定するために使用します。 このタグは、serverProvider または clientProvider> の下<に配置できます。>< これらの要素の 0 個以上を使用できます。

子要素:

なし

必須の属性:

id: id は、フォーマッタを参照するためにアプリケーション セクションで使用する名前を指定します。

type: 型は、このフォーマッタのインスタンス化が必要なクラス/アセンブリを指定します。

ref: チャネルで使用するフォーマッタ テンプレートの ID を指定します。 この属性はフォーマッタ テンプレート自体では使用できません。

省略可能な属性:

includeVersions: 型をシリアル化するときに、フォーマッタに完全なバージョン管理を含める必要があることを指定します。

strictBinding: オブジェクトの逆シリアル化時にフォーマッタが部分バインドを使用しないように指定します。 false に設定すると、型は厳密な名前を使用して読み込まれます。 これが失敗した場合、部分バインドを使用して型が読み込まれます。 これが失敗した場合は、例外がスローされます。

プロパティ: フォーマッタの追加のプロパティを指定します。 指定できるプロパティは、フォーマッタ自体によって決まります。 ノードの下のすべてのデータが DOM 構造体として渡されるため、XML タグの名前は重要ではありません。

ノード上のすべての XML 属性とフォーマッタ ノードの下にある XML セクションは"パッケージ化" され、リモート処理によって構成ファイルで指定されたフォーマッタが作成されるときにフォーマッタのコンストラクターに渡されます。 構成ファイルで指定されるすべてのフォーマッタには、IDictionary と ICollection をパラメーターとして受け取るコンストラクターが必要です。 ディクショナリには、フォーマッタ ノードで指定された XML 属性が含まれます。 コレクションは常に、サブノードの DOM 構造である SinkProviderData のコレクションです。

<soapInterop>

Parent 要素:

system.runtime.remoting

説明:

SOAP で使用される型マッピングを指定します。

子要素:

preLoad、interopXmlElement、interopXmlType

必須の属性:

なし

省略可能な属性:

なし

<プリロード>

Parent 要素:

soapInterop

説明:

SoapAttribute を拡張するすべてのクラスのマッピングを読み込みます。 これらの型はシリアル化のために自動的に取得されますが、.NET リモート処理システムでは、正しく逆シリアル化するために、これらの構成要素 (またはプログラムと同等のを呼び出す) が必要です。

子要素:

なし

必須の属性:

なし

省略可能な属性:

type: 逆シリアル化を有効にするために事前に読み込む型を指定します。

assembly: 指定したアセンブリ内のすべての型を事前に読み込みます。

次の例では、 要素 ElementName と XML 名前空間 Example:mynamespace を、アセンブリによって実装される .NET 型 TypeName AssemblyName 関連付けます。 XML の型および名前空間についても同様です。

<configuration>
   <system.runtime.remoting>
      <application name="soapInterop">
         <soapInterop>
            <interopXmlElement 
               xml="ElementName,Example:mynamespace"                
clr="TypeName,AssemblyName"
            />
            <interopXmlType  
               xml="XmlTypeName,Example:TypeNamespace" 
               clr="TypeName,AssemblyName"
            />
            <preLoad
               type="TypeName"
               assembly="AssemblyName"
         </soapInterop>
      </application>
   </system.runtime.remoting>
</configuration>

<interopXmlElement>

Parent 要素:

soapInterop

説明:

共通言語ランタイム型と XML 要素と XML 名前空間の間に双方向マップを作成します。 1 回以上発生する可能性があります。

子要素:

なし

必須の属性:

clr: XML 要素と XML 名前空間へのマッピングを作成する型の完全な型名とアセンブリ名を指定します。

xml: 型とアセンブリへのマッピングを作成する XML 要素と XML 名前空間を指定します。

省略可能な属性:

なし

例:

次の例では、 要素 ElementName と XML 名前空間 Example:mynamespace を、アセンブリによって実装される .NET 型 TypeName AssemblyName 関連付けます。 XML の型および名前空間についても同様です。

<configuration>
   <system.runtime.remoting>
      <application name="soapInterop">
         <soapInterop>
            <interopXmlElement 
               xml="ElementName,Example:mynamespace"                
clr="TypeName,AssemblyName"
            />
            <interopXmlType  
               xml="XmlTypeName,Example:TypeNamespace" 
               clr="TypeName,AssemblyName"
            />
         </soapInterop>
      </application>
   </system.runtime.remoting>
</configuration>

<interopXmlType>

Parent 要素:

soapInterop

説明:

要素名を変更できない場合に、共通言語ランタイム型と XML 要素と XML 名前空間の間に双方向マップを作成します。 これらの要素の 1 つだけが許可されます。

子要素:

なし

必須の属性:

clr: XML 型と XML 名前空間へのマッピングを作成する型の完全な型名とアセンブリ名を指定します。

xml: 型とアセンブリへのマッピングを作成する XML 型名と XML 型名前空間を指定します。

省略可能な属性:

なし

例:

次の例では、 要素 ElementName と XML 名前空間 Example:mynamespace を、アセンブリによって実装される .NET 型 TypeName AssemblyName 関連付けます。 XML の型および名前空間についても同様です。

<configuration>
   <system.runtime.remoting>
      <application name="soapInterop">
         <soapInterop>
            <interopXmlElement 
               xml="ElementName,Example:mynamespace"                
clr="TypeName,AssemblyName"
            />
            <interopXmlType  
               xml="XmlTypeName,Example:TypeNamespace" 
               clr="TypeName,AssemblyName"
            />
         </soapInterop>
      </application>
   </system.runtime.remoting>
</configuration>

<デバッグ>

Parent 要素:

system.runtime.remoting

説明:

アプリケーションの起動時に、構成ファイル内に指定されている型を読み込んでおくかどうかを指定します。 構成ファイルに web.configという名前が付けられ、リモートの種類が IIS でホストされている場合、この要素を指定できません。

子要素:

なし

必須の属性:

loadTypes: アプリケーションの起動時に構成ファイルで指定されたすべての型を読み込むかどうかを指定します。 これは、単純な入力エラーが面倒なデバッグ作業になるのを防ぐのに役立ちます。

省略可能な属性:

なし

例:

次の構成ファイルの例では、クライアント アプリケーションの起動時に、このファイルで指定された型 (この場合は ServiceClass 型と TcpChannel 型) を読み込もうとするように .NET リモート処理システムに指示します。

<configuration>
   <system.runtime.remoting>
      <application>
         <client>
            <wellknown 
               type="ServiceClass, IService"
               url="tcp://computername:8080/TcpService"
            />
         </client>
         <channels>
            <channel ref="tcp"/>
         </channels>
      </application>
      <debug loadTypes="true" />
   </system.runtime.remoting>
</configuration>

構成ファイルの名前付け規則

構成ファイルは、バインド ポリシーやセキュリティなどの設定を格納するためにも使用されます。 すべての EXE ホストと COM ホストは、作成するアプリケーション ドメインの構成ファイルを自動的に生成します。 この構成ファイルの名前は、拡張子を含む完全なモジュール名です。 そのため、foo.exeの場合、構成ファイル名がfoo.exe.configされます。.NET リモート処理では構成ファイルの名前は必須ではありませんが、開発者は上記の名前付け規則を使用して、指定されたセキュリティ ポリシーとバインド ポリシーがアプリケーションの実行時に確実に取得されるようにすることをお勧めします。

アプリケーション構成ファイルの名前は、次のように AppDomain から取得できます。

String configfilename = 
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;

状況によっては、複数の構成ファイルを使用してリモート アプリケーションを構成することが望ましい場合があります。 したがって、開発者は、アプリケーションの実行時に読み取られないため、セキュリティまたはバインド ポリシーを格納するためにこれらの追加のリモート処理構成ファイルを使用しないようにする必要があります。 RemotingConfiguration の構成呼び出しでは、リモート処理に適用される構成ファイル内の関連するセクションのみが読み取られます。残りの情報は無視されます。