
	バージョン 6.3.3	検索索引目次 \| PDF BOOKS \| ホーム上へ戻る次へ

— オペレーション —

アクティベーションポリシー

このドキュメントでは、次のトピックについて説明します。

Windows 環境のアクティベーションポリシー
アクティベーションポリシーの設定
アクティベーションポリシーを使用するタイミング

Windows 環境のアクティベーションポリシー

あるクラスのオブジェクトの作成をクライアントが要求した場合は、DCOM が、クラスを提供するサーバープロセスを開始し、このプロセスに要求を渡します。 Natural クラスを担当するサーバープロセスは NaturalX サーバーです。 DCOM は、新しいサーバープロセスの開始時や実行中のサーバープロセスでのオブジェクトの作成時を制御するオプションを認識します。詳細については、「登録」を参照してください。 Natural クラスを REGISTER コマンドで登録する場合は、DCOM がこのクラスに使用するアクティベーションオプションを制御できます。 NaturalX では、DCOM でサポートされているさまざまなオプションを、次の 3 つのアクティベーションポリシーの形式で組み合わせます。

ExternalMultiple
Natural クラスがアクティベーションポリシー "ExternalMultiple" で登録され、クライアントがそのクラスのオブジェクトを要求すると、DCOM は要求されたオブジェクトを最初に現在のプロセスで作成しようとします。クライアント自体が NaturalX サーバーでもあり、クラス自体を提供できる場合があることに注意してください。現在のプロセスがクラス用のサーバーではない場合は、DCOM は新しい NaturalX サーバープロセスを開始し、そのプロセスでオブジェクトを作成します。後で同じクラスの 2 番目のオブジェクトが作成されると、このオブジェクトはそのサーバープロセスでも作成されます。つまり、1 つのサーバープロセスはクラスの複数のオブジェクトを含むことができます。
ExternalSingle
Natural クラスがアクティベーションポリシー "ExternalSingle" で登録されると、このクラスのオブジェクトが作成されるたびに、DCOM は新しい NaturalX サーバープロセスを開始します。 1 つのサーバープロセスはクラスのオブジェクトを 1 つだけ含むことができます。
InternalMultiple
Natural クラスがアクティベーションポリシー "InternalMultiple" で登録されると、DCOM は常に現在のプロセスでこのクラスのオブジェクトを作成します。 1 つのサーバープロセスはクラスの複数のオブジェクトを含むことができます。

デフォルトのアクティベーションポリシーは "ExternalMultiple" です。このデフォルトは、Natura パラメータ ACTPOLICY で定義され、コンフィグレーションユーティリティで変更できます。

アクティベーションポリシーの設定

クラスのアクティベーションポリシーは、次の順に 3 通りの方法で設定できます。

REGISTER コマンドの一部として明示的に
DEFINE CLASS ステートメントで
プロファイルパラメータ ACTPOLICY を使用して

アクティベーションポリシーを使用するタイミング

単純ではない DCOM アプリケーションは、ほとんどの場合、"パーシスタント" オブジェクト（データベースに保存されたオブジェクト）を処理します。このようなアプリケーションのために、データベースアクセス、トランザクション処理、およびユーザー分離についていくつか考慮する必要があります。次のシナリオを考えてみます。クライアント A と B の両方が、ある NaturalX サーバープロセスによって提供されるクラスのオブジェクトを作成します。そのオブジェクトをロードし保存するために、NaturalX サーバーがデータベースを使用します。両方のクライアントが同じサーバープロセスによって処理される場合は、それらはデータベースに単一ユーザーとして表示されます。これは、クライアント A からのメソッド呼び出しで開始されたトランザクションを、クライアント B からのメソッド呼び出しでコミットまたはバックアウトできることを意味します。このような衝突は、明らかに回避する必要があります。

この衝突を回避するためのアプローチは 2 つあります。クライアントでパーシスタントオブジェクトを使用しないようにするか、クライアントがそれぞれ独自の NaturalX サーバープロセスによって処理されるようにします。どちらのアプローチにも状況によってそれぞれ利点があります。データベースまたは他の共有リソースにアクセスしないクラスまたはアプリケーションの場合は、単一サーバープロセスで複数のクライアントを処理するのは便利です。データベースまたは他の共有リソースにアクセスするクラスの場合は、異なるサーバープロセスで異なるクライアントを分離する必要があります。したがって、両方のアプローチが有効です。アクティベーションポリシーは、登録時にクラスごとに起動動作を制御する方法を管理者に提供します。

例

この例では、さまざまなアクティベーションポリシーをどのように使用できるかについて説明します。架空の旅行代理店アプリケーションの一部を例に取ります。アプリケーションには、ビジネスクラス Trip、Skipper、および RoutePlanner があります。 Trip クラスは船旅の計画を表し、Skipper クラスは旅行を導くことができる船長を表します。 RoutePlanner クラスは、旅行の最適なルートを決定します。 Trip クラスと Skipperクラスは、オブジェクトの読み取りと保存にデータベースを使用します。 RoutePlanner クラスは、特定の Trip オブジェクトに関する計算を実行するだけで、データベースは使用しません。

ビジネスクラスのいくつかがデータベースへのトランザクションアクセスを使用し、トランザクションが複数のメソッド呼び出しにわたる可能性があるので、アクティブな各クライアントは独自の NaturalX サーバープロセスで処理される必要があります。これは、追加のクラス SagTours を定義することによって実行できます。このクラスは、アプリケーションセッションを表します。このクラスはセッションステータスの全般的な情報の保持などに使用できますが、メインタスクはクライアントの代わりにビジネスオブジェクトを作成することです。

クラス SagTours

* Represents a SagTours application session.
  *
  define class SagTours
    local using tour-ids
    id clsid-sagtours
  *
    interface Create  /* Used to create application objects. */
      id iid-sagtours-create
  *
      method newTrip  /* Creates a new Trip object. */
        is trip-n
        parameter
        1 trip handle of object by value result
      end-method
  

      method newSkipper   /* Creates a new Skipper object. */
        is skip-n
        parameter
        1 skipper handle of object by value result
      end-method
  *
  end-interface
  *
  end-class
  end

このクラスは "ExternalSingle" として登録されます。これは、SagTours オブジェクトが作成されるたびに、オブジェクトを要求したクライアントに対して NaturalX サーバープロセスが開始されることを意味します。クライアントは SagTours オブジェクトを 1 回だけ作成し、後でそのメソッドを使用して必要なビジネスオブジェクトを作成します。 Trip オブジェクトを作成するために、クライアントは次のように実装されるメソッド newTrip を呼び出します。

メソッド newTrip

* This method creates a new Trip object.
*
define data parameter
1 trip handle of object by value result
end-define
*
create object trip of class "Trip"
*
end

Trip クラス自体は "InternalMultiple" として登録されます。これは、メソッド newTrip によって作成された Trip オブジェクトが、このクライアント用に開始された NaturalX サーバープロセスで作成されることを意味します。

クラス RoutePlanner を見てみましょう。

クラス RoutePlanner

* Plans optimal routes for sailing trips.
  *
  define class RoutePlanner
    local using tour-ids
    id clsid-planner
  *
    interface routing
      id iid-planner-routing
  *
      method plan   /* Plans a sailing trip. */
        is plan-n
        parameter
        1 trip handle of object by value
      end-method
  *
    end-interface
  *
  end-class
  end

メソッド plan

* This method plans a sailing trip.
*
define data parameter
1 trip handle of object by value
end-define
*
* Perform some operations on the given Trip object.
*
end

このクラスは "ExternalMultiple" として登録できます。この場合は、異なるクライアントによって作成されたすべての RoutePlanner オブジェクトが、同じ NaturalX サーバープロセスで作成されます。このクラスのメソッドがデータベースにアクセスしない場合、または各データベーストランザクションが 1 つのメソッド内に完全に含まれている場合（つまり、各メソッドサブプログラムが BACKOUT TRANSACTION ステートメントまたは END TRANSACTION ステートメントで終わる場合）は、他に影響しません。

サンプルクライアントプログラムを見てみましょう。

サンプルクライアントプログラム

define data local
 sagTours handle of object
 trip handle of object
 planner handle of object
end-define
*
* Start the application session.
create object sagTours of "SagTours"
*
* Create a Trip object.
send "newTrip" to sagTours return trip
* Create a RoutePlanner object.
create object planner of "RoutePlanner"
* Plan the trip.
send "plan" to planner with trip
*
end

クライアントは、まず SagTours オブジェクトを作成します。これは、このクライアント用に新しい NaturalX サーバープロセスを排他的に開始します。クライアントは、次に SagTours オブジェクトを使用して、このアプリケーションセッションのコンテキスト内に Trip オブジェクトを作成します。クライアントが RoutePlanner オブジェクトを直接作成することに注意してください。これは、クラスが "ExternalMultiple" として登録されるので可能ですが、必要というわけではありません。SagTours クラスは RoutePlanner オブジェクトを作成するメソッドも提供できます。その後、ビジネスオブジェクトが各自のジョブを実行します。オブジェクトはプログラム終了時に自動的に解放されます。 SagTours オブジェクトが削除されると、NaturalX サーバーがシャットダウンします。

注意:
この例では、アクティベーションポリシーの使用方法を説明するために必要な NaturalX の手法のみを示しています。実際のアプリケーションでは、これより多くを必要とします。クラスは、オブジェクトデータエリアを使用し、必ずグローバルユニーク ID が割り当てられています。また、インラインパラメータ宣言の代わりにパラメータデータエリアが使用されます。

検索索引目次 | PDF BOOKS | ホーム上へ戻る次へ