|
|
この章では、プロデューサ内でポートレットを開発する上でのベスト プラクティスについて説明します。この章で説明するベスト プラクティスに従えば、必ず正しく機能するリモート ポートレットをコンシューマで作成できます。この章を読む前に、「連合ポータルのアーキテクチャ」の内容を確認することをお勧めします。
「リモート ポートレットのライフサイクル」で説明したように、リモート ポートレットのライフサイクルの表示段階と対話段階は分離されています。このため、ポートレットが対話で受け取ったのと同じ HTTP 応答やリクエストを表示段階でも受け取るとは限りません。
ポートレットを表示する際、リクエスト オブジェクトでフォーム データを受け取らない場合があります。これは、表示が今であっても、リクエストはしばらく前に発行されていることがあり、データが同じではない可能性があるためです。
リクエスト間でデータを維持するには、データをローカルに保存する必要があります。通常はセッションを使用します。たとえば、注文 ID を処理している場合、その ID をローカルに保存できます。
ページ フローを使用している場合、データは自動的に次に渡されます。ただし、リモート ポートレットでバッキング ファイルを使用している場合、同じリクエスト オブジェクトを再度受け取らずに済むようにデータがセッションに保存されていることを確認する必要があります。
ポートレット間に依存関係を明示的に構築するのではなく、イベントを使用してポートレット間の通信を行います。たとえば、ポータル ページに注文を収集するポートレットと全注文の状況を表示するポートレットがあるとします。注文を受けると、データがデータベースに保存されてから、注文状態 ポートレットに表示されます。図で示すと、図 14-1 のようになります。
このシナリオでは、注文収集ポートレットと注文状態ポートレット間に強力な従属関係が構築されます。注文収集ポートレットは、情報を (注文 ID) をと注文状態ポートレットにどうにかして伝える必要があります。セッションやポートレット間のその他の共通のステートに ID を保存すると、注文収集ポートレットと注文状態ポートレット間に強力な依存関係が構築されます。ポートレットの実装にもよりますが、いずれかのポートレットが変更または置き換えられた場合、他のポートレットにも影響します。
この依存関係を避けるには、イベントを使用してポートレット間の通信を行います。この例で、イベントを使用して注文情報を注文ステータス ポートレットに伝える場合、注文ステータス ポートレットは注文の発生元を気にする必要がありません。注文ステータス ポートレットはイベントを処理するだけです。たとえば、イベントのペイロードから注文 ID を取得するだけです。
WebLogic 連合ポータルでのイベント処理の詳細については、「イベントによるポートレット間の通信」を参照してください。
一部のポータルには、固有のポータル レイアウト従属関係が組み込まれています。たとえば、ログイン ポートレットの機能は、人事部のページと経理部のページでは異なります。つまり、対話が行われたときに、ポートレットは処理する前にどのページなのかを調べます。この方法では、ポートレットがコンシューマのページ、ブック、デスクトップなどポータル フレームワーク要素に関連付けられます。
このシナリオは、連合ポータルでは機能しません。プロデューサがコンシューマにどのようなページ レイアウトがあるのかわからないためです。このシナリオは、できれば回避します。必要であれば、コンシューマにポートレットをローカルに用意します。または、できれば共有コンポーネントを使用し、各ポートレットから代わりのレイアウトを作成します。
ポートレットにリンクなどの URL を埋め込んだ場合、ポートレットをローカルで実行していても場合によっては期待どおりに機能します。しかし、ポートレットを連合環境に移すと、リンクは機能しなくなります。たとえば、次のコード例では、開発者は文字列を操作することで、ページ フロー ポートレットのアクションを同じポートレットで呼び出しています。連合ポータルでは、このタイプの構造は機能しません。通常、このタイプのプログラミングは、開発者がリバース エンジニアリングを行った際に、リンクの作成をコピーしたために生じます。
String url = "http://mydomain.com/portal/portal.portal?";
url = url + "myportlet_actionOverride=login";
url = url + "...";
同様に、次のリソース URL はドキュメントにリンクが明示的に指定されているために連合ポータルでは機能しません。ドキュメントがコンシューマには存在しないため、コンシューマでは処理方法がわかりません。
<img src="images/logo.jpg"/>
<a href="/docServlet?docId=9999">Download</a>
連合ポータルでよく見られる URL の問題には、次のものがあります。これらの問題は、リモート ポートレットがローカル環境のポートレットと同じ URL 構造に従っていないために生じます。
JSP タグ ライブラリとユーティリティ クラスを使用して、WebLogic Portal Framework から URL を作成することが重要です。次のタグとクラスを使用します。
これらのすべてのタグは WebLogic Portal URL リライタで処理されて、連合環境で正しく機能します。
重要なことは、リモート ポートレットとローカル ポートレットには本質的に異なる点があります。正しく機能するすべてのローカル ポートレットがリモート ポートレットとして適切に機能するとは限りません (機能する場合も多いですが)。
ローカル ポートレットを使用する場合、ポートレットはポータルのリクエスト パラメータおよび同じページの他のポートレットで設定されたリクエスト属性にアクセスできます。このようなリクエスト パラメータや属性に依存するポートレットを実装する場合、ポートレットは WSRP 環境では正しく機能しません。WSRP 環境では、リモート ポートレットはリモート システムで実行されます。リモート ポートレットがプロデューサで受信する HTTP リクエストは、コンシューマのポータルで受信されるものと異なります。
プロデューサを追加してリモート ポートレットを作成した場合、プロデューサのレジストリ (WEB-INF/wsrp-producer-registry.xml) とポータル フレームワークのデータベース テーブルに、プロデューサの WSDL アドレスや WSDL に記述されたポートのアドレスなど、プロデューサに関する特定の情報が保存されます。プロデューサを別の環境に伝播または移動すると、このデータは無効になります。この場合、プロキシ ポートレットからプロデューサのポートレットを参照しているコンシューマは、データを見つけられなくなります。
| 注意 : | 現在、WebLogic Portal では共有登録モデルのみサポートされており、同じプロデューサ登録ハンドルをステージング環境とプロダクション環境で共有しています。登録の共有および WSRP プロデューサの伝播については、『プロダクション業務ガイド』を参照してください。 |
プロデューサのデータベース エントリをプログラムで更新できます。次のクラスに、プロデューサの情報を取得および更新するためのメソッドがあります。
com.bea.wsrp.consumer.management.producer.ProducerManager
このクラスについては、「Javadoc」を参照してください。
WebLogic Portal コンポーネントが含まれていないプロデューサ環境から、WSRP を使用してポートレットを公開する必要がある場合があります。たとえば、基本的な WebLogic Server ドメインで Struts Web アプリケーションを実行したり、基本的な WebLogic Workshop ドメインで Java ページ フロー アプリケーションを実行したりすることがあります。どちらの場合も、サーバ コンフィグレーションに WebLogic Portal が含まれません。非ポータル サーバ ドメインを使用してリモート ポートレットをホストする方法の詳細については、「WebLogic Server プロデューサのコンフィグレーション」を参照してください。
ポータル Web アプリケーションをプロデューサとして使用すると、すべてのポータル アーティファクトが Web アプリケーションで使用できるようになります。ただし、ポータル Web アプリケーションでない WSRP プロデューサの場合は、プロパティ セットなどのポータル機能を使用できません。プロデューサでポータル機能にアクセスする必要がある場合は、ポータル Web アプリケーションを使用してください。
メッセージの安全を確保するには、プロデューサが提供されるすべてのポートで SSL を実装します。連合ポータルでシングル サインオン セキュリティをコンフィグレーションする方法の詳細については、以下を参照してください。
この節では、連合ポータルでのエラー処理方法の概要について説明します。
スタック トレースが表示されないように、プロデューサ側でエラーを処理し、適切なビジネス メッセージを表示します。
リモート ポートレットを開いた Workshop for WebLogic で次を実行します。
インターセプタを使用して、プロデューサから返されるエラーを処理できます。たとえば、特定のプロデューサが登録されていない場合に、登録エラーを検出して適切な処理を行うことができます。インターセプタの使用方法の詳細については、「インターセプタ フレームワーク」を参照してください。
この節では、リモート ポートレットを開発するためのガイドラインとベスト プラクティスについて説明します。
複数のリモート ポートレットでセッション データを共有する場合、それらのポートレットを同じプロデューサでホストします。異なるシステムでホストされているポートレットでは、セッション情報を共有できません。
<wl:cache> または p13nCache を使用します。RenderCacheable 属性を使用します。ただし、これはセッション スコープ キャッシュであるため、コンフィグレーションできません。
キャッシングについては、『ポートレット開発ガイド』の「ポートレットのキャッシュ」を参照してください。
プロデューサとコンシューマの最適なパフォーマンスを確保するために、以下のパフォーマンス チューニングのガイドラインに従うことをお勧めします。
<markup transport="attachment"/> を WEB-INF/wsrp-producer-config.xml に追加することにより、接続サポートを有効化にします。<?xml version="1.0" encoding="UTF-8"?>
wsrp-producer-config
xmlns="http://www.bea.com/servers/weblogic/wsrp-producer-config/8.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/weblogic/wsrp-producer-config/8.0
wsrp-producer-cnfig.xsd">
<service-config>
<registration required="false" secure="true"/>
<service-description secure="true"/>
<markup secure="true" rewrite-urls="true"transport="attachment"/>
<portlet-management required="false" secure="true"/>
</service-config>
WEB-INF/web.xml から MessageMonitor サーブレットをアンデプロイしてロギングを無効にする。
ローカル プロキシ サポートにより、プロデューサ Web アプリケーションとコンシューマ Web アプリケーションが同じ場所にある場合は、ネットワーク I/O および「HTTP 上での SOAP」のオーバーヘッドを回避できます。この機能を有効にすると、コンシューマは、プロデューサが同じサーバにデプロイされているかどうかを判別しようとします。同じサーバにデプロイされていることがわかると、ローカル プロキシを使用してリクエストをプロデューサに送信します。プロデューサが同じサーバにデプロイされていない場合、コンシューマはデフォルトのリモート プロキシを使用します。ローカル プロキシ サポートが有効になっていても、リモート プロデューサは通常どおりに呼び出すことができます。
この節では、ローカル プロキシ サポートを実装する方法について説明します。内容は以下のとおりです。
ローカル プロキシ モードは、同じ場所にあるコンシューマとプロデューサを使用する際に、デフォルトのリモート プロキシに比べて多くの利点があります。ローカル プロキシ モードの大きな利点は次のとおりです。
また、ローカル プロキシを有効にすることで、ユーザは、パフォーマンスのオーバーヘッドを発生させずに WSRP による分離の利点を活用できます。
ローカル プロキシ サポートを活用するには、次の手順に従います。
WEB-INF/wsrp-producer-registry.xml で <enable-local-proxy> を true に設定して、ローカル プロキシ サポートを有効にします。<wsrp-producer-registry
xmlns="http://www.bea.com/servers/weblogic/wsrp-producer-registry/8.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/weblogic/wsrp-producer-
registry/8.0 wsrp-producer-registry.xsd">
<!-- アップロードの制限 (バイト単位) -->
<upload-read-limit>1048576</upload-read-limit>
<!-- タイムアウト (ミリ秒単位) -->
<connection-timeout-secs>120000</connection-timeout-secs>
<!-- ローカル プロキシの有効化 -->
<enable-local-proxy>true</enable-local-proxy>
...
</wsrp-producer-registry>
システム プロパティを com.bea.wsrp.proxy.LocalProxy.enabled = true のように設定することでも、ローカル プロキシ サポートを有効にできます。このシステム プロパティを true に設定すると、WEB-INF/wsrp-producer-registry.xml の <enable-local-proxy> の設定はオーバーライドされます。
ローカル プロキシ サポートは、Web アプリケーション テンプレートではデフォルトで無効になっています。
ローカル プロキシ サポートは強力なツールであるため、アプリケーションに効果が得られる場合のみ使用してください。ローカル プロキシ サポートを使用する一般的な理由は次のとおりです。
また、BEA 以外のプロデューサおよびコンシューマと相互運用する場合は、ローカル プロキシ サポートを使用しないでください。
Workshop for WebLogic と共にインストールされるメッセージ モニタ サーブレットを使用することにより、プロデューサとコンシューマの間のアクティビティをモニタすることができます。また、カスタム ログを作成して、WSRP セッションに関する特定の情報を表示することもできます。
プロデューサとコンシューマ間で受け渡される SOAP のアクション メッセージに加えて、応答ヘッダとリクエスト ヘッダをモニタするには次を実行します。
http://localhost:7001/wsrpMonitorTest/monitor
図 14-2 のように、ブラウザにモニタが表示されます。
モニタを開始するには、[有効化] をクリックします。最新のトランザクションを表示するには、[更新] をクリックします。ブラウザ ウィンドウからすべてのメッセージを削除するには、[Clear] をクリックします。
| ヒント : | モニタは、[更新] をクリックするまで新しいトランザクションを表示しません。 |
リモート ポートレットがプロデューサと通信するたびに、図 14-3 に示すようなリクエストと応答のメッセージ ヘッダがモニタ画面に表示されます。
[Show] をクリックすると、図 14-4 に示すように、リクエストや応答の内容を表示できます。[Hide] をクリックすると、メッセージの内容が閉じます。
カスタム ログを作成するには、「インターセプタ フレームワーク」で説明するインターセプタ フレームワークを使用することをお勧めします。
WebLogic Server によってインスタンス化した Logger オブジェクトや Handler オブジェクトを使用すれば、WSRP セッションに関する特定の情報を表示するカスタム ログも作成できます。これらのオブジェクトを使用すると、独自のメッセージ ハンドラを作成し、ｌogger にサブスクライブできます。たとえば、プロデューサが生成するメッセージをリモート ポートレットでリスンする場合、handler を作成してそのプロデューサの logger にサブスクライブできます。Logger オブジェクトと Handler オブジェクトの使用方法の詳細については、WebLogic Server トピックの「WebLogic Server ログ メッセージのフィルタ処理」を参照してください。
この節では、リモート ポートレットにリソースを要求した時にコンシューマのセッションが失われるのを防ぐための 2 つのテクニックを説明します。次のようなテクニックがあります。
画像を含むリモート ポートレットがある場合、画像リソースが要求されると、WebLogic Portal はクッキーとその他のヘッダをプロデューサからブラウザに送信します。プロデューサのポートレットにリソースが要求されると、ユーザのブラウザがコンシューマのセッションをドロップしたり失ったりする場合もあります。この状況は、セッションクッキーにデフォルト パス (「/」) のみを含むようにプロデューサとコンシューマがコンフィグレーションされた場合に発生します。その場合、ブラウザではコンシューマによって設定された Set-Cookie ヘッダが、プロデューサによって設定された Set-Cookie ヘッダで置き換えられます。
このようにコンシューマのセッションが失われるのを防止するには、weblogic.xml を開き、Web アプリケーションにセッション クッキーのドメイン名 と Web アプリケーション パスが組み込まれるようにコンフィグレーションします。このテクニックを使用することにより、クッキー名のオーバーラップを防止することができます。ドメイン名とパスの設定方法の詳細については、WebLogic Server のドキュメントの「weblogic.xml デプロイメント記述子の要素」にある「session-descriptor」を参照してください。
ほとんどの場合、別のクッキー名を使用すると、リソースを要求したときにコンシューマのセッションが失われるという問題は解決されます。ただし、この方法で問題が解決されない場合もあります。その一例として、同じドメインで実行されるプロデューサとコンシューマにシングル サインオンが使用される場合があります。この場合、クッキー名は同じでなければなりません。別のクッキー名を使用しても問題が解決されない場合、次のシステム プロパティを設定します。
"wlp.resource.proxy.servlet.block.response.headers=true"
このシステム プロパティを有効にすると、WebLogic Portal は、Set-Cookie ヘッダがユーザのブラウザに返送されないようにします。このプロパティは、リソースが戻されたときに、ブラウザ上でコンシューマのクッキーがプロデューサのクッキーによって上書きされないようにします。このテクニックを使用すると、同じクッキー名をプロデューサとコンシューマの両方に使用し、シングル サインオンに必要な条件を満たすことができます。
プロデューサとコンシューマとの間のセッション クッキーが重複する場合は、CWEB アプリケーションのユーザ セッションが失われる場合があります。これを防止するには、weblogic.xml を開き、Web アプリケーションにセッション クッキーのドメイン名 と Web アプリケーション パスが組み込まれるようにコンフィグレーションします。ドメイン名とパスの設定方法の詳細については、WebLogic Server のドキュメントの「weblogic.xml デプロイメント記述子の要素」にある「session-descriptor」を参照してください。
リモート ポートレットの複数のビューが作成される場合は常に、ポートレットのリンクが一致せず、正しく動作しない可能性があります。通常、複数のビューは、リモート ポートレットがページフローでポップアップ メカニズムを使用する場合や、ユーザがポートレットの [フロート] ボタンを使用してリモート ポートレットをフロートする場合に発生します。
コンシューマが提供する URL テンプレートを使用するように WebLogic Portal プロデューサが設定されている場合、WebLogic Portal プロデューサは、プロデューサ上で作成されたセッションにそれらのテンプレートをキャッシュします。ただし、ページ フローのポップアップ メカニズムまたは [フロート] ボタンを使用してポートレットの複数のビューが作成される場合は、キャッシュされたテンプレートが現在のビューには有効でない可能性があります。
次に示すいずれかの方法を使用して一致しないリンクを修正できます。
ポータルから生成されたリクエストの実行中にユーザ ID を変更すると、リモート ポートレットが一貫性のない動作をする場合があります。通常これは、ポータル デスクトップに、ユーザのログインとログアウトのためのポートレットやその他のメカニズムが含まれている場合に発生します。ポータルによってロードされるユーザ固有データがある場合、ユーザ ID を変更すると無効になることがあります。リモート ポートレットの場合、そのようなデータにはリモート ポートレットの永続状態が含まれています。ユーザ ID を変更すると、コンシューマ ポータルは誤った永続状態データをプロデューサに送信する可能性があります。
この問題を避けるには、ログインとログアウトの直後に、常にブラウザ リダイレクトを使用する必要があります。ブラウザ リダイレクトにより、ポータルによってロードされるデータがリクエストに対して有効になります。
  
|
