WebLogic Web サービス プログラマーズ ガイド
|
 |
 |
|
以下の節では、WebLogic Server インスタンス間で、SOAP メッセージの送信側および受信側として信頼性のある SOAP メッセージングを使用する方法について説明します。
警告 :信頼性のある SOAP メッセージングは、クラスタ化環境ではサポートされません。
信頼性のある SOAP メッセージングというフレームワークでは、ある WebLogic Server インスタンスで稼動しているアプリケーションによって、別の WebLogic Server インスタンスで稼動している Web サービスを、非同期かつ確実に呼び出せます。信頼性のある、とは 2 つの Web サービス間でのメッセージの配信を保証できるということです。
注意 :信頼性のある SOAP メッセージングは、1 つの WebLogic Server インスタンスにデプロイされた 2 つの Web サービス間で機能します。通常、この設定は開発のために使用されます。しかし、実際には、信頼性のある SOAP メッセージングは 2 つの WebLogic Server インスタンス間で使用され、これらの 2 つのインスタンスは、信頼性のある SOAP メッセージングを使用するようにコンフィグレーションする必要があります。
送信側の WebLogic Server は、受信側の WebLogic Server で実行している信頼性のある Web サービス オペレーションを非同期に呼び出すアプリケーションを備えています。送信側は、信頼性のある SOAP メッセージングの情報をヘッダに含む SOAP メッセージを受信側に送信します。呼び出される Web サービス オペレーションは、信頼性のある SOAP メッセージング用にコンフィグレーションされています。呼び出しは非同期に行われるため、送信側は、該当するオペレーションが呼び出されたかどうかを直ちに確認できません。ただし、次の 2 つの通知のいずれかを受信することになります。
注意 :この通知は、受信側 WebLogic Server 上の Web サービス オペレーションが正常に呼び出されたことを意味するものではありません。アプリケーション例外のために、オペレーションの呼び出しに失敗することもあります。例外は送信側への通知に記載されます。トランザクションの詳細については、「受信側のトランザクションのコンテキスト」を参照してください。
WebLogic Web サービス非同期 API を使用すると、送信側は受信側にポーリングして通知を確認するか、または通知するコールバックを登録できます。その結果、送信側は、メッセージが受信されたことを伝える通知を受け取るか、またはメッセージが配信されなかったことを伝える通知を受け取ります。
信頼性のある SOAP メッセージングは、転送方法に依存しません。デフォルトでは HTTP/S が使用されますが、受信する Web サービスを適切にコンフィグレーションして送信側が Web サービスを呼び出すときに JMS ポートを利用するようにすれば、JMS を使用することもできます。JMS 転送の使い方の詳細については、「JMS 転送を使用した WebLogic Web サービスの呼び出し」を参照してください。
次の図と手順では、信頼性のある SOAP メッセージング機能のアーキテクチャについて説明します。
図 10-1 WebLogic SOAP メッセージング アーキテクチャ
注意 :メッセージ全体ではなく、メッセージ ID だけが受信側のストアに永続的に保存されます。
受信側が実行するアクションは、トランザクションのコンテキスト内で行われます。「受信側のトランザクションのコンテキスト」を参照してください。
確実に呼び出せるのは void オペレーションだけなので、受信側は送信側に値を返しません。呼び出したオペレーションでアプリケーション例外が送出されると、その例外も送信側に返送されます。Java クラスではなく EJB によるシステム例外では、受信側が開始したトランザクションがロールバックされます。詳細については、「受信側のトランザクションのコンテキスト」を参照してください。
受信側ランタイムが送信側からのメッセージを受け取ると、トランザクションが開始され、受信側の以降のすべてのアクションはこのトランザクションのコンテキスト内ですべて実行されます。
受信側のすべてのアクションをトランザクションのコンテキスト内で実行する主な理由は、永続ストアでのメッセージ ID の整合性を維持することにあります。たとえば、受信側がメッセージ ID をストアに保存した直後に WebLogic Server がクラッシュし、受信側がまだオペレーションを呼び出していない場合は、トランザクションがロールバックされ、保存したメッセージ ID はストアから削除されます。後で送信側がメッセージを再送信すると (オペレーションの呼び出しの応答確認を送信側がまだ受信していないため)、受信側にはメッセージの履歴がなく、全プロセスが正しく再実行されます。受信側がトランザクションのコンテキスト内で実行されなかった場合は、不適切なメッセージ ID がストア内に存在するため、オペレーションは呼び出されません。
トランザクション中に以下のいずれかのイベントが発生すると、受信側が開始したトランザクションはロールバックされます。
RemoteException などのシステム例外を送出する。次のイベントでは、トランザクションのロールバックが行われません。
WithdrawalErrorException などがあります。ステートレス セッション EJB で実装された、オペレーションの確実な呼び出しが可能な Web サービスを作成するには、EJB のプログラミング時に以下のガイドラインに従います。
EJBContext.setRollbackOnly() メソッドを使用する。RemoteException など) では、トランザクションがロールバックされるので注意する。ユーザがその銀行口座から引き出そうとする金額が多すぎるときに EJB が送出する WithdrawalErrorException のようなアプリケーション例外では、トランザクションはロールバックされません。詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』と『WebLogic JTA プログラマーズ ガイド』を参照してください。
Java クラスで実装された、オペレーションの確実な呼び出しが可能な Web サービスを作成するには、Java クラスのプログラミング時に以下のガイドラインに従います。
詳細については、『WebLogic JTA プログラマーズ ガイド』を参照してください。
Administration Console を使用して、次のトランザクション属性をコンフィグレーションします。
JTA トランザクションのコンフィグレーション設定は、ドメイン レベルで適用できます。つまり、コンフィグレーション属性の設定はドメイン内のすべてのサーバに適用されることになります。 詳細については、「トランザクションのコンフィグレーション」を参照してください。
void を返す Web サービス オペレーションだけである。
ここでは、信頼性のある SOAP メッセージングをコンフィグレーションして WebLogic Web サービス オペレーションを呼び出すための主な手順を示します。この手順では、送信側と受信側の WebLogic Server インスタンスで行われるコンフィグレーションとコード記述のタスクについて説明します。
注意 :この手順では、ユーザが WebLogic Web サービスをすでに実装およびアセンブルしていて、かつ 1 つまたは複数の Web サービス オペレーションの確実な呼び出しを可能にするのが目的であることを前提としています。さらに、信頼性のない方法で Web サービスを呼び出すサーバサイド アプリケーション (Web アプリケーションのサーブレットなど) をすでにコーディングしており、このアプリケーションを更新して Web サービスを確実に呼び出すのが目的であることを前提としています。
これらのタスクの詳細については、「WebLogic Web サービスの実装」、「Ant タスクを使用した WebLogic Web サービスのアセンブル」、および「クライアント アプリケーションおよび WebLogic Server からの Web サービスの呼び出し」を参照してください。
「送信側 WebLogic Server をコンフィグレーションする」を参照してください。
「受信側 WebLogic Server をコンフィグレーションする」を参照してください。
<servicegen
destEar="ears/myWebService.ear"
warName="myWAR.war"
contextURI="web_services" >
<service
ejbJar="jars/myEJB.jar"
targetNamespace="http://www.bea.com/examples/Trader"
serviceName="TraderService"
serviceURI="/TraderService"
generateTypes="True"
expandMethods="True" >
<reliability duplicateElimination="True"
persistDuration="60"
/>
</service>
</servicegen>
この例では、Web サービスは同じ送信側アプリケーションによる重複呼び出しを無視し、少なくとも 60 秒間メッセージを保持します。<reliability> 要素の属性の詳細については、「servicegen」を参照してください。
注意 :この build.xml ファイルを使用して Web サービスを再生成すると、void を返すすべてのオペレーションで信頼性のある呼び出しが有効化されます。あるオペレーションのみを確実に呼び出す場合や、servicegen で Web サービスを再生成しない場合は、WebLogic Web サービスの web-services.xml ファイルを手動で更新できます。詳細については、「信頼性のある SOAP メッセージングの web-services.xml ファイルを手動で更新する」を参照してください。
generateAsyncMethods="True" 属性を指定して clientgen Ant タスクを再実行し、非同期オペレーションの呼び出しを含む、Web サービス固有のクライアント JAR ファイルを新規に生成します。この新しいクライアント JAR ファイルは、送信側 WebLogic Server で実行しているサーバサイド アプリケーションで使用されます。例については、「確実にオペレーションを呼び出す Java コードを記述する」を参照してください。
この節では、送信側 WebLogic Server インスタンスの信頼性のある SOAP メッセージングの属性をコンフィグレーションする方法について説明します。
注意 :信頼性のある SOAP メッセージングのコンフィグレーションには、JMS ファイルまたは JDBC ストアのコンフィグレーションを伴います (JMS ファイルまたは JDBC ストアが存在していない場合)。
次の表では、信頼性のある SOAP メッセージングの属性について説明します。
これらの属性をコンフィグレーションするには、次の手順に従います。
この節では、受信側 WebLogic Server インスタンスの信頼性のある SOAP メッセージングの属性をコンフィグレーションする方法について説明します。
注意 :信頼性のある SOAP メッセージングのコンフィグレーションには、JMS ファイルまたは JDBC ストアのコンフィグレーションを伴います (JMS ファイルまたは JDBC ストアが存在していない場合)。
次の表では、信頼性のある SOAP メッセージングの属性について説明します。
これらの属性をコンフィグレーションするには、次の手順に従います。
このマニュアルの以降の節では、各 Web サービス オペレーションでこのデフォルト値をオーバーライドする方法について説明します。「信頼性のある SOAP メッセージングの web-services.xml ファイルを手動で更新する」を参照してください。
web-services.xml ファイルで WebLogic Web サービス オペレーションの定義を更新し、対応する <operation> 要素に <reliable-deliver> 子要素を追加して、WebLogic Web サービス オペレーションに信頼性があることを指定します。この操作を行うには、servicegen Ant タスクを使用するか (「信頼性のある SOAP メッセージングの使い方 : 主な手順」を参照)、または web-services.xml ファイルを手動で更新します (「信頼性のある SOAP メッセージングの web-services.xml ファイルを手動で更新する」を参照)。ただし、信頼性のあるオペレーションを信頼性のある状態で呼び出すときにクライアント アプリケーションは不要です。以下の 3 つの方法で信頼性のあるオペレーションを呼び出すことができます。
送信側アプリケーションから Web サービス オペレーションを確実に呼び出す Java コードの記述は、オペレーションを非同期に呼び出す場合 (「非同期クライアント アプリケーションの記述」を参照) とよく似ています。オペレーションの非同期での呼び出しは、startOperation() と endOperation() の 2 つのメソッドに分かれています。
確実にオペレーションを呼び出すには、標準の非同期クライアント Java コード以外に以下の作業が必要になります。
AsyncInfo.setReliableDelivery(true) メソッドを使用して、クライアント アプリケーションで信頼性のある配信を可能にする。AsyncInfo.setResultListener(listener) メソッドを使用して信頼性のあるオペレーションの呼び出しの結果をリスンする。リスナ クラスでは、ResultListener インタフェースが実装されます。このインタフェースでは、信頼性のある非同期オペレーションの呼び出し完了時の動作を定義する、onCompletion() リスナ コールバック メソッドが定義されます。 次の例は、processOrder() オペレーションを非同期で確実に呼び出す最も簡単な方法を示しています。この方法では、setReliableDeliver(true) メソッドを指定し、非同期 API を使用してオペレーションを startProcessOrder() と endProcessOrder() の 2 つの呼び出しに分割します。generateAsyncMethods 属性を指定することにより、これらの 2 つのメソッドをスタブで生成することを clientgen Ant タスクに指示します。
import weblogic.utils.Debug;
import weblogic.webservice.async.AsyncInfo;
import weblogic.webservice.async.FutureResult;
public final class ReliableSender {
public void placeOrder(String order) {
try {
// Web サービスのポートを設定する
MarketService market = new MarketService_Impl();
MarketServicePort marketPort = marketService.getMarketServicePort();
// 信頼性のある配信を可能にする
AsyncInfo asyncCtx = new AsyncInfo();
asyncCtx.setReliableDelivery(true);
// Web サービスを非同期に呼び出す
FutureResult futureResult = marketPort.startProcessOrder(order, asyncCtx);
marketPort.endProcessOrder(futureResult);
} catch (Exception e) {
Debug.say("Exception in ReliableSender: " + e);
}
}
}
前回の例に基づく、より複雑な例を次に示します。この例では結果のリスナを設定し、非同期で信頼性のあるオペレーションの呼び出し完了をリスンします。onCompletion() メソッドの実装では、呼び出し完了時の動作が指定されます。この例では、呼び出しに失敗するとメッセージが出力されます。
import java.io.Serializable;
import weblogic.webservice.async.AsyncInfo;
import weblogic.webservice.async.FutureResult;
import weblogic.webservice.async.InvokeCompletedEvent;
import weblogic.webservice.async.ResultListener;
import weblogic.webservice.async.ReliableDeliveryFailureEvent;
import weblogic.utils.Debug;
public final class ReliableSender {
public void placeOrder(String order) {
try {
// Web サービスのポートを設定する
MarketService market = new MarketService_Impl();
MarketServicePort marketPort = marketService.getMarketServicePort();
// 信頼性のある配信を可能にする
AsyncInfo asyncCtx = new AsyncInfo();
asyncCtx.setReliableDelivery(true);
// 結果のリスナを設定する
RMListener listener = new RMListener();
asyncCtx.setResultListener(listener);
// Web サービスを非同期に呼び出す
FutureResult futureResult = marketPort.startProcessOrder(order, asyncCtx);
while ( !futureResult.isCompleted()) {
Debug.say("async polling ..."); // 何か他の処理をする
Thread.sleep(3000);
}
marketPort.endProcessOrder(futureResult);
} catch (Exception e) {
Debug.say("Exception in ReliableSender: " + e);
}
}
}
class RMListener implements ResultListener, Serializable {
public void onCompletion(InvokeCompletedEvent event) {
if (event instanceof ReliableDeliveryFailureEvent) {
ReliableDeliveryFailureEvent rdEvent =
(ReliableDeliveryFailureEvent) event;
Debug.say("Reliable delivery failed with the following message: " +
rdEvent.getErrorMessage());
}
}
}
オペレーションを確実に呼び出すアプリケーションは、SOAP メッセージ配信の再試行中に送信側サーバがクラッシュしても対応できる必要があります。送信側サーバが再起動すると、正しく配信されていないメッセージの有無が永続ストアでチェックされ、メッセージがある場合は受信側サーバへのメッセージ送信が引き続き試行されます。一方、送信側サーバのクラッシュのために、最初にオペレーションを確実に呼び出したアプリケーションはデプロイされなくなり、送信側サーバの再起動後に受信側サーバが確認応答を返送しても、この確認応答を受け付けるアプリケーションが存在しないという問題が生じます。
こうした状況に正しく対処するには、次のガイドラインに従ってアプリケーションをコーディングします。
ResultListener インタフェースを実装するクラスを作成する。このクラスは、信頼性のあるオペレーションの呼び出し完了をリスンします。このクラスの記述例については、「確実にオペレーションを呼び出す Java コードを記述する」の 2 番目の例を参照してください。ResultListener インタフェースを実装するクラスをコーディングし、Serializable インタフェースも実装して、送信側サーバがクラッシュした場合にクラスがシリアライズされてディスクに格納されるようにする。その後、送信側サーバが再起動すると結果のリスナ クラスも呼び出され、受信側からの以降の確認応答メッセージが処理されます。 servicegen Ant タスクを使用して Web サービスを再生成すると、void を返すすべてのオペレーションで信頼性のある呼び出しが可能になります。この節で説明するように、あるオペレーションのみを確実に呼び出す場合や、servicegen で Web サービスを再生成しない場合は、WebLogic Web サービスの web-services.xml ファイルを手動で更新できます。
web-services.xml ファイルは、Web サービス EAR ファイルにある Web アプリケーションの WEB-INF ディレクトリにあります。ファイルの場所の詳細については、「Web サービス EAR ファイル パッケージ」を参照してください。
web-services.xml ファイルを更新して 1 つまたは複数のオペレーションに対して信頼性のある SOAP メッセージングを有効化するには、以下の手順に従います。
duplicate-elimination - 同じ送信側アプリケーションによる、同じメッセージ ID を持つ重複呼び出しを WebLogic Web サービスで無視するかどうかを指定するブール。デフォルト値は True です。persist-duration - Web サービスを呼び出した送信側から受信した信頼性のある SOAP メッセージの履歴を Web サービスがストレージで保持する最小秒数を指定する整数値。persist-duration の秒数が経過すると、受信側 WebLogic Server はメッセージの履歴をストアから削除します。この属性の値 (設定する場合) は、送信側の再試行間隔と再試行回数の積よりも大きい値を指定します。この属性によって、「受信側 WebLogic Server をコンフィグレーションする」で設定したサーバのデフォルト値がオーバーライドされます。いずれも未設定の場合のデフォルト値は 360 秒です。
|
|
|