 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
IBM Workplace Managed Client アプリケーションの管理 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hangsu Ma, Software Development Engineer, IBM レベル：中級 原文の掲載：2005年09月13日 更 新 日：2006年02月24日更新  原文はこちら
IBM Workplace Managed Client (以前の IBM Workplace Client Technology, rich edition) は、サーバー上で IBM Workplace の Web ベース・アプリケーションを実行することへの代替手法をもたらします。Workplace Managed Client によって、クライアント・サイドでのアプリケーションの実行が可能になり、パフォーマンスの向上、オフライン機能、よりリッチなユーザー・エクスペリエンスが得られます。 名前からもわかるように、Workplace Managed Client の主な機能の 1 つに一元管理があります。システム管理者は、サーバーからすべてのアプリケーション・アクセスを非常に詳細に制御できます。クライアント・アプリケーションのユーザーは、使用が許可されているアプリケーションにのみアクセスできます。この記事では、Workplace Managed Client でのアクセス制御の理論と実践について解説します。 この記事は、IBM WebSphere Portal のシステム管理の経験があり、XMLAccess の機能に習熟し、Workplace Managed Client の基本概念を理解されている方を対象に書かれています。Workplace Managed Client の詳細については、製品ページ（US）を参照してください。 IBM Workplace Managed Client Developer Toolkit説明を始める前に、IBM Workplace Managed Client Developer Toolkit について簡単に触れておきます。これは、Workplace Managed Client アプリケーションの開発をサポートする Eclipse ベースのツールキットです。このツールキットは、Eclipse と IBM Rational Application Developer の両方で使用できます。ツールキットによって、Workplace Managed Client アプリケーションの作成プロセスが大幅に簡素化されます。プロビジョニング・サーバーを使用せずに、クライアント・アプリケーションをローカルでテストおよびデバッグできます。また、「デプロイ・セット」を生成できるので、developerWorks: Lotus 記事『IBM Workplace での更新のデプロイ』に書かれている面倒な作業を省略できます。IBM Workplace Managed Client Developer Toolkit は IBM Dublin Software Lab によって開発されました。この記事では、このツールキットを標準開発環境として使用します。ツールキットの詳細については、developerWorks: Lotus 記事『IBM Workplace Managed Client Developer Toolkit のご紹介（US）』を参照してください。ツールキットは IBM alphaWorks（US） からダウンロードできます。
Workplace Managed Client のサンプル・アプリケーションWorkplace Managed Client は非常に詳細なアクセス制御システムを持っています。このシステムは、個々のユーザーやユーザー・グループに対し、特定のアプリケーションの特定の機能へのアクセスを制御できます。詳細な説明の前に、IBM WebSphere Portal（US） のアクセス制御を理解する必要があります。それでは、実際の例を見ていきましょう。ここで取り上げるのは、遠洋航海用の IBM Workplace Collaboration Services システムで、それぞれの乗組員がこのシステムを使用します。このシステムのユーザーは、Silver Blade (Pirate ユーザー・グループのメンバー) と Marco Polo (Adventurer ユーザー・グループのメンバー) に分けられます。どちらのユーザーも、仕事を進める上での重要なシステムとして Workplace Collaboration Services を信頼してきました。しかし、船上でのモバイル・ネットワークはあまり良い状態ではなく、ときどき「ページが見つかりません」というエラーになり、船員たちは不安を感じています。これを防ぐために、Marco と Silver のどちらも、Workplace Managed Client をインストールしてオフライン機能を利用することにしました。Marco の Workplace Managed Client の画面ショットを図 1 に示します。 図1. Marco Polo の Workplace Managed Client  図2 は Silver Blade の Workplace Managed Client の画面ショットです。 図2. Silver Blade の Workplace Managed Client  Managed Client インターフェースの左側の垂直のバーは切り替えバーです。切り替えバーに表示されている各アイコンは、Workplace Managed Client で実行されているアプリケーションを示します。図からわかるように、Marco と Silver のどちらも、[Navigate]、[Logbook]、[Weather Forecast]、および [Sea Battle] にアクセスできます。また、図 1 によると Marco は [Adventure Club] に排他的にアクセスできるのに対し、図 2 によると Silver は [Pirate Club] を使用して海賊仲間と連絡できます。 Workplace Managed Client アプリケーションを利用するための権限は、システム管理者がアクセス制御を使用して付与します。予想されるように、これらの権限は、ブラウザーを使用して Workplace サーバー上の Workplace Collaboration Services アプリケーションにアクセスしたときの権限と、整合性が維持されます。これによって、ユーザーは Web ブラウザーを用いたときの機能とまったく同じ機能を使用できます。 図 1 と 2 では、Marco と Silver のどちらも [Sea Battle] アプリケーションを選択しています。しかし、Marco の [Sea Battle] インターフェースは、Silver のインターフェースと異なっています。Marco と Silver のどちらにも [Battle Field Commands] 機能がありますが、[Flee] 機能は Marco だけに、[Rob] 機能は Silver だけにあります ([Rob] は Silver のお気に入りの機能です)。驚くべきことに、これらの違いはコードによるものではありません。Workplace Managed Client のアクセス制御によって実現されているのです。これは、開発者は Workplace Managed Client アプリケーションの機能だけに注力すればよく、アクセス制御はシステム管理者に任せられることを意味します。システム管理者は、Workplace Managed Client アプリケーションへのアクセスをユーザーにどのように付与するのかを決定できます。ユーザーのアクセスは、アプリケーション内のサブ機能に至るまで制御できます。コードを 1 行も変更しなくても、これらのすべてが可能です。この機能により、プログラマーはセキュリティー・チェックから解放され、Workplace Managed Client アプリケーションの再利用性と管理性が高まるため、大規模な企業レベルでの用途に適しています。 次のセクションでは、Workplace Managed Client のアクセス制御がどのように機能するのかを説明します。
Workplace Managed Client でのアクセス制御Workplace Managed Client は、IBM Workplace サーバーのアクセス制御機構を活用して、非常に詳細なアクセス制御を実現しています。特に、Workplace Managed Client はそのアプリケーションを管理するために、Workplace サーバーでのページとポートレット用のアクセス制御設定を使用します。各 Workplace Managed Client アプリケーションは Workplace サーバー上でページとして表され、アプリケーションのレイアウトはページ上でポートレットのレイアウトとして表されます。Workplace Managed Client アプリケーションの各ビューは、ページ内のポートレットに対応します。このポートレットが、ビューと同じ機能を提供します。これによって、サーバーとクライアントの両方で実行できるアプリケーションが得られます。 [Sea Battle] のサンプルでは、「プレースホルダー」ポートレットが使用されています。このポートレットは、デフォルトで Workplace サーバーにインストールされます。このポートレットは Workplace Managed Client 用の RCPML を生成するだけなので、サンプルは Managed Client でのみ実行されます。ここでは Workplace Managed Client のアクセス制御の動作を説明するだけなので、これで十分です。 RCPML (Rich Client Platform Markup Language) は、各 Workplace Managed Client アプリケーションのレイアウトを記述する XML ベースのマークアップ言語です。Workplace Managed Client は RCPML ファイルを使用してアプリケーションを構築します。RCPML は、必要なときに Workplace Collaboration Services サーバーからダウンロードされます。RCPML の詳細については、developerWorks: Lotus 記事『IBM Workplace Managed Client Developer Toolkit のご紹介（US）』を参照してください。また、Workplace Managed Client の製品ページ（US）も参考になります。 サンプルの Workplace アプリケーションを構成するページと、Marco の Workplace Managed Client ユーザー・インターフェースとの対応を図 3 に示します。[Pirate Club] を除き、各ページが Workplace Managed Client のアプリケーションを表していることがわかります。このアプリケーションは、ユーザー・グループ「Pirate Club」のユーザーからのアクセスだけを受け付けます。Marco はこのグループのメンバーではないため、このアプリケーションはクライアントに表示されません。 図3. ページと UI の対応  図 4 は、[Sea Battle] アプリケーションのページ・レイアウトが、Silver の [Sea Battle] アプリケーションのユーザー・インターフェースにどのように対応するのかを示します。 図4. [Sea Battle] アプリケーションのページと UI の対応  このように、[Sea Battle] ページの各ポートレットはアプリケーション内のビューに対応しますが、2 番目のポートレットがありません。この理由は、[Flee] 機能を使用するには、ユーザーが Adventurer Club のメンバーであることが必要だからです。Silver はメンバーではないので、このビューを使用できません。Pirate Club と Adventurer Club は、このサンプルで作成しなければならない 2 つのユーザー・グループです。すでに、Pirate Club のメンバーである Silver_Blade と、Adventurer Club のメンバーである Marco_Polo という 2 人のユーザーがいます。 これらの対応が Workplace Managed Client でのアクセス制御にどのように関連するのかを明らかにするために、まずは RCPML の生成プロセスから説明しましょう。クライアントがサーバーに接続すると、サーバーはページを組み立て、完成したページから RCPML ファイルを生成します。次に、サーバーは RCPML をクライアントに送信し、クライアントはこの RCPML に従ってアプリケーションを構築します。 最初のステップでのポイントは、Workplace サーバーがページを組み立てるとき、要求者の権限をチェックすることです。完成したページには、要求者がアクセス権を持つページとポートレットだけが組み込まれています。完成したページは RCPML のソースなので、クライアントの権限に応じて RCPML に格納される内容が決められます。この結果、利用可能なアプリケーションまたは機能が決定されます。システム管理者は、プロビジョニング・ページまたはページ上のポートレットへのクライアントのアクセス権を制御することで、Workplace Managed Client アプリケーションとその機能への制御を完全に掌握できます。 理論について説明したので、次は実践に進みましょう。[Sea Battle] アプリケーションを順番に設定していきます。最初に、サンプル・アプリケーションのセットアップが必要です。
サンプル・アプリケーションのセットアップ[Sea Battle] サンプル・アプリケーションをセットアップします。このアプリケーションは 3 つのビューを持ち、各ビューにはいくつかのボタンがあります。IBM Workplace Managed Client Developer Toolkit（US） を使用すると、コードを 1 行も書かずに、このアプリケーションを作成できます。また、ツールキットを使用することで、アプリケーションをサーバーにデプロイするために必要なすべてのファイルが含まれるデプロイ・セットを生成できます。この優れたツールキットによって、Workplace Managed Client アプリケーションの作成やデプロイがあまりにも簡単にできるので驚くでしょう。もちろん、常により良い方法は存在します。この場合のもっと簡単な方法は、デプロイ・セットをダウンロードすることです (デプロイ・セットのダウンロードについては、この記事の最後にある「ダウンロード」セクションを参照してください)。説明ファイルに従うと、サンプル・アプリケーションのデプロイも難しくありません。ガイダンスが必要な場合は、IBM Workplace Managed Client Developer Toolkitフォーラムにお問い合わせください。 デプロイメントに成功したら、次の手順に進みます。システム管理者のアカウントを使用してクライアントを実行します。[Sea Battle] アプリケーションが実行され、3 つのビューが表示されます。システム管理者以外のアカウントで実行すると、切り替えバーには [Sea Battle] のアイコンだけが表示されます。しかし、このアイコンをクリックしても、アプリケーションは正しく実行されません。これはユーザーのせいではないので、心配する必要はありません。 システム管理者以外のアカウントの問題は、アクセス制御にあります。生成された新しいプロビジョニング・ページは、デフォルトで、認証済みのすべてのポータル・ユーザーからアクセスできます。しかし、このページにあるプレースホルダー・ポートレットは、デフォルトで、wpsadmins ユーザー・グループにのみアクセス権が与えられます。つまり、システム管理者のユーザーはすべての RCPML ファイルを入手するので、何の問題もなくアプリケーションを使用できることを意味します。ページ・レイアウトの RCPML を生成するポートレットが欠けているので、システム管理者以外のユーザーには、切り替えバー内のアイコンが表示されるだけで、このアプリケーションは正しく実行されません。この問題を解決するには、生成されたプロビジョニング・ページ上のプレースホルダー・ポートレットへのアクセス権をユーザーに付与することが必要です。 次のセクションでは、この問題を解決し、サンプル・アプリケーションを手順ごとに設定していきます。
Workplace Managed Client アプリケーションのアクセス制御の設定前のセクションでは、[Sea Battle] をサーバーにデプロイしました。ここでは、このサンプル・アプリケーションにアクセス制御を設定し、前のセクション「Workplace Managed Client でのアクセス制御」での説明に沿ってアプリケーションが動作するようにします。システム管理者のアカウントを使用し、Web ブラウザーで Workplace サーバーにログインします。次に、名前が「sea_battle」で始まるポートレットを検索します。sea_battle.AdventurerView、sea_battle.CommonView、sea_battle.PirateView の 3 つのポートレットが表示されます (図 5 参照)。 図5. [Sea Battle] ポートレット  最初のポートレットは [Flee] ビューに対応します。冒険家 (Adventurer) は避難すること (Flee) が必要な状況もあるので、「Adventurer Club」をこの [User] ロールに追加します。これは、Marco は [Sea Battle] アプリケーションで [Flee] ビューを見ることができ、Silver は見られないことを意味します。また、ユーザー Marco_Polo をユーザーロールに追加することによってもこれを実現できます。しかし、この方法を用いると、この機能を使用させたい冒険家が他にもいる場合は、一人ずつ順番にユーザーロールに追加しなければなりません。Workplace Managed Client アプリケーションのアクセスを管理するときは、ユーザー・グループを使用することをお勧めします。 2 番目のポートレットは、[Battle Fields Commands] ビューを表します。海賊も冒険家もこのビューを使用できるので、「Pirate Club」と「Adventurer Club」を [User] ロールに追加します。これによって、このユーザー・グループのすべてのメンバーが、このビュー内の機能を使用できます。これらのユーザーは、[Sea Battle] アプリケーションで、大砲、拳銃、格闘を選択できます。(異なるロールのメンバーは、リソースへのアクセス・レベルが異なることに注意してください。このアプリケーションでは違いがないので、1 つのユーザーロールを使用しました。このプレースホルダー・ポートレット以外のポートレットを使用する場合、ロールの違いの詳細については WebSphere Portal InfoCenter（US） を参照してください。) 最後のポートレットは [Rob] ビューに対応します。同じ基準で、「Pirates Club」をこのユーザーロールに追加します。 これで、Macro_Polo と Silver_Blade に対して、[Sea Battle] アプリケーションが正しく機能するようになりました。しかし、もう 1 つだけ必要なことがあります。アプリケーションのプロビジョニング・ページは、認証済みのすべてのポータル・ユーザーからアクセスできます。このページは WorkplaceRCPPages の下にあり、「sea_batttle」に似たタイトルと、「com.ibm.page…」で始まる固有の名前を持ちます。このページは、デフォルトで親ページからアクセス設定を継承します。つまり、切り替えバーで [Sea Battle] のアイコンは認証済みのすべてのユーザーに表示されますが、これを正しく使用できるのは「Adventurer Club」と「Pirate Club」のユーザーだけとなります。しかし、アイコンはアプリケーションを使用できるユーザーだけに表示すべきです。そこで、このページが親ページからアクセス設定を継承することを禁止します。または、親ページでアクセス設定の伝達を禁止します。この方法を用いることにより、以降のページはアクセス設定をいっさい継承しないようになります。最後に、「Adventurer Club」と「Pirates Club」をページのユーザーロールに追加します。これで、海賊と冒険家だけが、このアプリケーションのアイコンを表示したり、アプリケーションを使用することができます。 すべての設定は、Web ブラウザーを使用して実行できます。しかし、この記事では Workplace Managed Client アプリケーションの管理を中心に解説しているので、この詳しい方法については触れません。リソース権限の設定方法と、ユーザーおよびユーザー・グループの管理方法の詳細については、WebSphere Portal InfoCenter（US）を参照してください。Web ブラウザーのユーザー・インターフェースは、たいへんユーザー・フレンドリーで直感的です。しかし、トラブルが発生した場合は、Workplace Managed Client を調べることにより、アプリケーションがサーバーに正しくデプロイされていることを確認してください。 IBM WebSphere Portal の XMLAccess 機能を使用することによっても、Workplace Managed Client アプリケーションのアクセス制御を設定できます。次のセクションでは、簡単な説明を添えて、いくつかの XMLAccess スクリプトを紹介します。
XMLAccess を使用したアクセス制御の設定サンプル・アプリケーションをセットアップするときに、XMLAccess を使用して Workplace サーバー扱うとたいへん便利なことに気づいたかもしれません。都合の良いことに、XMLAccess を使用すると、Workplace Managed Client アプリケーションのアクセス制御も設定できます。始める前に、この記事の最後にある「ダウンロード」セクションから、2 つのユーザー・グループと 2 名のユーザーを作成および削除する 2 つのスクリプト (addUser.xml と delUser.xml) をダウンロードします。パスワードはプレーン・テキストなので、XMLAccess を使用してユーザーを作成した後は、パスワードを変更することをお勧めます。 次に示すスクリプトは、デプロイメント後に、サンプルの Workplace Managed Client アプリケーションを正しく設定します。このスクリプトは、デフォルトのプレースホルダー・ポートレットが使用され、ページの固有名とポートレットの名前が変更されていないという前提で作成されています。
これまでに XMLAccess 機能を使用したことがある方は、これがたいへん簡単であることに気づくでしょう。プレースホルダー・ポートレットに対応する 3 つの要素があります。ポートレットは、名前で識別されます。ポートレットの名前は、アプリケーションのデプロイに使用したデプロイ・スクリプトに記述されています。それぞれの名前は、アプリケーション名で始まります。各要素は、ロールのメンバー・リストを定義します。つまり、各要素によって、リストにメンバーを追加したり、リストからメンバーを削除します。subjectid 属性は、ユーザー名またはユーザー・グループ名です。subjecttype は USER または USER_GROUP です。メンバーを追加したいとき、またはメンバーをリストから削除したいときに、update 属性を "set" (設定) します。任意の数の要素を追加できます。 要素でページを設定します。ページは固有名によって識別されます。固有名もデプロイ・スクリプトに記述されています。前述のように、ページはデフォルトでアクセス制御を継承するため、最初に継承を禁止する必要があります。この後で、「Pirate Club」と「Adventurer Club」を前と同様にユーザーロールに追加します。 1 つの文で、スクリプトはポートレットとページを見つけ、アクセス制御を更新します。このスクリプトは、独自のスクリプトを作成するときのテンプレートとして使用できます。使用する環境に合わせて、太字で示した属性だけを変更してください。 XMLAccess の詳細および XMLAccess スクリプトの実行方法については、WebSphere Portal InfoCenter（US）を参照してください。
まとめこの記事では、Workplace Managed Client のアクセス制御の利点について解説しました。また、このアクセス制御が Workplace Collaboration Services サーバーのアクセス制御を活用してどのように機能するのかを明らかにし、Workplace Managed Client アプリケーションのアクセス制御の設定方法についても説明しました。Workplace Managed Client ツールキットの価値についても、ご理解いただけたと思います。
ダウンロード研究所での測定では、以前のリリースより、特定のCPU量でより稼働することを示しています。加えて、Lotus Domino 7は特定の量のワークで、明らかに使用するシステム・リソースが減少しました。これまで実施されたどのベンチマーク・テストよりも、実際のお客様の環境を厳密に再現して計測されました。この正味の結果がLotus Domino 7での非常に大きなTCOの削減を示しています。
リソース
筆者について（原文のまま）Hangsu Ma works in the IBM Dublin Software Lab. He is also an Undead Warcraft III TFT player, who recently reached level 26 on the battle.net. You can contact Hangsu at hangsuma@ie.ibm.com.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
