構成モデル

3 種類の構成モデルから選択することができます。それぞれの定義は次のとおりです。

• HTML ベース・モデル
• 構成サーバー・ベースのモデル
• 複合モデル

HTML ベース・モデル
すべてのセッション情報をこの HTML ファイル内で定義および管理するように指定します。セッション・オプションは、構成サーバーを使用している場合と同じセットです。

必要な構成情報およびユーザー設定 (例えば、色の変更など) は、許可されている場合は、 ユーザーのマシンにローカルに保管されます。

Z and I Emulator for Web ポートレットのユーザー設定は、ユーザーのローカル・マシンでなく WebSphere Portal に保管されています。ただし、これは、ポートレットおよびポートレットにアクセスする Web ページに対する適切なアクセス権がユーザーに与えられている場合にかぎります。WebSphere Portal V4 のユーザーには Edit または Manager の アクセス権が必要で、WebSphere Portal V5 のユーザーには Privileged User、Editor、 Manager、または Administrator の アクセス権が必要です。ユーザーにアクセスを許可する方法について詳しくは、WebSphere Portal の資料を参照してください。

HTML ベースのモデルは、Z and I Emulator for Web ポートレットに推奨される構成のモデルです。これを他の構成のモデルと比較するには、「Z and I Emulator for Web 計画、インストール、および構成」ガイドの「Z and I Emulator for Web ポートレット使用時の特別な考慮事項」を参照してください。

このモデルを選択すると、いくつかの利点があります。

• 構成サーバーは使用されません。したがって、リダイレクターや i5/OS および OS/400 プロキシー、ライセンス使用カウント (ライセンス使用カウントはデフォルトで使用できるようになっていますが、 使用不可にできます) などの Z and I Emulator for Webd サービスを使用していない限り、Z and I Emulator for Web サービス・マネージャーを開始する必要はありません。
• パフォーマンスは構成サーバーを使用するよりも優れている可能性があります。その理由は、 構成サーバー上で個別設定された構成にアクセスするユーザーが多くないためです。
• Z and I Emulator for Web ユーザー ID を作成したり保守したりする必要がありません。
• ユーザーのログオンが必要ありません。
• 別のポートを開いて構成サーバーにアクセスする必要はないので、 ファイアウォールの問題は起こりません。

このモデルを選択すると、いくつかの制約があります (ご使用の環境にもよります)。

• ユーザー個人の構成を変更する場合、それらの変更は、 物理的にコピーしない限り、他のマシンでは利用できません。
• 管理者が多数の異なる構成を定義する必要がある場合は、 すべての HTML ファイルを保守するのが煩雑になることがあります。
• デプロイメント・ウィザードは、リモートでは実行されません。したがって、リモートでは、セッションを管理する組み込みメカニズムがないことになります。

このオプションを選択した場合、管理者は、 デプロイメント・ウィザードを使用して HTML でセッションを定義します。ユーザーの行った変更はすべて、ユーザーのマシンに保管されます。(ただし管理者は、ユーザーがセッションの変更を保管したり、 または特定のプロパティーをロックしたりできないような選択を今までどおり行えます。) その後で管理者がデプロイメント・ウィザードを使用してセッション・データを更新する場合、 それらの更新はユーザーがそれまでに行ったすべての変更とマージされます。この場合、すべてのユーザー設定は、管理者がその設定のオーバーライドを選択しない限り保持されます。

HTML ベースのモデルはデフォルト値です。

構成サーバー・ベースのモデル
すべてのセッションを、管理ユーティリティーを使用して構成サーバーで構成して管理するように指定し、 それぞれのユーザーが、ユーザー特定の情報が保持される構成サーバーで ID を持つように指定します。

必要な構成は、構成サーバーのグループ ID またはユーザー ID に保管されます。 すなわち、ユーザー設定は、許可されている場合、ユーザーの ID に保管されます。構成サーバーでは、ユーザーごとに 1 つのユーザー ID が必要です。

このモデルを選択すると、いくつかの利点があります。

• ユーザーは、ネットワークにアクセスしているどのマシンからも、 それぞれの個別設定構成にアクセスすることができます。その理由は、それらの構成が構成サーバーに保管されているからです。
• 異なる構成が多数ある場合は、構成を編成するのに、 構成サーバー・グループとユーザー構造を使用すると効果的です。
• 管理ユーティリティーを使用すると、セッションのリモート管理が可能になります。

このモデルを選択すると、いくつかの制約があります。

• 単一の WebSphere Portal ページに複数の Z and I Emulator for Web ポートレットを入れることはできません。単一の WebSphere Portal ページに複数の Z and I Emulator for Web ポートレットを表示したい場合には、HTML ベースのモデルを使用してください。HTML ベースのモデルは、Z and I Emulator for Web ポートレットを使用する際に推奨されるモデルです。
• ユーザー ID のすべてを作成して保守するには、きわめて高度な管理要件があります。(ただし、このプロセスの単純化を手助けするために、 オプションで、Windows のユーザー名に基づいてユーザー ID を自動的に作成できます)。
• 構成サーバーで個別設定構成にアクセスするユーザーが多数いると、 パフォーマンスが低下する場合があります。
• それぞれのユーザーは、Z and I Emulator for Web を使用する前に、構成サーバーに連絡することが必要です。
• ユーザーはログオンしなければなりません。(ただし、ユーザーは Windows のユーザー名を使用して自動的にログオンされています。)

このモデルでは、管理者は管理ユーティリティーを使用して、ユーザーおよびグループのセッション情報を定義します。

その後で管理者が管理ユーティリティーを使用してセッション・データを更新する場合、 それらの更新はユーザーがそれまでに行ったすべての変更とマージされます。すべてのユーザー設定は保持されます。

複合モデル
構成サーバー・ベースのモデルのように、すべてのセッション情報を、 管理ユーティリティーを使用して構成サーバーで定義して管理するように指定します (ユーザーは、デフォルトのセッションを、 構成サーバーで指定されたグループから入手します)。

ただし、構成サーバー・ベースのモデルとは異なり、 必要な構成情報およびユーザー設定は、許可されている場合は、 ユーザーの ID で構成サーバーに保管されるのではなく、ユーザーのマシンにローカルに保管されます。

Z and I Emulator for Web ポートレットのユーザー設定は、ユーザーのローカル・マシンでなく WebSphere Portal に保管されています。ただし、これは、ポートレットおよびポートレットにアクセスする Web ページに対する適切なアクセス権がユーザーに与えられている場合にかぎります。WebSphere Portal V4 のユーザーには Edit または Manager の アクセス権が必要で、WebSphere Portal V5 のユーザーには Privileged User、Editor、 Manager、または Administrator の アクセス権が必要です。ユーザーにアクセスを許可する方法について詳しくは、WebSphere Portal の資料を参照してください。

このモデルを選択すると、いくつかの利点があります。

• Z and I Emulator for Web ユーザー ID を作成したり保守したりする必要がありません。
• パフォーマンスは構成サーバーを使用するよりも優れている可能性があります。その理由は、 一方では今までどおり構成サーバーにアクセスしなければなりませんが、 構成サーバー上で個別設定された構成にアクセスするユーザーが多くないためです (情報の一部はローカルに保管されています)。
• ユーザーのログオンが必要ありません。
• 異なる構成が多数ある場合は、構成を編成するのに、 構成サーバー・グループとユーザー構造を使用すると効果的です。
• 管理ユーティリティーを使用すると、セッションのリモート管理が可能になります。 (ただし、HTML ファイルの情報については、今までどおりデプロイメント・ウィザードを使用しなければなりません。)

このモデルを選択すると、いくつかの制約があります (ご使用の環境にもよります)。

• ユーザー個人の構成を変更する場合、それらの変更は、 物理的にコピーしない限り、他のマシンでは利用できません。
• 同時に多数のユーザーが、構成サーバーにアクセスしてデフォルトの構成を取得すると、 パフォーマンスが低下する場合があります。ただし、ユーザーがユーザー設定を取得または保管するために、構成サーバーにアクセスすることはありません。

このオプションを選択すると、管理ユーティリティーを使用して、 構成サーバーでグループが作成され、そのグループで必要なセッションが作成されます。その後、管理者はデプロイメント・ウィザードを使用して、ユーザーがアクセスする HTML ファイルを構成します。 ここで HTML ファイルはデフォルトのセッション構成を取得すべき構成サーバー・グループを指定します。その後で管理者が管理ユーティリティーを使用してセッション・データを更新する場合、 それらの更新はユーザーがそれまでに行ったすべての変更とマージされます。この場合、すべてのユーザー設定は、管理者がその設定のオーバーライドを選択しない限り保持されます。