|
|
この章では、プロデューサ内でポートレットを開発する上でのベスト プラクティスについて説明します。この章で説明するベスト プラクティスに従えば、必ず正しく機能するリモート ポートレットをコンシューマで作成できます。この章を読む前に、「連合ポータルのアーキテクチャ」の内容を確認することをお勧めします。
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 の機能と、サポートされない機能を説明します。
「リモート ポートレットのライフサイクル」で説明したように、リモート ポートレットのライフサイクルの表示段階と対話段階は分離されています。このため、ポートレットが対話で受け取ったのと同じ 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 に記述されたポートのアドレスなど、プロデューサに関する特定の情報が保存されます。プロデューサを別の環境に伝播または移動すると、このデータは無効になります。この場合、プロキシ ポートレットからプロデューサのポートレットを参照しているコンシューマは、データを見つけられなくなります。
| 注意 : | 現在、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 属性を使用します。ただし、これはセッション スコープ キャッシュであるため、コンフィグレーションできません。
キャッシングについては、『ポートレット開発ガイド』の「ポートレットのキャッシュ」を参照してください。
プロデューサとコンシューマの最適なパフォーマンスを確保するために、以下のパフォーマンス チューニングのガイドラインに従うことをお勧めします。
この節では、プロデューサ アプリケーションのパフォーマンスを向上する方法をいくつか示します。
プロデューサのパフォーマンスを向上する方法の 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 のローカル プロキシのアーキテクチャの進展についてまとめています。
ローカル プロキシ サポートは強力なツールであるため、アプリケーションに効果が得られる場合のみ使用してください。ローカル プロキシ サポートを使用する一般的な理由は次のとおりです。
また、BEA 以外のプロデューサおよびコンシューマと相互運用する場合は、ローカル プロキシ サポートを使用しないでください。
Workshop for WebLogic と共にインストールされるメッセージ モニタ サーブレットを使用することにより、プロデューサとコンシューマの間のアクティビティをモニタすることができます。また、カスタム ログを作成して、WSRP セッションに関する特定の情報を表示することもできます。
プロデューサとコンシューマ間で受け渡される SOAP のアクション メッセージに加えて、応答ヘッダとリクエスト ヘッダをモニタするには次を実行します。
http://localhost:7001/wsrpMonitorTest/monitor
モニタがブラウザ内に表示されます。モニタを開始するには、[有効化] をクリックします。最新のトランザクションを表示するには、[更新] をクリックします。ブラウザ ウィンドウからすべてのメッセージを削除するには、[クリア] をクリックします。
| ヒント : | モニタは、[更新] をクリックするまで新しいトランザクションを表示しません。 |
リモート ポートレットがプロデューサと通信するたびに、図 14-4 に示すようなリクエストと応答のメッセージ ヘッダがモニタ画面に表示されます。
[表示] をクリックすると、図 14-5 に示すように、リクエストや応答の内容を表示できます。[非表示] をクリックすると、メッセージの内容が閉じます。
カスタム ログを作成するには、「インターセプタ フレームワーク」で説明するインターセプタ フレームワークを使用することをお勧めします。
WebLogic Server によってインスタンス化した Logger オブジェクトや Handler オブジェクトを使用すれば、WSRP セッションに関する特定の情報を表示するカスタム ログも作成できます。これらのオブジェクトを使用すると、独自のメッセージ ハンドラを作成し、ｌogger にサブスクライブできます。たとえば、プロデューサが生成するメッセージをリモート ポートレットでリスンする場合、handler を作成してそのプロデューサの logger にサブスクライブできます。Logger オブジェクトと Handler オブジェクトの使用方法の詳細については、WebLogic Server トピックの「WebLogic Server ログ メッセージのフィルタ処理」を参照してください。
この節では、リモート ポートレットにリソースを要求した時にコンシューマのセッションが失われるのを防ぐための 3 つのテクニックを説明します。次のようなテクニックがあります。
画像を含むリモート ポートレットがある場合、画像リソースが要求されると、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 を変更すると、コンシューマ ポータルは誤った永続状態データをプロデューサに送信する可能性があります。
この問題を避けるには、ログインとログアウトの直後に、常にブラウザ リダイレクトを使用する必要があります。ブラウザ リダイレクトにより、ポータルによってロードされるデータがリクエストに対して有効になります。
プロデューサによって生成された WSDL をカスタマイズできます。たとえば、WSDL がデフォルト以外のプロキシ サーバを指すようにする場合があります。デフォルトの WSDL をカスタマイズするには、WEB-INF/beehive-url-template-config.xml ファイルを編集します。このファイルを編集する最も簡単な方法は、ファイルを Workshop for WebLogic のワークスペースにコピーする方法です。これを行うには、Workshop のマージ済みプロジェクト ビューでファイルを見つけます。ファイルを右クリックし [ワークスペースにコピー] を選択します。テンプレート ファイルは 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 のマージ済みプロジェクト ビューでファイルを見つけます。ファイルを右クリックし [ワークスペースにコピー] を選択します。
コード リスト 14-4 は、コンフィグレーション ファイルの例を示しています。
<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 ファイルを編集します。
|
