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