|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IBM Workplaceでの更新のデプロイ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hangsu Ma , Software Developer, IBM レベル:上級 原文の掲載:2005年5月10日 更 新 日:2005年11月4日更新 時間の節約に興味がある方は (または、興味がない方も)、ぜひこの記事をお読みください。IBM Workplace ユーザーに更新とアプリケーションを自動的にデプロイするシステムのセットアップ方法を理解できます。 IBM Workplace Managed Client (以前の IBM Workplace Client Technology, Rich Edition) は、Web ブラウザーを介した IBM Workplace 製品へのアクセスに、機能豊富な代替手段をもたらします。Workplace Managed Client (リッチクライアントとも呼ばれます) は、オフライン・サポート、同期、検索、文書エディターなどの機能を提供します。 Workplace Managed Client の重要な機能の 1つとして、サーバーを介した集中的な管理が挙げられます。これには、ポリシー・ベースの管理、プロビジョニング、トラブルシューティングなどがあります。(詳細については、developerWorks の Lotus 記事『Administering the rich client in IBM Lotus Workplace』を参照してください。)また、Managed Client に更新を自動的にデプロイする機能も含まれています。 この記事では、Workplace ユーザーに更新とアプリケーションを自動的にデプロイするプロセスを作成および構成する方法について解説します。これには、Eclipse ベースの更新サイトと WebSphere Portal プロビジョニング・ページの作成が含まれます。このプロビジョニング・ページは、更新サイトへのアクセス方法とダウンロードするファイルを Managed Client に指示します。このプロセスによって、Workplace コミュニティ内で、更新とアプリケーションをいつ、どのような方法でデプロイするのかを制御できます。このプロセスは、新規アプリケーションのデプロイおよび既存のアプリケーションへの更新のデプロイに使用できます。 この記事は、プラグイン・アプリケーションの開発経験があり、Workplace と WebSphere Portal にある程度習熟している開発者を対象に書かれています。Eclipse、XMLAccess の機能、Workplace または WebSphere サーバー管理に関する知識も内容の理解に役立ちます。
Workplace Managed Client のアーキテクチャーこのセクションでは、Workplace Managed Client の基盤となるいくつかのテクノロジーについて簡単に説明します。詳細については、developerWorks
の Lotus 記事『IBM Workplace Client Technology architecture』を参照してください。
更新のデプロイ Managed Client をインストールおよび構成するとき、Managed Client はサーバーにマニフェスト・ファイルを要求し、これをダウンロードして解析します。次に、このファイルで指定されているプラグインをダウンロードし、Managed
Client アプリケーションを構築します。簡単に説明すると、このプロセスは次のように進行します。
このプロセスで知っておきたい重要なことは、ユーザーに関する限り、すべてが自動的に行われる点です。ユーザーは、ダウンロードする更新やその入手先を指示する必要はありません。その代わり、これはプロビジョニング・ページを介して制御されます。プロビジョニング・ページと更新サイトのどちらも、Workplace
管理者が作成し、維持することによって、このプロセスを集中的に管理できます。
以降の内容は、プロビジョニング・コンポーネントがインストールされた Workplace Collaboration Services 2.5 または Workplace Services Express 2.5 が実行されているものとして説明されています。これは、WebSphere Application Server 5.0.2.6 および WebSphere Portal V5.0.2.2 上で実行されている必要があります。さらに、Rational Application Developer 6.0 または Eclipse 3.0 などの開発環境が必要です (Eclipse 3.0 は Eclipse Web サイトのダウンロードページから無料でダウンロードできます)。この記事では、開発環境として Eclipse を使用しているものとして説明します。
サンプルのダウンロード ここでは、シンプルなプラグインと Eclipse フィーチャーを Managed Client
アプリケーションのサンプルとして使用します。Eclipse 用語の「フィーチャー」とは、基本的な「ダウンロード可能な」コンポーネントを意味します。主にマニフェスト・ファイルの
1つのタイプであるフィーチャーは、プラグインと他のフィーチャーを組み合わせることにより、コンポーネントのダウンロードと管理を容易にします。サンプルのプラグイン
(com.ibm.wct.sample.plugin) は、Eclipse の新規プラグイン・ウィザードによって作成されます。サンプルのフィーチャー
(ibm.wct.sample.feature) は、プラグインを含みます。このフィーチャーとプラグインは、どちらも
ここ からダウンロードできます。そして、unzip の実行後、[ファイル] - [インポート]
を選択することによってインポートできます。 ![]()
プロビジョニングの設定 プロビジョニング・プロセスによって、システム管理者は、Managed Client をオンデマンドでユーザーに配布できます。これには、サーバー管理 (server-managed) ロールとポリシーベースの配布が関与します。プロビジョニングには、Workplace プロビジョニング・コンポーネント (プロビジョニング・サーバーと呼ばれることもあります) がインストールされている必要があります。Managed Client のプロビジョニングの方法については、IBM Workplace のマニュアルで説明されています。また、developerWorks の Lotus 記事 『Administering the rich client in IBM Lotus Workplace』 は、プロビジョニング・プロセスの理解に役立ちます。
更新サイトの作成前述のように、Managed Client の更新とアプリケーションをユーザーがダウンロードできるよう、更新サイトを作成する必要があります。この更新サイトは、Eclipse から作成できます。Managed Client 更新サイトは、実際には Eclipse 更新サイトなので、作成手順は同じです。(このため、Eclipse プラグインを Workplace に移行することが容易になります。)一般的な Managed Client 更新サイトは、フィーチャーとプラグイン用のフォルダ、site.xml というマニフェスト・ファイル、およびオプションのフォルダで構成されます。これらのフォルダには、ユーザーがローカル・マシンにダウンロードできるファイルが含まれます。サンプルの Managed Client 更新サイトの構造を図 2 に示します。 図 2. Managed Client 更新サイトの構造 ![]() デフォルトでは、Managed Client 更新サイトの構造は、site.xml ファイルによって制御されます。このファイルは、IBM HTTP Server (IHS) のインストール・ディレクトリーにあります。(このファイルについては後で詳しく説明します。) 始める前に、フィーチャーとプラグインの関係について明確にしておきましょう。前述のように、フィーチャーはプラグイン (および、場合によっては他のフィーチャー) を含みます。これによって、ユーザーは、関連するプラグイン・グループのダウンロードと管理が容易になります。プラグインを個別にダウンロードする必要はなく、フィーチャーだけをダウンロードすればよいからです。Eclipse はフィーチャー内のマニフェスト・ファイルを解析し、関連するプラグインをダウンロードします。また、Eclipse は自分自身の構成を管理するユニットとして「フィーチャー」を使用します。ユーザーは、各フィーチャーをインストール、アンインストール、および無効化することができます。 Managed Client 更新サイトは Eclipse 更新サイトと同一なので、Eclipse の [更新サイト・プロジェクト] 機能を使用して、サンプル・アプリケーションの更新サイトを作成できます。これを行うには、Eclipse PDE (Plugin Development Environment) を開き、[ファイル] - [新規] - [プロジェクト] - [プラグイン開発] - [更新サイト・プロジェクト] を選択します。[新規更新サイト] ウィザードが表示されます。 図 3. [新規更新サイト] ウィザード [新規更新サイト] ウィザードには、次の項目があります。
[終了] をクリックすると、Eclipse は更新サイト・プロジェクトを作成します。次に、更新サイトを開き、左側のナビゲータにある site.xml をダブルクリックします。そして、エディターで [フィーチャー] タブを選択します。これによって、[サイト・マニフェスト] エディターが表示されます。 図 5. [サイト・マニフェスト] エディター ![]() [サイト・マニフェスト] エディターでは、更新サイトに含めたいフィーチャーを選択し、分類することができます。これを行うには、[追加] をクリックして利用できるフィーチャーのリストを表示します。 図 6. フィーチャーの選択 ![]() [サイト・マニフェスト] エディターは、現在のワークスペースにあるすべてのフィーチャーをリストします。(異なるバージョン番号を持つフィーチャーは、異なるフィーチャーとして扱われます。(更新サイトに追加するフィーチャーを選択します。次に、[新規カテゴリー] ボタンを使用して、更新サイトに表示するカテゴリーを作成し、選択したフィーチャーをこのカテゴリーに含めます。(内部的には、これによって、更新サイトのマニフェスト・ファイルである site.xml が更新されます。site.xml ファイルは、更新サイトにどのフィーチャーとカテゴリーをリストするのかを制御します。カテゴリーは、フィーチャーの集まりをグループ化するために使用されます。)設定が終了したら、[すべてを構築] をクリックして更新サイトを作成します。 更新サイトを構築するために、Eclipse は各フィーチャーに含まれるマニフェスト・ファイル (feature.xml) を解析し、それぞれのフィーチャーにどのプラグインが関連するのかを判断します。次に、Eclipse は各フィーチャーとプラグイン用の .jar files ファイルを構築し、これを更新サイトに置きます。後でユーザーが更新サイトからフィーチャーをダウンロードすると、これらの .jar ファイル (および、関連するプラグインの .jar ファイル) はユーザーのローカル・クライアントにロードされます。 新規の更新サイトを確認するには、Eclipse を起動し、[ヘルプ] - [ソフトウェア更新] - [検索とインストール] - [インストールする新規フィーチャーを検索] を選択します。次に、更新サイトのディレクトリーを入力します。また、図 3 で [サイト内のすべての・・・] チェックボックスをオンにした場合は、ブラウザーで更新サイトの URL (たとえば、http://hangsu.ibmirl.lan/lwpupdate/wct/index.html) を開くことによっても、更新サイトを参照できます。
site.xml の編集 新規の更新サイトには、Plugins という名前のフォルダがあります。このフォルダには、プラグインの各バージョンのすべての .jar ファイルが含まれています。また、ダウンロード用のフィーチャーを格納する Features フォルダもあります。 メモ: ほとんどの場合、ユーザーは個々のプラグインを直接ダウンロードすべきではありません。特定の機能を入手するには、そのプラグインを含むフィーチャーをダウンロードします。 site.xml ファイルを編集することによって、フィーチャーを手動で更新サイトに追加できます。たとえば、次のコードによって、フィーチャー features/com.ibm.wct.sample.feature_1.0.0 を追加できます。このコードを site.xml に追加すると、更新サイトの利用可能なフィーチャーのリストに features/com.ibm.wct.sample.feature_1.0.0 が追加されます。
URL はフィーチャーが置かれる場所で、id は feature.xml での id 設定です。category name は、このフィーチャーが表示される更新サイトのカテゴリーを示します。 更新サイトはカテゴリーごとに参照できます。デフォルトでは、site.xml には WCT という名前のカテゴリーが含まれます。site.xml を編集することで、他のカテゴリーを追加できます。たとえば、次のコードは WCT Sample というカテゴリーを追加します。
プロビジョニング・ページの作成前述のように、Workplace における自動化された更新プロセスのセットアップは、2 つステップに大きく分けられます。最初のステップである更新サイトの作成は、すでに説明しました。ここでは 2番目のステップに移り、Workplace サーバーにプロビジョニング・ページを作成します。クライアントが Workplace プロビジョニング・サーバーに接続すると、サーバーは関連するパラメーター (後述します) をプロビジョニング・ページとプロビジョニング・ページに置かれている「プレースホルダー」ポートレットから取得します。クライアントは起動時に、プロビジョニング・ページとプレースホルダー・ポートレットで表される RCPML を取得する要求をサーバーに送信します。クライアントからの要求への応答として、Workplace サーバーは、利用可能なアプリケーションのリストを表す RCPML を使用してマニフェスト・ファイルを生成します。クライアントはこのマニフェストを使用して、セットアップサイトからどのアプリケーションをダウンロードし、ユーザーに使用できるようにするかを判断します。このセクションでは、プレースホルダー・ポートレットを含むプロビジョニング・ページを作成します。このポートレットには、サーバーサイドで RCPML を生成するのに必要な情報が含まれます。私たちはサンプル・スクリプトを用意しました。このスクリプトをダウンロードして実行すると、独自のプロビジョニング・ページを作成できます。(このセクションで使用されている用語のヘルプについては、WebSphere Portal のマニュアルを参照してください。) プロビジョニング・コンポーネントをサーバーにインストールすると、WCT Place Holder という新しいポートレットが利用可能になります。このプレースホルダー・ポートレットの 1 つ以上のコピーが、アプリケーションを表すページで使用されます。ポータル用語では、ポートレットのコピーは「コンクリート・ポートレット・インスタンス」と呼ばれています。各プレースホルダー・ポートレットは、アプリケーション内でのビューを表すのに必要なパラメーターで構成されています。 ポータルには、lwp.WorkPlaceRCPPages という固有の名前を持つ特殊なページがあります。クライアント・アプリケーションを表すサーバー上のすべてのページは、この lwp.WorkPlaceRCPPages ページの子ページとして作成されます。lwp.WorkPlaceRCPPages のデフォルトの場所は、ポータル・サーバーのルート・ページ・レベルにあります。 ここで、プレースホルダー・ポートレットのコピーを作成し (このコピーを「コンクリート・コピー」と呼びます)、Managed Client 内の対応するビューの属性 (サイズ、場所など) を示すパラメーターを追加する必要があります。ほとんどの RCPML マニフェスト・ファイルはポートレットに含まれるパラメーターから作成されますが、プロビジョニング・ページ自身もいくつかの重要なパラメーターを持っています。たとえば、切り替えバーのアイコン (前セクション参照) の外観などがそうです。また、Managed Client はプロビジョニング・ページのタイトルをアプリケーションのタイトルとして使用します。これは、クライアント・アプリケーション切り替えバーのアイコンの下に表示されます。 メモ: 最初は、システム管理者以外のユーザーは、新しいページと新規作成したコンクリート・ポートレットにはアクセスできません。このため、ページへのアクセスを許可するために、ページとポートレットの両方のアクセス設定を変更する必要があります。たとえば、ユーザー・ロールのメンバーリストに [全認証ポータルユーザー] を追加します。(ページのアクセス制御の設定については、WebSphere Portal の管理者マニュアルを参照してください。)また、ページを作成するときは、[詳細] オプションの [RCPML のサポート] を必ず選択してください。 プレースホルダー・ポートレットの各コピーで構成する必要があるパラメーターのリストは次のとおりです。
図 7. ポートレット設定 次に、Workplace サーバーで XMLAccess 機能を実行します。これによって、サーバーに対してリモートでスクリプトを実行できます。私たちのケースでは、必要なパラメーターを含むプレースホルダー・ポートレットのコンクリート・ポートレットを作成するスクリプトを実行し、これをプロビジョニング・ページに配置し、ページとポートレットの両方にアクセス制御を設定します。(XMLAccess の詳細については、WebSphere Portal InfoCenter を参照してください。)サンプル・スクリプトの全体のコードは、このサイドファイルに含まれています。 このスクリプト・コードについて、いくつか注意点があります。スクリプトの element 要素で指定された create-oids="true" オプションは、スクリプトによって生成される各リソースに新規の objectid 値を生成するようサーバーに指示します。つまり、既存のリソースは上書きされず、新規リソースが作成されます (ただし、サーバー上の既存のリソースの uniquename と一致する uniquename が同時に指定されている場合を除きます)。一致する uniquename がすでに存在する場合、新しいリソースは作成されず、既存のサーバー・リソースが更新されます。 Uniquename は、ユーザーが指定する各リソースの識別子です。このため、名前の競合の可能性が高まります。名前の競合が発生した場合、XMLAccess は確認せずにすべてのリソースを単純に上書きします。したがって、uniquename の取り扱いには注意が必要です。次のシンプルな XMLAccess スクリプトを使用すると、RCP ルートページ下のすべてをエクスポートし、名前の競合がないかチェックできます。
出力にはプロビジョニング・コンポーネントとともに得られたアプリケーションが含まれるので、より複雑なアプリケーションへの準備が整いました。出力ファイルは、よいサンプルとなります。 XMLAccess スクリプトをクライアント・マシンから実行したい場合は、tools.jar ファイルを <LWP Server install direction>\PortalServer\bin からコピーする必要があります。これで、クライアントの JVM でスクリプトが利用可能になります。次に、コマンド行で次のように実行します。
このコマンド行は Windows の場合です。他のプラットフォームでも同様に実行できます。 <output_script_name> 設定は XMLAccess からの出力です。これは XMLAccess スクリプトで、入力スクリプトとしても機能します。たとえば、サーバーからファイルをエクスポートするとき、出力ファイルを使用して、これを他のサーバーに復元またはコピーできます。私たちのケースでは、スクリプトは更新オペレーションで、出力ファイルは結果を表示する以外は何もしません。すべてが正しく実行されていることを示す <status element="all" result="ok"/> のような status 要素が表示されることを期待できます。オペレーションの詳細は、出力ファイルの先頭の XML コメントに記録されます。XMLAccess 機能を使用するには、仮想リソース Portal への管理者の権限が必要なので注意してください。
まとめそれでは、結果を調べてみましょう。Workplace サーバーから Managed Client をダウンロードし、実行します。次のような画面が表示されます。図 8. Workplace Managed Client ページのサンプル 左側のナビゲーターの一番下に、明るい緑色の「Hi」アイコンがあります。このアイコンは、自動デプロイ・システムによってサンプル・アプリケーションが Managed Client に正しくデプロイされたことを示します。これは、アイコンとビューだけで構成される非常にシンプルなアプリケーションです。しかし、独自のアプリケーションと他の更新をこのデプロイ・システムでどのようにデプロイするかを十分に示しています。 この記事では、Workplace Managed Client ユーザーに更新を自動的にデプロイするシステムの基本的なセットアップ方法について説明しました。これに関する 2つの主な手順である Eclipse での更新サイトのセットアップと Workplace でのプロビジョニング・ページの作成についても解説しました。紹介したサンプルに従うと、独自のアプリケーションを作成できます。これは、現在扱っている Workplace コミュニティが発展する際に、更新とデプロイ用のプロセスを管理および制御するために役立つでしょう。
リソース
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||