Microsoft .NET リモート処理フレームワークの概要

[アーティクル]
04/05/2007

水田スリニヴァサン
Microsoft Corporation

概要： この記事では、Microsoft .NET Remoting Framework の基礎について説明します。このドキュメントでは、.NET リモート処理フレームワークを構成するメインコンポーネントについて説明するだけでなく、.NET リモート処理を使用して分散オブジェクトと通信できるさまざまなシナリオについて説明します。 (11ページ印刷)

メモこの記事には、更新されたベータ 2 コードが含まれています。

内容

はじめに
.NET リモート処理オブジェクト
.NET リモート処理オブジェクトのホスト
.NET リモート処理メタデータと構成ファイル
.NET リモート処理のシナリオ
まとめ
もっと読む

はじめに

Microsoft® .NET Remoting は、異なる AppDomains、異なるプロセス、および異なるマシンに住むオブジェクトがシームレスに通信するための、豊富で拡張可能なフレームワークを提供します。 .NET リモート処理では、これらの対話を透過的にするための強力でシンプルなプログラミングモデルとランタイムサポートが提供されます。この記事では、リモート処理アーキテクチャのさまざまな構成要素を見て、.NET リモート処理を利用できる一般的なシナリオをいくつか説明します。 .NET リモート処理の概要については、まず「Microsoft .NET リモート処理: 技術的な概要」の記事を参照してください。

.NET リモート処理オブジェクト

.NET リモートオブジェクトとして機能するように構成できるオブジェクトには、3 つの種類があります。アプリケーションの要件に応じて、オブジェクトの種類を選択できます。このセクションでは、次のオブジェクトについて詳しく説明します。

1 回の呼び出し
単一呼び出しオブジェクトは、1 つの要求のみを受け入れるサービスを提供します。単一呼び出しオブジェクトは、オブジェクトが有限の作業を行う必要があるシナリオで役立ちます。通常、単一呼び出しオブジェクトは状態情報を格納するために必要ではなく、メソッド呼び出し間で状態情報を保持することはできません。ただし、単一呼び出しオブジェクトは負荷分散された方法で構成できます。
**シングルトンオブジェクト
**Singleton オブジェクトは、複数のクライアントにサービスを提供し、クライアント呼び出し間で状態情報を格納することによってデータを共有するオブジェクトです。これらは、クライアント間でデータを明示的に共有する必要がある場合や、オブジェクトの作成と保守のオーバーヘッドが大きい場合に便利です。
**クライアントでアクティブ化されたオブジェクト (CAO)
**クライアントアクティブ化オブジェクト (CAO) は、クライアントからの要求に応じてアクティブ化されるサーバー側オブジェクトです。サーバーオブジェクトをアクティブ化するこの方法は、従来の COM コクラスアクティブ化とよく似ています。クライアントが "new" 演算子を使用してサーバーオブジェクトの要求を送信すると、アクティブ化要求メッセージがリモートアプリケーションに送信されます。その後、サーバーは要求されたクラスのインスタンスを作成し、それを呼び出したクライアントアプリケーションに ObjRef を返します。その後、ObjRef を使用してクライアント側にプロキシが作成されます。クライアントのメソッド呼び出しはプロキシで実行されます。クライアントでアクティブ化されたオブジェクトは、異なるクライアントオブジェクト間ではなく、その特定のクライアントのメソッド呼び出しの間に状態情報を格納できます。 "new" を呼び出すたびに、サーバーの種類の独立したインスタンスにプロキシが返されます。

.NET リモート処理を使用してオブジェクトを渡す

.NET リモート処理では、次の方法でオブジェクトを 1 つのアプリケーションから別のアプリケーションに渡すことができます。

メソッド呼び出しのパラメーターとして

例: public int myRemoteMethod(MyRemoteObject myObj)
メソッド呼び出しの戻り値

例: public MyRemoteObjectmyRemoteMethod(String myString)
.NET コンポーネントのプロパティまたはフィールドアクセスの結果の値

例:myObj.myNestedObject

値によるマーシャリング (MBV) のオブジェクトの場合、オブジェクトがアプリケーション間で渡されるときに、オブジェクトの完全なコピーが作成されます。

参照によるマーシャリング (MBR) オブジェクトの場合、あるアプリケーションから別のアプリケーションに渡されると、オブジェクトへの参照が作成されます。オブジェクト参照 (ObjRef) がリモートアプリケーションに到着すると、元のオブジェクトへの "プロキシ" に戻されます。

単純な .NET リモート処理サーバーオブジェクトのサンプルコード

using System;
using System.Runtime.Remoting;
namespace myRemoteService
{
    // Well Known Web Service object
    public class myRemoteObject : MarshalByRefObject
    {
        // Method myRemoteMethod
        public String myRemoteMethod(String s) 
        {
         return "Hello World";
        }
    }
}

このオブジェクトにアクセスするためのサンプルクライアントコード

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using myRemoteService;
public class Client
{
    public static int Main(string[] args)
    {
        ChannelServices.RegisterChannel(new HttpChannel());
      // Create an instance of a myRemoteObject class 
   myRemoteObject myObj = ( myRemoteObject)Activator.GetObject(typeof(myRemoteObject),
            "http://myHost:7021/host/myRemoteObject.soap");
      myObj. myRemoteMethod ("Hello World");
        return 0;
    }
}

リースベースの有効期間

アプリケーションの外部で転送されるオブジェクト参照を持つオブジェクトの場合は、リースが作成されます。リースにはリース時間があります。リースが 0 に達すると、有効期限が切れ、オブジェクトが .NET リモート処理フレームワークから切断されます。 AppDomain 内のオブジェクトへのすべての参照が解放されると、次のガベージコレクションが発生したときにオブジェクトが収集されます。リースは、オブジェクトの有効期間を制御します。

オブジェクトには既定のリース期間がありますが、クライアントが同じサーバーオブジェクトで状態を維持する場合に備えて、オブジェクトを維持するためにリース期間を延長する方法は多数あります。

サーバーオブジェクトはリース時間を無限大に設定できます。これにより、ガベージコレクションサイクル中にリモート処理で収集しないように指示されます。
クライアントは RemotingServices.GetLifetimeService メソッドを呼び出して、AppDomain のリースマネージャーからサーバーオブジェクトのリースを取得できます。リースオブジェクトから、クライアントは Lease.Renew メソッドを呼び出してリースを拡張できます。
クライアントは、特定のリースのスポンサーを AppDomain のリースマネージャーに登録できます。リモートオブジェクトのリースの有効期限が切れると、リースマネージャーはスポンサーに電話をかけ直してリースの更新を要求します。
ILease::RenewOnCallTime プロパティが設定されている場合、リモートオブジェクトを呼び出すたびに、RenewOnCallTime プロパティで指定された時間だけリースが更新されます。

	単一呼び出し/シングルトンオブジェクト	クライアント側でアクティブ化されるオブジェクト
クライアント側のアクティブ化コード (クライアント側でコードが必要) 詳細については、構成ファイルに関するセクションを参照してください。	a) Activator.GetObject() b) new() with CFG file クライアントの CFG ファイルは URL を参照します。 Foo= https://localhost:80/ObjectZone/Foo.soap	a) Activator.CreateInstance() b) new() with CFG file クライアントの CFG ファイルが URL を参照しています。次に例を示します。 https://localhost:80/ObjectZone
サーバーオブジェクトのアクティブ化	最初のメソッド呼び出しが行われるまで、アクティブ化メッセージはネットワーク経由で送信されません。	クライアントがオブジェクトを作成し、クライアント側でプロキシを作成すると、アクティブ化メッセージがサーバーコンピューターに送信されます。パラメーターを持つコンストラクターがサポートされています。
サーバーオブジェクトの有効期間	有効期間は、サーバー上の構成によって決まります。 SingleCall または Singleton のいずれかです。シングルトンオブジェクトも有効期間管理の対象となります。	有効期間は、次の 2 つのイベントの早い段階です。 a) リースの有効期限が切れる b) クライアントがサーバーオブジェクトの参照を失った場合
サーバー側の登録	a) 構成ファイルを使用して型 (SingleCall または Singleton) を指定します。 b) RegisterWellKnownServiceType() api を使用して型を登録します。	構成ファイルを使用して、クライアントでアクティブ化されたオブジェクトをエクスポートします。詳細については、構成ファイルに関するセクションを参照してください。
モデルの利点	a) クライアントは、サーバーコンポーネントの基本クラスまたはインターフェイス定義の共通言語ランタイムメタデータに対してコンパイルできます。 b) サーバー側で有限の操作を実行するのに役立ちます。 c) 単一呼び出しオブジェクトは、状態を保持しないため、負荷分散システムに簡単にデプロイできます。 d) シングルトンオブジェクトは、クライアントオブジェクト間で状態情報を保持できます。	a) サーバーオブジェクトの呼び出しのような従来の COM "コクラス"。 b) クライアントは、サーバーオブジェクトの有効期間をより柔軟に管理できます。 c) クライアントは、作成されたオブジェクトにコンストラクターパラメーターを渡すことができます。 d) サーバーオブジェクトは、メソッド呼び出しの間に特定のクライアントの状態を保持できます。

.NET リモート処理オブジェクトのホスト

.NET リモート処理オブジェクトは、次の中でホストできます。

**マネージド実行可能ファイル
**NET リモート処理オブジェクトは、通常の .NET EXE またはマネージドサービスでホストできます。
**Iis
**リモート処理オブジェクトは、インターネットインフォメーションサーバー (IIS) でホストできます。既定では、IIS でホストされているリモート処理オブジェクトは、HTTP チャネルを介してメッセージを受信します。 IIS でリモート処理オブジェクトをホストするには、仮想ルートを作成し、"remoting.config" ファイルをコピーする必要があります。リモートオブジェクトを含む実行可能ファイルまたは DLL は、IIS ルートが指すディレクトリの下の bin ディレクトリに配置する必要があります。 IIS ルート名は、構成ファイルで指定されたアプリケーション名と同じである必要があることに注意してください。リモート処理構成ファイルは、最初のメッセージがアプリケーションに到着すると自動的に読み込まれます。これにより、.NET リモート処理オブジェクトを Web サービスとして公開できます。

Remoting.cfg ファイルのサンプル:
```
<configuration>
  <system.runtime.remoting>
    <application name="RemotingHello">

      <service>
        <wellknown mode="SingleCall" 
                   type="Hello.HelloService, Hello" 
                   objectUri="HelloService.soap" />
      </service>

      <channels>
        <channel port="8000" 
type="System.Runtime.Remoting.Channels.Http.HttpChannel, 
System.Runtime.Remoting" />
      </channels>

    </application>
  </system.runtime.remoting>
</configuration>
```
**.NET コンポーネントサービス
**NET リモート処理オブジェクトは、トランザクション、JIT、オブジェクトプールなどのさまざまな COM+ サービスを利用するために、.NET コンポーネントサービスインフラストラクチャでホストできます。

詳細については、「Microsoft .NET Framework コンポーネントサービス、パート 1」を参照してください。

Channel Services (System.Runtime.Remoting.Channels)

.NET アプリケーションと AppDomains は、メッセージを使用して相互に通信します。 .NET Channel Services は、この通信の基になるトランスポートメカニズムを提供します。

.NET Frameworkは HTTP チャネルと TCP チャネルを提供しますが、サードパーティは独自のチャネルを書き込んでプラグインできます。 HTTP チャネルは既定で SOAP を使用して通信しますが、TCP チャネルでは既定でバイナリペイロードが使用されます。

チャネルサービスは、異種アプリケーションを統合するために記述できるカスタムチャネルを使用してプラグ可能です (IChannel を使用)。

チャネルサービスを読み込むサンプルコード

public class myRemotingObj
{
    HttpChannel httpChannel;
    TcpChannel tcpChannel;
    public void myRemotingMethod()
    {
httpChannel =  new HttpChannel();
tcpChannel  =  new TcpChannel();
        ChannelServices.RegisterChannel(httpChannel);
// Register the HTTP Channel 
        ChannelServices.RegisterChannel(tcpChannel);
// Register the TCP Channel  


    }
}

シリアル化フォーマッタ (System.Runtime.Serialization.Formatters)

.NET シリアル化フォーマッタは、.NET アプリケーションと AppDomains の間でメッセージをエンコードおよびデコードします。 .NET ランタイムには、Binary(System.Runtime.Serialization.Formatters.Binary) と SOAP (System.Runtime.Serialization.Formatters.Soap) という 2 つのネイティブフォーマッタがあります。

シリアル化フォーマッタは、IRemotingFormatter インターフェイスを実装し、上記のチャネルに接続することでプラグ可能です。このプロセスは、このドキュメントの後のセクションで説明しますが、アプリケーションに最適なチャネルとフォーマッタの組み合わせを柔軟に選択できます。

例：バイナリデータをシリアル化するバイナリフォーマッタを使用する HTTP チャネルと、SOAP 書式設定を使用した TCP チャネルを使用できます。

リモート処理コンテキスト

コンテキストは、共通のランタイムプロパティを共有するオブジェクトを含む境界です。コンテキスト属性の例としては、同期とスレッドアフィニティがあります。 .NET オブジェクトがアクティブ化されると、ランタイムは現在のコンテキストに互換性があるかどうかを確認し、互換性がない場合は、新しいコンテキストが作成されます。 1 つのコンテキストで複数のオブジェクトを同時に実行でき、AppDomain には複数のコンテキストを含めることができます。

あるコンテキスト内のオブジェクトから別のコンテキスト内のオブジェクトへの呼び出しは、コンテキストプロキシを経由し、組み合わせたコンテキストプロパティによって適用されるポリシーの影響を受けます。新しいオブジェクトのコンテキストは、通常、クラスのメタデータ属性に基づいて選択されます。

コンテキストにバインドされるクラスは、コンテキストバインドクラスと呼ばれます。コンテキストバインドクラスは、コンテキスト属性と呼ばれる特殊なカスタム 属性を使用して属性付けできます。コンテキスト属性は完全に拡張可能であり、これらの属性を作成してクラスにアタッチできます。コンテキストにバインドされているオブジェクトは、 System.ContextBoundObject から派生します。

.NET リモート処理メタデータと構成ファイル

Metadata

.NET Frameworkでは、メタデータとアセンブリを使用してコンポーネントに関する情報を格納し、言語間プログラミングを可能にします。 .NET リモート処理では、メタデータを使用してプロキシオブジェクトを動的に作成します。クライアント側で作成されるプロキシオブジェクトには、元のクラスと同じメンバーがあります。ただし、プロキシオブジェクトの実装では、.NET リモート処理ランタイムを通じてすべての要求が元のオブジェクトに転送されます。シリアル化フォーマッタはメタデータを使用して、メソッド呼び出しをペイロードストリームに変換して戻します。

クライアントは、次の方法でリモートオブジェクトにアクセスするために必要なメタデータ情報を取得できます。

サーバーオブジェクトの .NET アセンブリ — サーバーオブジェクトは、メタデータアセンブリを作成してクライアントに配布できます。クライアントオブジェクトは、クライアントオブジェクトのコンパイル中にアセンブリを参照できます。これは、クライアントとサーバーがマネージドコンポーネントである閉じたシナリオで非常に便利です。
リモート処理オブジェクトは、オブジェクトとそのメソッドを記述する WSDL (Web サービス記述言語 (WSDL) 1.1 を参照) ファイルを提供できます。 WSDL ファイルに対応する SOAP 要求を読み取って生成できるクライアントは、このオブジェクトを呼び出し、SOAP を使用して通信できます。 .NET リモート処理サーバーオブジェクトは、.NET SDK に付属する SOAPSUDS.EXE ツールを使用して、メタデータとして機能する WSDL ファイルを生成できます。これは、organizationが任意のクライアントがアクセスして使用できるパブリックサービスを提供する場合に便利です。
.NET クライアントは、SOAPSUDS ユーティリティを使用して、(サーバー上で生成された) サーバーから XML スキーマをダウンロードして、ソースファイルまたはメタデータのみを含み、コードを含まないアセンブリを生成できます。必要に応じて、ソースファイルをクライアントアプリケーションにコンパイルできます。このメソッドは、ある層のオブジェクトが別の層のリモートオブジェクトにアクセスする多層アプリケーションで役立ちます。

構成ファイル

構成ファイル (.config ファイル) は、特定のオブジェクトのさまざまなリモート処理固有の情報を指定するために使用されます。通常、各 AppDomain には独自の構成ファイルがあります。構成ファイルを使用すると、場所の透明性を実現するのに役立ちます。構成ファイルで指定された詳細は、プログラムで実行することもできます。構成ファイルを使用するメイン利点は、ソースファイルの編集と再コンパイルではなく、構成ファイルを変更するだけで将来の変更を行えるように、クライアントコードに対して透過的な構成情報を分離することです。構成ファイルは、.NET リモート処理クライアントオブジェクトとサーバーオブジェクトの両方で使用されます。

一般的な構成ファイルには、次のような情報が含まれます。

ホストアプリケーション情報
オブジェクトの名前
オブジェクトの URI
登録されているチャネル (複数のチャネルを同時に登録できます)
サーバーオブジェクトのリース時間情報

構成ファイルの例を次に示します (この形式は今後のリリースで XML に変更される可能性があることに注意してください)。

<configuration>
  <system.runtime.remoting>
    <application name="HelloNew">

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

      <client url="https://localhost:8000/RemotingHello">
        <wellknown type="Hello.HelloService, MyHello" 
      url="https://localhost:8000/RemotingHello/HelloService.soap" />
        <activated type="Hello.AddService, MyHello"/>
      </client>
      
      <channels>
        <channel port="8001" 
      type="System.Runtime.Remoting.Channels.Http.HttpChannel, 
      System.Runtime.Remoting" />
      </channels>
      
    </application>
  </system.runtime.remoting>
</configuration>

.NET リモート処理のシナリオ

.NET リモート処理のしくみを理解したので、さまざまなシナリオを見て、それぞれのシナリオで .NET リモート処理を最適に使用する方法を調べてみましょう。次の表に、クライアントとサーバーの組み合わせと、既定で使用される基になるプロトコルとペイロードの一覧を示します。 .NET Remoting Framework は拡張可能であり、独自の通信チャネルとシリアル化フォーマッタを記述できる点に注意してください。

クライアント	サーバー	ペイロード	Protocol
.NET コンポーネント	.NET コンポーネント	SOAP/XML	http
.NET コンポーネント	.NET コンポーネント	Binary	TCP
マネージド/アンマネージド	.NET Web Services	SOAP/XML	http
.NET コンポーネント	アンマネージクラシック COM コンポーネント	NDR (ネットワークデータ表現)	DCOM
アンマネージドクラシック COM コンポーネント	.NET コンポーネント	Ndr	DCOM

ANY Client <-> HTTP-SOAP を使用した .NET

Web サービスは、URL アドレス指定可能なリソースであり、使用するクライアントにプログラムによって情報を返します。クライアントは、実装の詳細を気にせずに Web サービスを使用できます。 Web サービスは、Web サービス記述言語 (WSDL) ファイルを使用して記述されるコントラクトと呼ばれる適切に定義されたインターフェイスを使用します。 WSDL の詳細については、「Web サービス記述言語 (WSDL) 1.0」を参照してください。

.NET リモート処理オブジェクトは、IIS でホストすることで Web サービスとして公開できます。 WSDL ファイルを使用できるクライアントは、WSDL ファイルで指定されたコントラクトに従って、リモートオブジェクトに対して SOAP 呼び出しを行うことができます。 IIS は、ISAPI 拡張機能を使用して適切なオブジェクトに要求をルーティングします。したがって、リモート処理オブジェクトは Web サービスオブジェクトとして機能し、豊富な.NET Frameworkインフラストラクチャを活用できます。この構成は、さまざまなプラットフォームまたは環境のプログラムからオブジェクトにアクセスする場合に便利です。 Web サービスの詳細については、「プログラミング可能な Web: Web サービスは Microsoft .NET Frameworkの構成要素を提供する」を参照してください。この構成により、クライアントはファイアウォール経由で .NET オブジェクトに簡単にアクセスできます。

図 1. HTTP-SOAP を介してリモート処理オブジェクトの Web サービスを呼び出すクライアントの例

SOAP-HTTP> チャネルを使用した .NET<-.NET

HTTP チャネルは既定で SOAP フォーマッタを使用するため、クライアントがインターネット経由でオブジェクトにアクセスするシナリオで使用できます。この方法では HTTP を使用するため、ファイアウォールを介してリモートで .NET オブジェクトにアクセスすることは、この構成によって有効になります。この方法で公開されるオブジェクトは、前のセクションで説明したように、IIS でこれらのオブジェクトをホストするだけで、Web サービスオブジェクトとして簡単に構成できます。クライアントは、これらのオブジェクトの WSDL ファイルを読み取り、SOAP を使用してリモートオブジェクトと通信できます。

TCP チャネルを使用した .NET<->.NET

TCP チャネルでは、既定でバイナリフォーマッタが使用されます。このフォーマッタは、データをバイナリ形式でシリアル化し、生ソケットを使用してネットワーク経由でデータを送信します。この方法は、オブジェクトがファイアウォールの範囲内で閉じられた環境にデプロイされている場合に最適です。この方法は、ソケットを使用してオブジェクト間でバイナリデータを通信するため、より最適化されています。 TCP チャネルを使用してオブジェクトを公開すると、閉じた環境でのオーバーヘッドが少なくなります。ファイアウォールと構成の問題のため、この方法をインターネット経由で使用することはできません。

図 2. TCP チャネルを使用してコンピューターの境界を越えてリモート処理オブジェクトを呼び出すクライアントの例

.NET <-> アンマネージド COM コンポーネント <-> .NET

COM 相互運用サービスを介してアンマネージクラシック COM コンポーネントを呼び出す可能性があります。 .NET リモート処理クライアントオブジェクトが COM オブジェクトのインスタンスを作成すると、オブジェクトは、実際のアンマネージドオブジェクトのプロキシとして機能するランタイム呼び出し可能ラッパー (RCW) を介して公開されます。これらのラッパーは、.NET クライアントの他のマネージドクラスと同じように見えますが、実際には、マネージド (.NET) コードとアンマネージド (COM) コードの間で呼び出しをマーシャリングするだけです。

同様に、.NET リモート処理サーバーオブジェクトを従来の COM クライアントに公開できます。 COM クライアントが .NET オブジェクトのインスタンスを作成すると、オブジェクトは、実際のマネージドオブジェクトのプロキシとして機能する COM 呼び出し可能ラッパー (CCW) を介して公開されます。

どちらのシナリオでも、通信に DCOM が使用されます。この相互運用性は、クラシック COM と .NET コンポーネントが混在するシナリオで非常に便利です。

まとめ

Microsoft .NET Frameworkは、堅牢でスケーラブルな分散システムを開発するための、強力で拡張可能な言語に依存しないフレームワークを提供します。 .NET リモート処理フレームワークは、システムの要件に応じて、リモート操作を行う強力な方法を提供します。 .NET リモート処理は Web サービスとシームレスに統合され、複数のプラットフォーム間でアクセスするための .NET オブジェクトを公開する方法を提供します。

もっと読む

.NET リモート処理の詳細については、「 Microsoft .NET リモート処理: 技術的な概要」を参照してください。
Microsoft .NET の最新情報については、の Web サイトhttps://msdn.microsoft.com/net/をチェックしてください。