| Oracle® Fusion Middleware Oracle SOA Suite開発者ガイド 11gリリース1 (11.1.1.9) B56238-11 |
|
 前 |
 次 |
この章では、BPELプロセス・サービス・コンポーネントと外部サービスとの間における共通の相互作用パターン(一方向メッセージ、同期および非同期の相互作用、1リクエストと複数/単一レスポンス、1リクエストと必須/オプション・レスポンス、部分処理、複数アプリケーション間の相互作用など)について説明します。また、それぞれを使用する場合のベスト・プラクティスについても説明します。
この章では、次の項目について説明します。
一方向メッセージ(Fire and Forget)では、クライアントはメッセージをサービスに送信し(図5-1のd1)、サービスはそれに対して返信する必要がありません。メッセージを送信するクライアントは、レスポンスを待機せずに即時に実行を続行します。例5-1に、この環境におけるBPELプロセスWSDLファイルのportTypeとoperationのパートを示します。
例5-1 一方向WSDLファイル
. . .
<wsdl:portType name="BPELProcess1">
<wsdl:operation name="process">
<wsdl:input message="client:BPELProcess1RequestMessage" />
</wsdl:operation>
</wsdl:portType>
. . .
図5-1に概要を示します。
同期相互作用では、クライアントはリクエストをサービスに送信し(図5-2のd1)、リプライを即時に受信します(図5-2のd2)。BPELプロセス・サービス・コンポーネントはこの相互作用のいずれかの終端であり、そのロール(クライアントまたはサービス)に従ってコーディングする必要があります。たとえば、オンライン新聞の購読をリクエストしたユーザーは、リクエストの受取り確認電子メールを即時に受信します。例5-2に、この環境におけるBPELプロセスWSDLファイルのportTypeとoperationのパートを示します。
例5-2 同期WSDLファイル
. . .
<wsdl:portType name="BPELProcess1">
<wsdl:operation name="process">
<wsdl:input message="client:BPELProcess1RequestMessage" />
<wsdl:output message="client:BPELProcess1ResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
図5-2に概要を示します。
BPELプロセス・サービス・コンポーネントが同期トランザクションのクライアント側にある場合は、invokeアクティビティが必要です。クライアント側のポートは、リクエストを送信し、リプライを受信します。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
BPELプロセス・サービス・コンポーネントが同期トランザクションのサービス側にある場合は、着信リクエストを受け取るreceiveアクティビティ、およびリクエストされた情報またはWSDLで定義されたエラー・メッセージ(フォルト、図5-2のf1)のいずれかを返すreplyアクティビティが必要です。
同期相互作用の詳細は、第7章「BPELプロセスからの同期Webサービスの起動」を参照してください。
非同期相互作用では、クライアントはリクエストをサービスに送信し、サービスが応答するまで待機します。例5-3に、この環境におけるBPELプロセスWSDLファイルのportTypeとoperationのパートを示します。
例5-3 非同期WSDLファイル
. . .
<wsdl:portType name="BPELProcess1">
<wsdl:operation name="process">
<wsdl:input message="client:BPELProcess1RequestMessage"/>
</wsdl:operation>
</wsdl:portType>
. . .
<wsdl:portType name="BPELProcess1Callback">
<wsdl:operation name="processResponse">
<wsdl:input message="client:BPELProcess1ResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
図5-3に概要を示します。
BPELプロセス・サービス・コンポーネントが非同期トランザクションのクライアント側にある場合は、リクエストを送信するinvokeアクティビティおよびリプライを受信するreceiveアクティビティが必要です。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
同期トランザクションと同様に、BPELプロセス・サービス・コンポーネントが非同期トランザクションのサービス側にある場合は、着信リクエストを受け取るreceiveアクティビティ、およびリクエストされた情報またはフォルトのいずれかを返すinvokeアクティビティが必要です。同期BPELプロセスからの応答との違いに注意してください。同期BPELプロセスはクライアントへの応答にreplyアクティビティを使用します。非同期サービスはinvokeアクティビティを使用します。
非同期相互作用の詳細は、第8章「BPELプロセスからの非同期Webサービスの起動」を参照してください。
タイムアウト付き非同期相互作用(BPELでpickアクティビティを使用して実行)では、クライアントはリクエストをサービスに送信し、リプライを受信するまであるいは一定の時間が経過するまでの、いずれか早い時点まで待機します。たとえば、クライアントが融資提案をリクエストします。クライアントが指定時間内に融資提案リプライを受信しなかった場合は、リクエストが取り消されます。図5-4に概要を示します。
BPELプロセス・サービス・コンポーネントがタイムアウト付きの非同期トランザクションのクライアント側にある場合は、リクエストを送信するinvokeアクティビティおよび2つのブランチ(onMessageブランチおよびonAlarmブランチ)を持つpickアクティビティが必要です。時間制限の後にリプライが到着した場合、メッセージは配信不能キューに送られます。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
タイムアウト付き非同期相互作用の詳細は、第15.2項「プロセスの継続または待機を選択するpickアクティビティの作成」を参照してください。
通知タイマー付き非同期相互作用では、クライアントはリクエストをサービスに送信し、リプライを待機しますが、タイマーが時間切れになると通知が送信されます。タイマーが時間切れになっても、クライアントはサービスからのリプライを待機し続けます。図5-5に概要を示します。
このタイプの相互作用では、クライアントは1つのリクエストをサービスに送信し、複数のレスポンスを受信します。たとえば、商品をオンラインで注文するリクエストに対し、最初のレスポンスは納期予定、2番目のレスポンスは支払い確認、3番目のレスポンスは商品が発送されたことの通知である場合があります。この例では、レスポンスの数とタイプが予想されていることに注意してください。図5-6に概要を示します。
1リクエストと二者択一レスポンスを使用する相互作用では、クライアントは1つのリクエストをサービスに送信し、2つのうちのいずれかのレスポンスを受信します。たとえば、商品をオンラインで注文するリクエストに対し、最初のレスポンスは在庫ありメッセージまたは在庫切れメッセージのいずれかである場合があります。図5-7に概要を示します。
BPELプロセス・サービス・コンポーネントがこのトランザクションのクライアント側にある場合は、BPELプロセス・サービス・コンポーネント内に次のアクティビティが必要です。
リクエストを送信するinvokeアクティビティ。
2つのブランチを持つpickアクティビティ。1つ目のonMessageブランチは、在庫ありメッセージを受信した場合の、在庫ありレスポンスおよび指示用。
2つ目のonMessageブランチは、在庫切れメッセージを受信した場合の、在庫切れレスポンスおよび指示用。
すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
1リクエストと二者択一レスポンスを使用する相互作用の詳細は、第15.2項「プロセスの継続または待機を選択するpickアクティビティの作成」を参照してください。
このタイプの相互作用では、クライアントは1つのリクエストをサービスに送信し、1つまたは2つのレスポンスを受信します。ここでのリクエストは、商品をオンラインで注文することです。商品が遅れている場合は、遅延を顧客に通知するメッセージがサービスにより送信されます。どのような場合も、商品の発送時には必ず通知が送信されます。図5-8に概要を示します。
BPELプロセス・サービス・コンポーネントがこのトランザクションのクライアント側にある場合は、リクエストを送信するinvokeアクティビティおよび必須リプライを受信するreceiveアクティビティを含む、scopeアクティビティが必要です。scopeアクティビティのonMessageハンドラは、オプションのメッセージおよびそれを受信した場合の指示(商品が遅れていることをユーザーに通知するなど)を受け取るように設定されています。クライアントBPELプロセス・サービス・コンポーネントは必須リプライの受信を待機します。最初に必須リプライを受信すると、BPELプロセス・サービス・コンポーネントはオプションのリプライを待機せずに続行します。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
部分処理では、クライアントはリクエストをサービスに送信し、すぐにレスポンスを受信しますが、処理はサービス側で続行されます。たとえば、クライアントはパッケージ・ツアーを購入するリクエストを送信します。サービスは購入を確認するリプライをただちに送信して、ホテル、フライト、レンタカーなどの予約を続行します。このパターンでは、長期間の処理が続く複数の単発コールバックも含まれることがあります。図5-9に概要を示します。
購入者、販売者、発送者など、トランザクションに3つ以上のアプリケーションが必要な場合があります。この場合、購入者は販売者にリクエストを送信し、販売者はそのリクエストを発送者に送信し、発送者は購入者に通知を送信します。この「A-B-C-A」トランザクション・パターンは、同時に多数のトランザクションを処理できます。このため、どのメッセージがどこに送信されるのかを追跡するためのメカニズムが必要です。図5-10に概要を示します。
すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
このような調整は、WS-Addressingと相関セットを使用して管理できます。これらの詳細は、第8章「BPELプロセスからの非同期Webサービスの起動」を参照してください。
