|
|
この章で説明する手順を使用して、既存のアプリケーションに WebLogic Portal の機能を追加できます。たとえば、以下のように実行できます。
必要な WebLogic Portal 固有のファセットをインストールすることで、既存の Workshop for WebLogic Web アプリケーションをポータル Web プロジェクトに簡単に変換できます。次に、Web アプリケーションのポータル ユーザ インタフェースを設定し、パーソナライゼーションとキャンペーン機能を追加して、WebLogic Portal のコンテンツとユーザ管理サービスを利用できます。
最初にポータル プロジェクトにコマース タグ ライブラリをインストールするように選択しなかった場合は、必要に応じて後からその機能を追加できます。
| 注意 : | すでに GroupSpace 以外のポートレットが含まれるポータル Web プロジェクトに GroupSpace を追加しないでください。詳細については、『コミュニティ ガイド』を参照してください。 |
アプリケーションがどのように表示されるかにかかわらず、その設計で意図されたすべての機能が維持されます。
WebLogic Portal 環境への Web アプリケーションの統合には、以下の手順が含まれます。
| 注意 : | これらの手順は、Workshop for WebLogic バージョン 9.2 環境の要件を満たし、EAR プロジェクトと Workshop for WebLogic の動的 Web プロジェクトが含まれている既存の Web アプリケーションがあることを前提としています。 |
既存の Web アプリケーションを Workshop for WebLogic に統合し、WebLogic Portal 機能を追加するには、以下の手順に従います。
図 6-1 に示すように、この EAR プロジェクトに関連付けられたプロジェクト ファセットがテーブル内に表示されます。
[Add/Remove Project Facets - Select Project Facets] ダイアログが表示されます。
デフォルトで、WebLogic Portal ファセットのすべての機能が選択されます。図 6-2 に示す例は、選択した WebLogic Portal ファセットのツリーが展開された状態を示します。
図 6-3 に示すように、プロパティ ダイアログの [Project Facets] テーブルに、追加したファセットが表示されます。
[パッケージ・エクスプローラ] ビューには、新しいポータル関連コンテンツが表示されます。
追加完了後、プロパティ ビューの画面に WebLogic Portal ファセットが表示され、[パッケージ・エクスプローラ] ビューのツリーに、追加したポータル固有の共有 J2EE ライブラリが表示されます。
図 6-4 は、EAR プロジェクトと Web プロジェクトに追加された新しいポータル関連コンテンツの例を示します。
これで、WebLogic Portal 機能を使用して、ポータル環境を作成し、構築し、管理できるようになりました。
| 注意 : | すでに GroupSpace 以外のポートレットが含まれるポータル Web プロジェクトに GroupSpace を追加しないでください。詳細については、『コミュニティ ガイド』を参照してください。 |
Struts アプリケーションを Workshop for WebLogic のエンタープライズ アプリケーションに統合またはインポートできます。Workshop for WebLogic に統合またはインポートしたら、ポートレットを作成して Struts アプリケーションのポータル ユーザ インタフェースを設定し、パーソナライゼーションとキャンペーン機能を追加して、WebLogic Portal のコンテンツとユーザ管理サービスを利用できます。
この節で説明するガイドラインに従って、既存の Struts アプリケーションを WebLogic Portal に統合する準備を行います。
トップレベル Struts アプリケーションを使用している場合は、統合する前にリファクタリングを実施する必要があります。ポータルで使用することを目的とする Struts アプリケーションは、JSP で使用する URL 用の html:link タグの使用を含む、Struts モジュールとして開発されている必要があります。このように開発されていない場合、WebLogic Portal は、ポートレット内で Struts アプリケーションを使用するときに、透過的にリンクを変更するために必要な URL の書き換えを行うことができません。
このプロセスの一環として、以下のいずれかの方法を使用して、WebLogic Portal タグを使用するようにアプリケーションを変更します。
![[Select Project Facets] ダイアログで選択 (展開) された WebLogic Portal ファセット](wwimages/tut_integ_webapp_ear_wlp_facets.gif)
![ポータル統合前および統合後の Web アプリケーションの [パッケージ・エクスプローラ] ビュー](wwimages/portals-08-1-4.gif)
web.xml の taglib マッピングを使用して、WebLogic Portal の Struts アダプタ タグを JSP 内にすでに設定した URI にマップする。これにより、既存の JSP の使用が可能になります。 web.xml ファイルを変更しなくても済むようになり、これらの taglib が自動的にデプロイされる利点が得られます。
ポータル内で使用する Struts アプリケーションがスタンドアロン操作もサポートする必要がある場合、アクション フォワードによって参照される JSP は、struts.jar および struts-adapter.jar (BEA が作成するファイル) にある HTML タグ ライブラリのいくつかのオプション タグを使用するように作成する必要があります。これらの内の最初のタグは、Struts と Struts アダプタの両方にある <html:html> です。Struts アダプタ バージョンは、Struts バージョンのタグをオーバーライドし、タグ出力テキストをポータル内で使用する場合に、表示を抑制するかどうかを検出するサポートを追加します。この場合、HTML テキストの出力は非整形式の HTML 形式で生成される場合があります。HTML タグ ライブラリの Struts アダプタ バージョンでは 2 つの追加タグ <html:head> と <html:body> が提供されます。JSP でこれらのタグを使用する場合も、スタンドアロンで使用する必要があります。これらの 2 つのタグは、<html:html> タグと同じポータル対応の表示動作を備えています。
一部の Struts アプリケーションは、カスタム RequestProcessor を使用します。WebLogic Portal と Struts の統合では、RequestProcessor の特定の動作をオーバーライドする必要があります。struts-adapter.jar にある com.bea.struts.adapter.action.AdapterRequestProcessor クラスは、この標準動作を提供し、ポータル内で使用するすべての Struts アプリケーションで使用する必要があります。カスタム RequestProcessor は、このクラスを拡張するか、またはユーティリティ クラスを使用して、この RequestProcessor が実行するのと同じ操作を実行する必要があります。このクラスを拡張する場合、doForward() のオーバーライドはスーパークラスの doForward() を呼び出すと共に、応答への書き込みを行わないようにする必要があります。AdapterRequestProcessor を拡張しないカスタム RequestProcessor は、com.bea.struts.adapter.action.AdapterRequestProcessorUtil.forwardUsingRequest() を呼び出して、転送操作を実行する必要があります。(このメソッドは、実際の RequestDispatcher 転送リクエストを、後で URI をポータルの出力に取り込む際に使用する転送 URI を取得するだけの操作と置き換えます。)
Struts アプリケーションがカスタム アクション サーブレットの使用に依存する場合は、上記で概説したとおり、また Struts の実装で推奨されているとおり、カスタム RequestProcessor を代わりに使用するためにリファクタリングを実施する必要があります。WebLogic Portal のページ フロー機能がカスタム アクション サーブレットを使用し、ポータル Web プロジェクトにはアクション サーブレットは 1 つしかないため、ポータル Struts 統合ではアクション サーブレットをカスタマイズしないようにする必要があります。アクション サーブレットのカスタマイズを RequestProcessor カスタマイズにリファクタリングする方法の詳細については、http://jakarta.apache.org/struts/ にある Struts ドキュメントを参照してください。
StrutsContent コントロールは、アクション フォワードを使用して、モジュールの切り替えをサポートします。呼び出されたアクションによって返されるアクション フォワードによって、別のモジュールにあるコンテンツ URL が生成される場合、現在のモジュールが対応する新しいモジュールに切り替えられ、コントロールを含む Struts ポートレットへのすべての追加リクエストは新しいモジュールを使用して実行されます。モジュールの切り替えは、アクション フォワードだけを使用して実行し、別のモジュールの JSP に直接リンクする <html:link> タグを使用して実行しないでください。このタグを使用すると、ポータルと Struts フレームワークがモジュールを適切に設定し、選択できない恐れがあります。
リファクタリングされた Struts アプリケーションを統合するには、以下の手順を実行します。
WEB-INF/netuix-config.xml ファイルを編集して、有効にする必要があります。 コード リスト 6-1 は、netuix-config.xml ファイルに追加する必要のあるタグの構文を示します。<enable> 要素は true に設定されています。<!-- ページフロー サポートを有効または無効にします -->
<pageflow>
<enable>true</enable>
</pageflow>
このブロックが netuix-config.xml に存在しない場合、追加しないでください。このブロックがないと、デフォルトで true に設定されます。
| 注意 : | 以下の手順は、分割ソースをベースとしないデプロイメント構造を前提としています。ユーザの実際の手順は、この例で示す手順と異なる場合があります。 |
/src) にコピーします。WEB-INF/lib フォルダにコピーします。struts-config.xml またはモジュール コンフィグレーション ファイルを WEB-INF にコピーして、名前を struts-auto-config-<module-path>.xml に変更します。ここで、<module-path> は Web アプリケーションのルートへの Struts アプリケーションの相対モジュール パスです。また、「/」や「\」で指定されたすべてのインスタンスが「-」に変更されます。
たとえば、モジュール パスが /struts/my/module の場合、struts-config.xml の名前が struts-auto-config-struts-my-module.xml に変更されます。このような方法でモジュール コンフィグレーションの名前を指定することにより、アクション サーブレットとして使用される PageFlowActionServlet は、web.xml の init-param に明示的に登録せずに、自動的にモジュールを登録できます。この機能を利用する必要がない場合は、struts-config.xml の名前を任意に変更できます。ただし、Struts 1.1 または 1.2 (Beehive) モジュールの場合と同様に web.xml にモジュールを手動で登録する必要があります。
<controller processorClass="com.bea.struts.adapter.action .AdapterRequestProcessor"/>
Struts アプリケーションをポータルに統合するには、以下のガイドラインに従います。
web.xml に登録されているかどうかを確認する。これは、Struts アプリケーションをスタンドアロンで実行することにより、テストできます。
一般的に、JSF の統合プロセスは単純です。つまり、使用する JSF の配布時に付属する手順に従うだけです。JSF アプリケーションを WebLogic Portal に組み込むためのポータル固有のタスクは次のとおりです。
.portlet ファイルを作成する。
この手順は省略可能ですが、実行するように強くお勧めします。このタグの詳細については、「JSF と namingContainer JSP タグ」を参照してください。
次の節では、namingContainer JSP タグの詳細について説明します。
namingContainer JSP の目的は、ページ上にユニークな ID を生成することです。現在、JSF アーキテクチャは、デフォルトのコンポーネント ID 生成をオーバーライドするフック メカニズムを明示的に備えていません。JSF はページ上のコンポーネントの階層ネームスペースを使用して、ページ上のコンポーネントのユニークな ID を自動的に生成します。ただし、JSF はポータルに「対応」していないため、ページ上でユニークではない ID を生成する場合があります。この問題が発生することが少ない単純なフォームを使用しながら、ページ上で JavaScript とユニークではない ID を使用する場合、Javascript は不正なコンポーネントを対象に設定する場合があります。
WebLogic Portal への JSF の実装の詳細については、Javadoc の com.bea.portlet.adapter.faces パッケージを参照してください。
ページ フローを持つ既存の非ポータル アプリケーションを使用する場合、「Workshop for WebLogic への既存の Web アプリケーションの統合」で説明する手順を使用し、WebLogic Portal に関連するファセットをインストールして、これらのページ フローをポータルに統合した後、ポートレットを使用してこれらのページ フローを表示できます。ページ フロー ポートレットを作成する前に、ポータル Web プロジェクト内に新しいページ フローを構築することもできます。
ページ フローの作成手順については、Workshop for WebLogic のドキュメントを参照してください。ページ フロー ポートレットの作成手順の詳細については、『ポートレット開発ガイド』の「ポートレットの構築」の章を参照してください。
ページ フローの URL を正しく解決するには、ページ フロー サポートを有効にする必要があります。デフォルトで、ページ フロー サポートは有効になっていますが、ページ フロー設定がある時点で無効になった場合は、ポータル Web プロジェクトのWEB-INF/netuix-config.xml ファイルを編集して、有効にする必要があります。コード リスト 6-2 は、netuix-config.xml ファイルに追加する必要のあるタグの構文を示します。<enable> 要素は true に設定されています。
<!-- ページフロー サポートを有効または無効にします -->
<pageflow>
<enable>true</enable>
</pageflow>
このブロックが netuix-config.xml に存在しない場合、追加しないでください。このブロックがないと、デフォルトで true に設定されます。
プロジェクト ファセットを作成したら、後で EAR プロジェクトまたはポータル Web プロジェクトに追加できます。たとえば、ポータル Web プロジェクトで、訪問者ツールを有効にするファセットを最初にインストールしなかった場合、後でこの機能を使用することになる場合があります。
| 注意 : | すでに GroupSpace ファセット以外のポートレットが含まれるポータル Web プロジェクトに GroupSpace ファセットを追加しないでください。詳細については、『コミュニティ ガイド』を参照してください。 |
既存の EAR プロジェクトまたはポータル Web プロジェクトにファセットを追加するには、以下の手順に従います。
プロパティ ダイアログが表示されます。図 6-5 に例を示します。
[Add/Remove Project Facets] ダイアログが表示されます。
図 6-6 は、コラボレーション ポートレットの追加を選択した一般的なポータル Web プロジェクトの例を示します。
ファセットが追加され、プロパティ ダイアログにファセットの一覧が表示されます。
Web アプリケーションの機能をポータルに統合する推奨方法は、アプリケーションを Java ページ フロー ポートレットに組み込むことです。ただし、アプリケーションが MVC アーキテクチャ、Java、または Struts をベースとしていない場合、この実装が難しい場合があります。このような場合は、アプリケーションをポータル プロジェクトの外部からホストしながら、コンテンツを WebLogic Portal 内に表示する方法を使用できます。
通常、この代わりの実装方法は、既存の Web アプリケーションをそのまま維持できる一種のプロキシのように動作する JSP ポートレットに依存します。JSP の「プロキシ」ポートレットを使用できる実装方法には、次の方法があります。
Web Services for Remote Portlets (WSRP) はもう 1 つの代わりの実装方法を提供しますが、この実装方法には SOAP および WSDL をサポートし、MVC を使用して設計された既存のアプリケーションで最も効果を発揮する従来のサーバが必要になります。
WebLogic Portal は、特定の URI から HTTP 応答ドキュメントを取得するために使用する uriContent というユーティリティ JSP タグを備えています。「ブラウザ ポートレット」は、uriContent タグ (コンテンツ URL) を使用し、ポートレットを使用して、ポータルの外部 Web アプリケーションを表示します。ブラウザ ポートレットの詳細については、『ポートレット開発ガイド』を参照してください。
  
|
![コラボレーション ポートレットを選択した [Add/Remove Project Facets] ダイアログの例](wwimages/dlg_webproj_facet_add_collab.gif)