| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、アプリケーション・ビジネス・コネクタ・サービス(ABCS)の概要を示し、ABCSコントラクトの定義方法とMEPの識別方法、アプリケーションとのアウトバウンド相互作用のテクノロジ・オプション、およびBPELを使用したABCSの作成方法について説明します。
この章の内容は次のとおりです。
ABCSの役割は、参加アプリケーションによって提供されるビジネス機能を、エンタープライズ・ビジネス・サービス(EBS)に合わせた表現で公開することです。また、参加アプリケーションからEBSを呼び出すことができるように、両者を結び付ける役割も果たします。図6-1に、E-Business SuiteアプリケーションがABCSを使用してEBSを呼び出すシナリオを示します。このシナリオでは、ABCSはリクエスタとして機能しています。また、同じ図では、EBSが3つのABCSの1つを呼び出して、特定のタスクを実行する方法も示されています。ここでは、3つのABCSはプロバイダとして機能しています。
図6-1 Oracle AIAアーキテクチャにおけるABCS
ABCSを使用すると、参加アプリケーションはサービス・プロバイダやサービス・コンシューマになることができます。また、非標準接続を行うアプリケーションの機能をWebサービスとして公開できます。
ABCSの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのアプリケーション・ビジネス・コネクタ・サービスの理解に関する項を参照してください。
リクエスタABCSは要求側アプリケーションによって提供され、EBSとインタフェースして1つのタスクを実行します。サービスは、要求側/ソース・アプリケーションとEBS間をインタフェースします。リクエスタABCSの役割は、参加アプリケーションがEBSを呼び出して、データにアクセスしたり、トランザクション・タスクを実行できるようにすることです。
リクエスタABCSは、EBSを呼び出すために要求側アプリケーションによって提供されるサービスです。アプリケーション・ビジネス・メッセージ(ABM)をペイロードとして受け取り、オプションでABMをレスポンスとして返します。
ABMは、リクエスタ・アプリケーションとの追加の対話によってエンリッチできます。ABMは、XSLを使用してエンタープライズ・ビジネス・メッセージ(EBM)に変換されます。EBSから受信するレスポンス(EBM)はABMに変換されます。
非SOAPペイロードは、リクエスタ・アプリケーションとリクエスタABCSの間でトランスポート・アダプタを使用して処理されます。リクエスタ・アプリケーションは、ABCSに関するシステム情報を渡して後続の対話を行う必要があります。
プロバイダABCSはプロバイダ・アプリケーションによって提供され、EBSとインタフェースして1つのタスクを実行します。サービスは、EBSとプロバイダまたはターゲット・アプリケーション間をインタフェースします。
プロバイダABCSとは:
プロバイダ・アプリケーションとインタフェースするために、プロバイダ・アプリケーションによって提供されるサービスです
EBMをペイロードとして受け取ります
(オプション) EBMをレスポンスとして返します
EBMは、XSLを使用してABMに変換されます。ABMは、プロバイダ・アプリケーションとの追加の対話によってエンリッチできます。アプリケーションから受信するレスポンス(ABM)はEBMに変換されます。
プロバイダ・アプリケーションとの非SOAP接続は、プロバイダABCSとプロバイダ・アプリケーションとの間でトランスポート・アダプタを使用して処理されます。
ABCSの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのアプリケーション・ビジネス・コネクタ・サービスの理解に関する項を参照してください。
ABCSコントラクト(WSDL)は、コール元がビジネス・コネクタ・サービスと相互作用する方法を指定します。コール元は、参加アプリケーションまたは他のサービス(EBSなど)のいずれかです。
図6-2に、ABCSのコントラクト(WSDL)を定義するためのデシジョン・フローを示します。
図6-2 ABCSコントラクトを定義するためのデシジョン・フロー
この項では、ABCSがリクエスタまたはプロバイダの役割で参加するために必要な設計デシジョンについて説明します。
ABCSがリクエスタの役割で参加できる方法を決定するには、次のことを検討します。
ABCSが呼出しまたはトリガーされる方法を決定します。この分析によって、ABCSがアプリケーションによって呼び出される方法が示されます。次を決定します。
アプリケーションがSOAPベースでABCSを呼び出せるかどうか。
アプリケーション・サービスがJCAアダプタを使用してABCSを呼び出せるかどうか。
ビジネス・イベントの発生によってアプリケーションが公開するメッセージを、ABCSがサブスクライブする必要があるかどうか。
必要な相互作用パターンを決定します。
次の質問は、アーキテクトが最適なメッセージ交換パターンを識別するのに役立ちます。
リクエスタABCSの呼出しを発生するビジネス・イベントは何か。
アプリケーションはリクエスタABCSからのレスポンスが必要か。
アプリケーションはレスポンスを受信するまで待機してから次のタスクを実行する必要があるか。
アプリケーションはリクエストがプロバイダ・アプリケーションによって完全に処理されるまで待機する必要があるか。
MEPの選択方法の詳細は、「適切なMEPの選択」を参照してください。
呼び出す必要があるエンタープライズ・ビジネス・サービスまたは操作を決定します。
リクエスタ・アプリケーションによって送信されるメッセージに、リクエスタABCSがEBMを作成するのに必要な情報がすべて含まれているか。
そうでない場合は、アプリケーションにアクセスして追加情報を取得する必要があるか。
そうである場合、使用可能なテクノロジは何か。追加情報を取得するのに使用されるアプリケーション・インタフェースは何か。
詳細は、「テクノロジ・オプション」を参照してください。
アプリケーションは不完全な情報を含むメッセージを公開できるか。
完全な情報を含むメッセージが公開されるまでABCSは待機する必要があるか。
この場合、関連メッセージの完全セットを受け取るまで、アグリゲータによって各メッセージを収集および格納する必要があります。
そうである場合、アプリケーション・サービスは何か、通信はどのような方法か。
ABMスキーマは、参加アプリケーションによって作成されます。ABMを定義するときは、次の点を考慮してください。
ABM定義を頻繁に変更するとABCS開発に負荷がかかるため、持続的で長期に使用できるメッセージを作成します。
変換マップの再利用を促進するために、複数のABM間でビジネス・コンポーネントを再利用できるようにします。
次のシステム・データを渡すようにABMを設計します。
システム・インスタンス - システム・レジストリに登録されたシステムIDの識別に役立つ接続情報
ロケール - リクエストが送信されるときの言語コード
送信者情報 - メッセージの作成に関連するコンテキスト詳細
拡張可能なABMを設計します。
ABCSとそのクライアント間で可能な相互作用タイプは次のとおりです。
同期リクエスト/レスポンス
非同期リクエストのみ
非同期リクエスト/遅延レスポンス
MEPの機能と使用方法は、ABCSの役割によって異なります。
MEPの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドの相互作用パターンの理解に関する項を参照してください。
同期リクエスト/レスポンス・パターン
リクエスタがリクエストをプロバイダに送信すると、プロバイダはそのリクエストを処理してレスポンスを返信します。
リクエスタは、プロバイダからレスポンスを受信するまで一時停止モードになります。
結果は、リアルタイムレスポンスまたはエラー・フィードバックです。
非同期リクエストのみ
メッセージ交換は、リクエスタがリクエストをプロバイダに送信する一方向です。プロバイダからリクエスタへのレスポンスはありません。
リクエスタは、リクエストの送信後、通常の実行を再開できます。
非同期リクエスト/遅延レスポンス
これには、一方向の呼出しが2つ含まれます。
最初に、リクエスタからプロバイダへの一方向メッセージが送信されます。その後に、別の一方向メッセージがプロバイダから元のリクエスタに返されます。
2つの異なる一方向メッセージは相互に関連しています。
MEPの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドの相互作用パターンの理解に関する項を参照してください。
参加アプリケーションがABCSとの間でインバウンドとアウトバウンドの相互作用を行う方法を識別します。
リクエスタ・アプリケーションは、プロバイダ・アプリケーションからレスポンスを受信するまで、呼出しを待機する必要があるかどうかを識別します。
プロバイダ・アプリケーションからレスポンスを受信するまで待機する場合、リクエスタ・アプリケーションはABCSを同期で呼び出すように強制されます。たとえば、リクエストを送信して請求アプリケーションからアカウント詳細を取得するCRMアプリケーションがこれに該当します。この場合、リクエスタはレスポンスを受信するまで他のタスクを実行できません。
ただし、請求アプリケーションで顧客を作成する場合、CRMアプリケーションからのリクエストの送信は非同期で行うことができます。CRMアプリケーションはアウトバウンド・リクエストを公開した後に次のアクティビティに移行でき、プロバイダ・アプリケーションが顧客を正常に作成するまで待機する必要はありません。この場合、CRMアプリケーションはこのアウトバウンド・リクエストを非同期で呼び出します。
アプリケーションは、様々な種類の統合テクノロジを利用して、同期または非同期の呼出しを行うことができます。状況に応じて、最適なテクノロジを選択する必要があります。
AIAサービスがアプリケーションと相互作用する方法の詳細は、「リソース接続の確立」を参照してください。
1つのフロー内で、リクエスタABCSのMEPは、呼び出されるEBS操作のMEPの影響を受けますが、リクエスタ・アプリケーションの相互作用機能もリクエスタABCSのMEPに影響を与えます。プロバイダABCSの場合、MEPはEBS操作のMEPの影響を多く受けます。
リクエストを開始した参加アプリケーションはレスポンスを待機しているため、問合せと検証を含むほとんどのケースでこのパターンが必要です。その他のケースでこのパターンが適しているかどうかは、実行される処理量に基づき、求められるレスポンス時間や要件が満たされる可能性によって決まります。
リクエスタABCSとEBS間のMEPは同期です。プロバイダABCSとリクエストを開始する参加アプリケーションとの間のMEPは、同期または非同期が可能です。
問合せの詳細は、「問合せ」を参照してください。
検証の詳細は、「検証」を参照してください。
ユースケース
請求システムから顧客に関するアカウント詳細をリクエストするCRMアプリケーション
図6-3に、AIAサービス、リクエスタABCSおよびCustomerPartyEBS間の双方向通信を示します。
図6-3 GetAccountBalanceSummary統合シナリオ
このパターンは次の場合に使用します。
リクエスタABCSが参加アプリケーションからリクエスト・メッセージを受信し、EBSを呼び出して終了します。この場合、EBSからリクエスタABCSへのレスポンスはなく、リクエストを開始した参加アプリケーションへのレスポンスもありません。
プロバイダABCSがEBSからリクエスト・メッセージを受信し、プロバイダ参加アプリケーションAPIを呼び出して終了します。リクエストを開始したEBSへのレスポンスはありません。
ユースケース
CustomerPartyを作成するためにBRMアプリケーションにリクエストを送信するCRMアプリケーション
参加アプリケーションであるSiebelの観点から見ると、CustomerPartyを作成するためのBRMアプリケーションへのリクエスト・メッセージは、後で処理するためにエンキューされます。Siebelアプリケーションは即時に処理を再開できます。リクエスト・メッセージはキューからデキューされ、非同期で処理されます。
図6-4に、AIAサービス、リクエスタABCSおよびCustomerPartyEBS間の一方向呼出しを示します。
図6-4 一方向呼出しの例
このパターンは次の場合に使用します。
リクエスタABCSは、リクエスト・メッセージを受信し、そのメッセージを処理して、最後に、参加アプリケーションによって公開されたAPIを呼び出して、リクエストを開始した参加アプリケーションを更新します。参加アプリケーションはレスポンスを待機しません。
プロバイダABCSは、EBSリクエスト・メディエータ・サービスからリクエスト・メッセージを受信し、そのメッセージを処理して、最後に、EBSリクエスト・メディエータ・サービスのレスポンス操作を呼び出して、要求側サービス(リクエスタABCSまたはエンタープライズ・ビジネス・フロー(EBF))に応答します。EBSメディエータ・サービスはレスポンスを待機しません。
MEPは、リクエスタABCSとEBS間で同期または非同期が可能で、プロバイダABCSとプロバイダ参加アプリケーション間でも同期または非同期が可能です。
ABCSとアプリケーション間の通信は、アプリケーション機能によって管理されます。
通信テクノロジは次のとおりです。
JCAアダプタ
標準Webサービス・インタフェース
アダプタ
JMSキュー
JCAアダプタが使用可能で使用が認可されている場合は、開発者がアプリケーションに接続する方法として最初に選択する必要があります。
JCAアダプタとは:
同一の場所に配置する方法でネイティブに参加アプリケーションを呼び出します。
プログラミング・インタフェースを標準化します。
サービス品質(QoS)の実装を標準化します。
ランタイム環境と組み合せて、接続管理、トランザクション管理およびスケーラビリティに関連するタスクをサポートします。
アウトバウンド接続の確立の詳細は、「リソース接続の確立」を参照してください。
これは、参加アプリケーションと通信する最も一般的な方法です。
ほとんどのアプリケーションは、Webサービスの形式で機能を公開しています。最も一般的に使用されるトランスポートはSOAP over HTTPですが、アプリケーションによっては直接XML over HTTPを公開しています。
メッセージの送信がメッセージ処理から分離している場合は、キューの使用をお薦めします。JMSキューを使用すると、JMSアダプタを使用してJMSキューにアクセスする必要があります。ABCSによってメッセージがJMSキューにエンキューされ、アプリケーションによってそのメッセージがデキューされます。
ヒント:
非同期モードのアウトバウンド相互作用を行う参加アプリケーションの場合は、メッセージ・キューを使用してリクエストを公開することをお薦めします。この方法を推奨するのは、高いスケーラビリティが実現し、エンドユーザーの操作性も向上するためです。同様に、アプリケーションへのアウトバウンド相互作用を行うABCSでは、アプリケーションによって実行されるタスクを評価する必要があります。アプリケーションでタスクを実行するのに長時間かかる場合は、メッセージ・キューを使用してアプリケーションと通信してください。
同期モードのみでアウトバウンド相互作用を行う参加アプリケーションは、SOAP/HTTPを使用してリクエストを送信する必要があります。
JMSアダプタの詳細は、『Oracle WebLogic Server JMSリソースの管理』を参照してください。
BPELコンポーネントを使用してABCSコンポジットを作成することをお薦めします。
次の場合にBPELを使用すると最も効率的です。
長時間実行プロセスが存在する場合。
数時間または数日を要する長時間実行プロセスが存在する場合は、BPELテクノロジの使用をお薦めします。この場合、BPELは特定のフック・ポイントでプロセスを保持(デハイドレーション)し、必要になった時点でプロセスを再開します。
複雑な編成機能が必要な場合。
複雑な編成、並列処理、参加アプリケーションまたは統合サービス(BPA、BAM、ワークフロー、ルール・エンジンなど)との複数の対話を必要とするシナリオの場合は、BPELを使用すると最も効率的です。
XSLTを使用して実行できないコンテンツを拡充および検証する場合。
意思決定や検証が複雑でXSLTを使用して実行できない場合は、標準的なBPEL手続き型コンストラクトやルール・エンジンの呼出しなどの方法が必要になります。BPELを使用すると、非常に複雑な意思決定ツリーの実行や、複数パートナへの結果のルーティングが容易になります。
集約または分割が必要な場合。
メッセージ処理またはデータ収集を行うために、ABCSがアプリケーション呼出しを複数回実行し、結果を1つのメッセージにまとめる必要がある場合は、BPELテクノロジの使用をお薦めします。BPELコンストラクトを使用すると、ペイロードの分割または統合、あるいは呼出しの集約または分割が可能になります。BPELプロセスは、呼出し間の状態保持やトランザクション処理も行います。
参加アプリケーション機能の補完が必要な場合。
詳細は、『Oracle SOAスイートでのSOAアプリケーションの開発』を参照してください。
