作業域区画サービス

作業域区画サービスは、複数のカスタム作業域の作成を可能にする、作業域サービスの拡張機能です。作業域区画サービスはユーザーに対するオプションのサービスです。作業域サービスおよび UserWorkArea 区画を現在使用しているユーザーは、 それを同じ方法で継続して使用できます。UserWorkArea 区画は、それが使用不可にされていない限り、 作業域区画サービスにより自動的に作成されます。作業域区画サービスを介して 独自の作業域区画を作成するオプションがあることにより、区画へのアクセスおよび構成において、 ユーザーがより多くを制御できます。

作業域区画サービスは本来、UserWorkArea インターフェースのインスタンスを作成するためのファクトリーです。アプリケーションは UserWorkArea インターフェースおよびその実装を使用して、作業域と対話します。このインターフェースは、作業域を作成、操作、および完了するために使用されるすべてのメソッドを定義しています。 作業域区画サービスにより、ユーザーは、UserWorkArea インターフェースの独自の名前付きインスタンスを作成できます。 それぞれの名前付きインスタンスは、ユーザー定義の作業域区画 (略して区画) と呼ばれます。UserWorkArea インターフェース (区画) の各インスタンスは、その他のユーザー定義区画から分離されています。さらに、各種オプションを使用して区画を構成して、個別ユーザーのユース・ケースに固有のサービスの品質を提供できます。 「作業域区画サービス」パネルで指定された構成オプションは、作業域サービスには影響しません。

公開される UserWorkArea 区画とは異なり、作業域区画サービスにより 作成された作業域は、作成者にのみ既知であり、アクセス可能です。ただし、区画へのアクセスや操作を区画作成者に限定することが、 作業域区画サービスによって厳密に強制されるわけではありません。 作成者が自分の作業域区画の公表を希望し、 その区画リファレンスを Java ネーミングにバインディングすることにより、 またはその他の方法により、それを公開する場合、制限はありません。ただし、 特定の区画を他人に知られたくない場合、作業域区画サービスは可能な限り 区画の隠蔽を試みます。作業域区画サービスでは、作成されたすべての区画の名前の判別や照会を可能にするわけではありません。ただし、区画の作成者以外のユーザーによる、その区画へのアクセスを制限していません。UserWorkArea 区画やユーザー定義区画などの区画の コンテキストは、単一スレッドにスコープを限定されていて、マルチスレッドによる アクセスはできません。

ユーザーに戻された作業域区画参照は javax.naming.Referenceable および com.ibm.websphere.UserWorkArea を実装します。 したがって、区画を公開する場合、ユーザーはその区画を名前にバインドすることができます。 区画のバインドやアクセスに Java™ ネーミングを使用する代わりとして、 作業域区画マネージャー・インターフェースを使用することもできます。作業域区画マネージャー・インターフェースには 誰でもアクセス可能です。したがって、自分の区画を公開する場合、 必要なことは区画名を公開することのみです。これにより、公開された名前を使用して、他のユーザーが作業域区画 マネージャー・インターフェース上で getWorkAreaPartition メソッドを 呼び出すことができます。

WorkAreaPartitionManager.createWorkAreaPartition メソッドは、Java Platform, Enterprise Edition (Java EE) クライアントからのみ 使用できます。サーバー・サイドで作業域区画を作成するには、 管理コンソールを使用する必要があります。サーバー・サイドでは、サーバーの始動時に 作業域区画を作成する必要があります。これは、サーバーが始動してしまう前に、各区画を 適切な Web コラボレーターおよび Enterprise JavaBeans (EJB) コラボレーターに登録する必要があるからです。 カスタム作業域区画は作業域区画サービスにより作成され、UserWorkArea インターフェースにより定義されます。

また、作業域区画サービスでは、作業域区画コンテキストの双方向伝搬や属性の シリアライゼーションの延期など、UserWorkArea 区画では使用できない 追加プロパティーによる区画の構成が可能です。 これらのプロパティーは、区画の作成時に、構成プロパティーとして使用可能です。 区画の作成時に使用可能な構成プロパティーの完全なリストについては、『作業域区画マネージャーのインターフェース』の項の「構成可能な作業域区画のプロパティー」セクションを参照してください。プロパティーは次のように定義されています。

作業域コンテキストの双方向伝搬

作業域と関連付けられたスレッドから、リモート呼び出しが出された場合、 作業域のコピーが自動的にターゲット・オブジェクトへ伝搬されます。 ターゲット・オブジェクトは必要に応じて、作業域内の情報を 使用することも無視することもできます。 呼び出しアプリケーションが、 アプリケーションに関連した、ネストされた作業域を持っている場合、 そのネストされた作業域のコピーおよび、その上位のすべての作業域がターゲット・アプリケーションへ伝搬されます。 ターゲット・アプリケーションは、プロパティーのモードによる許可に従い、 追加のネストされた作業域を作成することによって、情報をローカルに変更できます。 この情報は、アプリケーションが呼び出したリモート・オブジェクトへ伝搬されます。

コンテキストの変更が、 リモート・アプリケーションから呼び出し側のアプリケーションへ、戻して伝搬されるかどうかは、 作業域区画の構成に依存します。ユーザーが区画の作成時に Bidirectional プロパティーを選択して双方向になるように区画を作成した場合、リモート・アプリケーションにより加えられた変更は、呼び出し側のアプリケーションに再び伝搬されます。これは、下流のプロセスによる作業域コンテキストへの変更が、上流のプロセスへ再び伝搬されることを意味します。UserWorkArea 区画は双方向に構成されません。また、構成することができません。したがって、コンテキストの変更は下流のプロセスにのみ流れ、上流のプロセスに再び伝搬されません。

例: 作業域コンテキストの双方向伝搬

コンテキストの変更が、 リモート・アプリケーションから呼び出し側のアプリケーションへ、戻して伝搬されるかどうかは、 作業域区画の構成に依存します。双方向の区画が作成された場合、 リモート・アプリケーションにより加えられた変更は、呼び出し側のアプリケーションに 戻して伝搬されます。下流のプロセスにより加えられた作業域コンテキストの変更が 上流のプロセスに戻されて伝搬されます。双方向伝搬用に構成されている場合の作業域コンテキストの配布の図は、サーバーへのリモート呼び出し中のこの関係を示しています。この図の説明では、クライアントおよびサーバーが同じ名前の区画を作成している 必要があります。

図 1. 双方向伝搬用に構成されている場合の作業域コンテキストの配布. この図では、サービスが双方向伝搬用に構成されている場合における作業域コンテキストの配布を示します。作業域コンテキストの双方向伝搬の例

クライアントがサーバーに対しリモート呼び出しを行う場合、サーバーはクライアント・プロセス で設定されたコンテキストを受け取ります。次に、サーバーはこのコンテキストに対し 変更や追加を行います。この図では、サーバーが key1 の値を上書きし、key2 のプロパティーを除去し、さらに、2 個の新規プロパティー key5 および key6 を 追加しています。サーバー・アプリケーションがクライアントに戻ったとき、作業域コンテキストはクライアントに再び伝搬され、アンマーシャルされます。 次に、現行の作業域が新しいコンテキストに更新されます。 なお、区画が双方向として構成されていない場合、サーバーが Work Area 1 のコンテキストの変更や除去を行おうとすると、com.ibm.websphere.workarea.NotOriginator 例外を受け取ります。これは、クライアントがその作業域のオリジネーターであるためです。 サーバーは Work Area 1 内のコンテキストを取得できます。これが、コンテキストの双方向伝搬と非双方向伝搬の間の主な違いです。

例: ネストされた作業域コンテキストの双方向伝搬

リモート・アプリケーションにおいて、 それ自身またはその他のリモート・オブジェクトに 使用されるだけの作業域に対してコンテキストの追加が必要な場合、リモート・アプリケーションにより 新たな作業域が開始される必要があります。新規作業域を開始することにより、追加コンテキストのスコープがそのアプリケーションに限定されて、呼び出し側のアプリケーションに流し戻されません。 ネストされた作業域の主な利点は、作業域コンテキストのスコープを 特定のアプリケーションに限定できることです。図の説明を一歩進めると、 key1 の値への上書きや、key2 のプロパティーの除去、key5 および key6 での新規プロパティーの追加などを行う前に、サーバーにより作業域が 開始された場合、それらの変更はクライアントに戻されて伝搬されません。これは、双方向伝搬用に構成されている場合のネストされた作業域コンテキストの配布の図に示されています。 この図には、クライアントが、サーバーにより開始されたネストされた作業域からコンテキストを受け取らないことも示されています。

図 2. 双方向伝搬用に構成されている場合のネストされた作業域コンテキストの配布. この図では、サービスが双方向伝搬用に構成されている場合におけるネストされた作業域コンテキストの配布を示します。ネストされた作業域コンテキストの双方向伝搬の例

作業域コンテキストの属性のシリアライゼーションの延期

デフォルトでは、各設定オペレーションにおいて、作業域に設定された属性は、 作業域サービスにより自動的にシリアライズされます。後続の取得オペレーションにおいて、 その属性がデシリアライズされ、リクエスターに戻されます。これにより、 作業域サービスによる属性の完全な制御が可能になり、ユーザーが作業域への属性の再設定を特に 指定しない限り、変化しやすいオブジェクトへのどのような変更も 作業域の属性のコピーへ反映されません。 ただし、これが過剰なシリアライゼーションとデシリアライゼーションにつながる可能性があります。

過剰なシリアライゼーションとデシリアライゼーションは、負荷の重い状況下で、無視できない 性能低下をもたらす場合があります。 属性のシリアライゼーションの延期の構成プロパティーは、キャッシュ機能であり、 シリアライゼーションとデシリアライゼーションのオペレーションを削減します。 クライアントまたはサーバー・プロセスで作業域の作成中に「属性のシリアライゼーションの延期」フィールドを選択して、属性のシリアライゼーションの延期を使用可能にした場合、 作業域サービスに設定された属性が、 設定オペレーション中に自動的にシリアライズされることはありません。代わりに、属性へのリファレンスが 作業域に保管されます。 属性が変化しやすい場合、オブジェクトへの変更は、作業域におけるその属性への参照に反映されます。 その属性に取得オペレーションが実行された場合、オブジェクトへのリファレンスが 戻され、デシリアライゼーションは実行されません。

属性に関連付けされた スレッドがリモート IIOP 呼び出しを行うまで、属性はシリアライズされません。 呼び出しが行われた時点で属性がシリアライズされ、属性のシリアライズ・フォームが キャッシュされます。属性が作業域に対し再設定されない場合、 オリジナル属性への変更は、引き続き、作業域内に含まれる属性内で反映されます。 これは、作業域がオリジナル・オブジェクトへのキャッシュされたリファレンスを 引き続き保持しているからです。ただし、作業域に対する属性の再設定により 属性が変更されたことが作業域に伝えられていない場合、後続のリモート要求は 引き続きキャッシュされたシリアライズ版の属性を使用し、 変化しやすい属性への直接の変更は伝搬されません。 これは、属性のシリアライゼーションの延期の構成プロパティーを使用可能にした場合と 使用可能にしない場合での重要な違いです。ユーザーは、この違いに十分注意し、 属性のシリアライゼーションの延期を使用可能にした場合に、 変化しやすいオブジェクトがどのように扱われるかにも注意する必要があります。次のいずれかの状態が発生した場合、作業域サービスは、キャッシュされたリファレンスおよび、キャッシュされたシリアライズ版の属性を解放します。

  • 属性が再設定されるか除去される。
  • 作業域がアプリケーションにより明示的に完了される。
  • 作業域が開始されたときに、サーバー・コンポーネントが要求の実行を終了させる。
  • 作業域を開始したクライアント・プロセスが終了する。

プロセスの境界を越える区画コンテキストの伝搬

クライアントが サーバーにリモート呼び出しを行った場合、作業域コンテキストはクライアントからサーバーに 自動的に伝搬されます。例えば、クライアントが、3 つの異なった作業域区画で構成されていて、そのクライアントがサーバー server1 にリモート呼び出しを行った場合、クライアント・スレッドの各区画に関連したコンテキストは、server1 に伝搬されます。同一の 3 つの区画が server1 上に作成された場合、コンテキストは適切な区画にアンマーシャルされます。ただし、3 つの区画がまったく、または一部しか server1 上に作成されていない場合、クライアントおよびサーバーの両者に存在する区画に関連したコンテキストだけがアンマーシャルされます。 server1 上に常駐していない区画に関連したコンテキストは、server1 上に常駐しては いますが、アクセス可能ではありません。 server1 上に常駐していない区画に関連したコンテキストも、 他のリモート呼び出しが別のサーバーに行われた場合のために、server1 上に常駐し続ける必要が あります。一歩進めると、server1 が別のサーバー server2 に呼び出しを行い、server2 がクライアントと同じ区画を持つ場合、server2 は server1 上には常駐していない区画のコンテキストを受け取ります。server1 上に常駐し、クライアント上には常駐していなかった区画のコンテキストも、server2 に伝搬されます。

作業域について詳しくは、アプリケーション・プログラミング・インターフェース (API) の com.ibm.websphere.workarea パッケージを参照してください。 生成済み API 文書は、インフォメーション・センターの目次で、 「参照」 > 「API - アプリケーション・プログラミング・インターフェース」の順にたどって入手できます。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwa_partition
ファイル名:cwa_partition.html