| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、AIAメッセージ処理パターン、AIAアセット一元化パターン、AIAアセット拡張性パターンの概要を説明します。
注意:
コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。
この章の内容は次のとおりです。
この項では、AIAメッセージ処理パターンについて説明し、発生する可能性がある特定の問題のソリューションを提供します。
この項には次のトピックが含まれます:
問題
コンシューマがサービス・プロバイダにリクエストを同期的に送信し、各リクエストに対するレスポンスを即時に取得することは、多くのユースケースによって正当化されています。これらのユースケースでは、コンシューマは、レスポンスを受信するまで待機してから次のタスクに進む必要があります。
たとえば、顧客関係管理(CRM)アプリケーションでは、勘定残高の取得、与信チェック、ATP(有効在庫)計算などのタスクを実行するために、顧客サービス担当およびシステムからプロバイダにリクエストを送信可能にするなどの機能が提供されます。CRMアプリケーションでは、レスポンスが後続のタスクで使用されることを想定しているため、レスポンスが受信されるまで、ユーザーがその他のタスクを実行できないようにします。
ソリューション
バックエンド・システムの処理または接続を必要とするすべてのコンポジットで、同期リクエスト/レスポンス・サービス・インタフェースを使用することをお薦めします。問合せ処理に関係するサービスにはシングルトン・サービスを挿入できません。一般的には、すべての仲介サービス、およびプロバイダ・アプリケーションによって公開されたサービスに対して、リクエスト/レスポンス・ベース(双方向操作)のインタフェースを実装することをお薦めします。初期コール元を除くすべてのサービスで2つの一方向リクエストを実装するような設計が技術的に可能であっても、回避できる場合はこの実装テクニックを使用しないでください。
状態情報(デハイドレーション)または監査詳細が、いずれかの仲介サービスまたは最終サービス・プロバイダによって永続的に確保されることがない実装を目指してください。これらのテクニックは、待機を可能なかぎり短くするのに役立ちます。
また、SOAPドキュメントのマーシャリングおよびアンマーシャリングによって通常発生するオーバーヘッドを解消するために、仲介サービスを同一の場所に配置することをお薦めします。
図18-1に、リクエスタ・アプリケーションによって、エンタープライズ・ビジネス・サービス(EBS)として実装されたタスクが同期的に呼び出される様子を示します。
図18-1 リクエスタ・アプリケーションによるEBSの同期呼出し
影響
サービス・プロバイダからのレスポンスが送信元システムまたはユーザーに返るまで、すべてのリソースがロックされます。
いずれかのサービスまたは参加アプリケーションで処理に時間がかかる場合は、トランザクション・タイムアウトまたは長時間の待機になる可能性があります。
サービス・プロバイダが常に対応可能で、サービス・リクエストの遂行準備が整っている必要があります。
サービス・プロバイダがレスポンス・メッセージを生成するために複数のバックエンド・システムからデータのリアルタイム取得および照合を実行すると、全体としてリソースに大きな犠牲が生じたり、待機時間が増加する可能性があります。同期リクエスト/レスポンス設計パターンは、複雑なリアルタイム処理を伴うタスクの実装には使用しないでください。負荷のかからない処理を実行する必要があります。リアルタイム処理を可能なかぎり軽量化できるように、ある程度準備されたデータのステージングに対応するように設計を変更する必要があります。
同期リクエスト/レスポンス・パターンに関係するサービスでは、リクエスト・メッセージに存在する繰返し可能な各子ノードに対する処理の実行を抑制してください。本番環境のペイロードに多数の子ノードがあると、システムに悪影響を与える可能性があります。
問題
リクエスタ・アプリケーションは、タスクを実行する必要があるサービス・プロバイダが即時に対応可能な状態かどうかに関係なく、リクエストの発行後にその処理を続行できる必要があります。さらに、リクエストを開始するユーザーには、リクエストが完全に処理されるまで待機する必要性は機能的にもありません。つまり、サービス・リクエスタおよびサービス・プロバイダには、相互に直接依存せずに独自のペースで提供するメッセージを作成および使用する機能が必要です。
また、コンポジット・ビジネス・プロセスでは、参加アプリケーションまたはAIA機能プロセス・フローに依存せずに、分離された方法でエラー処理サービスやビジネス・アクティビティ監視サービスなどのインフラストラクチャ・サービスをサポートできる必要があります。
たとえば、注文獲得アプリケーションでは、注文履行システムなどのバックエンド・システムがその時点で使用可能かどうかに関係なく、注文に対応できる必要があります。注文履行プロセスの実行に参加しているなんらかのサービスまたはアプリケーションが有効な状態でないために、注文獲得機能が停止することは望まれません。
ソリューション
データベースまたはファイルを永続ストアとして設定したキューイング・テクノロジを使用するファイア・アンド・フォーゲット・パターンによって、参加アプリケーションを統合レイヤーから分離することをお薦めします。キューは、リクエスタ・アプリケーションがリクエスト・メッセージを配置できるステージング領域として機能します。その後、サービス・プロバイダの処理準備が整っている場合は、リクエスト・メッセージをサービス・プロバイダにリクエスタにかわって転送します。
リクエスト・メッセージをキューにエンキューする場合は、その処理を実行するリクエスタ・アプリケーションによって開始された同じトランザクション内で実行することをお薦めします。これによって、リクエスト・メッセージは、参加アプリケーションのトランザクションが正常に実行された場合にのみ、キューにエンキューされるようになります。トランザクションが正常に実行されていない状況では、リクエスト・メッセージはエンキューされません。連続する2つのマイルストンの間にあるサービスよって、そのサービス自体が単一のグローバル・トランザクションに登録されることに注意してください。
メッセージの保証付き配信を確保するために、マイルストンが仲介信頼性アーティファクトとしてどのように使用されるかを理解するには、「保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装」を参照してください。
ビジネス・オブジェクトごとにキューを用意することをお薦めします。1つのビジネス・オブジェクトのリクエスタ・アプリケーションで発生するすべてのリクエストで同じキューを使用します。
図18-2に、ソース・アプリケーションを統合レイヤーから分離する際にJMSキューが使用される様子を示します。ソース・アプリケーションは、JMSキューにメッセージを発行し、統合レイヤーからのレスポンスを待機せずに、他の処理を続行します。
JMSキュー内のアプリケーションがメッセージの作成を続行している間、AIAコンポジット・ビジネス・プロセスは起動および実行されません。AIAコンポジット・ビジネス・プロセスが起動すると、メッセージの使用が開始され、メッセージが処理されます。
また、図18-2に、JMSキューを利用して主要なAIA機能フローから監視サービスを分離する方法を示します。すべてのAIAサービスおよび参加アプリケーションは、監視メッセージをキューに発行して、それがダウンストリーム・アプリケーションでどのように処理されるかについては関知しません。このパターンでは、サービスまたは参加アプリケーションはレスポンスを期待しません。同様に、AIAインフラストラクチャ・サービスは、コンポジット・ビジネス・プロセスからシステム・エラーまたはビジネス・エラーを取得してAIAエラー・トピックに公開し、これをエラー・ハンドリング・フレームワークが使用して、その後の処理(再発行、通知、ロギングなど)を実行します。
図18-2 キューイング・テクノロジを使用したファイア・アンド・フォーゲット・パターン
影響
デフォルトの実装には、メッセージの成功または失敗をリクエスタ・アプリケーションに通知するための固有のサポートはありません。ミドルウェア・システムには処理中メッセージ転送の流れを監視して管理する機能が用意されていますが、リクエスタ・アプリケーションが、プログラムによる通知の受信または論理的な逆処理を必要とするユースケースがあります。
このメッセージ交換パターンに対する補正ハンドラの実装方法の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」および「ABCSの作成」を参照してください。
問題
参加システムとそれらのシステムを統合するサービスが信頼性の低い形式で相互作用する場合、メッセージ配信は保証されません。
たとえば、注文獲得システムで、ビジネス・プロセスをトリガーする注文履行リクエストを発行し、リクエストを履行するために複数の異種システムによって提供される各サービスを順番に呼び出します。サービス・プロバイダのすべてが常に使用可能であることを期待するのは現実的ではありません。
ソリューション
マイルストンはメッセージのチェックポイントであり、この論理ポイントで特定量のビジネス機能が完了した後は、エンリッチしたメッセージが保持されるか、そのメッセージをエンドツーエンド・コンポジット・ビジネス・プロセスでさらに処理するように参加アプリケーションに発行されます。マイルストンは、その論理ポイントに対して実行されたビジネス・トランザクションをコミットし、AIAサービスおよび参加アプリケーションで使用されたリソースをリリースするのに役立ちます。
異種システムを統合してビジネス要件に取り組むために、コンポジット・ビジネス・プロセス、ビジネス・アクティビティ・サービスまたはデータ・サービスが設計および実装されたエンドツーエンド統合の適切な論理ポイントにマイルストンを導入することをお薦めします。マイルストンの実装には、データベースまたはファイルを永続ストアとするキューが使用されます。
図18-3に、簡単なユースケースのマイルストンを使用して、保証付き配信を確保する方法を示します。このユースケースでは、カスタマ・サービス担当がソース・アプリケーションで請求プロファイルを更新し、更新されたプロファイルがバックエンド請求システムに反映されます。
図18-3 マイルストンを使用した保証付き配信の確保
メッセージの保証付き配信を確保するために、ソース・アプリケーションがトランザクション・モードで請求プロファイル情報をマイルストン1 (JMSキュー)にプッシュことをお薦めします。このトランザクションは、AIAトランザクションの範囲外にあり、図には表示されていません。マイルストン1への請求プロファイル情報の格納後は、ターゲット・アプリケーションに対するメッセージの保証付き配信が確保されるため、ソース・アプリケーションのリソースをリリースできます。
実装サービスにはメッセージ・エンリッチメント・ロジックがあり(必要な場合)、エンタープライズ・ビジネス・サービス(EBS)は、エンリッチされたメッセージを適切なプロバイダまたはマイルストン2にルーティングします(実装サービスのエンリッチメントや処理の要件がないような、単純でわかりやすいユースケースの場合はオプション)。
エンリッチされたすべてのメッセージは、マイルストン2に転送されるか、修正処理または再発行のためにマイルストン1にロールバックされます。そのためには、マイルストン1とマイルストン2の間にあるすべてのサービスが、単一のグローバル・トランザクションに含まれている必要があります。メッセージがマイルストン2に転送された後、マイルストン1のすべての実装サービス・インスタンスがリリースされ、新規リクエストに対応できるようになります。
プロバイダ実装サービスが請求プロファイル情報を取得し、ターゲット・アプリケーションへのメッセージの配信を確保します。ターゲット・アプリケーションは、マイルストン2とマイルストン3の間のトランザクションへの参加機能に対応している場合も未対応の場合もあるため、補正トランザクションを処理するように実装サービスを設計する必要があります。
ターゲット・アプリケーションでXA機能を作成して、保証付き配信を確保することをお薦めします。ターゲット・アプリケーションにXA機能がない場合は、AIAに付属のビジネス・メッセージに対するターゲット・システムの確認機能に基づいて、手動補正または半自動/自動補正するように実装サービスを設計する必要があります。
図18-4に、ソース・システムがAIAに注文プロビジョニング・リクエストを発行する複雑なユースケースで、保証付き配信を確保するためのマイルストンの使用方法を示します。
図18-4 複雑なユースケースで保証付き配信を確保するためのマイルストンの使用
影響
マイルストンを導入すると、処理オーバーヘッドが加わり、コンポジット・ビジネス・プロセス、ビジネス・アクティビティ・サービスまたはデータ・サービスのパフォーマンスに影響する可能性があります。したがって、マイルストンの数は設計者にとって課題です。しかし、マイルストンを最小にすると、結果的に多くの処理が単一のトランザクションに追加されて悪影響を与える可能性もあります。
保証付き配信を実現するために「マイルストン」間と「アプリケーションとマイルストン」間に信頼できるメッセージングを確保することで、トランザクション・オーバーヘッドは増加します。場合によっては実行時のパフォーマンスに影響する可能性があり(2つのマイルストン間で実行する処理量が非常に多い場合)、補正のための別途のプロセス設計要件が必要になる可能性もあります。
問題
リクエスタ・アプリケーションから特定のターゲット・システムに情報を送信する必要がある場合は、密接に結合されたサービスをリクエスタ・アプリケーションで作成する必要があります。サービス・プロバイダと、場合によってはサービス・プロバイダ・インスタンス(同じプロバイダに対して複数のアプリケーション・インスタンスがある場合)を識別するためのロジックを、コール元サービスのロジックに埋め込む必要があります。新しいサービス・プロバイダがその集合に追加されたり、既存のサービス・プロバイダが集合から撤退されるかぎり、コール元サービスの判断ロジックは常に変更に対応する必要があります。
たとえば、ある顧客に3つの請求システムが実装されており、2つはベンダーAの請求システムに対する2つのインスタンス(北米に居住する顧客専用のインスタンスとアジア太平洋に居住する顧客専用のインスタンス)、もう1つは世界の他の地域に居住する顧客専用のベンダーBの請求システムのインスタンスであるとします。リクエスタ・サービスには、リクエストの委託先を判別するための判断ロジックが必要です。
ソリューション
このメッセージをさらに処理してターゲット・アプリケーションに送信するには、コンテンツ・ベースのサービス・ルーティングで、適切なターゲット・サービスの実装にルーティングすることをお薦めします。実際のリクエスト・アプリケーションまたはサービスから適切なサービス・プロバイダを判断するために、判断ロジックを外部化することをお薦めします。この判断ロジックは、ルーティング・サービスに組み込まれています。これによって、不測の状況が発生した場合にメッセージの経路を宣言的に変更できます。エンタープライズ・ビジネス・サービスがルーティング・サービスとして機能します。これによって、コンテンツ・ベースのフィルタ処理に基づく1対多のメッセージ・ルーティングが容易になります。リクエスタから発信されたメッセージは、ビジネス・ルールまたはコンテンツ・フィルタに基づいて、すべてのターゲット、一部のターゲットまたは単一のターゲットに配信されます。
ルーティング・サービスでは、ルールを評価して、特定のメッセージを処理するために使用する必要がある実際のサービス・プロバイダを把握します。このアプローチを使用することで、クライアントまたはサービス・リクエスタは実際のサービス・プロバイダを一切意識しません。同様に、基礎となるサービス・プロバイダはリクエストを作成したクライアント・アプリケーションには関知しません。これによって、実際のリクエスタ・サービスに変更を加えることなく、新規のプロバイダを導入し、既存のプロバイダを撤退できます。
図18-5に、ルーティング・サービスによるコンテキスト・ベース・ルーティングを使用して、2つのターゲット・アプリケーションのいずれか、または取引パートナ(B2B)にReq Impl Service (リクエスタ・サービス)を送信することで、リクエストを送信する様子を示します。
図18-5 コンテンツ・ベースのサービス・インスタンスのルーティング
影響
実際のサービス・プロバイダと緩やかに結合されたリクエスタ・サービスの場合は、ルーティング・サービスが抽象レイヤーとして機能する必要があるため、そのサービス・インタフェースを慎重に設計する必要があります。一意のサービス・プロバイダが1つのみ存在するか、正規のインタフェースを使用できる場合、そのインタフェースで実際のサービス・プロバイダのインタフェースをエミュレートできます。
メディエータのテクノロジによって、ルーティング・ルールを宣言的な方法で追加できるとしても、本番環境にデプロイする前に、異なるルーティング・パスの妥当性をテストする必要があります。
判断ロジックを各ルーティング・サービスでローカルに管理することは重複や競合の原因になるため、Oracleビジネス・ルール・エンジンなどの一元化されたルール管理システムでの管理を考慮することは選択肢の1つです。
問題
リクエスタ・アプリケーションが、処理してターゲット・アプリケーションに送信する必要がある大量のビジネス・メッセージを作成する場合は、期待されるスループットに対応するようにすべてのメッセージを処理することが課題となります。各メッセージの処理に多数のシステムとの相互作用が必要で、その結果、処理の完了を待機して相当な時間ブロックされることになる場合は、さらに深刻です。
たとえば、注文獲得アプリケーションが、注文を履行するために注文処理キューに注文を発行します。各注文履行リクエストは、キューから取得して、分解するために注文編成エンジンに渡す必要があります。次のメッセージを注文処理キューから取得できるのは、確認時のみです。注文編成プラットフォームの機能が予定外に停止すると、注文履行リクエストが大量に蓄積され、プラットフォームが使用可能になったときも、これらのリクエストの一連の処理に非常に大きな遅延が発生する可能性があります。
ソリューション
ソース・キューに接続された複数のコンシューマまたはリスナーを設定することをお薦めします。AIAでは、リクエスタ・アプリケーションからソース・キューにメッセージが発行済であることが前提となります。
詳細は、「非同期ファイア・アンド・フォーゲット・パターン」を参照してください。
図18-6に、複数のリスナーがパラレルに複数のメッセージの使用をトリガーする設定を示します。単一のキューからメッセージを受信するために複数のコンシューマを作成したとしても(ポイントツーポイント・チャネル)、JMSによる配信時にメッセージを受信できるのは単一のコンシューマのみです。すべてのコンシューマが受信者であるために相互に競合するとしても、そのいずれかのコンシューマのみがメッセージを受信することになります。ビジネス要件に基づいて、このパターンは、HA環境の各ノード、拡張性を向上するためのクラスタ、またはAIAアーティファクト内の各コンシューマが設定されている複数のノードで使用できます。
図18-6 ソース・キューに接続された複数のコンシューマまたはリスナーの設定
影響
このソリューションはキューに対してのみ機能し、トピック(パブリッシュ/サブスクライブ・チャネル)では使用できません。トピックの場合、各コンシューマはメッセージのコピーを受信します。
複数のコンシューマがメッセージをパラレルに処理するため、メッセージは特定の順序では処理されません。機能上の理由で並列性および効率に支障を与えずに順番に処理する必要がある場合は、連続した配列を受信するまで、これらのメッセージを保持するステージング領域を導入する必要があり、その後、最終的な受信者に配信します。
問題
サービス・プロバイダによるリクエストの処理に長い時間が必要な場合は、どのようにすると、処理の全体にわたってリクエスタを一時停止モードにせずに、リクエスタが結果を受信できるかを考えてみます。
たとえば、注文獲得アプリケーションが、注文を履行するためのリクエストを発行します。注文履行プロセス自体は、必要なタスクの複雑度によって数分から数日かかります。注文獲得アプリケーションが履行リクエストの結果の把握を希望する場合も、結果を把握するために、プロセスが完了するまで無駄に待機するのは現実的ではありません。
ソリューション
非同期遅延/レスポンス・パターンを使用することをお薦めします。このパターンでは、リクエスタがリクエストを統合レイヤーに発行し、リクエスト・メッセージ(WSAヘッダー)にメタデータ・セクションを挿入することで、コールバック・レスポンス・アドレスを設定します。コールバック・レスポンス・アドレスは、完了後にサービス・プロバイダから連絡を受ける当初のコール元サービスのエンド・ポイントの場所を指します。最終的な受信者にメッセージが送信されるまでに複数の仲介サービスが関係するため、メッセージのメタデータ・セクションを使用したコールバック・アドレスの送信が必要になります。コールバック・アドレスに加え、リクエスタがレスポンス・メッセージを当初のリクエストに関連付けできるように、リクエスタには相関詳細を送信することが期待され、これによって、サービス・プロバイダが将来の対話でこの情報を送信できるようになります。
リクエスト/遅延レスポンス・パターンは実質的に非同期であるため、リクエスタはリクエスト・メッセージを送信した後、レスポンスを待機します。図18-7に示すように、このパターンを実装するフローでは、関係するサービスすべてに2つの一方向操作を確保することをお薦めします。レスポンス・メッセージを開始するには、個別のスレッドを呼び出す必要があります。プロバイダ参加アプリケーションからリプライを取得した後、AIAプロバイダ・サービスがメッセージを処理する場合は、レスポンスEBSを呼び出すことでレスポンス・スレッドを作成します。レスポンスEBSは、要求側アプリケーションが指定したコールバック・アドレスを呼び出すために、WSAヘッダーを使用して要求側サービスを識別し、レスポンスを処理します。EBSには、リクエスト送信用とレスポンス受信用の2つの一方向コールをサポートする1組の操作があります。操作は両方とも独立し、自立しています。相関メカニズムは、アプリケーションまたはコール元のコンテキストを設定する際に使用されます。
図18-7 非同期遅延/レスポンス・パターンの例
影響
プロバイダ・アプリケーションには、リクエスタ・アプリケーションから送信された相関詳細およびコールバック・アドレスを保持する機能が必要で、これらの詳細をレスポンス・メッセージに入力する必要があります。
問題
統合アーキテクトは、非同期リクエスト/レスポンス・パターンの実装を決定する前に、トランザクション要件、グローバル・トランザクションへの参加に対する参加アプリケーションの機能、およびマイルストンの概念を理解する必要があります。次の項では、3つの異なるシナリオについて実装ソリューションのガイドラインを示します。
ソリューション: 成功シナリオでは、エラー処理に対して同じリクエスタの別のサービスをコールします。
このソリューションでは相互作用が2つのトランザクションに分割され、つまり、エラー処理部分がリクエスタABCS実装から切り離されます。レスポンスEBSからエラー・メッセージを受け入れるために新しいサービスを作成し、エラー・レスポンス・サービスをソース参加アプリケーションに転送する必要があります。
図18-8に、リクエストが正常に処理された場合に、残りのプロセス・アクティビティを完了するためにリクエストがリクエスタABCSに戻される様子を示します。レスポンスの処理でエラーを検出した場合は、通常のエラー処理メカニズムに従って、ソース参加アプリケーションに通知が送信されます。エラーがコール元に返された場合、エラー・レスポンス・サービスへのWebサービス・コールは、リクエスタABCS実装のエラー処理ブロックで実行されます。
図18-8 エラー処理とリクエスタABCSの2つのトランザクションに分割された相互作用の例
ソリューション: マイルストンとしてのJMSキューの使用
このソリューションでは、相互作用が3つのトランザクションに分割されます。トランザクション境界を使用可能にするには、JMSキュー/マイルストンを使用する必要があります。図18-9に、エラーのシナリオを示します。成功のシナリオにJMS-2キューはありません。かわりに、プロバイダABCSがレスポンスEBSを直接呼び出します。したがって、成功シナリオでは、相互作用全体が2つのトランザクションで完了します。
図18-9 JMSキューをマイルストンとして使用している場合のエラー・シナリオ
ソリューション: パラレル・ルーティング・ルールおよびWebサービス・コールの使用
このソリューションでは、相互作用が3つのトランザクションに分割されます。図18-10に、エラーのシナリオを示します。トランザクション境界を使用可能にするには、メディエータ(EBS)のパラレル・ルーティング・ルールおよびレスポンスEBSへのプロバイダABCS参照からのWebサービス・コールを使用する必要があります。成功シナリオでは、最適化された参照コンポーネント・バインディングを使用してレスポンスEBSを直接コールします。そのため、成功の場合は2つのトランザクション境界のみがあります。
図18-10 パラレル・ルーティング・ルールおよびWebサービス・コールを使用したエラー・シナリオ
この項では、AIAでの冗長なデータ・モデル表現およびサービス・コントラクト表現の回避方法について説明します。
この項には次のトピックが含まれます:
問題
アプリケーションとAIAインタフェース間のサービス・コントラクトでは、冗長なデータ・モデル表現になる類似したビジネス・ドキュメントまたはデータ・セットを使用する必要があります。データ・モデルの変更は適用するのが非常に難しく、管理も困難です。
ソリューション
サービス・コントラクトまたは実装からデータ・モデルまたはスキーマを物理的に分離することをお薦めします。これらのスキーマは、設計または実行時に簡単に参照できる場所に一元化してください。
EBO (エンタープライズ・ビジネス・オブジェクト)、ABO (アプリケーション・ビジネス・オブジェクト)およびその他のユーティリティ・スキーマのすべてを中央の場所に体系化された方法で保持する必要があります。
様々な共通のビジネス・プロセスでEBOスキーマが使用されるように、正規データ・モデルを策定する前に綿密な分析を実行してください。
影響
データ・モデルまたはスキーマの変更は、複数の従属サービス・コントラクトに細かい変更の影響を与える可能性があるため、慎重に取り扱う必要があります。
バージョニング・ポリシーは明確に定義する必要があり、明確にしておかないと、わずかな変更のために冗長なサービス実装が生じる可能性があります。
共有データ・モデルまたは共通アセットの取扱いでは、管理が課題になります。
問題
サービス・コントラクトの粒度は、操作レベルまたはエンティティ・レベルになります。エンティティ・レベルの定義では、様々な操作を同じサービス・コントラクトに定義できますが、実装は操作レベルとなり、同じサービス・コントラクトを使用して複数の実装アーティファクトを作成することになります。これによって、様々な実装で冗長なサービス・コントラクト表現が発生します。
ソリューション
サービス・コントラクト(WSDL)を実装から物理的に分離することをお薦めします。これらのサービス・コントラクトは、設計または実行時に簡単に参照できる場所に一元化してください。
EBS (エンタープライズ・ビジネス・サービス)、ABCS (アプリケーション・ビジネス・コネクタ・サービス)およびその他のユーティリティ・サービス・コントラクトのすべてを中央の場所に体系化された方法で保持する必要があります。
影響
サービス・コントラクトの変更は、複数の従属サービスの実装に細かい変更の影響を与える可能性があるため、慎重に取り扱う必要があります。
共有サービス・コントラクトまたは共通アセットの取扱いでは、管理が課題になります。
この項では、AIAアセットの拡張性パターンについて説明し、AIAアーティファクトの拡張に関する問題とソリューションを示します。
この項には次のトピックが含まれます:
問題
付属のスキーマでは、一部の特定のビジネス操作には十分でない可能性があるため、安全なアップグレード手段で要素を既存のスキーマに追加できます。顧客固有の要素を既存のスキーマに単に追加するのみでは使用可能ではなく、スキーマ拡張モデルが必要です。
ソリューション
EBOまたはエンタープライズ・ビジネス・メッセージ(EBM)のスキーマを負担が少ない手段で拡張できるように、すべてのビジネス・コンポーネントに定義された複合タイプおよび各EBOまたはEBMスキーマにある共通コンポーネントの最後に、Customという拡張プレースホルダ要素があります。このカスタム要素のデータ・タイプは、カスタムEBOスキーマ・ファイルの顧客拡張を保持するために割り当てたスキーマ・モジュールに定義されます。
例18-1では、「スキーマA」の複合タイプの最後に追加されたカスタム要素がプレースホルダとして機能し、「カスタム・スキーマA」に追加された顧客拡張が取得されます。
ここでは、「スキーマA」はAIAComponents\EnterpriseObjectLibrary\Industry\Telco\EBO\ CustomerParty\V2\CustomerPartyEBO.xsdです。
例18-2に、「カスタム・スキーマA」に相当するAIAComponents\EnterpriseObjectLibrary\Industry\Telco\Custom\ EBO\CustomerParty\V2\CustomCustomerPartyEBO.xsdを示します。
例18-1 プレースホルダとして機能するカスタム要素
<xsd:complexType name="CustomerPartyAccountContactCreditCardType">
<xsd:sequence>
<xsd:element ref="corecom:Identification" minOccurs="0"/>
<xsd:element ref="corecom:CreditCard" minOccurs="0"/>
<xsd:element name="Custom"
type="corecustomerpartycust:CustomCustomerPartyAccountContactCreditCardType"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="actionCode" type="corecom:ActionCodeType"
use="optional"/>
</xsd:complexType>
例18-2 EBOまたはEBMスキーマへの拡張の追加
<!-- ================================================================== --> <!-- ============== CustomerParty Custom Components ================ --> <!-- ============================================================ --> <xsd:complexType name="CustomCustomerPartyAccountAttachmentType"/> <xsd:complexType name="CustomCustomerPartyAccountContactType"/> <xsd:complexType name="CustomCustomerPartyAccountContactCreditCardType"> <!-- CUSTOMERS CAN ADD EXTENSIONS HERE ...> </xsd:complexType> <xsd:complexType name="CustomCustomerPartyAccountContactUsageType"/>
問題
付属のサービスでは、一部の特定のビジネス機能に対応するには十分でない可能性があります。なんらかの検証ロジックの追加、サービスの既存のコンテンツのエンリッチ、または既存のサービス実装間へのなんらかの処理ロジックの追加の必要性が生じることがあります。アップグレード・プロセスでは既存のサービス・コードがアップグレードの一環として追加された新機能で上書きされるため、このロジックを既存のサービス・コードに追加すると、安全なアップグレードが保証されません。そのため、サービス拡張モデルが必要になります。
ソリューション
サービス実装時の論理ポイントで、様々な拡張ポイントを導入することをお薦めします。図18-11に、ABCSに4つの論理拡張ポイントが識別され、顧客固有の検証、コンテンツのエンリッチメントやメッセージの変更、および追加のロジックを実行するために、その拡張ポイントで指定のペイロードを組み込む実装の様子を示します。通常は、2つの前処理拡張ポイントと2つの後処理拡張ポイントが識別されます(前処理ABM、後処理ABM、前処理EBM、後処理EBM)。
拡張ポイントの数は、サービス実装およびそのサービスで使用されるメッセージ交換パターンのタイプに従って、4つより多いまたは少ない場合があります。
これらの拡張ポイントは、そのカスタム拡張ポイントを実装するかどうかに応じて使用可能または使用不可にできます。
図18-11 AIAサービスの拡張
問題
既存のスキーマとともに付属している変換では、一部の特定のビジネス操作には十分でない可能性があります。あるアプリケーションから別のアプリケーションに安全なアップグレード手段で情報を転送するには、要素を既存のスキーマに追加した後、新規に追加した要素の変換マップを追加します。顧客固有の変換を既存のXSLファイルに単に追加するのみでは使用可能ではなく、変換拡張モデルが必要です。
ソリューション
負担が少ない手段で変換を拡張するには、カスタムXSL変換に定義されたカスタム・テンプレートという各XSL変換ファイルに存在するすべてのビジネス・コンポーネント・マッピングに対して、コール・テンプレートを定義します。
例18-3は、顧客によって追加されたカスタム要素に対して新規の変換を追加する例です。
メインXSLマッピングXformListOfCmuAccsyncAccountIoToCreateCustomerPartyListEBM.xslでは、カスタムXSLファイルをインポートし、複合タイプまたはビジネス・コンポーネントごとに、拡張テンプレートに対するテンプレート・コール文があります。
例18-4に、テンプレートが定義されたカスタムXSLファイルを示します。このテンプレートを使用して、メインの変換でマップされない新規に追加されたカスタム要素または既存の要素についてカスタム・マッピングを追加できます。
例18-3 顧客が定義したカスタム要素に対する新しい変換の追加
<?xml version = '1.0' encoding = 'UTF-8'?>
..………………………………………..
xmlns:dvm="http://www.oracle.com/XSL/Transform/java/oracle.tip.dvm.LookupValue">
<xsl:import href="XformListOfCmuAccsyncAccountIoToCreateCustomerPartyListEBM_
Custom.xsl"/>
..………………………………………..
<xsl:value-of select="aia:getServiceProperty($ConfigServiceName,
'Routing.CustomerPartyEBS.CreateCustomerPartyList.CAVS.EndpointURI', false())"/>
</corecom:DefinitionID>
</xsl:if>
<xsl:call-template name="MessageProcessingInstructionType_ext">
<xsl:with-param name="currentNode" select="."/>
</xsl:call-template>
</corecom:MessageProcessingInstruction>
例18-4 カスタムXSLテンプレート定義
<!-- HEADER CUSTOMIZATION -->
<xsl:template name="MessageProcessingInstructionType_ext">
<xsl:template name="EBMHeaderType_ext">
<xsl:param name="currentNode"/>
<!-- Customers add transformations here -->
</xsl:template>
<xsl:param name="currentNode"/>
<!-- Customers add transformations here -->
</xsl:template>
<!-- DATA AREA CUSTOMIZATION -->
<xsl:template name="ContactType_ext">
<xsl:param name="currentNode"/>
<!-- Customers add transformations here -->
</xsl:template>
問題
付属のコンポジット・ビジネス・プロセスまたはエンタープライズ・ビジネス・フローでは、一部の特定のビジネス機能に対応するには十分でない可能性があります。追加の処理ステップ、メッセージの変更、または既存のコンポジット・ビジネス・プロセス実装間への処理ロジックの追加の必要性が生じることがあります。このロジックを既存のプロセス編成に追加すると、安全なアップグレードが保証されないため、プロセス拡張モデルが必要になります。
ソリューション
サービス実装時の論理ポイントで、拡張ポイントを導入することをお薦めします。コンポジット・ビジネス・プロセス(CBP)またはエンタープライズ・ビジネス・フロー(EBF)では、固定の論理拡張ポイントは識別されません。拡張ポイントの数は、ビジネス・プロセスの複雑性および実装でプロセスを処理するメッセージ・タイプの数で異なります。
CBPまたはEBF実装では、様々な論理ポイントの各メッセージに対して、1つの前処理拡張ポイントと1つの後処理拡張ポイントを保持することをお薦めします。拡張プロセスは常に、その拡張ポイントに対するリクエストおよびレスポンスに同じメッセージ・ペイロードを使用した同期プロセスである必要があります。
これらの拡張ポイントは、そのカスタム拡張ポイントを実装するかどうかに応じて使用可能または使用不可にできます。
