WebSphere Portal V5.1.0.1プログラミング・モデルを活用する: 第1部:モデルの概要

これは、ポータル開発者とシステム管理者がIBM® WebSphere®Portal V5.1.0.1プログラミング・モデルを企業ポータルに適用する際に役立つ5部構成の最初の記事です。この記事では、モデルのさまざまな部分について紹介し、ポータル・テクノロジーの概要と、ポータルがサービス指向アーキテクチャー(SOA)にどのように関連するのかを説明します。モデルの成果物(ポートレット、テーマ、スキン、ポートレット・サービスなど)や、異なるパーツをまとめてポータル・ページを作成する、集約と呼ばれるプロセスの制御方法について理解できます。 次に、2つの一般的な概念であるセキュリティーと仮想ポータルがどのようにプログラミング・モデルと関連するのかを説明します。最後に、第1部で説明した概念を表すポートレット・アプリケーションをダウンロードし、試すことができます。このポートレット・アプリケーションは、以降の連続記事でも使用されます。

Stefan Hepper, WebSphere Portal Programming Model Architect, EMC

Author photoStefan Hepper is the architect responsible for the WebSphere Portal programming model and public APIs. He was co-leader of the Java Portlet Specification JSR 168. He also started the Pluto project at Apache, which provides the reference implementation of JSR 168. Stefan has delivered a number of lectures at international conferences, such as JavaOne, published various papers, and is co-author of the book Pervasive Computing (Addison-Wesley 2001). His research interests are component-based software architectures, pervasive infrastructures, and, of course, portals and portlets. Stefan received a Diploma of Computer Science from the University of Karlsruhe, Germany, and in 1998 he joined the IBM Böblingen Development Laboratory.


developerWorks
        プロフェッショナル著者レベル

Stefan Liesche, WebSphere Portal and Workplace Foundation Lead Architect, EMC

Author photoStefan Liesche is a Certified Senior IT Architect in the IBM Development Laboratory in Boeblingen, Germany. He has 11 years of experience in the software development field. He holds a master of science degree in computer science from University of Hildesheim, Germany. He joined IBM in 1998 as part of the services group where his speciality was designing large-scale end-to-end e-business solutions for complex environments. Stefan has been working with IBM WebSphere Portal for years. He first worked on the construction of large-scale portal solutions before joining the WebSphere Portal development architecture team. He is the Lead Architect of Workplace and Portal Foundation.



2006年 8月 25日 (初版 2005年 12月 24日)

はじめに

WebSphere Portalプログラミング・モデルは、J2EEプログラミング・モデルの拡張です。このプログラミング・モデルを使用して、WebSphere Portalプラットフォームの豊富な機能を活用するWebアプリケーションを実装します。 これには、コンポーネントをページ階層に組み込む集約と統合、柔軟なナビゲーション、コンテンツとアプリケーションの集約、ブランディング、カスタマイズ、パーソナライズ、コンテンツ管理、文書管理、検索などが含まれます。 ポータルが原理的にどのように動作するのかを図1に示します。

図1.ポータルの原理:画面上でのアプリケーション統合
図1.ポータルの原理:画面上でのアプリケーション統合

ユーザーはポータルと対話します。ポータルはさまざまなバックエンド・アプリケーションと対話し、ユーザーのためにこれらをまとめて、単一のブラウザー・ウィンドウ、つまりポータル・ページへと集約します。 また、WebSphere Portalは、これらのコンポーネントを1つのコンテキスト内に統合します。この機能は、画面上での統合と呼ばれることがあります。ユーザーのアプリケーションはポータルによって統合され、単一のウィンドウに表示されます。 このため、エンド・ユーザーは、多くの異なるシステムからの内容を、ユーザーにとって意味のある1つのコンテキストで、統一されたビューとして入手できます。 この強力な機能により、企業はユーザーに、広範囲に分散したITインフラストラクチャー内で、アプリケーションの複雑なネットワークを扱うための統合および統一された作業方法を提供できます。 異なるITシステムを異なるユーザー・インターフェースで扱う代わりに、ユーザーは単一のユーザー・インターフェースを用いて、1つのITシステム、つまりポータルを扱うだけでよいのです。

WebSphere Portalプログラミング・モデルは、集約ステップを異なるレベルでカスタマイズできるさまざまなAPI、SPI、JSP、Taglib、およびディスクリプターで構成されています。 この記事の目的は、このモデルを使用してポータルのどの部分をカスタマイズおよび拡張できるかについて、その概要を説明することです。


モデルの各部を調べる

ポータル・ページは、ポートレットによって生成された異なるマークアップ・フラグメントで構成されています。 すべてのポートレット・フラグメントを収集し、クライアントに送り返される単一ページを作成するプロセスは、集約と呼ばれています。これを図2に示します。

図2.ポータル・ページの集約
図2.ポータル・ページの集約

集約の流れは次のようになります。

  1. クライアントはポータルに要求を送信します。ポータル・サーブレットは要求ヘッダーを調べ、どのデバイスとどのユーザーがページを要求しているのかを判断します。
  2. ポータルはこのページのポートレットを決定し、これらのポートレットへのユーザーのアクセス権をチェックします。ここが、カスタマイズできる最初のプラグ・ポイントとなります。ログインとログアウトの動作を変更できます。このカスタマイズ方法の詳細については、このシリーズの後の記事で解説します。
  3. レイアウト・システムが呼び出されます。これは、ルック・アンド・フィールをレンダリングするテーマとスキンで構成されています。テーマとスキンはポータル・システムの重要なプラグイン・ポイントで、ポータル・ページ全体のルック・アンド・フィールを制御します。テーマとスキンの詳細については、この記事の「成果物:テーマとスキン」で後述します。
  4. ユーザー・アクションは、ポータルから、ポートレットに対応するポートレット・コンテナーに転送されます。このコンテナーはポートレットのランタイム環境を提供し、ポートレットAPIを介してポートレットと対話します。ポートレット・コンテナーはプロセス・アクション呼び出しをポートレットに発行し、ポートレットはアクションを処理して、必要に応じてその状態を変更します。
  5. 最後に、レイアウト・システムによってレンダリングが開始され、ポータルはページ上の各ポートレットのポートレット・コンテナーを呼び出します。ポートレット・コンテナーは要求されたポートレットのレンダリング・メソッドを呼び出し、ポートレットはそのマークアップ・フラグメントを出力ストリームにレンダリングします。すべてのポートレットが処理されると、完成したページがクライアントに返されます。

ポータルとSOA

サービス指向アーキテクチャー(SOA)は、アプリケーションの機能をサービスとしてエンド・ユーザー・アプリケーションまたは他のサービスに配布する分散システムを構築するためのアプローチです。SOAは、これらの異なるサービスを統合および管理するメカニズムを提供します。

ポータルはSOAの概念にどのように適合するのでしょうか。ポータルは優れたユーザー・インターフェース(UI)のサポートをSOAに提供します。ミドルウェアがライフ・サイクル(ユーザー単位のカスタマイズ、集約、他のコンポーネントとの統合など)の共通機能を処理するのに対し、開発者は、ポータルの構築ブロックであるポートレットを使用することで、アプリケーション固有の機能に重点を置くことができます。

ポータルは、SOAランタイムがサービスを組み合わせて統合する方法と似た方法で、UIを集約および統合する機能をもたらします。コンポーネントUIはより大きく価値のあるUIへと集約され、ITサービスの単一ビューをユーザーに提供します。ユーザーは、この1つのUIだけをマスターすれば済みます。もともと個別に設計されたアプリケーションを新しい機能として統合できます。ポートレット間通信を使用して、コンポーネントを統合できます。たとえば、電子メール・ポートレットがコラボレーション・ポートレットと通信し、受信ボックスにフィルターを設定し、送信者がオンラインでチャット可能なときだけ受信済みメールを表示する、といったことが可能です。この機能は、どちらのオリジナル・アプリケーションでも利用できません。

ポータル・モデルの驚くべき結果として、オンデマンド・ビジネスの機敏さが改善されたことが挙げられます。システム管理者は、プログラミングなしに新しいアプリケーションを作成するアプリケーション・インテグレーターになることができます。必要なのは、新しいページの定義、ページへのポートレットの追加、ポートレット間のワイヤリング、権限の設定です。セルフサービス・ポータルにより、ユーザーは自分自身の必要性に応じて作業環境を調整できます。このため、アプリケーション開発者はポータル・アーキテクチャーによって解放され、新しいビジネス・バリューの構築に専念できます。

ローカル・ポートレットのサービス・インターフェースとプロトコルは、Java Portlet Specification によって定義されます。Web Services Remote Portlet(WSRP)はポートレットのリモート・レンダリングの標準で、ポータルが複数のリモート・ソースからコンテンツを集約することを可能にします。WSRPはWebサービスの統合機能をプレゼンテーション指向コンポーネントに拡張し、プラットフォーム、実装言語、およびベンダー間でビュー・レイヤーを共有できるようにします。追加のプログラミングを行うことなく、コンテンツとアプリケーション・プロバイダーのサービスを検出し、標準に準拠したアプリケーションに組み込むことができます。


成果物:ポートレット

ポートレットは、ポートレット・アプリケーションの基本的な構築ブロックです。この記事では、JavaPortlet APIまたはプログラミング・モデルについて触れない代わりに、WebSphere Portal特有の拡張に重点を置いて説明します。Portlet APIの詳細については、「参考文献」を参照してください。

タグ・ライブラリー

JSR168は、ほとんどの共通ポートレット仕様の機能(アクションの作成やURLのレンダリングなど)についてのタグ・ライブラリーを定義します。また、JSP Standard Template Library(JSTL)は、JSPの追加共通機能(反復、フォーマット、国際化対応)を提供します。WebSphere Portal は、他の国際化対応の拡張を使用可能にするポートレットについての追加タグ・ライブラリーを提供します。

標準タグ・ライブラリーが十分でない場合に限り、アプリケーション固有のタグ・ライブラリーをポートレット・アプリケーションに含める必要があります。

ブローカーによるポートレットの対話

現在、Java Portlet Specificationが提供するポートレット間のデータ共有のサポートには制限があります。ポートレットは、他のポートレットとデータを共有するために、同じWebアプリケーション内のポートレット・セッションだけを利用できます。

WebSphere Portalは、ブローカーによるポートレット間の対話メカニズムの概念を提供します。すべてのポートレットはブローカーとの対話機能を登録し、ブローカーはポートレット間の対話を推進します。ブローカーは、「ポートレットは、型付きプロパティーのプロバイダーであり、コンシューマーである」という原理に基づいて動作するため、プロパティー・ブローカーと呼ばれています。ポートレットは、プロパティーの提供と消費の権利を直接登録するか、プロパティーを消費および提供するアクションの登録を介してこれを間接的に行います。プロパティーに関連する型付き情報を使用することにより、プロパティー・ブローカーは異なるポートレットに属するプロパティー間の互換性を判断できます。これによって、疎結合で高度に対話的なアプリケーションが可能になります。ポータル管理者は、実行時に統合されるようにポートレット間の結び付きを定義できます。

ポートレット間通信のプログラミング・モデルは、既存のJSRポートレットのAPIメソッドprocessActionを使用して、ポートレットにプロパティーの変更を通知します。このため、これらのポートレットはIBM拡張をサポートしない環境でも実行できます。IBM以外の環境では、プロパティー・ブローカーの特殊なアクションは起動されません。

通常、ポートレット・アプリケーションの開発者は、ブローカーによる基本的な連携メカニズムを利用するために、(通常のポートレット開発を超える)追加のプログラミングを求められることはありません。代わりに、開発者はプロパティーとアクションをWSDLファイルでブローカーに宣言する必要があります。WebSphere Portal V5.1.0.1では、プロパティー・ブローカーのメカニズムは、同じページ上のポートレット、または異なる2つのページ上のポートレットだけに制限されています。


ポートレット・フレームワーク

より複雑なポートレット・アプリケーションを作成するときにフレームワーク使用すると、多くの開発作業を節約できるだけでなく、これらのポートレット・アプリケーションが適切な設計となり、維持しやすくなります。WebSphere Portalは、Struts、Java Server Faces、および、JSF Widget Libraryの3つのフレームワークをサポートします。

Struts

Strutsは最も古いWeb開発フレームワークの1つで、非常に大きな開発者コミュニティーと非常に優れたツールのサポートを持っています。StrutsはApache[Struts]のオープン・ソース・プロジェクトで、サーブレットおよびJSPプログラマーにマルチページのModel-View-Controller(MVC)フレームワークを提供するために作成されました。Strutsはサーブレット用に開発されたため、ポートレットに対してはそのままでは機能しません。ポートレットは、アクションおよびレンダリング・フェーズと共に、インターフェースに厳密に組み込まれたMVCパターンを持ちます。また、ポートレットとサーブレットの要求/応答は異なるので、適合させる必要があります。WebSphere Portalは、WebSphere Portal上でJSR168ポートレットをサポートするよう変更された特殊なバージョンのStrutsV1.1ライブラリーを提供します。

Java Server Faces(JSF)

Java Server FacesはJava Webアプリケーション用のUIフレームワークで、Java Community Processを介して標準化されました。これはたいへん新しいフレームワークなので、ポートレットについて考慮しており、ポートレットとサーブレットに対してそのままで機能します。UIコンポーネントに加え、JSFは、ステート・ハンドリング、検証、およびこれらのコンポーネントのイベント処理についてのインフラストラクチャー・サポートも提供します。JSFは、ポートレットと共に適切に動作する強力で柔軟性の高いフレームワークです。

WebSphere PortalはJSFライブラリーを含めることによってJSFをサポートするため、テーマとスキンはこのUIフレームワークを活用できます。Rational Application Developerは、ツールのサポートを行います。ウィザードを使用してJSFベースのポートレットを作成できます。また、ポートレットが用いる追加JSF UIウィジェットを使用することもできます。

JSF Widget Library(JWL)

Rational Application Developerによって提供されるJWLは、ポータルとポートレット・プログラマーがJSFをベースとした追加ウィジェットを使用できるようにします。このライブラリーの大きな特長の1つとして、これらのウィジェットがクライアント機能を持つことが挙げられます。ウィジェットは、ビューを更新するためにクライアントで処理を実行できます。これによってサーバーとのやり取りが削減され、応答時間が劇的に短くなるため、ユーザー・エクスペリエンスが飛躍的に改善されます。他のポートレットと同様に、これらのウィジェットを使用するWebSphere Portalポートレットをデプロイできます。


成果物:テーマとスキン

J2EE JSPモデルは、Webアプリケーションの構築時に、プログラミングの役割を設計の役割から切り離すためのベースを提供します。WebSphere Portalは、より明確な分離と高い柔軟性を持つフレームワークを提供することにより、これを進化させています。WebSphere Portalのテーマとスキンは、適切に定義された成果物(JSPとCSSクラスを含む)によって、ユーザー・エクスペリエンスのブランディングとルック・アンド・フィールのアスペクトを分離しています。トポロジー・モデルで参照されるテーマとスキンの実装を単に置き換えることにより、ユーザー・エクスペリエンスのブランディングと全体のルック・アンド・フィールを簡単に変更できます。WebSphere Portal V5.1.xでは、テーマとスキンを適用しなければならないディレクトリー構造を定義するため、テーマとスキンをWebSphere Portalにデプロイすることができます。

テーマはページのルック・アンド・フィール(ブランディングを含む)のアスペクトを制御します。スキンは、ポートレット・コントロールを公開します。テーマとスキンを円滑に機能させるために、ポートレットのプログラマーは、グローバルに定義された標準CSS形式クラス(JSR 168およびWSRPで定義されたものなど)を実装で使用する必要があります。これにより、個別に開発されたポートレットが同じページに集められ、同じチームによって開発されたポートレットのように表示されます。

WebSphere Portal5.1のデフォルトのテーマの一部を図3に示します。どのテーマも、ページ用のテーマとして選択できます。また、これらのテーマをテンプレートとして使用して、カスタム・テーマを作成できます。

図3.WebSphere Portal5.1のデフォルトのテーマの一部
図3.WebSphere Portal5.1のデフォルトのテーマの一部

ポートレット・ウィンドウをレンダリングするWebSphere Portal V5.1のデフォルトのスキンの一部を図4に示します。テーマの場合と同様に、スキンをカスタマイズしたり、独自のスキンを作る際のサンプルとして使用できます。

図4.WebSphere Portal V5.1のデフォルトのスキンの一部
図4.WebSphere Portal V5.1のデフォルトのスキンの一部

テーマとスキンに関する情報は、Theme ListモデルおよびSkin Listモデルを介してプログラマチックに取得できます。これらのモデルは、テーマ・オブジェクトとスキン・オブジェクトを公開しています。これらは、特定のテーマまたはスキンに関する情報を入手するために使用します。


成果物:ポートレット・サービス

ポートレット・サービスは、名前からもわかるように、ポートレットによって使用されるサービスです。サービスの種類には、WP5.1と共に出荷されるデフォルト・ポートレット・サービスとカスタム・ポートレット・サービスの2種類があります。

ポートレット・サービスのプログラミング・モデルは、ポートレットAPIで指定されていない機能をポートレットに提供するためのフレームワークを定義します。ポートレットは、このようなサービスを標準JDNI検索を通じて取得できます。インターフェースの定義では、ポートレット・サービスはまったく制限されていません。一般に、ポートレット・サービスはポートレットAPI(ポートレット要求など)からオブジェクトを入力パラメーターとして受け取ります。一部の(IBM独自の)ポートレット・サービスは、WebSphere-Portalの一部として提供されますが、カスタム・サービスをポータルに追加することもできます。

ポートレット・サービスには、ほぼ独立する次の2つの観点があります。

  • サービス・アクセス(クライアント・ビュー)は、ポートレット・サービスのインターフェースをどのように定義し、ポートレットがサービスの実装をどのように取得するのかを示します。
  • サービス・プロバイダー(サーバー・ビュー)は、サービスがどのように実装および登録されるのかを示します。

ポートレット・サービスのプログラミング・モデルはシングルトン・ベースです。これは、ポートレット・サービスのポートレット・エンティティー固有のインスタンスがないことを意味します。このため、ポートレットのinitメソッドでサービスを検索し、それをインスタンス変数に格納するプログラミング手法が推奨されています。

WebSphere Portal V5.1.0.1は、次のポートレット・サービスを提供します。これらのサービスは、一般的な使用を目的としたAPIです。

  • コンテンツ・アクセス・サービス(Content access service)
    com.ibm.portal.portlet.service.contentaccess.ContentAccessService
    ポートレットのインターネットへのアクセスを可能にし、ポータル管理者がこのアクセスを一括して管理できるようにします(たとえば、プロキシー・サーバーを設定し、特定のWebサイトを除外します)。
  • クリデンシャル・ボールト(Credential vault)
    com.ibm.portal.portlet.service.credentialvault.CredentialVaultService
    バックエンド・システム用のユーザーIDとパスワードを保存し、ポータル・ユーザーにシングル・サインオンを提供します。このサービスについては、このシリーズのセキュリティーとユーザー管理の記事で詳しく説明する予定です。
  • 動的UIマネージャー(Dynamic UI manager)
    com.ibm.portal.portlet.service.dynamicui.DynamicUIManagementFactoryService
    動的ポートレットとページを起動します。詳細については、次のセクション(LINK)を参照してください。
  • タスク・マネージャー・サービス(Task manager service)
    com.ibm.portal.portlet.service.taskmanager.TaskManagerDelegateFactoryService
    および
    com.ibm.portal.portlet.service.taskui.TaskUIManager
    ポートレットがBPEL関連のワークフローに参加できるようにします。

次のサービスはSystem Programming Interface (SPI)です。より複雑で、高度な用途を目的としています。

  • Pumaユーザー管理(Puma user management)
    com.ibm.portal.um.portletservice.PumaHome
    ポータル・ユーザーまたはグループのプロファイルへのアクセスを提供します。ユーザーおよびグループを検索、作成、変更、削除できます。このサービスについては、このシリーズのセキュリティーとユーザー管理の記事で詳しく説明する予定です。
  • クリデンシャル・ボールト暗号化出口(Credential Vault encryption exit)
    com.ibm.portal.portlet.service.credentialvault.spi.EncryptionExit
    保存されているユーザーIDとパスワードの暗号化を可能にします。
  • ポータル・モデルSPI(Portal model SPI)
    com.ibm.portal.model
    現在のナビゲーションとポータルのコンテンツ・モデルに読み取りアクセスを与えます。他のポートレットとページへのナビゲーション・リンクを提供するポートレットを作成できます。このプログラミング・インターフェースについては、動的および状況依存ポートレットに関する記事で詳しく説明する予定です。

部品の組み立て:ポータルの集約

集約は、ページ上のポートレットによって生成されたすべてのマークアップ・フラグメントと、テーマおよびスキンによって生成された全体の追加マークアップ・フラグメントをまとめて、ユーザーに送り返す1つのページに組み込むプロセスです。

テーマとスキンを通じて、集約されたページのルック・アンド・フィールをカスタマイズできます(「成果物:テーマとスキン」を参照)。また、マークアップ用のテーマとスキンを提供することにより、新しいマークアップのサポートを追加できます。

カスタマイズのもう1つのポイントは、どのポートレットが現在のページにマークアップを提供するのかを決定することです。これは、ポータル管理者、またはページを作成してページ上にポートレットを配置できるエンド・ユーザーによって静的に行うことができます。あるいは、次のセクションで説明する動的UIマネージャーを介して動的に行うこともできます。ポータル管理者は、ページをカスタマイズするアクセス権を他のポータル管理者またはポータルのエンド・ユーザーに委任することができます。

ユーザー用にページをレンダリングするために、集約は、ユーザーの現在のページと、そのページに存在するリソースを決定する必要があります。これらのすべての情報は、ポータルのトポロジー・モデルに保存されています。トポロジー・モデルは、いくつかの種類のポータル・リソースに及びます。これらのリソースは、異なる種類のモデルを通じて利用できます。これらのモデルには、コンテンツ・モデル(Content Model)、レイアウト・モデル(Layout Model)、ナビゲーション・モデル(Navigation Model)、およびナビゲーション選択モデル(Navigation Selection Model)が含まれます。ナビゲーション選択モデルを除き、これらはすべてツリー・モデルです。情報はツリー階層に従って順番に並べられ、ツリー・モデルの通常の方法でモデルを探索できます。

コンテンツ・モデルの要素には、ページ、ラベル、およびURLがあります。ページを表す各コンテンツ・ノードごとに、ページのレイアウトを表すモデル(レイアウト・モデル)が存在します。このモデルには、ページ(コンテナーとポートレット・ウィンドウ、コントロールと呼ばれることもあります)のレイアウトとコンテンツを表すレイアウト・ノードが含まれています。

ナビゲーション・モデルは、ポータル・ユーザーに表示されるナビゲーションの選択肢の構築に使用される要素を表します。ナビゲーション・モデルの要素は、ナビゲーション・ノードです。このような各ノードは、コンテンツ・ノードを参照できます。

ユーザーがポータル内を移動するときは、現在のページをレンダリングするために、現在選択されているナビゲーション・ノードが必要となります。ナビゲーション選択モデルは、現在の選択を反映します。これは、ナビゲーション・モデルを通じたパスを定義するリストを表します(図5参照)。

図5.ポータルの集約に関連するさまざまなモデル
図5.ポータルの集約に関連するさまざまなモデル

動的UI管理

動的UI管理は、ユーザー対話に基づいて動的ページとポートレットを動的に追加または削除する特殊なユース・ケース(動的ユーザー・インターフェースまたは動的UIと呼ばれます)を扱います。動的ページのレイアウトは、ページ定義によって定義されます。これは、マスター・コピーとして動作する静的ポータル・ページです。ページとポートレットは、その動的な特性により、ポータル・データベースでは維持されず、ポータルのユーザー・セッションと同じ最大ライフタイムを持ちます。ページとポートレットは、セッションが終了する前に、プログラマチックに、またはユーザーによって閉じることができます。

動的UI管理を使用すると、次のことができます。

  • ポータル内のページ数とページ内のポートレット数を最小限に保つことにより、ユーザビリティーを向上させます。
    ユーザーとの対話に基づき、必要なときにページとポートレットを表示し、不要になったときに削除できます。
  • コンポーネントの再利用を促進します。
    ページとポートレットが呼び出し側のアプリケーションとシームレスに統合するよう、現在のアプリケーション・コンテキストと共にページとポートレットをパラメーター化することができます。
  • マルチページ・アプリケーションをサポートします。
    アプリケーションが複数のページを使用できます。これによって、たとえば、ウィザード・ダイアログを実装できます。

動的UI管理に密接に関連する概念として、ページとポートレットのコンテキストの転送があります。このメカニズムを使用すると、現在のアプリケーション・コンテキストと共にパラメーター化されたページまたはポートレットを動的に起動できます。これにより、動的UIを作成したポートレットとのシームレスな統合が実現されます。動的ページが起動されたときに、動的ポートレットはプロパティー・ブローカー・イベントを通じて、この動的UIコンテキストを受け取ります。動的UIのプログラミング・モデルは、プロパティー・ブローカー・モデルと密接に関連しています。

動的UI管理については、後の記事で詳しく説明します。


セキュリティー

WebSphere Portalのセキュリティーは、WebSphere Application Serverによって提供されるセキュリティー機能にほぼ基づいています。いくつかの領域では、WebSphere Portalはポータル固有のセキュリティー拡張を有効にする追加サービスを提供します。

WebSphere Portalのセキュリティーには、次の各機能が含まれています。

  • J2EE権限
    WebSphere Portalポートレット・コンテナーは、J2EE仕様に基づいてプログラムによるJ2EE権限をサポートします。
  • ポータル・アクセス制御
    ポータル・ドメイン内のアクセス制御は、J2EE権限モデルには基づいていません。このモデルはあまり強力でなく、ポータル認証ドメインの実行可能なソリューションにならないからです。代わりに、アクセス制御はポータル・アクセス制御に基づいています。ポータル・アクセス制御の詳細およびポータル・アクセス制御を使用してポータルのパフォーマンスを最適化する方法については、リソースを参照してください。
  • クリデンシャル・ボールト
    クリデンシャル・ボールトは、ポートレットがユーザー名とパスワードのペアなどの機密情報を安全に保存するために使用するWebSphere Portal内のコンポーネントです。クリデンシャル・ボールトは、ポートレットが機密情報を読み書きするために使用するポートレット・サービスと既存のクリデンシャル管理システムと統合するために実装できるサービス・プロバイダー・インターフェースを公開します。
  • Java2セキュリティーのサポート
    Java2プラットフォーム・セキュリティーは、WebSphere Application Server V5によって新たに導入されたセキュリティー機能です。この機能は、オペレーションの実行を許可する特定の権限をコードに付与する形で、個々の機密オペレーション(ファイルI/Oやネットワーク・アクセスなど)を保護します。

セキュリティーの詳細と、ポータルのデフォルトの動作をカスタマイズする方法については、このシリーズの今後の記事で解説する予定です。


仮想ポータル

WebSphere Portalは、ユーザーとシステム管理者の統合、共通のルック・アンド・フィール、および標準化されたアプリケーション・プログラミング・モデルが一体となったものです。さまざまなバックエンド・システムを共通のユーザー・エクスペリエンスに統合できます。しかし、独立したユーザーの集まりがあり、これらの各ユーザーに、非常に独自で優れたルック・アンド・フィールを与える場合もあります。各コミュニティーは、他のコミュニティーには依存せずに、WebSphere Portal固有の論理パーティションで作業することを希望しています。複雑なハードウェアおよびソフトウェア・システムを何度もインストールせずに、これらのコミュニティーを効率よくサポートすることが目的です。

時間がかかるこのような面倒なインストールは、ハードウェアまたはソフトウェアを共有し、仮想ポータルと呼ばれる複数の論理ポータルを有効にすることにより回避できます。 エンド・ユーザーは、標準WebSphere Portalがフルにインストールされた環境によって要求が処理されたのか、あるいは共有環境内で定義された論理ポータルによって要求が処理されたのかを区別することができません。 並行して行うインストールの数が減少するため、システム管理が簡素化されます。このようなハードウェアまたはソフトウェアの共有は、ホスティング環境で特に重要です。 たとえば、サービス・プロバイダーが複数のテナントにポータル・サービスを提供するような場合です。仮想ポータルのいくつかの特長は、プログラミング・モデルに影響を与えます。これについて、以下で説明します。

複数の仮想ポータルを単一のWebSphere Portalインストール済み環境で公開するには、各論理ポータルがそれぞれ独自のルック・アンド・フィールを示すことが不可欠です。これは、各論理ポータルに、並列のルート・コンテンツ・ノードを作成することで実現できます。各コンテンツ・ルートとその子ページは、並列するツリーの他のコンテンツに影響を与えずに、個別のテーマとスキンを適用できます。エンド・ユーザーは、2つの異なるコンテンツ・ノードが、物理的に同じWebSphere Portalのインストール済み環境に実際に存在していることに気付きません。

3つの仮想ポータルでのこのコンテンツ階層を図6に示します。各仮想ポータルのコンテンツ・ルートには、個別のURLを介してアクセスできます。また、仮想ポータル固有のログイン、エラー、ログアウト、自己登録の各「ページ」を用意することもできます。この目的のために、現在の「画面」の代わりに、カスタマイズされたポートレットを使用できます。

図6.仮想ポータルのコンテンツ階層
図6.仮想ポータルのコンテンツ階層

ポータルに要求を送信するときは、どの仮想ポータルにアクセスするのかをURLに含める必要があります。この目的のために、わかりやすいURLマッピングが適用されます。各仮想ポータルは、そのコンテンツ・ルートを参照する固有のURLマッピングを持ちます。このマッピングは、仮想ポータルの初期化の際に定義および作成されます。仮想ポータルのわかりやすいURLは次のようになります。

http://www.ibm.com:9081/wps/portal/aVirtualPortal

仮想ポータル内のページへの追加URLマッピングは、5.0Portalの通常のインストール済み環境で行われるのとまったく同じ方法で、いつでも作成できます。 URLマッピングを指定しないと、ユーザーは「デフォルト」の仮想ポータルに誘導されます。デフォルトのポータルとは、WebSphere Portalのインストール時に作成されたポータルです。無効なURLマッピングが使用された場合も、ユーザーは「デフォルト」の仮想ポータルに誘導されます。

WebSphere Portalは、使用されているURLマッピングに基づき、内部の仮想ポータル・コンテキストを設定します。ユーザーのアクティビティーは、その仮想ポータルのコンテキスト内ですべて実行されます。現在のコンテキストに応じて、異なるコンテンツがユーザーに表示されます。

アプリケーションの共有を可能にしながら、個々の仮想ポータルのコンテンツを分離するという課題は、WebSphere Portal V5.1の新しい概念によって解決されました。 WebSphere Portalのリソースのタイプに応じて、次のいずれかの方法でスコープが設定されます。

  • 特定の仮想ポータルにスコープを設定する
    スコープ設定されたこのようなリソースを使用するには、対応する仮想ポータルにアクセスする必要があります。これらのリソースは、他の仮想ポータルに表示されず、また他の仮想ポータルからアクセスされません。このため、これらのリソースは仮想ポータル間で共有できません。ページ、ポートレット・エンティティー、および検索索引はスコープ設定されたリソース・タイプです。これらのリソース・タイプのスコープは、WebSphere Portalによって実施されます。
  • インストール済み環境のすべての仮想ポータル間で共有する
    共有リソースはWebSphere Portalのインストール済み環境全体で利用可能であるため、すべての仮想ポータルで使用できます。ポートレット定義、ポートレット・アプリケーション、Webモジュール、 URLマッピング、WSRPプロデューサー、テーマ、およびスキンは共有リソース・タイプです。しかし、ポータル・アクセス制御を適用し、これらの共有リソースの使用を特定の仮想ポータルに制限することができます。選択した仮想ポータルのユーザーにのみ、共有リソースへの権限を付与することができます。

モデルへの影響

インストール済み環境全体で1つの共通ポータルを共有しているため、アプリケーションを開発するときは、仮想ポータル間では真のアプリケーションの分離は行われないことに注意する必要があります。セッションやWebアプリケーションなど、J2EEの基本的な概念では、仮想ポータルの概念は認識されません。

ポートレット・アプリケーションは、仮想ポータル間にわたる同じセッションを共有します。ポートレットのプログラミング・モデルの観点から、これは1つのページまたは異なるページで同じポートレットを複数回使用することに他なりません。この記事の「ポートレット」セクションでは、ポートレット定義、ポートレット・エンティティー、およびポートレット・ウィンドウの異なるカスタマイズ・レベルについて説明しました。セッションのアプリケーション・スコープでデータを保存するとき、ポートレットは、このポートレットの複数のインスタンスがポートレット定義およびポートレット・エンティティーのレベルで存在し、予防策を講じないと、それぞれのインスタンスがデータを上書きする可能性があることを考慮しなければなりません。

ポートレット定義レベルでポータルは、これらの異なる定義を識別するために使用されるプリファレンス設定をポータル管理者に提供できます。ポートレットはこのプリファレンス属性を使用して、ポートレット定義ごとにセッション・データのネームスペースを指定できます。たとえば、新しいポートレットがセッション・スコープ・キーをnews Portlet Instanceという名前で提供するとき、システム管理者は、ヨーロッパの新しいプロバイダーを指す最初のポートレット定義に対してこの値を「EuropeanNews」に設定し、米国の新しいプロバイダーを指す2番目のポートレット定義に対してこの値を「USNews」に設定できます。

ポートレット・ウィンドウは、共有アプリケーション・セッション内のデータを分割するために使用できます。これにより、ポートレットのそれぞれの外観がアプリケーション・セッション・スコープ内に保存された独自のデータを持つことができ、J2EEの他の成果物との間で共有されません。

1つのポートレットを異なるWebアプリケーションとして複数回デプロイすることができます。デプロイされた各アプリケーションはすべての仮想ポータル間で共有されますが、ポータル管理者は、アクセス制御を適用し、デプロイされた各インスタンスを特定の仮想ポータルに制限することができます。そして、仮想ポータルはWebアプリケーションの独自のコピーを使用し、より高度な分離(セッション・データの分離など)を行うことができます。


ポートレット・アプリケーションのサンプル

これまで、WebSphere Portalプログラミング・モデルのさまざまな特長を説明してきました。ここで、実際の例を見ることにしましょう。まず、この第1部の記事では、標準に厳密に基づくカレンダー・ポートレット・アプリケーションから始めます。今後の記事で、ポートレット間通信などのWebSphere Portal拡張を用いてこのサンプルを拡張します。

カレンダー・ポートレット・アプリケーションは、カレンダー・ポートレットと表示ポートレットの2つのポートレットで構成されます。カレンダー・ポートレットは、ユーザーが日付を選択できる特定の月を表示し、表示ポートレットは、選択された日付のタスクをカレンダー・ポートレットにレンダリングします。カレンダー・ポートレットと表示ポートレットは、ポートレット・アプリケーション・セッションを介してデータを共有します。実行中のサンプルを図7に示します。

図7.実行中のカレンダーのサンプル(12/12の日付が選択され、タスク・リストがタスク・ポートレットに表示されています)
図7.実行中のカレンダーのサンプル(12/12の日付が選択され、タスク・リストがタスク・ポートレットに表示されています)

ダウンロードできるこのサンプルについては、全体のコードを含め、『Portletsand Apache Portals』のセクション3.2で解説されています。この参考文献、およびRational Application Developerを使用したポートレットの作成とWebSphere Portalへのデプロイに関する参考文献については、「参考文献」を参照してください。


まとめ

WebSphere Portalプログラミング・モデルは、さまざまな機能を提供するプログラミング成果物(ポートレット、テーマとスキン、ポートレット・サービスなど)によって成り立っています。WebSphere Portalには多数のカスタマイズ・ポイントがあり、これを利用することにより、ニーズに応じてポータルを調整および拡張することができます。新しいV5.1.0.1APIの使い方については、このシリーズの後の記事で詳しく解説します。

次の第2部では、ポータルURL生成について取り上げ、この機能を独自のテーマで利用する方法について解説します。別の記事では、ポートレットをより動的にする方法や現在のユーザー・コンテキストに応答する方法を解説します。さらに、別の記事では、セキュリティーを詳しく掘り下げ、クリデンシャル・ボールトやログイン/ログアウト動作のカスタマイズ方法、お使いのインフラストラクチャーでのシングル・サインオンの実現方法について解説します。最後に、独自のポートレット・サービスの作成方法を解説します。


ダウンロード

内容ファイル名サイズ
コードサンプルCalendarPortlet.zip  ( HTTP | FTP )928B

参考文献

学ぶために

製品や技術を入手するために

  • Rational Application Developer V6(US):developerWorksから試用版をダウンロードできます。ポータル・ツールとプロトタイプ開発に使えるポータルのテスト・ランタイムのコピーが含まれています。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus, WebSphere
ArticleID=339121
ArticleTitle=WebSphere Portal V5.1.0.1プログラミング・モデルを活用する: 第1部:モデルの概要
publish-date=08252006