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