| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、AIA統合フローの作成方法について説明します。
この章の内容は次のとおりです。
AIAの開発とテストでは、開発環境およびテスト環境の設定でSOA SuiteのダウンロードとAIA環境の設定を行います。
AIA開発を開始するには、まずSOA Suite Quick Startをインストールして、SOAサーバーに接続します。
SOA Suite 12.1.3 Quick Startをダウンロードしてインストールします。
AIA開発用に設定されたSOA Suiteサーバーへの接続を作成し、Oracle Fusion Middlewareの設定後にこれらの詳細を使用してテストします。
接続名: <アプリケーションの接続名を指定>。
接続タイプ: デフォルト値のWebLogic 12.1.3を使用します。
WebLogicサーバーのユーザー名とパスワードを指定します。
WebLogicホスト名: <サーバーのホスト名>。
ポート: <サーバーのポート番号>。
SSLポート: <サーバーのSSLポート>。
WLSドメイン: <SOAサーバーがインストールされているドメイン名を指定>。
AIAワークステーションは、AIA開発を実行するために設定された専用システムです。このシステムにSOAコア拡張機能をインストールし、SOAコア拡張機能からAIAプロジェクト・ライフサイクル・ワークベンチを設定します。
この項には次のトピックが含まれます:
12.1.3 WebLogic ServerをOracle Application Development Frameworkとともにインストールします。
Oracle Databaseをインストールします。
SOA Suite Quick Startをインストールします。
OTN(http://www.oracle.com/technetwork/middleware/fusion-middleware/overview/index.html)で詳述されている、サポートされているシステム構成に準拠していることを確認します。
ハードウェアは、サポートされているオペレーティング・システムで、少なくとも4つのCPUと32GBのRAMが搭載されている必要があります。
Oracle Metadata Services (MDS)リポジトリには、WLS上のSOA Suiteなど、デプロイ済J2EEアプリケーションのメタデータが格納されます。
SOA用に特別に作成されたパーティションSOA-MDSの下に、すべてのSOAコンポジット(AIAコンポジットを含む)もデプロイメント時に格納されます。
同じパーティションの下に、$SOA_HOME/AIAMetaDataのコンテンツがSOA-MDS→apps/AIAMetaDataにアップロードされます。
メタデータの各セットのコンテンツと詳細、およびそのAIAによる使用方法を次に示します。また、新規コンテンツの作成または既存コンテンツの変更のプロセスについても説明します。
詳細は、OTNネットワークでSOAコア・コンポジット・アプリケーションの開発を参照してください。
注意:
新規の12c顧客は、ユーティリティ・オブジェクトを入手し、ライセンスの取得を選択した適切な事前作成済の統合を介してその他のオブジェクトを受け取ります。
AIAメタデータ($SOA_HOME/AIAMetaData)には次のコンテンツが含まれています。
AIAComponents - 様々なサービスによって参照される様々なスキーマおよびWSDLを提示します。構造は次のとおりです。
ApplicationConnectorServiceLibrary: 様々なアプリケーション・ビジネス・コネクタ・サービス(ABCS)の抽象WSDL
ApplicationObjectLibrary: アプリケーションによって公開されるサービスのWSDLおよびアプリケーション・ビジネス・オブジェクトのスキーマ
B2BObjectLibrary: 企業間(B2B)スキーマ
B2BServiceLibrary: 様々なB2Bコネクタ・サービス(B2BCS)およびB2Bインフラストラクチャ・サービスの抽象WSDL
BusinessProcessServiceLibrary: エンタープライズ・ビジネス・フロー(EBF)の抽象WSDL
EnterpriseBusinessServiceLibrary: エンタープライズ・ビジネス・サービス(EBS)の抽象WSDL
EnterpriseObjectLibrary: Oracle AIA標準モデルのスキーマ
ExtensionServiceLibrary: ミラー・サーブレットを指す具象WSDL
InfrastructureServiceLibrary: インフラストラクチャ・サービスの抽象WSDL
Transformations: 様々なサービス間で共有されるXSL
UtilityArtifacts: ユーティリティ・スキーマおよびWSDL
config: AIAConfigurationProperties.xmlおよびAIAEHNotification.xml
dvm: ドメイン値マップ
faultPolicies: すべてのサービスに適用可能なデフォルト・ポリシー
xref: 相互参照用のメタデータ
AIAコンポーネントは、実行時に様々なAIAアーティファクト間で共有されるスキーマ、WSDLおよびXSLで構成されます。これらの各ファイルの使用方法と目的は、このマニュアルのAIAアーティファクト固有の章で詳細に説明します。
AIAコンポーネントのフォルダ構造
様々なアプリケーション・コネクタ・サービスおよびアダプタ・サービスの抽象WSDLはすべて、ここに格納されます。従うフォルダ構造規則は、ApplicationConnectorServiceLibraryです。
AIAMetaData\AIAComponents\ApplicationConnectorServiceLibrary\<アプリケーション名>\<バージョン番号>\<サービス・タイプ>
<バージョン番号>に使用できる値は、V1、V2などです。
<サービス・タイプ>に使用できる値は、次のとおりです。
RequesterABCS
ProviderABCS
AdapterServices
<アプリケーション名>に使用できる値は、次のとおりです。
PeopleSoft
BRM
UCM
SAP
PIM
OracleRetail
Logistics
JDEE1
CRMOD
Agile
Ebiz
Siebel
注意:
ここで指定する<アプリケーション名>は、AIAプロジェクト・ライフサイクル・ワークベンチで、デプロイメントに対する部品構成表の定義で使用されます。これは、ワークベンチの<製品コード>値リストと一致する必要があります。
例:
AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/RequestorABCS
AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/ProviderABCS
ApplicationObjectLibrary
参加アプリケーションによって公開されるサービスのWSDLのすべて、および参照されるスキーマは、次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/ApplicationObjectLibrary
アプリケーションでは、AIAリクエスタ・サービスのWSDLが使用されます。参加アプリケーションでの変換が必要ないように、AIAリクエスタ・サービスのWSDLは、参加アプリケーションの外部向けビジネス・オブジェクト・スキーマを参照して開発されています。これらのスキーマも次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/ApplicationObjectLibrary
従うフォルダ構造規則は、次のとおりです。
ApplicationObjectLibrary/<アプリケーション名>/<バージョン番号>/schemas
ApplicationObjectLibrary/<アプリケーション名>/<バージョン番号>/wsdls
<アプリケーション名>および<バージョン番号>に使用できる値は、前述の項に記載されています。
注意:
ここで指定する<アプリケーション名>は、AIAプロジェクト・ライフサイクル・ワークベンチで、デプロイメントに対する部品構成表の定義で使用されます。
例:
AIAMetaData/AIAComponents/ApplicationObjectLibrary/Siebel/V1/schemas
AIAMetaData/AIAComponents/ApplicationObjectLibrary/Siebel/V1/wsdls
B2BServiceLibrary
B2Bコネクタ・サービス(B2BCS)の抽象WSDLはすべて、この場所に格納されます。
リクエスタB2BCSのWSDLは、$SOA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdlsの下に格納されます。
従うフォルダ構造規則は、B2BServiceLibrary/Connectors/wsdls/<B2B標準>/RequesterB2BCS/<コネクタ・バージョン>/*.wsdlです。
プロバイダB2BCSのWSDLは、$SOA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdlsの下に格納されます。
従うフォルダ構造規則は、B2BServiceLibrary/Connectors/wsdls/<B2B標準>/ProviderB2BCS/<コネクタ・バージョン>/*.wsdlです。
再使用可能なインフラストラクチャ・サービスのその他の抽象WSDLは、$SOA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Infrastructure/<サービス・バージョン>/の下に格納されます。
BusinessProcessServiceLibrary
コンポジット・ビジネス・プロセスおよびエンタープライズ・ビジネス・フローの抽象WSDLはすべて、次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/ BusinessProcessServiceLibrary
従うフォルダ構造規則は、次のとおりです。
BusinessProcessServiceLibrary/<サービス・タイプ>
<サービス・タイプ>に使用できる値は、CBPおよびEBFです。
例:
AIAMetaData/AIAComponents/BusinessProcessServiceLibrary/CBP
AIAMetaData/AIAComponents/BusinessProcessServiceLibrary/EBF
EnterpriseBusinessServiceLibrary
Oracle AIA標準モデルの一部
エンタープライズ・ビジネス・サービスの抽象WSDLはすべて、次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary
EnterpriseObjectLibrary
Oracle AIA標準モデルの一部
エンタープライズ・オブジェクト・ライブラリのスキーマ・モジュールはすべて、次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary
ExtensionServiceLibrary
ミラー・サーブレットを指す具象WSDLはすべて、次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/ExtensionServiceLibrary
従うフォルダ構造規則は、次のとおりです。
ExtensionServiceLibrary/<アプリケーション名>
<アプリケーション名>に指定できる値は、例の項に記載されています。
注意:
ここで指定する<アプリケーション名>は、AIAプロジェクト・ライフサイクル・ワークベンチで、デプロイメントに対する部品構成表の定義で使用されます。
例:
AIAMetaData/AIAComponents/ExtensionServiceLibrary/Siebel InfrastructureServiceLibrary
インフラストラクチャ・サービスの抽象WSDLはすべて、次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/InfrastructureServiceLibrary
従うフォルダ構造規則は、次のとおりです。
InfrastructureServiceLibrary/<バージョン番号>
例:
AIAMetaData/AIAComponents/InfrastructureServiceLibrary/V1
Transformations
様々なAIAサービス間で共有されるXSLはすべて、次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/Transformations
従うフォルダ構造規則は、次のとおりです。
Transformations/<アプリケーション名>/<バージョン>
<アプリケーション名>および<バージョン番号>に使用できる値は、次の項に記載します。
注意:
ここで指定する<アプリケーション名>は、AIAプロジェクト・ライフサイクル・ワークベンチで、デプロイメントに対する部品構成表の定義で使用されます。
例:
AIAMetaData/AIAComponents/Transformations/Siebel/V1
UtilityArtifacts
ユーティリティ・スキーマおよびWSDLはすべて、次の場所に格納されます。
$SOA_HOME/AIAMetaData/AIAComponents/UtilityArtifacts
従うフォルダ構造規則は、次のとおりです。
UtilityArtifacts/schemas
UtilityArtifacts/wsdls
既存ファイルを変更する手順は、次のとおりです。
ファイルを作成する手順は、次のとおりです。
AIAコンポーネント・フォルダのファイルへのアクセス
次のプロトコルを使用して、設計時および実行時に、すべてのAIAサービス・アーティファクトからAIAコンテンツにアクセスします。
oramds:/apps/AIAMetaData/AIAComponents/<リソース・パス名>
例:
oramds:/apps/AIAMetaData/AIAComponents/ApplicationObjectLibrary/SampleSEBL/schemas/CmuAccsyncAccountIo.xsd
注意:
AIAコンポーネント・フォルダのすべてのファイルで、AIAコンポーネント・フォルダの他のファイルを参照するために、必要に応じて相対パスが使用されます。
エンタープライズ・ビジネス・サービス・ライブラリのWSDLでは、エンタープライズ・オブジェクト・ライブラリのスキーマを参照するために相対パスが使用されます。
AIAでは、システムのランタイム動作、インフラストラクチャ・コンポーネントおよびサービスに影響を与える外部構成プロパティが提供されます。これらのプロパティは、AIAConfigurationProperties.xmlのシステム、モジュールおよびサービスのレベルで、名前と値のペアとして提供されます。
AIAConfigurationProperties.xmlでは、2つの構成タイプがサポートされます。
モジュール・レベルを含むシステム・レベル
システムレベルの構成の名前と値のペア、およびシステム・レベル内のモジュールレベルの構成の名前と値のペアが含まれます。
サービス・レベル
サービス固有の構成の名前と値のペアが含まれます。
次のXPath関数は、AIAConfigurationProperties.xmlにある構成の名前と値のペアにアクセスするために提供されています。
aiacfg:getSystemProperty (文字列のpropertyName, ブール値のneedAnException)では、propertyValueが文字列で返されます
aiacfg:getSystemModuleProperty (文字列のmoduleName, 文字列のpropertyName, ブール値のneedAnException)では、propertyValueが文字列で返されます
aiacfg:getServiceProperty (文字列のEBOName, 文字列のserviceName, 文字列のpropertyName, ブール値のneedAnException)では、propertyValueが文字列で返されます
getSystemModuleProperty()およびgetServiceProperty()関数では、最初に適切なモジュール・プロパティとサービス・プロパティが検索され、見つからない場合は、同じプロパティ名のシステム・プロパティが検索されます。
3つの関数すべてで、一致するプロパティが見つからない場合、結果はneedAnException引数の値に依存します。needAnExceptionがtrueの場合は、PropertyNotFound例外がスローされ、それ以外の場合は空の文字列が返されます。
新規プロパティをAIAConfigurationProperties.xmlに追加する手順は、次のとおりです。
このファイルは、エラー処理フレームワークの一部として送信される電子メール通知のテンプレートです。
AIAEHNotification.xmlを変更する手順は、次のとおりです。
ドメイン値マップ・ユーティリティは、Oracle SOA Suiteの機能です。静的な値マップの作成がサポートされ、カスタムXPath関数が提供されます。
dvm:lookupValue("oramds:/apps/AIAMetaData/dvm/<DVM Map Name>",<Source Column>,<Source Column Value>,<Target Column>,"")
DVMの詳細は、「DVMおよび相互参照の使用」を参照してください。
DVMは、AIAの事前作成済の統合すべてで使用され、SOAコア拡張機能の一部として同梱されています。これらは$SOA_HOME/AIAMetaData/dvmに格納されます。
ドメイン値マップを変更する手順は、次のとおりです。
相互参照ユーティリティは、Oracle SOA Suiteの機能です。動的な値の作成がサポートされます。
相互参照の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の相互参照の操作に関する項を参照してください。
すべてのAIAプロセス統合パックによって使用される相互参照のメタ情報は、SOAコア拡張機能の一部として同梱されており、$SOA_HOME/AIAMetaData/xrefに格納されます。
相互参照メタデータを変更する手順は、次のとおりです。
デフォルトのフォルト・ポリシー・ファイルであるfault-bindings.xmlは、SOAコア拡張機能の一部として同梱されており、$SOA_HOME/AIAMetaData/faultPolicies/V1に格納されます。
fault-bindings.xmlを変更する手順は、次のとおりです。
注意:
この手順は、ファイルがMDSに追加されるたびに繰り返します。
SOA-MDS→apps/AIAMetaDataを更新する手順は、次のとおりです。
$SOA_HOME/aia_instances/$INSTANCE_NAME/binにあるフォルダを参照します。
次のコマンドを実行して、aiaenv.shファイルをソースとして指定します。
source aiaenv.sh
$SOA_HOME/aia_instances/$INSTANCE_NAME/configにあるフォルダを参照して、デプロイメント計画ファイルであるUpdateMetaDataDP.xmlを開きます。
MDSに追加する各リソース・グループに対してincludeタグを挿入して、UpdateMetaDataDP.xmlファイルを更新します。
AIAMetaDataの下にあるすべてのファイルをアップロードするには、次を追加します。
<include name ="**"/>
AIAComponents/ApplicationObjectLibrary/SEBL/schemasフォルダにコピーされたファイルをアップロードするには、次を追加します。
<include name ="AIAComponents/ApplicationObjectLibrary/SEBL/schemas/**"/>
注意:
includeタグでは、フォルダ・パスはAIAMetaDataフォルダと相対的である必要があります。
SOA_HOME/Infrastructure/Install/configを参照します。コマンドを入力して、UpdateMetaData.xmlスクリプトを実行します。
ant -f UpdateMetaData.xml
注意:
メタデータは、SOAコア拡張機能をアンインストールすると削除されます。SOAコア拡張機能のアンインストール後にMDSを消去する方法の具体的な指示は、Oracle Application Integration Architecture Foundation Packインストレーションおよびアップグレード・ガイドのMDSの消去に関する項を参照してください。
AIAアーキテクチャでは、統合フローでのメッセージのフライトを可能にするために、様々な統合スタイルおよびAIAパターンが推奨されています。
AIA実装チームは、次の点を評価して、様々なAIAアーティファクトを作成する際に従う統合スタイルと手法を選択する必要があります。
ビジネス・シナリオ - 機能設計ドキュメント(FDD)によってビジネス・シナリオが記述され、次が提供されます。
ビジネス・ケースの詳細な説明。
多数の異なるアクターによる想定アクションを含む例外ケースなど、様々な使用シナリオを詳細に説明する各種ユースケース。
すべての参加アプリケーションに関する詳細 - 商用、バージョン付き既製品および自社作成。
トリガー・ビジネス・イベントに関する詳細。
機能フローに関する詳細。
パフォーマンスおよびスケーラビリティ要件に関する詳細。
使用するビジネス・オブジェクトに関する詳細。
様々なビジネス・オブジェクトに対して実行するアクション。
利用するOracleのツールおよびテクノロジ。
アプリケーションまたは機能間のコラボレーションに必要なAIAアーティファクトは、統合フローに採用した統合スタイルに依存します。これらのアーティファクトには、ABCS、EBS、EBF、CBPおよび様々なアダプタ・サービスが含まれます。
AIAプロジェクト・ライフサイクル・ワークベンチは、設計、開発、テスト、パッケージ化および配信するすべてのアーティファクトの定義を含む、AIAプロジェクトの定義に使用されます。
このスタイルでは、メッセージは、リクエスタ・アプリケーションから提供側アプリケーションに送信されます。接続性のモードは、SOAP/HTTP、キュー、トピックまたはネイティブ・アダプタです。
この統合にミドルウェアは含まれません。
リクエスタ・アプリケーションは、プロバイダ・アプリケーションとの接続を確立する必要があります。リクエスタ・アプリケーションは、プロバイダのAPIで指定された書式でリクエストを送信し、プロバイダが送信するレスポンスを解釈する必要があります。リクエスタ・アプリケーションとプロバイダ・アプリケーションで、リクエストの認証および認可が実行されます。
統合フローは、直接相互作用する個々のアプリケーション機能で構成されます。この相互作用を可能にするために必要なすべての機能が、個々のアプリケーションで使用可能であるかまたは使用可能にする必要があります。
図2-1は、リクエスタ・アプリケーションがプロバイダ・アプリケーションと直接相互作用する方法を示しています。
図2-1 プロバイダ・アプリケーションと直接相互作用するリクエスタ・アプリケーションの例
さらに複雑な状況では、統合フローが複数アプリケーションとの相互作用を含む複数のステップで構成されている場合は、1つ以上のアプリケーションでワークフローに似た機能が利用されます。
このケースでは、AIAアーティファクトは作成されません。アプリケーション間の直接接続を確立します。
接続の様々なモードの詳細は、「リソース接続の確立」を参照してください。
統合フレームワークを備えたすべての統合スタイルで、ミドルウェア・テクノロジが利用されます。アプリケーションによってメッセージがミドルウェアにプッシュされ、ミドルウェアによってそのメッセージがターゲット・アプリケーションにプッシュされます。
これらの統合スタイルに統合フレームワークがあります。
プロバイダ・サービスを利用する統合フロー
標準モデルベースの仮想化を含むプロバイダ・サービスを利用する統合フロー
統合フレームワークを備えた任意の統合スタイルで統合フローを実装するために必要なAIAサービス・アーティファクトは、次に依存します。
データ交換の複雑さ
処理ロジックなし
処理ロジックあり
メッセージ交換パターン
同期リクエスト/レスポンス
非同期の一方向(ファイア・アンド・フォーゲット) - 保証付き配信の想定の必要性あり
非同期リクエスト/遅延レスポンス - 保証付き配信およびレスポンスの相関の想定の必要性あり
これらのAIAサービス・アーティファクトは、AIAアーキテクチャで定義されます。
CBP
EBS
EBF
ABCS
アダプタ・サービス
JMSプロデューサとJMSコンシューマ
JCAアダプタ・サービス
様々なメッセージ交換パターンの詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」および「AIA設計パターンの使用」を参照してください。
様々なAIAサービス・アーティファクトとこれらの実装に使用されるOracle SOA Suiteコンポーネントの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドを参照してください。
注意:
次の各項では、統合フレームワークを備えた統合スタイルごとに、状況の組合せに対して開発するAIAアーティファクトが推奨されます。
リクエスタ・アプリケーションによって、ミドルウェアで単一のAIAサービスが呼び出されます。リクエスタ・アプリケーションによって提示されるリクエストは、プロバイダ・アプリケーションで適切なAPIを呼び出すことによってAIAサービスで履行されます。AIAサービスでは、リクエスタ・アプリケーションの書式でメッセージを受け入れることができます。AIAサービスでは、プロバイダのAPIで指定された書式で、リクエストがプロバイダ・アプリケーションに提示されます。AIAサービスでは、必要に応じて、プロバイダ・アプリケーションの書式でレスポンスが受け入れられます。AIAサービスで、リクエストの認証および認可が実行されます。
統合フローは、すべての参加アプリケーションとの相互作用をすべて管理する、ミドルウェアにデプロイされたこの単一のAIAサービス・アーティファクトで構成されます。
図2-2は、ミドルウェアにデプロイされたサービスによって、リクエスタ・アプリケーションとプロバイダ・アプリケーション間の統合を可能にする方法を示しています。
図2-2 ネイティブ・アプリケーション・サービスを使用した統合フローの例
統合フローが複数アプリケーションとの相互作用を含む複数のステップで構成されているさらに複雑な状況の場合、AIAサービスでは、ワークフローに似た機能が実装され、すべての参加アプリケーションとの相互作用がすべて管理されます。
開発するAIAサービス・アーティファクトは、データ交換の複雑さおよび様々なメッセージ交換パターンに依存します。
表2-1に、状況の組合せに対して適切なAIAアーティファクトを示します。
表2-1 リクエスタ・アプリケーション・サービスを使用した統合フローに対するAIAアーティファクト
| メッセージ・パターン | 処理ロジックなし | 処理ロジックあり |
|---|---|---|
同期リクエスト/レスポンス |
EBS |
EBF |
非同期の一方向 |
EBS |
EBF |
非同期リクエスト/遅延レスポンス |
EBS - リクエスト EBS - レスポンス |
EBF |
1つ以上のAPIを利用するプロバイダ・アプリケーションの粒度が粗い機能を公開する、プロバイダ・アプリケーション固有のAIAサービスは、適切なプロバイダ・アプリケーション固有のインタフェースを使用して作成されます。複数のビジネス・イニシエータがこのAIAサービスを呼び出すことができます。ビジネス・イニシエータがプロバイダ・アプリケーション固有のAIAサービスによって理解される書式でリクエストを提示できない場合は、ビジネス・イニシエータのリクエストをプロバイダ・アプリケーションの書式に変換するために、リクエスタ・アプリケーション固有のAIAサービスが使用されます。リクエスタ・アプリケーション固有のAIAサービスで、リクエストの認証および認可が実行されます。プロバイダ・アプリケーション固有のAIAサービスでは、リクエストの認証および認可情報がプロバイダ・アプリケーションに伝播されます。
統合フローは、すべてのプロバイダ・アプリケーション固有のAIAサービスとの相互作用をすべて管理する、ミドルウェアにデプロイされたリクエスタ・アプリケーション固有のAIAサービスで構成されます。
図2-3は、ミドルウェアにデプロイされたサービスによって、リクエスタ・アプリケーションとプロバイダ・アプリケーション間の統合を可能にする方法を示しています。
図2-3 プロバイダ・サービスを利用する統合フローの例
統合フローに複数アプリケーションとの相互作用が含まれているさらに複雑な状況の場合、リクエスタ・アプリケーション固有のAIAサービスによって、ワークフローに似た機能が実装され、すべてのプロバイダ・アプリケーション固有のAIAサービスとの相互作用がすべて管理されます。
開発するAIAサービス・アーティファクトは、データ交換の複雑さおよび様々なメッセージ交換パターンに依存します。
表2-2に、状況の組合せに対して適切なAIAアーティファクトを示します。
表2-2 プロバイダ・サービスを利用するためのAIAアーティファクト
| メッセージ・パターン | 処理ロジックなし | 処理ロジックあり |
|---|---|---|
同期リクエスト/レスポンス |
リクエスタABCS プロバイダABCS |
リクエスタABCS プロバイダABCS |
非同期の一方向 |
リクエスタABCS プロバイダABCS |
リクエスタABCS プロバイダABCS |
非同期リクエスト/遅延レスポンス |
リクエスタABCS プロバイダABCS |
リクエスタABCS プロバイダABCS |
標準(アプリケーション非依存)モデルを介した疎結合は、真のSOAを表すものです。疎結合された統合の参加アプリケーションは、仮想レイヤーを介して通信します。データ・モデル間の直接マッピングのかわりに、標準データ・モデルにマップするために変換が使用されます。この結果、再利用性が向上しますが、変換によって、メッセージ・サイズが増加するのみでなく、より多くのコンピューティング・リソースも消費されます。機能統合に関しては、獲得する再利用性は多少の諸経費をかける価値があるため、この統合パターンが最善です。
この場合、エンタープライズ・ビジネス・オブジェクト(EBO)とエンタープライズ・ビジネス・メッセージ(EBM)に基づいたEBSが、メディエータ・サービスとして作成されます。
1つ以上のAPIを利用するプロバイダ・アプリケーションの粒度が粗い機能を公開するプロバイダ・サービスは、EBS操作インタフェースと同じEBMインタフェースを使用して作成されます。
ビジネス・イニシエータがEBS操作インタフェースによって理解される書式でリクエストを提示できない場合は、ビジネス・イニシエータのリクエストをプロバイダ・サービスの書式に変換するために、リクエスタ・サービスが使用されます。
図2-4に、ソース・アプリケーションによって送信されたリクエストが、EBSおよび一連の仲介サービスを使用してターゲット・アプリケーションでどのように処理されるかを示します。リクエストおよびプロバイダのトランスポート・サービスはオプションであり、非SOAPベースのトランスポートの場合にのみ必要です。
図2-4 標準モデルベースの仮想化を示す例
統合フローに複数アプリケーションとの相互作用が含まれているさらに複雑な状況の場合、リクエスタ・アプリケーション固有のAIAサービスによって、そのリクエストはメディエータAIAサービスに提示されます。メディエータAIAサービスによってAIAサービスがトリガーされ、AIAサービスでは、ワークフローに似た機能が実装され、メディエータAIAサービスを介して、すべてのプロバイダ・アプリケーション固有のAIAサービスとの相互作用がすべて管理されます。この場合、選択したメディエータAIAサービス・インタフェースは、共通インタフェースとして受け入れられると想定されています。このように、すべてのリクエスタ・アプリケーション固有のAIAサービスによってこのメディエータAIAサービスが呼び出され、すべてのプロバイダ・アプリケーション固有のAIAサービスによってこの共通インタフェースが実装されます。開発するAIAサービス・アーティファクトは、データ交換の複雑さおよび様々なメッセージ交換パターンに依存します。
表2-3に、状況の組合せに対して適切なAIAアーティファクトを示します。
表2-3 複数のアプリケーション相互作用を含む統合フローに対するAIAアーティファクト
| メッセージ・パターン | 処理ロジックなし | 処理ロジックあり |
|---|---|---|
同期リクエスト/レスポンス |
リクエスタABCS EBS プロバイダABCS |
リクエスタABCS EBS プロバイダABCS |
非同期の一方向 |
リクエスタABCS EBS プロバイダABCS |
CBP リクエスタABCS EBS EBF プロバイダABCS |
非同期リクエスト/遅延レスポンス |
リクエスタABCS EBS プロバイダABCS |
CBP リクエスタABCS EBS EBF プロバイダABCS |
バルク・データ処理には、離散レコードまたは非常に大きいデータを含むレコードの大規模バッチが含まれます。手法は、パフォーマンスの高いデータ移動に特殊化したポイントツーポイント統合ですが、再利用性とのトレードオフがあります。
バルク・データ処理は、複数アプリケーション間でレプリケートされる永続データを対象とします。統合は、4つのスタイルに分類されます。
初期データ・ロード
Xref表ありの大規模トランザクション
断続的な大規模トランザクション
Xref表なしの大規模トランザクション
AIAを使用したバルク・データ処理の使用方法の詳細は、「バルク処理に対するOracle Data Integratorの使用」を参照してください。
AIA実装では、それぞれ異なる統合スタイルに準拠する様々な統合フローが共存します。統合フローは、必要なビジネス機能を配信するためにデプロイされたAIAサービスによるメッセージの処理を表します。
統合スタイルの選択は、AIAサービスの設計に影響を与えます。反対に、AIAサービスの設計に関する決定によって特定の統合スタイルが選択されます。
AIAサービス設計の様々な側面を次に示します。
サービスの粒度
サービスで実装する機能を、ビジネス・アクティビティまたはタスクに必要なビジネス・ロジック(ビジネス・プロセス分析の結果)、あるいはプロバイダ・アプリケーションによって公開される機能に基づいて決定します。
サービスの粒度は、ビジネス・ロジックがビジネス・アクティビティまたはタスクの要件(AIA参照プロセス・モデルのビジネス・プロセス分析の結果)に準拠している場合は、粒度が粗くなります。この場合、サービスは、プロバイダ・アプリケーションの複数の低APIを呼び出すことによって実装されます。
サービスの粒度は、ビジネス・ロジックがプロバイダ・アプリケーションによって公開される低レベル機能に準拠する場合は、細かくなります。
サービスの再利用性
サービスの再利用は、その設計がモジュール型で、様々なビジネス・ユースケースの要件に対して作成されている場合は、異なる統合フローに対して高くなります。ビジネス・アクティビティまたはタスクの要件(AIA参照プロセス・モデルのビジネス・プロセス分析の結果)に準拠すると、モジュール型設計になります。
サービスが特定のビジネス・ユースケースの要件を満たすように作成された場合、ロジックは一体型となり、再利用は低くなります。
サービスの仮想化
この側面では、関心の分離、およびリクエスタ・アプリケーションとプロバイダ・アプリケーションの変更からの独立が提供されます。選択肢は、「はい」または「いいえ」です。
サービスの相互運用性
様々なサービス実装を相互運用する機能は、WS-I標準、一般的なメッセージ・メタ・モデル、および堅牢なバージョニング戦略に準拠しているかどうかに依存します。AIAのEBSのWSDLおよびAIAのEBOとEBMでは、この機能が配信時に提供されます。その他については、相互運用性を保証するには、特別な作業が必要です。
表2-4に、様々な統合スタイルに対する粒度、再利用性、仮想化および相互運用性を要約します。
表2-4 AIAサービス設計の要約
| 統合スタイル | 粒度 | 再利用性 | 仮想化 | 相互運用性 |
|---|---|---|---|---|
ネイティブ・アプリケーションAPIを使用した統合フロー |
ミドルウェア上にAIAサービスなし、アプリケーション間の直接の相互作用 |
ミドルウェア上にAIAサービスなし、アプリケーション間の直接の相互作用 |
ミドルウェア上にAIAサービスなし、アプリケーション間の直接の相互作用 |
ミドルウェア上にAIAサービスなし、アプリケーション間の直接の相互作用 |
リクエスタ・アプリケーション・サービスを使用した統合フロー |
粒度が粗い(高パフォーマンスのオーバーヘッドを伴う) |
低 |
いいえ |
特別な作業 |
プロバイダ・サービスを利用する統合フロー |
細かい |
高 |
いいえ |
特別な作業 |
標準モデルベースの仮想化を含むプロバイダ・サービスを利用する統合フロー |
粒度が粗い |
高 |
はい |
配信時 |
この項では、AIAアーティファクトの開発タスク、および次のことを実行する方法について説明します。
EBOの識別
統合フローの設計
EBSの識別と作成
ABCSの作成
参加アプリケーションの有効化
EBFの識別と作成
FDDでは、次のことを検討します。
使用する概念的な標準モデルまたはEBO、およびこのエンティティで実行する必要があるアクション。
SOAコア拡張機能からのEBOの識別またはEBOの作成。EBOには、この統合で必要なすべての要件を組み込む必要があります。
SOAコア拡張機能からのEBMの識別または必要に応じたEBMの作成。
詳細は、My Oracle Supportの記事ID 983958.1の『Enterprise Object Library Extensibility Guide』を参照してください。
統合フローの設計は、技術設計ドキュメント(TDD)で詳細に説明しています。TDDの完了の基準は、プロジェクトとそれに付随する成果物に依存します。
TDDでは、フロー・ロジック、統合アーティファクト、オブジェクト/要素マッピング、DVMのタイプと値、エラー処理およびインストールの特性に関する完全な詳細が計画されます。また、開発者がランタイム操作の検証に使用するユニット・テスト計画のアウトラインも含まれます。
統合フローは、ランタイム実行可能アーティファクトではないため、メッセージ交換パターンを統合フローに結び付けることはできません。前述のAIAサービス・アーティファクトの設計には、ビジネス・シナリオの慎重な分析を含める必要があり、これによって、AIAサービス・アーティファクトごとにメッセージ交換パターンを決定します。
メッセージ交換パターンの決定の詳細は、「新規プロセスEBSのMEPの設定」、「MEPの識別」および「EBFのメッセージ・パターンを識別する方法」を参照してください。
Oracle AIAサービス・アーティファクトが様々なメッセージ交換パターンに関与するために必要なタスクは、これらのアーティファクトの開発を詳述している章で説明します。
統合フローを設計する手順は、次のとおりです。
Oracle AIA統合シナリオは、AIAサービス・アーティファクトの論理コレクションであり、次が含まれます。
EBS
EBF
ABCS
AIAサービス・アーティファクトは、複数のAIA統合フローに組み込むことができるため、Oracle Enterprise Repositoryを調べて、再使用可能なサービス・アーティファクトを識別します。AIAサービス・アーティファクトは、再利用性を考慮して作成されます。
アーティファクトごとに、これらの再利用性ガイドラインに従います。
EBSに関する再利用性ガイドライン
EBFに関する再利用性ガイドライン
ABCSに関する再利用性ガイドライン
AIA統合フローを開発する手順は、次のとおりです。
必要に応じて、EBSを識別して作成します。
「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください。
参加アプリケーションを有効化します。
「参加アプリケーションの有効化と登録」を参照してください。
ABCSを作成します。
「ABCSの作成」を参照してください。
EBFを作成します。
「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。
標準命名規則の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。
各EBOに、「作成、読取り、更新、削除」(CRUD)操作とその他のサポート操作を公開するためのEBSがあります。関連EBMで提示される各アクションは、EBSのサービス操作として実装されます。EBSの作成およびすべてのサービス操作の実装は、エンドツーエンドの統合フローの実装において重要なタスクです。
注意:
エンティティEBSの操作は、関連ビジネス・オブジェクトのみを実行対象とし、その他のビジネス・オブジェクトは実行対象としない必要があります。複数のビジネス・オブジェクトを実行対象とする操作は、プロセスEBSに常駐する必要があります。
EBSが存在する場合は、この統合フローに関するEBOを実行対象とするために必要なすべてのアクションがサービス操作として実装されたかどうかを確認します。これらが実装されていなかった場合は、既存のEBSを変更してサービス操作を追加します。
この手順では、エンティティ・ベースのEBSを作成する高度なタスクを示します。「エンタープライズ・ビジネス・サービスの設計と開発」に、これらの各タスクを完了する方法の詳細が記載されています。
エンティティベースのEBSを作成する手順は、次のとおりです。
詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください
この項では、SOAコア拡張機能エコシステムで参加アプリケーションを有効化するために必要な手順について説明します。また、AIAレジストリに対して参加アプリケーションを管理するために使用できるオプションについても説明します。
参加アプリケーションを有効化する手順は、次のとおりです。
呼び出す必要があるサービスAPIを識別します。
WSDLを参加アプリケーションに提供します。
必要に応じて、アダプタ・サービスを作成します。
この項では、Oracle Application Integration Architecture (AIA)システム・レジストリを管理する方法について説明します。
システム・レジストリの目的は、Oracle AIAエコシステムに参加するリクエスタ・システムとプロバイダ・システムに関する情報を識別し、取得することです。システム・レジストリでは、比較的静的なシステム属性が取得されます。
Oracle AIAエコシステムのシステム・レジストリは、最初はOracle AIAインストール・プロセス時にロードされますが、ユーザー・インタフェースを使用すると、レジストリの情報を管理できます。
システム・レジストリを保存する利点は、特定のシステム属性をエンタープライズ・ビジネス・メッセージのヘッダーに容易にデフォルト設定できることです。リクエスタ・システムとターゲット・システムには複数のインスタンスがあり、それぞれに異なる属性が設定されている場合があります。システム・レジストリを使用すると、各インスタンスに対する属性を取得できるため、後続の処理でそれらを識別できます。
SOAコア拡張機能では、システム・レジストリのデータを管理する方法が2通りあります。
「システム」ページ
SystemRegistration.xml構成ファイル
目標:
「システム」ページを使用して、Oracle AIAシステム・レジストリに格納されている参加アプリケーションを管理します。
アクター:
システム管理者(AIAApplicationUserロール)
「システム」ページを使用してOracle AIAシステム・レジストリを管理する手順は、次のとおりです。
表2-5 「システム」ページの要素
| ページの要素 | 説明 |
|---|---|
削除 |
システム行を選択し、「削除」をクリックして削除を実行します。 |
作成 |
クリックして、参加アプリケーションをシステム・レジストリに追加するために使用できるシステム行を追加します。 |
保存 |
クリックして、ページ上のすべてのエントリを保存します。 |
内部ID |
実装者が割り当てたシステム・インスタンス名(例: |
システム・コード |
これは必須値です。この値は、エンタープライズ・ビジネス・メッセージ(EBM)のヘッダーに入力されます。 |
システムの説明 |
「システム・コード」フィールドで識別されるリクエスタ・システムまたはプロバイダ・システムのインスタンスの詳細な説明。この値は、EBMのヘッダーに入力されます。 |
IPアドレス |
参加アプリケーションのIPアドレスであり、これを使用して、参加アプリケーションのエンドポイントにアクセスできます。この値は、EBMのヘッダーに入力されます。 |
URL |
これは、URL形式で指定されたホスト名とポートの組合せであり、これを使用して、参加アプリケーションにアクセスできます。通常は、 |
システム・タイプ |
システム・タイプを指定します。たとえば、 |
アプリケーション・タイプ |
指定したシステム内で実行中のアプリケーション。たとえば、システム・タイプ |
バージョン |
システムで実行中のアプリケーションのバージョンを指定します。この値は、EBMのヘッダーに入力されます。 |
連絡先名 |
システムを担当する連絡先の名前を指定します。この値は、EBMのヘッダーに入力されます。 |
連絡先電話番号 |
システムを担当する連絡先の電話番号を指定します。この値は、EBMのヘッダーに入力されます。 |
連絡先電子メール |
システムを担当する連絡先の電子メール・アドレスを指定します。この値は、EBMのヘッダーに入力されます。 |
目標:
「プロジェクト・ライフサイクル・ワークベンチ」プロセス統合プロジェクトに対するsystemRegistration.xml構成ファイルを作成します。プロジェクトごとに1つのsystemRegistration.xmlファイルを作成します。
「システム」ページの詳細は、「「システム」ページを使用したシステム・レジストリの管理方法」を参照してください。
ロール:
統合開発者
SystemRegistration.xml構成ファイルを使用してOracle AIAシステム・レジストリを管理する手順は、次のとおりです。
例2-1 AIAデプロイメント・ドライバによって抽出されるSQLコンテンツ
MERGE INTO AIA_SYSTEMS sysreg
USING dual
on (dual.dummy is not null and sysreg.SYSTEM_CODE='SampleSEBL' )
WHEN NOT MATCHED THEN INSERT
(SYSTEM_ID,SYSTEM_INTERNAL_ID,SYSTEM_CODE,SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_
URL,SYSTEM_TYPE,APPLICATION_TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_
PHONE,CONTACT_EMAIL)
VALUES (AIA_SYSTEMS_S.nextval,'Siebel','SampleSEBL','Sample Siebel Instance
01','10.0.0.1','http://siebel.xy.example.com:7001/ecommunications_enu',
SIEBEL','CRM','1.0, 'Siebel contact','1234567891','Siebelcontact@Siebel.com')
/
例2-2 AIAデプロイメント・ドライバによって抽出されたサンプルのSQLコンテンツ
<?xml version="1.0" encoding="UTF-8"?>
<properties>
<participatingapplications>
<siebel>
<http>
<host>siebel.xy.example.com</host>
<port>7001</port>
</http>
<internal>
<id>Siebel</id>
</internal>
<version>1.0</version>
<siebel>
...
</participatingapplications>
</properties>
例2-3 AIAデプロイメント・ドライバによって抽出されたサンプルのSQLコンテンツ
AIAデプロイメント・ドライバは、デプロイメント計画を読み取り、systemRegistration.xmlのトークンをAIAInstallProperties.xmlの実際の値に置き換え、システム登録のSQL文を実行してシステム・レジストリに値を入力します。
例2-1に、AIAデプロイメント・ドライバによって抽出されるSQLコンテンツを示します。
複数の「プロジェクト・ライフサイクル・ワークベンチ」プロセス統合プロジェクトを使用している場合は、複数のsystemRegistration.xmlファイルが追加されます。参加アプリケーションをデプロイする前に、参加アプリケーションがシステム・レジストリのエントリに追加されているかどうかを確認します。リクエストの重複は、システム・レジストリ表で有効化されている主キーと一意値の制約によって、SQL例外が発生する原因となります。
前述のSQLコンテンツの太字のテキストを組み込むことによって、これらを確認してください。参加アプリケーションの値の重複が検出された場合は作成されません。一意の場合は作成されます。
AIAデプロイメント・ドライバは、systemRegistration.xmlのトークンを$AIA_INSTANCE/config/AIAInstallProperties.xmlで提供されている例2-2のデータに置き換えることで、この例のSQLコンテンツを抽出しました。
例2-4 サンプルSQL作成コード
<AIASystemRegistration> <create> MERGE INTO AIA_SYSTEMS sysreg USING dual on (dual.dummy is not null and sysreg.SYSTEM_CODE='SampleSEBLDPT003' ) WHEN NOT MATCHED THEN INSERT (SYSTEM_ID,SYSTEM_INTERNAL_ID,SYSTEM_CODE, SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_URL,SYSTEM_TYPE,APPLICATION_ TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_PHONE,CONTACT_ EMAIL) VALUES (AIA_SYSTEMS_S.nextval,'SampleSEBLDPT003','SampleSEBLDPT003', 'Sample Siebel Instance01','10.0.0.1','http:// ${participatingapplications.SampleSiebel.server. soaserverhostname}:${participatingapplications.SampleSiebel. server.soaserverport} /ecommunications_enu' ,'Sample SIEBEL','CRM','${pips.BaseSample.version}','Siebel contact','1234567891','aiasamples_contact@aia.com') / MERGE INTO AIA_SYSTEMS sysreg USING dual on (dual.dummy is not null and sysreg.SYSTEM_CODE='SamplePortalDPT003' ) WHEN NOT MATCHED THEN INSERT (SYSTEM_ID,SYSTEM_INTERNAL_ ID,SYSTEM_CODE,SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_URL,SYSTEM_ TYPE,APPLICATION_TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_ PHONE,CONTACT_EMAIL) VALUES (AIA_SYSTEMSS.nextval, 'SamplePortalDPT003','SamplePortalDPT003', 'Sample Portal Instance 01','10.0.0.1', 'http://${participatingapplications.SamplePortal.server. soaserverhostname}:${participatingapplications.SamplePortal. server.soaserverport} ','Sample Portal','BILLING','${pips.BaseSample.version}','Portal contact','1234567892','aiasamples_contact@aia.com') / </create> </AIASystemRegistration>
例2-5 サンプル参加アプリケーション／コード
<properties>
<participatingapplications>
<SamplePortal>
<server>
<soaserverhostname>adc2180948.xy.example.com
</soaserverhostname>
</server>
...
</participatingapplications>
</properties>
例2-6 サンプル削除コード
<AIASystemRegistration>
<delete>
delete from AIA_SYSTEMS where SYSTEM_CODE='SampleSEBLDPT005'
/
delete from AIA_SYSTEMS where SYSTEM_CODE='SamplePortalDPT005'
/
</delete>
</AIASystemRegistration>
識別された各EBFには、対応するビジネス・プロセスEBSがあります。このEBS内の操作は、EBFへのエントリ・ポイントです。
詳細は、「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。
