WebLogic Portal での WSRP の使用
|
 |
 |
|
ローカル プロキシ サポートにより、プロデューサ Web アプリケーションとコンシューマ Web アプリケーションが同じ場所にある場合は、ネットワーク I/O および「HTTP 上での SOAP」のオーバーヘッドを回避できます。
注意 : コンシューマとプロデューサの両方を同じサーバ上で実行する場合、デッドロックの状況が発生する可能性があります。これは、プロデューサがポートレットごとに新しいスレッドを割り当てるためです。ローカル プロキシ モードで実行すると、追加のスレッドは割り当てられません。この理由から、プロデューサとコンシューマの両方を同じサーバで実行する場合は、この節の説明のようにローカル プロキシ モードを使用することをお勧めします。
この機能を有効にすると、コンシューマは、プロデューサが同じサーバにデプロイされているかどうかを判別しようとします。同じサーバにデプロイされていることがわかると、ローカル プロキシを使用してリクエストをプロデューサに送信します。プロデューサが同じサーバにデプロイされていない場合、コンシューマはデフォルトのリモート プロキシを使用します。ローカル プロキシ サポートが有効になっていても、リモート プロデューサは通常どおりに呼び出すことができます。
この節では、ローカル プロキシ サポートを実装する方法について説明します。内容は以下のとおりです。
ローカル プロキシ モードは、同じ場所にある Web アプリケーションを使用する際に、デフォルトのリモート プロキシに比べて多くの利点があります。特に重要な利点を次に示します。
OutOfMemoryErrors を引き起こさずに大容量ファイルのアップロードが可能になる。また、ローカル プロキシを有効にすることで、ユーザは、パフォーマンスのオーバーヘッドを発生させずに WSRP による分離の利点を活用できます。
ローカル プロキシ サポートを活用するには、次の手順に従います。
WEB-INF/wsrp-producer-registry.xml で <enable-local-proxy> を true に設定して、ローカル プロキシ サポートを有効にします。コード リスト 7-1 <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 limit (in bytes) -->
<upload-read-limit>1048576</upload-read-limit>
<!-- Timeout (in milli seconds) -->
<connection-timeout-secs>120000</connection-timeout-secs>
<!-- Enable local proxy -->
<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 以外のプロデューサおよびコンシューマと相互運用する場合は、ローカル プロキシ サポートを使用しないでください。
プロデューサとコンシューマが同じサーバ上にデプロイされている場合、ユーザが別の Web アプリケーションにデプロイされているポートレットと対話するとセッション状態が失われる可能性があります。この問題は、HTTP の観点では、ユーザが同じセッション ID (JSESSIONID) とパスで、クッキーを設定する 2 つの異なる Web アプリケーションと対話するために発生します。たとえば、図 7-1 のように、クッキー 1 とクッキー 2 のセッション名とパスが同じ場合、ブラウザは単にクッキー 1 をクッキー 2 で置き換えます。その結果、Web アプリケーション 1 のクッキー 1 が保持するセッション状態が失われます。
この状況を回避するには、いずれかの Web アプリケーションのクッキー名を手動で変更します。そのためには、アプリケーションの weblogic.xml ファイルの <session-descriptor> 要素を次のように編集します。
<session-descriptor>
<timeout-secs>300</timeout-secs>
<cookie-name>JMYCOOKIE</cookie-name>
</session-descriptor>
|
|
|
