|
|
この章では、ポータルの開発を始める際に役立つ概要および参考情報について説明します。
Workshop for WebLogic を使用してポータルを開発する場合、ポータルの定義は単一の XML ファイルとして存在します。エディタを使用してポータルを構築すると、Workshop for WebLogic によって自動的に XML ファイルが作成されます。
ポータル ファイルには、特定のポータル インスタンスを構成するすべてのコンポーネント (ブック、ページ、ポートレット、ルック アンド フィール コンポーネントなど) が含まれます。
多くのコンポーネントは、お互いに階層的な関係を持っています。たとえば、ブックにはページが含まれ、ページにはポートレットが含まれます。図 3-1 は、ポータルのコンポーネント間の関係を示しています。
Workshop for WebLogic でポータル リソースやテンプレートを開発する場合、または WebLogic Portal Administration Console でポータルの作成や管理を行う場合のいずれにおいても、ポータル フレームワークによって統一されたコンポーネントを個別に操作します。
図 3-1 は、WebLogic Portal アーキテクチャの柔軟性と拡張性を示しています。この図で、(0...1) は 0 または 1 を意味し、(1...n) は 1 以上を意味し、(0...n) は 0 以上を意味します。たとえば、ポータルには 1 つ以上のデスクトップを含めることができます。ルック アンド フィールやシェルなどのように一度だけ実行されるリソースの場合、一度に 1 つのリソースしか許可されていない場合でも、複数のバージョンを作成できます。
BEA Workshop for WebLogic Platform は、Eclipse Platform に対するプラグインとして実装されます。具体的には、Eclipse Workbench、Java 開発ツール (JDT)、Web Tools Platform Project (WTP) のカスタマイズ バージョン、Workshop for WebLogic 用のプラグインなどです。Workshop for WebLogic ワークベンチの使用手順については、『BEA Workshop for WebLogic Platform のドキュメント』を参照してください。WebLogic Portal には、ポータルおよびポートレットの開発を容易にする付加機能が用意されています。
この手順を進める前に、BEA Workshop for WebLogic のプログラマーズ ガイドまたは e-docs のヘルプにあるチュートリアル「BEA Workshop for WebLogic Platform 入門」を参照して、Workshop for WebLogic の機能をよく理解しておいてください。
「ポータル開発環境の設定」の説明に従ってポータル開発環境を設定した場合、一般的に、アプリケーションは図 3-2 に示すコンポーネントで構成されます。
これらは、ポータル アプリケーションの開発とテストに必要となる基本的な部分です。
WebLogic Portal では、Eclipse と Workshop for WebLogic の標準的なビューと独自のカスタマイズ ビューを使用して、ポータルの構築を簡素化しています。図 3-3 は、ポータル開発中の Workshop for WebLogic ワークベンチの例を示しています。
開発時には、伝播パースペクティブおよびページ フロー パースペクティブも使用します。伝播パースペクティブの詳細については、『プロダクション業務ガイド』を参照してください。ページ フロー パースペクティブの詳細については、「Workshop for WebLogic のヘルプ」を参照してください。
共有 J2EE ライブラリ (ライブラリ モジュールとも呼ばれます) を使用すると、すべての EAR プロジェクトおよびポータル Web プロジェクトにリソースを複製する代わりに、単一のリソース セットをデプロイして使用できます。ソース管理、ファイル共有、およびアプリケーションへのパッチ適用を行う場合に大きな利点があるため、共有 J2EE ライブラリの使用をお勧めします。WebLogic Portal では、共有 J2EE ライブラリが実装されたコンフィグレーションのみがサポートされます。共有 J2EE ライブラリの詳細については、WebLogic Server ドキュメントの「共通 J2EE ライブラリおよびオプション パッケージの作成」を参照してください。
図 3-2 のように、EAR プロジェクトと Web プロジェクトには、実際にはドメイン レベルで格納される共有 J2EE ライブラリへの参照が設定されています。これらのプロジェクトは、参照元アプリケーションの一部としてパッケージ化されたモジュールのように使用できます。
J2EE ライブラリのリソースは、J2EE ライブラリからポータル Web プロジェクトにコピーしてオーバーライドすると、そのリソースをカスタマイズできます。たとえば、特定のポータル Web プロジェクトでデフォルトのルック アンド フィールを変更する場合、デフォルトのルック アンド フィールをライブラリからポータル Web プロジェクトにコピーし、それを変更できます。
リソースをコピーすると、ポータル Web プロジェクト内の「一致する」場所にそのリソースが配置されます。このプロジェクトをデプロイすると、コピーしたリソースが検出され、ライブラリ内のリソースのインスタンスの代わりに、コピーしたリソースのインスタンスが使用されます。
| 警告 : | J2EE ライブラリのリソースをプロジェクトにコピーすると、将来 WebLogic Portal 製品を更新するときに、これらのリソースに影響する製品の変更を手動で組み込む作業が必要になる場合があります。今後配布されるパッチをインストールした場合、WebLogic Portal では、コピーされた J2EE ライブラリ リソースがプロジェクトにないコンフィグレーションのみサポートされます。 |
J2EE ライブラリのリソースをプロジェクトにコピーする方法については、「プロジェクトへの J2EE ライブラリ ファイルのコピー」を参照してください。ポータル開発に対する共有 J2EE ライブラリの影響については、「プロダクションへのポータルのデプロイ」を参照してください。
Workshop for WebLogic で作成する .portal ファイルはテンプレートです。このテンプレートの中に、ブック、ページ、およびポートレットを作成し、それぞれのデフォルト値を定義します。この .portal ファイルをブラウザで表示するときは、ポータルは「シングル ファイル モード」で表示されます。これは、ポータルをデータベースからではなく、ファイル システムから表示していることを意味します。つまり、.portal ファイルの XML が解析され、表示されたポータルがブラウザに返されるしくみです。.portal ファイルの作成と使用は開発を目的としていますが、プロダクション環境でも .portal ファイルにアクセスできます。データベースを使用しないため、ユーザ カスタマイズや資格などの機能は利用できません。
.portal ファイルの作成が済んだら、WebLogic Portal Administration Console を使用して、プロダクション環境用のデスクトップを作成することができます。
デスクトップは、訪問者がアクセスできるポータルのビューです。ポータルを複数のデスクトップで構成して、デスクトップのコンテナとして使用することができます。デスクトップには、ユーザ専用のポータル ビューを作成するために必要なポートレット、コンテンツ、シェル、レイアウト、およびルック アンド フィール要素をすべて配置できます。
WebLogic Portal Administration Console で .portal ファイルに基づいてデスクトップを作成する場合は、.portal とそのリソースをデータベースに格納することができます。.portal ファイルに記述されているルック アンド フィールなどの設定は、デスクトップのデフォルトとなります。.portal テンプレートから新しいデスクトップを作成した場合、そのデスクトップはテンプレートから切り離され、.portal ファイルへの変更はデスクトップに反映されなくなります (デスクトップへの変更も .portal ファイルに反映されない)。たとえば、WebLogic Portal Administration Console でデスクトップのルック アンド フィールを変更した場合は、その変更はデスクトップのみに反映され、元の .portal ファイルには反映されません。ブラウザでデスクトップを表示した場合は、そのデスクトップは (データベースから) 「ストリーミング モード」で表示されます。この場合はデータベースが使用されるため、デスクトップのカスタマイズを保存し、委託管理と資格をポータル リソースに設定することができます。
ストリーミング ポータルとファイルベース ポータルのシステム パフォーマンスの違いはそれほど大きくありません。それぞれのポータル タイプの利点は、作成するポートレット数、ポータルのエンド ユーザに提供する機能、およびポータルの管理方法に大きく左右されます。
表 3-1 では、ストリーミング ポータルとファイルベース ポータルの詳細な比較を示しています。
| 注意 : | ファイルベース ポータルで資格を設定することはできません。ただし、そのポータルに基づくデスクトップを作成し、デスクトップのアーティファクトに対して資格を設定すると、.portal ファイルは実行時にそれらを選択します。.portal ファイルはデータベースにアクセスしませんが、資格チェックは実行時に実施されます (これらの資格は LDAP に格納されます)。ファイルベース ポータルで実行時の資格チェックを行わない場合には、WEB-INF/netuix-config.xml ファイルでこの機能をオフにすることができます。 |
パフォーマンス関連の推奨事項については、「単純なアプリケーションでのファイルベース ポータルの使用」を参照してください。
Java コントロールはイベント、メソッド、およびプロパティで使用する視覚的コンポーネントで、既存のデータ、システム、アプリケーション、およびビジネス ロジックとの接続に関する詳細な実装を規定します。
WebLogic Portal および Workshop for WebLogic で利用可能なコントロールは、次の 3 つのカテゴリに分類されます。
Java コントロールの大部分は WebLogic Portal に含まれています。また、独自のカスタム Java コントロールを作成してビジネス ロジックをカプセル化することもできます。
WebLogic Portal で提供されるカスタム Java コントロールは、定義済みの実行時インタフェースや実行時にポータル HTML を表示するために使用されるコンフィグレーション可能なプロパティを備えた開発オブジェクトです。WebLogic Portal のカスタム コントロールを使用すると、開発者が利用しようと考えるすべての情報に基づいて、ポータルの実行時動作を動的に操作できます。コントロール ツリーは要求されるたびに作成されます。また、デスクトップ、メニュー、ページ、またはポートレット レベルで、ツリー内の各コントロールの動作を操作できます。WebLogic Portal のカスタム コントロールは、WebLogic Portal アーキテクチャの「コンテキスト」によって抽象化されます。これらのコンテキストでは、必要なほとんどすべての実行時動作を実現するのに使用可能な、わかりやすい一連の API が利用できます。
WebLogic Portal のポートレット向けカスタム コントロールは、明確に定義されたライフサイクルに準拠します。このライフサイクルは、必要なコントロール操作を行うためのプラグイン ポイントを提供します。たとえば、init() ライフサイクル ステージでは、ポートレットが表示されないように、ポートレットの「非表示」プロパティを動的に「true」に設定する場合があります。
WebLogic Portal のポータル向けカスタム コントロールは、ページ フロー コントロールと相互運用されます。コントロール アーキテクチャはページ フロー コントロール アーキテクチャと相互運用されます。これにより、ポートレットで表示されるページ フロー アプリケーション間の高度な対話と、より一般的なポータル ウィンドウ管理の定義が可能になります。WebLogic Portal のカスタム コントロールとページ フローの統合は、プロパティ シートなどの Workshop for WebLogic のワークベンチ ツールで表示されるため、ページ フローとポートレットを結合するためにコードを記述する必要はありません。
ポータルをデプロイする際にコントロールにアクセスする手順については、「ページ フローのカスタム コントロール」を参照してください。WebLogic Portal で提供されるコントロールとアクションの技術情報については、「コントロールの Javadoc」を参照してください。
WebLogic Portal には、JSP 内で使用できる JSP タグが用意されています。ポートレットは、コンテンツ ノードとして JSP を使用できます。これにより、再利用、パーソナライゼーション、およびその他のプログラム機能を実現できます。Workshop for WebLogic を使用して JSP を作成すると、ポートレットに追加する他の要素の構造を提供できます。
ポータルの開発時に利用可能な JSP タグを確認するには、[ウィンドウ｜ビューの表示｜JSP デザイン パレット] を選択します。
WebLogic Portal の JSP タグに関連付けられたクラスについては、「Javadoc」を参照してください。
ポータル フレームワーク コントロールのライフサイクル内のポータルの動作を制御する一般的な方法は、バッキング ファイルを使用することです。バッキング ファイルは、init()、preRender() など、ライフサイクルの各段階に対応するメソッドを含むことができる Java クラスです。ポータルのバッキング コンテキスト、つまり、ポータル フレームワーク コントロール 自体を抽象化したものを使用して、ポートレットの特性を問い合わせたり、変更したりすることができます。たとえば、init() ライフサイクル メソッドでは、要求パラメータが評価され、そのパラメータの値に応じて、ポートレットのバッキング コンテキストを使用してポートレットを表示するか非表示にするかを指定できます。バッキング コンテキストの詳細については、『ポータル開発ガイド』を参照してください。
バッキング ファイルは、Workshop for WebLogic を使用するか、特定のフレームワーク コントロールの XML ファイルにコードを直接入力することによって、ポータルに追加できます。
バッキング ファイルは、com.bea.netuix.servlets.controls.content.backing.JspBacking インタフェースの実装、または com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking インタフェース抽象クラスの拡張を行う単純な Java クラスです。インタフェースのメソッドは、コントロール ライフサイクル メソッド (「バッキング ファイルの実行方法」を参照) に類似しており、コントロール ライフサイクル メソッドの呼び出しと同時に呼び出されます。
以下のポータル コントロールがバッキング ファイルをサポートしています。
ポートレット間通信の例については、『ポートレット開発ガイド』を参照してください。
すべてのバッキング ファイルは、JSP 呼び出しの前後に実行されます。ライフサイクルの中で、各バッキング ファイルでは以下のメソッドが呼び出されます。
図 3-4 にバッキング ファイルのライフサイクルを示します。
| 注意 : | 以下の処理手順では、ツリーの最適化が有効で、非アクティブ ページの項目が「最適化により除外」されていない場合にメソッドが呼び出されます。たとえば、ツリーの最適化が有効で、生成される部分的なコントロール ツリーに非アクティブ ページの項目が含まれていない場合、メソッドは呼び出されません。 |
| ヒント : | AbstractJspBacking.isRequestTargeted(request) メソッドを使用して、特定のポートレットに対する要求かどうかを判別できます。 |
バッキング ファイルの新しいインスタンスは要求ごとに作成されるため、スレッドの安全性の問題を心配する必要はありません。新しい Java VM は、有効期限が短いオブジェクト用に特別に調整されているため、以前のようなパフォーマンスの問題は発生しません。さらに、JspContent コントロールでサポートされる特殊なバッキング ファイルを使用すると、バッキング ファイルがスレッド セーフかどうかを指定できます。この値を true に設定すると、バッキング ファイルのインスタンスが 1 つだけ作成され、すべての要求で共有されます。
異なるスコープのバッキング ファイルでは、動作が異なります。たとえば、あるフレームワーク コントロールのスコープで使用されるバッキング ファイルは、JSP コンテンツのスコープで使用されるものと異なる動作を持ちます。
<netuix: portlet backingfile =some_value> を使用してポートレット自体にバッキング ファイルがある場合、ポートレットの表示を実際に停止することができます。<netuix: jspContent backingfile=some_value> の一部としてバッキング ファイルを持っている場合、コントロール ツリーのポートレット部分はすでに実行されています。この実装は、ポートレット内の JSP 専用のプロセスを実行したい場合は、このスコープを使用します。
HTTPRequest オブジェクトは変更されやすいため、ライフサイクル メソッド間でデータを渡すときには、リクエスト オブジェクトでなくセッションを使用することをお勧めします。
バッキング ファイルを作成する際は、以下のガイドラインに従う必要があります。
コード リスト 3-1 にバッキング ファイルのサンプルを示します。このサンプルでは、AbstractJspBacking クラスが拡張され、ポートレットで必要なバッキング機能が使用可能になります。HTTPRequest オブジェクトは変更されやすいため、このサンプルではセッション属性を使用しています。ライフサイクル メソッド間でデータを渡すときには、リクエスト オブジェクトでなくセッションを使用することをお勧めします。
package backing;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import com.bea.netuix.events.Event;
import com.bea.netuix.events.CustomEvent;
import com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking;
public class ListenCustomerName extends AbstractJspBacking
{
public void listenCustomerName(HttpServletRequest request,
HttpServletResponse response, Event event)
{
CustomEvent customEvent = (CustomEvent) event;
String message = (String) customEvent.getPayload();
HttpSession mySession = request.getSession();
mySession.setAttribute("customerName", message);
}
}
バッキング ファイルを追加するには、Workshop for WebLogic を使用するか、関連付けするファイルにコードを直接入力します。図 3-5 に示すように、プロパティ ビューの [バッキング ファイル] フィールドにバッキング ファイルを指定するだけです。バッキング ディレクトリを指定し、ドット区切り文字に続けてバッキング ファイルの名前だけを指定します。バッキング ファイルの拡張子は含めないでください。たとえば次のように入力します。
backing.ListenCustomerName.java
この例では、ファイル拡張子を含めた場合、ファイル拡張子がファイル名と解釈されます。これは、ドット区切り文字によってファイル パスが指定されるためです。その結果、アプリケーションは、存在しない ListenCustomerName という名前のディレクトリの、存在しない java という名前のファイルを検索します。
バッキング ファイルをポータル フレームワーク コントロールの XML ファイルにコード化して追加するには、コード リスト 3-2 に示すように、<netuix:jspContent> 要素の中で backingFile パラメータを使用できます。
<netuix:content>
<netuix:jspContent
backingFile="portletToPortlet.pageFlowSelectionDisplayOnly.menu.contentUri="/portletToPortlet/pageFlowSelectionDisplayOnly/menu/
backing.MenuBacking"
menu.jsp"/>
</netuix:content>
Java ページ フローは、Struts ベースの Web アプリケーション プログラミング モデル上に構築される機能セットです。Java ページ フローは Struts の優れた機能と拡張性を利用するだけでなく、Struts ベース アプリケーションを構築する際の問題点を解消します。Java ページ フロー機能では、Web アプリケーション プログラミング モデルや、Web アプリケーション プログラミング モデルに基づいて開発者がアプリケーションを迅速かつ容易に構築するためのツールを実行時にサポートしています。
基本的に、ページ フローは Web アプリケーション ファイルのディレクトリです。これらのファイルは相互に連携して、ユーザ インタフェースの機能を実現します。たとえば、ページ フローによって、Web アプリケーションのユーザ登録ウィザード機能を実現することができます。
ページ間の状態、データ、およびナビゲーション フローは、Java ページ フロー (JPF) ファイルを使用して管理できます。ページ フローでは、他の Workshop for WebLogic アプリケーションと同じプログラミング モデルが使用されます。また、Java コントロールのワンクリック生成や標準的な Struts フレームワーク プラグインが利用できます。また、JPF では双方向の JSP/HTML エディタを使用して「WYSIWYG」の開発を行うこともできます。JPF は、コントロールやデータ バインディング タグを使用する Web サービス、ドラッグ アンド ドロップ コントロール、およびデータをバインドしてフォームやデータバウンド Web ページを作成できます。
ページ フローがある場合には、ページ フロー ポートレットを生成して容易にカプセル化できます。この手順の詳細については、『ポートレット開発ガイド』を参照してください。
Workshop for WebLogic によるページ フローの作成の詳細については、e-docs の『BEA Workshop for WebLogic Platform プログラマーズ ガイド』を参照してください。
WebLogic Portal では、さまざまなメカニズムを利用して HTTP セッションや HTTP リクエストなどの状態を管理できます。また、WebLogic Portal の Java ページ フローでも、Struts ベース フレームワーク内での柔軟性の高い強力な状態管理機能を利用できます。ページ フローの状態管理は、リクエストとセッションの状態管理の間にある溝を埋める役割を果たします。多くのプロジェクトにおいて、リクエストの有効期間は非常に短く、セッションの有効期間は非常に長いため、アプリケーションのニーズを満たすのは困難です。ページ フローを利用すると、状態の有効期間を必要なだけ長くすることができます。
  
|
