| Oracle BPEL Process Manager開発者ガイド 10g（10.1.3.1.0） B31874-03 |
|
 戻る |
 次へ |
この章では、BPELプロセスとその他のアプリケーションの間で共通の相互作用パターンを識別し、それぞれに最適な使用プラクティスを示します。
この章の内容は次のとおりです。
一方向メッセージ（Fire and Forget）ではクライアントがサービスにメッセージを送信し、サービスはそれに対して返信する必要がありません。 概要を図12-1に示します。
クライアントとしてのBPELプロセス
クライアントとしてのBPELプロセスには、有効なパートナ・リンク、およびターゲットのサービスとメッセージを持つinvokeアクティビティが必要です。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
サービスとしてのBPELプロセス
クライアントからメッセージを受け取るには、BPELプロセスはreceiveアクティビティが必要です。
同期相互作用では、クライアントはサービスにリクエストを送信し、すぐにリプライを受け取ります。BPELプロセスはこの相互作用のいずれかの終端であり、そのロール（クライアントまたはサービス）に合うようにコーディングする必要があります。 概要を図12-2に示します。
BPELプロセスが同期トランザクションのクライアント側の場合、invokeアクティビティが必要です。クライアント側のポートは、リクエストを送信し、リプライを受け取ります。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
BPELプロセスが同期トランザクションのサービス側の場合、着信リクエストを受け取るreceiveアクティビティ、および必要な情報またはエラー・メッセージ（フォルト）のいずれかを返すreplyアクティビティが必要です。
非同期相互作用では、クライアントはサービスにリクエストを送信し、サービスが応答するまで待機します。 概要を図12-3に示します。
BPELプロセスが非同期トランザクションのクライアント側の場合、リクエストを送信するinvokeアクティビティおよびリプライを受信するreceiveアクティビティが必要です。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
同期トランザクションと同様に、BPELプロセスが非同期トランザクションのサービス側の場合、着信リクエストを受け取るreceiveアクティビティ、および必要な情報またはフォルトのいずれかを返すinvokeアクティビティが必要です。
タイムアウト付きの非同期相互作用では、クライアントはリクエストをサービスに送信し、リプライを受け取るまであるいは一定の時間が経過するまでの、いずれか早い時点まで待機します。 概要を図12-4に示します。
BPELプロセスがタイムアウト付きの非同期トランザクションのクライアント側の場合、リクエストを送信するinvokeアクティビティおよび2つのブランチ（onMessageブランチおよびonAlarmブランチ）を持つpickアクティビティが必要です。時間制限の後にリプライが到着した場合、メッセージは配達不能キューに送られます。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
サービスBPELプロセスの動作は、非同期相互作用でのサービスとしてのBPELプロセス（「サービスとしてのBPELプロセス」で説明）と同じです。
通知タイマー付き非同期相互作用では、クライアントはリクエストをサービスに送信し、リプライを待機しますが、タイマーが時間切れになると通知が送信されます。タイマーが時間切れになっても、クライアントはサービスからのリプライを待機し続けます。 概要を図12-5に示します。
BPELプロセスがこのトランザクションのクライアント側の場合、リクエストを送信するinvokeアクティビティおよびリプライを受信するreceiveアクティビティを含むscopeアクティビティが必要です。scopeアクティビティのonAlarmハンドラには時間制限、および時間切れになったときの指示が含まれます。たとえば、30分待機した後、予想を超える時間がプロセスにかかっているという警告を送信します。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
サービスBPELプロセスの動作は、非同期相互作用でのサービスとしてのBPELプロセス（「サービスとしてのBPELプロセス」で説明）と同じです。
このタイプの相互作用では、クライアントは1つのリクエストをサービスに送信し、複数のレスポンスを受け取ります。たとえば、商品をオンラインで注文するリクエストに対し、最初のレスポンスは納期予定、2番目のレスポンスは支払い確認、3番目のレスポンスは商品が発送されたことの通知である場合があります。この例では、レスポンスの数とタイプが予想されていることに注意してください。 概要を図12-6に示します。
クライアントとしてのBPELプロセス
BPELプロセスがこのトランザクションのクライアント側の場合、リクエストを送信するinvokeアクティビティおよび3つのreceiveアクティビティ（各リプライに対して1つ）を持つsequenceアクティビティが必要です。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
サービスとしてのBPELプロセス
BPELサービスには、クライアントからのメッセージを受け取るreceiveアクティビティおよび3つのinvokeアクティビティ（各リプライに対して1つ）を持つsequence属性が必要です。
1リクエストと二者択一レスポンスを使用する相互作用では、クライアントはサービスに1つのリクエストを送信し、2つのうちのいずれかのレスポンスを受け取ります。たとえば、商品をオンラインで注文するリクエストに対し、最初のレスポンスは在庫ありメッセージまたは在庫切れメッセージのいずれかである場合があります。 概要を図12-7に示します。
クライアントとしてのBPELプロセス
BPELプロセスがこのトランザクションのクライアント側の場合、BPELプロセス内に次のアクティビティが必要です。
リクエストを送信するinvokeアクティビティ
2つのブランチを持つpickアクティビティ。1つ目のonMessageブランチは、在庫ありメッセージを受け取った場合の、在庫ありレスポンスおよび指示用
2つ目のonMessageブランチは、在庫切れメッセージを受け取った場合の、在庫切れレスポンスおよび指示用
すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
サービスとしてのBPELプロセス
BPELサービスにはクライアントからメッセージを受け取るreceiveアクティビティおよび2つのブランチ（品目が入手可能な場合に在庫ありメッセージを送信するinvokeアクティビティを持つブランチと、品目が入手不可の場合に在庫切れメッセージを送信するinvokeアクティビティを持つブランチ）を持つswitchアクティビティが必要です。
このタイプの相互作用では、クライアントは1つのリクエストをサービスに送信し、1つまたは2つのレスポンスを受け取ります。ここでのリクエストは、商品をオンラインで注文することです。商品が遅れている場合は、遅延を顧客に通知するメッセージがサービスにより送信されます。どのような場合も、商品の発送時には必ず通知が送信されます。 概要を図12-8に示します。
クライアントとしてのBPELプロセス
BPELプロセスがこのトランザクションのクライアント側の場合、リクエストを送信するinvokeアクティビティおよび必須リプライを受信するreceiveアクティビティを含む、scopeアクティビティが必要です。scopeアクティビティのonMessageハンドラは、オプションのメッセージおよびそれを受け取った場合の指示（商品が遅れていることをユーザーに通知するなど）を受け取るように設定されています。クライアントBPELプロセスは必須リプライの受信を待機します。最初に必須リプライを受信すると、BPELプロセスはオプションのリプライを待機せずに続行します。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
サービスとしてのBPELプロセス
BPELサービスにはreceiveアクティビティと必須発送メッセージを送信するinvokeアクティビティを含むscopeアクティビティ、および時間切れになった場合のオプションの遅延メッセージを送信する（品目が24時間以内に出荷されない場合の遅延メッセージの送信など）scopeのonAlarmハンドラが必要です。
部分処理では、クライアントはリクエストをサービスに送信し、すぐにレスポンスを受け取りますが、処理はサービス側で続行されます。たとえば、クライアントはパッケージ・ツアーを購入するリクエストを送信します。サービスは購入を確認するリプライをただちに送信して、ホテル、フライト、レンタカーなどの予約を続行します。このパターンでは、長期間の処理が続く複数の単発コールバックも含まれることがあります。 概要を図12-9に示します。
BPELクライアントが単純なこのケースでは、各リクエストにinvokeアクティビティと、非同期トランザクションの各リプライに対するreceiveアクティビティまたは各同期トランザクションに対するinvokeアクティビティが必要です。これらのトランザクションが完了すると、残りの作業はサービスによって制御されます。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
BPELサービスには、クライアントからの各リクエストに対するreceiveアクティビティと、各レスポンスに対するreplyアクティビティが必要です。レスポンスが終了すると、クライアントからさらに入力を受け取らずに、必要なタスクを実行する相互作用で収集された情報を使用して、サービスBPELプロセスはその処理を続行できます。
購入者、販売者、発送者など、トランザクションに3つ以上のアプリケーションが必要な場合があります。この場合、購入者は販売者にリクエストを送信し、販売者は発送者にリクエストを送信し、発送者は購入者に通知を送信します。この「A-B-C-A」トランザクション・パターンは、1度に多数のトランザクションを扱うことがあります。このため、どのメッセージがどこに送信されるのかを追跡するためのメカニズムが必要です。 概要を図12-10に示します。
すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。
