|
|
この章では、プロデューサ内でポートレットを開発する上でのベスト プラクティスについて説明します。この章で説明するベスト プラクティスに従えば、必ず正しく機能するリモート ポートレットをコンシューマで作成できます。この章を使用する前に、「連合ポータルのアーキテクチャ」の内容を確認することをお勧めします。
WebLogic Portal は、主に WSRP の伝播を有効化して支援するために、WSRP 2.0 の中核的機能をサポートします。WSRP の伝播の詳細については、『プロダクション業務ガイド』の「WSRP 伝播手順」を参照してください。
デフォルトではコンシューマに対する WSRP 2.0 のサポートは無効化されています。この節では、WebLogic Portal コンシューマに対する WSRP 2.0 サポートを有効化する方法、およびサポート対象の WSRP 2.0 機能について説明します。
デフォルトでは、WebLogic Portal コンシューマはプロデューサで実装された WSRP 1.0 機能のみをサポートします。プロデューサで任意の WSRP 2.0 機能を提供する場合、WebLogic Portal コンシューマのデフォルトではそれらの機能を無視します。WebLogic Portal コンシューマでプロデューサの WSRP 2.0 メッセージを処理できるようにこのデフォルトを変更するには、以下のシステム プロパティをコンシューマを実行するサーバの WebLogic Server Java 起動コマンドに渡すことができます。
-Dcom.bea.wsrp.consumer.preferred.version=2.0
Java 起動コマンドの変更の詳細については、WebLogic Server の手順の「WebLogic Server インスタンスの Java オプションの指定」を参照してください。
| 注意 : | この章で説明するように、コンシューマに対する WSRP 2.0 サポートを有効化することはお勧めできません。コンシューマに対して WSRP 2.0 を有効化すると、ポートレット間通信や添付ファイルを持つ SOAP などの機能を使用できなくなります。以下の節の、「コンシューマに対して WSRP 2.0 機能を有効化した場合」でサポート対象の機能について詳しく説明します。 |
この節では、前の節「コンシューマに対する WSRP 2.0 サポートの有効化」の説明に従って WSRP 2.0 サポートの有効化を選択した場合に、WebLogic Portal コンシューマでサポートされる WSRP 2.0 の機能と、サポートされない機能を説明します。
この節では、WebLogic Portal と WebCenter の WSRP 相互運用性に関する問題について説明します。
WebCenter 10g ADF Faces ポートレットを WLP コンシューマに使用するには、ポートレット プロパティ [非同期コンテンツ表示] を iframe_unwrapped に設定する必要があります。Workshop for WebLogic でのみ、このプロパティを設定できます。この設定により、ADF Faces ポートレットは WebLogic Portal がすでに提供するベース レベル HTML タグ （HTML、HEAD、BODY、BASE など）を含むので、発生する表示の問題を回避できます。iframe_unwrapped プロパティ値は、ADF Faces ポートレットを、ポートレットが適切に表示するように IFrame 内で参照します。非同期コンテンツ表示プロパティの詳細については、『ポートレット開発ガイド』を参照してください。
WLP ポートレットを WebCenter または Oracle Portal アプリケーションに使用する場合、このセクションの手順に従う必要があります。WSRP API の clonePortlet() と destroyPortlets() メソッドを実装する方法については、WLP と WebCenter/Oracle Portal との間に互換性がありません。この非互換性のため、WebCenter/Oracle Portal アプリケーションでは WLP プロデューサからポートレットを使用しようとすると、匿名のユーザ認証エラーが発生する場合もあります。
destroyPortlets() と clonePortlet() メソッドを呼び出すときに WLP では匿名ユーザ用の認証を必要とするので、互換性の問題が生じますが、WebCenter と Oracle Portal では、これらのメソッドのための匿名のユーザ認証を必要としません。
WLP ポートレットを WebCenter または Oracle Portal アプリケーションで使用する場合、匿名のユーザ認証エラーを防止するためには、次の手順に従います。
WEB-INF/wsrp-producer-config.xml ファイルをコピーし、開いて編集する。 wsrp-producer-config.xml ファイルに追加する。この要素は、<wsrp-producer-config> 要素の最後の要素である必要があります。（これを、閉じタグ </wsrp-producer-config> 行のすぐ上に配置する）。
<security anonymousCloneDestroyUser=”username”/> ユーザ名は作成したユーザの名前です。
「リモート ポートレットのライフサイクル」で説明したように、リモート ポートレットのライフサイクルの表示段階と対話段階は分離されています。このため、ポートレットが対話で受け取ったのと同じ HTTP 応答やリクエストを表示段階でも受け取るとは限りません。
ポートレットを表示する際、リクエスト オブジェクトでフォーム データを受け取らない場合があります。これは、表示が今であっても、リクエストはしばらく前に発行されていることがあり、データが同じではない可能性があるためです。
リクエスト間でデータを維持するには、データをローカルに保存する必要があります。通常はセッションを使用します。たとえば、注文 ID を処理している場合、その ID をローカルに保存できます。
ページ フローを使用している場合、データは自動的に次に渡されます。ただし、リモート ポートレットでバッキング ファイルを使用している場合、同じリクエスト オブジェクトを再度受け取らずに済むようにデータがセッションに保存されていることを確認する必要があります。
ポートレット間に依存関係を明示的に構築するのではなく、イベントを使用してポートレット間の通信を行います。たとえば、ポータル ページに注文を収集するポートレットと全注文の状況を表示するポートレットがあるとします。注文を受けると、データがデータベースに保存されてから、注文ステータス ポートレットに表示されます。図で示すと、図 14-1 のようになります。
このシナリオでは、注文収集ポートレットと注文ステータス ポートレット間に強力な従属関係が構築されます。Collect Order ポートレットは、情報を (注文 ID) を Order Status ポートレットにどうにかして伝える必要があります。セッションやポートレット間のその他の共通のステートに ID を保存すると、Collect Order と Order Status ポートレット間に強力な依存関係が構築されます。ポートレットの実装にもよりますが、いずれかのポートレットが変更または置き換えられた場合、他のポートレットにも影響します。
この依存関係を避けるには、イベントを使用してポートレット間の通信を行います。この例で、イベントを使用して注文情報を注文ステータス ポートレットに伝える場合、注文ステータス ポートレットは注文の発生元を気にする必要がありません。注文ステータス ポートレットはイベントを処理するだけです。たとえば、イベントのペイロードから注文 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 に記述されたポートのアドレスなど、プロデューサに関する特定の情報が保存されます。プロデューサを別の環境に移動すると、このデータは無効になります。この場合、プロキシ ポートレットからプロデューサのポートレットを参照しているコンシューマは、データを見つけられなくなります。
プロデューサを 1つの環境から別の環境 （ステージング環境からプロダクション環境へ） に移動する必要がある場合、WebLogic Portal では、2 種類のメカニズムがサポートされています。
最初のメカニズム (登録の共有) は、バージョン 10.0 より前の WebLogic Portal プロデューサの場合のみ推奨されています。登録の共有によって、同じプロデューサ登録ハンドルをステージング環境とプロダクション環境間で共有しています。このモデルは、多くの重大な欠点があります。プロデューサは 10.0 より前の WebLogic Portal のバージョンである場合のみ、このモデルを使用します。登録の共有および WSRP プロデューサの伝播の詳細については、『プロダクション業務ガイド』を参照してください。
2 つ目のメカニズムは、WSRP 2.0 exportPortlet と importPortlet 操作をサポートする WebLogic Portal バージョン 10.0 以上などのプロデューサに対してお勧めします。これらの操作を使用して、プロデューサが伝播される場合は、プロデューサ登録ハンドルは共有される必要はありません。WebLogic Portal バージョン 10.0 以上の伝播ツールは、これらの操作を自動的に処理します。詳細については、『プロダクション業務ガイド』を参照してください。
プロデューサのデータベース エントリをプログラムで更新できます。次のクラスに、プロデューサの情報を取得および更新するためのメソッドがあります。
com.bea.wsrp.consumer.management.producer.ProducerManager
このクラスについては、「Javadoc」を参照してください。
WebLogic Portal コンポーネントが含まれていないプロデューサ環境から、WSRP を使用してポートレットを公開する必要がある場合があります。たとえば、基本的な WebLogic Server ドメインで Struts Web アプリケーションを実行したり、基本的な Workshop for WebLogic ドメインで Java ページ フロー アプリケーションを実行したりすることがあります。どちらの場合も、サーバ コンフィグレーションに WebLogic Portal が含まれません。非ポータル サーバ ドメインを使用してリモート ポートレットをホストする方法の詳細については、「WebLogic Server プロデューサのコンフィグレーション」を参照してください。
ポータル Web アプリケーションをプロデューサとして使用すると、すべてのポータル アーティファクトが Web アプリケーションで使用できるようになります。ただし、ポータル Web アプリケーションでない WSRP プロデューサの場合は、プロパティ セットなどのポータル機能を使用できません。プロデューサでポータル機能にアクセスする必要がある場合は、ポータル Web アプリケーションを使用してください。
メッセージの安全を確保するには、プロデューサが提供されるすべてのポートで SSL を実装します。連合ポータルでシングル サインオン セキュリティをコンフィグレーションする方法の詳細については、以下を参照してください。
この節では、連合ポータルでのエラー処理方法の概要について説明します。
スタック トレースが表示されないように、プロデューサ側でエラーを処理し、適切なビジネス メッセージを表示します。
リモート ポートレットを開いた Workshop for WebLogic で次を実行します。
インターセプタを使用して、プロデューサから返されるエラーを処理できます。たとえば、特定のプロデューサが登録されていない場合に、登録エラーを検出して適切な処理を行うことができます。インターセプタの使用方法の詳細については、「インターセプタ フレームワーク」を参照してください。
この節では、リモート ポートレットを開発するためのガイドラインとベスト プラクティスについて説明します。
複数のリモート ポートレットでセッション データを共有する場合、それらのポートレットを同じプロデューサでホストします。異なるシステムでホストされているポートレットでは、セッション情報を共有できません。
<wl:cache> または p13nCache を使用します。RenderCacheable 属性を使用します。ただし、これはセッション スコープ キャッシュであるため、コンフィグレーションできません。
キャッシングについては、『ポートレット開発ガイド』の「ポートレットのキャッシュ」を参照してください。
プロデューサとコンシューマの最適なパフォーマンスを確保するために、以下のパフォーマンス チューニングのガイドラインに従うことをお勧めします。
この節では、プロデューサ アプリケーションのパフォーマンスを向上する方法をいくつか示します。
プロデューサのパフォーマンスを向上する方法の 1 つとして、SAML 認証プロバイダを、その他の認証プロバイダよりも前にデプロイする方法があります。プロバイダを並べ替えるには、次の手順に従います。
コード リスト 14-1 に示すように、WEB-INF/wsrp-producer-config.xml に <markup transport="attachment"/> を追加することにより、接続サポートを有効にします。
<?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 アプリケーション テンプレートではデフォルトで無効になっています。
図 14-2 では、ローカル プロキシ サポートが有効になっている場合の処理 (上のフロー チャート) と、有効になっていない場合の処理 (下のフロー チャート) を比較しています。ローカル プロキシの場合は、ネットワークまたは SOAP 関連のオーバーヘッドがなく、通信にはサーブレット API が使用されています。
| 注意 : | JSR-168 インポート ユーティリティを使用して JSR-168 ポートレットをデプロイする場合は、ローカル プロキシ モードを有効にすることをお勧めします。パフォーマンスと複雑さに関しては、168 ポートレットと WSRP ローカル プロキシを WebLogic Portal で相互運用する場合と他のベンダを使用する場合で、差異はありません。インポート ユーティリティの詳細については、『プロダクション業務ガイド』の「WAR ファイルへの JSR-168 ポートレットのデプロイ」を参照してください。 |
表 14-1 に WebLogic Portal のローカル プロキシのアーキテクチャの進展についてまとめています。
ローカル プロキシ サポートは強力なツールであるため、アプリケーションに効果が得られる場合のみ使用してください。ローカル プロキシ サポートを使用する一般的な理由は次のとおりです。
また、Oracle 以外のプロデューサおよびコンシューマと相互運用する場合は、ローカル プロキシ サポートを使用しないでください。
Workshop for WebLogic と共にインストールされるメッセージ モニタ サーブレットを使用することにより、プロデューサとコンシューマの間のアクティビティをモニタすることができます。また、カスタム ログを作成して、WSRP セッションに関する特定の情報を表示することもできます。これらの機能は、リモートのポートレットについての問題をデバッグすることができます。
プロデューサとコンシューマ間で受け渡される SOAP のアクション メッセージに加えて、応答ヘッダとリクエスト ヘッダをモニタするには次を実行します。
http://localhost:7001/wsrpMonitorTest/monitor
モニタがブラウザ内に表示されます。モニタを開始するには、[有効化] をクリックします。最新のトランザクションを表示するには、[更新] をクリックします。ブラウザ ウィンドウからすべてのメッセージを削除するには、[クリア] をクリックします。
| ヒント : | モニタは、[更新] をクリックするまで新しいトランザクションを表示しません。 |
リモート ポートレットがプロデューサと通信するたびに、図 14-4 に示すようなリクエストと応答のメッセージ ヘッダがモニタ画面に表示されます。
[表示] をクリックすると、図 14-5 に示すように、リクエストや応答の内容を表示できます。[非表示] をクリックすると、メッセージの内容が閉じます。
カスタム ログを作成するには、「インターセプタ フレームワーク」で説明するインターセプタ フレームワークを使用することをお勧めします。
WebLogic Server によってインスタンス化した Logger オブジェクトや Handler オブジェクトを使用すれば、WSRP セッションに関する特定の情報を表示するカスタム ログも作成できます。これらのオブジェクトを使用すると、独自のメッセージ ハンドラを作成し、Logger にサブスクライブできます。たとえば、プロデューサが生成するメッセージをリモート ポートレットでリスンする場合、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 ヘッダがユーザのブラウザに返送されることを防止します。このプロパティは、リソースが戻されたときに、ブラウザ上でコンシューマのクッキーがプロデューサのクッキーによって上書きされることを防止します。このテクニックを使用すると、同じクッキー名をプロデューサとコンシューマの両方に使用し、シングル サインオンに必要な条件を満たすことができます。
ブラウザへのクッキーをブロックするには、コード リスト 14-3 に示すように、コンシューマ アプリケーションの WEB-INF/wsrp-producer-registry.xml で、<resource-cookies> を block-all に設定します。この要素が block-all に設定されるていると、リソース プロキシ サーブレットは、プロデューサ リソースからブラウザにクッキーを転送しません。デフォルトでは、クッキーはブロックされていません。デフォルト設定は block-none です。
<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>
<!-- ブラウザへのクッキーのブロック -->
<resource-cookies>block-all</resource-cookies>
...
</wsrp-producer-registry>
プロデューサとコンシューマとの間のセッション クッキーが重複する場合は、CWEB アプリケーションのユーザ セッションが失われる場合があります。これを防止するには、weblogic.xml を開き、Web アプリケーションにセッション クッキーのドメイン名と Web アプリケーション パスが組み込まれるようにコンフィグレーションします。ドメイン名とパスの設定方法の詳細については、WebLogic Server ドキュメントの「weblogic.xml デプロイメント記述子の要素」にある「session-descriptor」を参照してください。
リモート ポートレットの複数のビューが作成される場合は常に、ポートレットのリンクが一致せず、正しく動作しない可能性があります。通常、複数のビューは、リモート ポートレットがページフローでポップアップ メカニズムを使用する場合や、ユーザがポートレットの [フロート] ボタンを使用してリモート ポートレットをフロートする場合に発生します。
コンシューマが提供する URL テンプレートを使用するように WebLogic Portal プロデューサが設定されている場合、WebLogic Portal プロデューサは、プロデューサ上で作成されたセッションにそれらのテンプレートをキャッシュします。ただし、ページ フローのポップアップ メカニズムまたは [フロート] ボタンを使用してポートレットの複数のビューが作成される場合は、キャッシュされたテンプレートが現在のビューには有効でない可能性があります。
次に示すいずれかの方法を使用して一致しないリンクを修正できます。
ポータルから生成されたリクエストの実行中にユーザ ID を変更すると、リモート ポートレットが一貫性のない動作をする場合があります。通常これは、ポータル デスクトップに、ユーザのログインとログアウトのためのポートレットやその他のメカニズムが含まれている場合に発生します。ポータルによってロードされるユーザ固有データがある場合、ユーザ ID を変更すると無効になることがあります。リモート ポートレットの場合、そのようなデータにはリモート ポートレットの永続状態が含まれています。ユーザ ID を変更すると、コンシューマ ポータルは誤った永続状態データをプロデューサに送信する可能性があります。
この問題を避けるには、ログインとログアウトの直後に、常にブラウザ リダイレクトを使用する必要があります。ブラウザ リダイレクトにより、ポータルによってロードされるデータがリクエストに対して有効になります。
この節では、登録プロパティの格納機能とそれらを有効にすることが推奨される理由について説明します。
Workshop for WebLogic または WebLogic Portal Administration Console を使用してプロデューサを登録する場合は、コンシューマ上に登録プロパティ セットを格納することができます。登録プロパティは、プロデューサが登録される時にコンシューマからプロデューサに渡される値です。これらの値は、プロデューサは特定のコンシューマに提供するポートレットを制御するときに役立ちます。
| ヒント : | コンシューマの資格および登録プロパティ セットの作成の詳細については、「コンシューマの資格」を参照してください。 |
この節では、なぜ、登録プロパティの格納が、Workshop for WebLogic と Administration Console を使用して登録プロパティを格納するための推奨された手続であるかを説明します。この節では、次のトピックについて説明します。
プロデューサを登録する時に、登録プロパティを格納することをお勧めします。このオプションは、以下の利点があります。
図 14-6 に示すように、[登録プロパティの格納] チェックボックスは、[プロデューサの追加] ウィザードの [プロデューサ プロパティの入力] ダイアログで提供されます。プロデューサを登録するための完全な手順は、「ライブラリへのリモート リソースの追加」で詳しく説明します。
WebLogic Portal Administration Console での [登録プロパティの格納] チェック ボックスの値を変更できます。[プロデューサ Url の更新] ダイアログを表示するには、プロデューサの [概要] タブに移動して [プロデューサ プロパティ] をクリックします。このダイアログで設定を変更することができます。
図 14-7 に示すように、[ローカル レジストリーに登録プロパティの格納] チェック ボックスは、[リモート ポートレット] ウィザードの [登録] ダイアログにあります。
| ヒント : | リモートのブックおよびページの登録プロパティを格納することもできます。リモート ポートレット、ページ、およびブックを作成するために使用されるウィザードの詳細については、「リモート ポートレット、ページ、ブックの作成」を参照してください。 |
[ローカル レジストリーに登録プロパティの格納] がチェックされる場合は、wsrp-producer-registry.xml ファイルは、格納される登録情報で更新されます。サンプルは、コード リスト 14-4 に示します。柔軟性を提供するために、このオプションは、プロパティが定義されない場合も、デフォルトで選択されます。登録の間にチェック ボックスを選択すると、後で登録プロパティを追加できます。
最初にプロデューサを登録するか、または再登録する時に、IDE ダイアログを使用して登録プロパティだけ編集することができます。プロデューサが登録された後にプロパティを変更するために、XML エディタを直接使用して XML ファイルを編集する必要があります。
...
<registration-properties>
<stringProperty name="{urn:bea:wlp:prop:reg:propset-1}Selection">
<value>OK</value>
</stringProperty>
<stringProperty name="{urn:bea:wlp:prop:reg:propset-1}Choices">
<value>Electronics</value>
</stringProperty>
</registration-properties>
<store-registration-properties>true</store-registration-properties>
...
プロデューサによって生成された WSDL をカスタマイズできます。たとえば、WSDL がデフォルト以外のプロキシ サーバを指すようにする場合があります。デフォルトの WSDL をカスタマイズするには、WEB-INF/beehive-url-template-config.xml ファイルを編集します。このファイルを編集する最も簡単な方法は、ファイルを Workshop for WebLogic のワークスペースにコピーする方法です。これを行うには、Workshop for WebLogic のマージ済みプロジェクト ビューでファイルを見つけます。ファイルを右クリックし [ワークスペースにコピー] を選択します。テンプレート ファイルは URL テンプレートを使用します。URL テンプレートのコンフィグレーションについては、GenericURL クラスの Javadoc を参照してください。
この節では、WSRP コンシューマまたはプロデューサでカスタム JAX-RPC ハンドラをコンフィグレーションする方法を説明します。カスタム ハンドラを使用して、送信 SOAP 要求および着信 SOAP 応答をインターセプトおよび処理できます。たとえば、ハンドラは、受信および送信メッセージを調べて、それらがエンド ポイントやログ情報などに到達する前に変更することができます。この節では、ハンドラのコンフィグレーションおよび登録方法のみを説明し、ハンドラ クラスの記述方法については説明しません。
| ヒント : | ハンドラ クラスは、javax.xml.rpc.handler.Handler インタフェースを実装するか、または、javax.xml.rpc.handler.GenericHandler を拡張する必要があります。 |
WEB-INF/wsrp-consumer-handler-config.xml ファイルを編集して、コンシューマにカスタム ハンドラを追加します。このファイルを編集する最も簡単な方法は、ファイルを Workshop for WebLogic のワークスペースにコピーする方法です。これを行うには、Workshop for WebLogic のマージ済みプロジェクト ビューでファイルを見つけます。ファイルを右クリックし [ワークスペースにコピー] を選択します。
コード リスト 14-5 は、コンフィグレーション ファイルの例を示しています。
<wsrp-consumer-handler-config
xmlns="http://www.bea.com/ns/portal/90/wsrp-consumer-handler-config">
<description>Description goes here</description>
<soap-handler>
<name>ProducerHandlesFilter</name>
<description>Producer Handles Filter test handler</description>
<!-- デプロイ対象のプロデューサ ハンドルのリスト、何も指定しない場合は、
すべてのプロデューサがこのハンドラを持ちます。 -->
<producer-handle>NoOpProducer1</producer-handle>
<handler-class>com.bea.wsrp.qa.consumer.handlers.ProducerHandlesFilter
</handler-class>
<!-- true の場合、SAML トークンが追加される前にハンドラが実行されます。-->
<pre-security>true</pre-security>
<!-- 必要に応じて init パラメータを使用します -->
<init-parameter>
<name>param1</name>
<value>value1</value>
</init-parameter>
<init-parameter>
<name>param2</name>
<value>value2</value>
</init-parameter>
<!-- ハンドラを追加するポートを指定します。-->
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WSRPServiceDescriptionService
</port-name>
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WSRPBaseService</port-name>
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WSRPRegistrationService
</port-name>
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WSRPPortletManagementService
</port-name>
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WLP_WSRP_Ext_Service
</port-name>
<soap-role>someRoleHere</soap-role>
</soap-handler>
プロデューサで、JAX-RPC 仕様の定義に従って、WEB-INF/webservices.xml ファイルを編集します。
|