WebSphere Application Server for z/OS, Version 6.1   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化

作業域区画サービス

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

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

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

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

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

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

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

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

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

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

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

属性に関連付けされた スレッドがリモート 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 文書は、インフォメーション・センターの目次で、 「参照」 > 「Developer」 > 「API documentation」 > 「Application programming interfaces」の順にたどって入手できます。




関連概念
ネストされた作業域
関連タスク
作業域区画の構成
関連資料
作業域区画マネージャーのインターフェース
例: 作業域区画マネージャーの使用
例: 双方向伝搬
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/workarea/concepts/cwa_partition.html