| Oracle® Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド 11g リリース1 (11.1.1.5.0) B55918-04 |
|
 前 |
 次 |
Oracle Application Serverアダプタは、Oracle WebLogic ServerおよびOracle Fusion Middlewareの各種コンポーネントと統合できます。この章では、アダプタをOracle WebLogic ServerおよびOracle Fusion Middlewareと統合する方法について説明します。
この章には、次の項目が含まれます。
Oracle JCAアダプタはJ2CA 1.5仕様に基づいており、Oracle WebLogic Serverにデプロイされます。リソース・アダプタは、Oracle Fusion Middlewareのアドレス空間内で使用されます。この項では、Oracle WebLogic Serverの概要と、アダプタとの設計時および実行時の統合について説明します。
この項には、次の項目が含まれます。
Oracle WebLogic Serverは、Oracle Application ServerのコアJ2EEランタイム・コンポーネントです。Oracle WebLogic Serverはスケーラブルなエンタープライズ対応のJava Platform, Enterprise Edition(Java EE)アプリケーション・サーバーです。WebLogic Serverインフラストラクチャは、様々なタイプの分散アプリケーションのデプロイをサポートしています。サービス指向アーキテクチャ(SOA)に基づくアプリケーションを構築する上で理想的な基盤です。
すべてのクライアント・アプリケーションは、Oracle WebLogic Server環境で実行されます。Oracle WebLogic Serverクライアント・アプリケーションをリソース・アダプタと統合するには、Common Client Interface(CCI)を使用します。Oracle WebLogic Serverアダプタ・クライアントには、CCI Application Program Interface(API)を実装するサーブレット、EJBまたはJavaアプリケーション・クライアントがあります。CCIでは、アプリケーション・コンポーネントがバックエンド・アプリケーションにアクセスするための標準的なクライアントAPIが定義されます。
これに対して、Oracle WebLogic Serverコンテナとリソース・アダプタの間の規定は、サービス・プロバイダ・インタフェース(SPI)により定義されます。規定により、Oracle WebLogic Serverとアダプタの間の標準が定義されます。これらの規定はシステムにより自動的に処理され、アプリケーション開発者から隠されます。図3-1に、CCIとSPIの規定を示します。
Oracle WebLogic Serverアーキテクチャには、次に示すシステム・レベルの一連の規定が含まれています。
接続管理: アプリケーション・コンポーネントがバックエンド・アプリケーションに接続して、Oracle WebLogic Serverコンテナの接続プーリング・サポート機能を利用できるようにします。これにより、バックエンド・アプリケーションへのアクセスを必要とする多数のコンポーネントをサポートできるスケーラブルで効果的な環境が得られます。詳細は、第2.19項「アダプタ・コネクション・ファクトリの追加」を参照してください。
トランザクション管理: アプリケーション・サーバーがトランザクション・マネージャを使用して、複数のリソース・マネージャ間のトランザクションを管理できるようにします。ほとんどのアダプタではローカル・トランザクション(1フェーズ・コミット)のみがサポートされ、XAトランザクション(2フェーズ・コミット)はサポートされていません。詳細は、第2.12項「メッセージの損失がないことをOracle JCAアダプタで保証する方法」を参照してください。
次のアダプタでは、XAトランザクションがサポートされています。
Oracle MQ Seriesアダプタ
Oracle JMSアダプタ
Oracle AQアダプタ
Oracleデータベース・アダプタ
Oracle EBSアダプタ
次のアダプタでは、XAトランザクションがサポートされていません。
Oracleファイル・アダプタ
Oracle FTPアダプタ
Oracleソケット・アダプタ
すべてのOracle JCAアダプタはトランザクションについて適切な値を使用して事前に構成されており、この構成はOracle WebLogic Server管理コンソールで変更しないでください。
セキュリティ管理: WebLogic Serverのセキュリティ・アーキテクチャは、Web上でアプリケーションを使用可能にするというセキュリティ上のチャレンジに対処するように設計された包括的で柔軟なセキュリティ・インフラストラクチャを提供します。WebLogicのセキュリティは、スタンドアロンで使用してWebLogic Serverアプリケーションを保護したり、最良のセキュリティ管理ソリューションを表すエンタープライズ単位のセキュリティ管理システムの一部として使用できます。
Oracle JCAアダプタはJ2CA 1.5仕様に基づいており、このリリースではOracle WebLogic ServerコンテナにJ2CAリソース・アダプタとしてデプロイされます。J2CAリソース・アダプタは、Javaアーカイブ(JAR)フォーマットを使用してリソース・アダプタ・アーカイブ(RAR)にパッケージされます。RARファイルには、適切にフォーマットされたデプロイメント・ディスクリプタ(/META-INF/ra.xml)が含まれています。さらに、RARファイルには、Oracle WebLogic Serverとリソース・アダプタの間の規定に関する宣言情報も含まれています。
Oracle WebLogic Serverでは、J2CAアダプタのデプロイメント中に対応するweblogic-ra.xmlファイルが生成されます。weblogic-ra.xmlファイルは、リソース・アダプタ用のデプロイメント・ディスクリプタです。これにはリソース・アダプタをOracle WebLogic Serverにデプロイするためのデプロイ構成が含まれています。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface(JNDI)名、接続プーリング・パラメータ、リソースのプリンシパル・マッピング・メカニズムおよび構成などが含まれます。
アダプタ設計時ツールを使用して、アダプタのリクエスト-レスポンス・サービス用のXMLスキーマ定義(XSD)ファイルを生成します。Oracle WebLogic Serverクライアントでは、これらのXSDファイルが実行時に使用されて、J2CAアウトバウンド相互作用がコールされます。パッケージ・アプリケーション・アダプタでは、OracleAS Adapter Application Explorer(アプリケーション・エクスプローラ)が使用され、レガシー・アダプタではOracleAS Studioが使用され、テクノロジ・アダプタではOracle JDeveloper(JDeveloper)が使用されます。
詳細は、第3.2.3.1項「設計時」を参照してください。
アダプタによりOracle Fusion MiddlewareプラットフォームのJCAバインディング・コンポーネントが統合されます。これにより、Oracle BPEL Process Manager(Oracle BPEL PM)やOracle Mediatorなどのサービス・エンジンがシームレスに統合されます。
図3-2に、Oracle JCAアダプタのアーキテクチャを示します。
図3-2 Oracle Fusion MiddlewareにおけるOracleアダプタのアーキテクチャ
アダプタ構成ウィザードでは、対応するサービスのバインディング情報を含むWSDLとJCAプロパティ・ファイルが生成されます。
Oracleテクノロジ・アダプタでは、処理するすべてのインバウンドおよびアウトバウンド・メッセージの統計を収集およびパブリッシュします。詳細は、第3.3項「Oracle JCAアダプタの監視」を参照してください。
この項には、次の項目が含まれます。
Oracle BPEL PMは、Oracle BPEL PMビジネス・プロセスを作成、デプロイおよび管理するための包括的なソリューションです。Oracle BPEL PMはサービス指向アーキテクチャ(SOA)に基づいており、柔軟性、相互運用性、再利用性、拡張性および迅速な実装を提供します。Oracle BPEL PMにより、既存のビジネス・プロセスの管理、変更、拡張および再デプロイに伴う全体のコストが削減されます。各ビジネス・アクティビティは自己完結型でわかりやすいモジュラー・アプリケーションで、WSDLファイルにより定義されるインタフェースと、Webサービスとしてモデル化されるビジネス・プロセスを備えています。
Oracle Mediatorは、サービスおよびイベントの各種プロデューサとコンシューマ間を仲介するための軽量フレームワークを提供します。ほとんどのビジネス環境では、顧客データはビジネス・パートナ、レガシー・アプリケーション、エンタープライズ・アプリケーション、データベースおよびカスタム・アプリケーションなどの異種ソースに常駐します。このデータを統合するというチャレンジは、Oracle Mediatorを使用して、同じデータが更新対象や共通の注目対象となる全アプリケーションに適切なリアルタイム・データ・アクセスを提供することで満たすことができます。たとえば、メディエータはアプリケーションやサービスからテキスト・ファイルに含まれたデータを受け入れ、顧客リポジトリとして機能するデータベースの更新に適したフォーマットに変換し、そのデータベースにルーティングして配信できます。
J2CA 1.5リソース・アダプタとOracle BPEL PMおよびOracle Mediatorを双方向で統合するために、JCAバインディング・コンポーネントが使用されています。Oracle JCAアダプタによりWSDLファイルとJCAバインディングが生成され、基礎となる相互作用がWebサービスとして公開されます。
アダプタ・サービスへのインタフェース(入力/出力XML要素)は、WSDLファイルを介して記述されます。ただし、リリース11gでは、バインディング要素が削除され、WSDLファイルが抽象になっています。かわりに、JCAバインディング・コンポーネント(以前のリリースにおけるアダプタ・フレームワーク)とアダプタが特定のEIS上で特定のコールについて起動するために必要とするバインディング情報は、個別のbinding.jcaファイルに格納されます。
この項では、次の内容について説明します。
アダプタをBPEL PMおよびOracle Mediatorと統合する間に、基礎となるアダプタ・サービスがJ2CA拡張を使用するWSDLファイルとして公開されます。次の表に、各種アダプタ用のWSDLファイルとJCAファイルの生成に使用する設計時ツールを示します。
| アダプタ | ツール |
|---|---|
| Oracleテクノロジ・アダプタ | Oracle JDeveloper |
| レガシー・アダプタ | Oracle Studio |
| パッケージ・アプリケーション・アダプタ | アプリケーション・エクスプローラ |
| Oracleアプリケーション用のOracleアダプタ | Oracle JDeveloper |
WSDLファイルは、アダプタのリクエスト-レスポンス・サービスとイベント通知サービスの両方について作成されます。J2CA拡張には、JCAバインディング・コンポーネントで実行時にWebサービス・メッセージをJ2CA相互作用との間で変換するために必要なJ2CA要素が含まれています。J2CAのWSDL拡張要素には、JCAバインディング・コンポーネントでリクエスト-レスポンス・サービスをコールし、インバウンドJ2CA 1.5エンドポイントをアクティブ化してインバウンド・イベントを受信するためのメタデータが含まれています。リクエスト-レスポンス・サービス用のJ2CA拡張要素には、アウトバウンド相互作用をコールするためのJNDIロケーションとInteractionSpecの詳細が含まれています。イベント通知サービス用のJ2CA拡張要素には、J2CAインバウンド相互作用を介してアダプタ・イベントをパブリッシュするための、リソース・アダプタ・クラス名とActivationSpecパラメータが含まれています。
図3-3に、Oracle JCAアダプタで使用される設計時ツールのJDeveloperを示します。
図3-4に、パッケージ・アプリケーション・アダプタの構成に使用する設計時ツールを示します。この図では、設計時ツールを使用して、アダプタ・メタデータがWSDLファイルとして公開されています。WSDLファイルは、実行時にBPEL Process Managerにより消費されます。
Oracle Application ServerアダプタはJ2CA 1.5仕様に基づいており、BPELはOracle WebLogic Server上の11gランタイムにデプロイされます。JCAバインディング・コンポーネントは、実行時に標準のJ2CA 1.5リソース・アダプタをOracle BPEL Process ManagerおよびOracle Mediatorと結び付けて統合するレイヤーとして機能します。JCAバインディング・コンポーネントは擬似J2CA 1.5コンテナとしても機能します。
BPEL Invokeアクティビティにより開始されたWebサービスの呼出しはJ2CA CCIアウトバウンド相互作用に変換され、J2CAレスポンスはWebサービス・レスポンスに変換されます。このエンドツーエンドの呼出しは同期的です。
カスタム・アダプタをWebサービスとしてラップし、それをBPEL Process Managerに公開することもできます。これは疎結合方針で、アダプタSDKは必要ありません。これらのアプローチ(JCA/Webサービス)は両方とも、参照と呼ばれるアウトバウンドの起動操作に適しています。Oracle BPEL PMがインバウンド・イベント(EISからJ2EE/Oracle BPEL PM)を受信できるのは、JCA 1.5統合のみです。Oracle BPEL PMは擬似JCA 1.5コンテナとして機能し、JCA 1.5固有のシステム規定を実装します。
アダプタの構成には任意のカスタム設計ツールを使用できますが、設計時フェーズの最後に、Oracle BPEL PMの設計時(Jdeveloper)に使用されるWSDLファイルを生成する必要があります。JCA相互作用のためのWSDLファイルには、JCA拡張子があります。アダプタは、Oracle BPEL PM製品と同じOracle WebLogic ServerコンテナにデプロイされるJCA 1.5リソース・アダプタです。JCA 1.5リソース・アダプタとOracle BPEL PMインスタンスは同じOracle WebLogic Serverコンテナにデプロイする必要があることに注意してください。
JCAバインディング・コンポーネントは、実行時に標準のJCA 1.5リソース・アダプタとOracle BPEL PM製品をシームレスに統合するレイヤーです。JCAバインディング・コンポーネントは、JCA相互作用をWebサービスとしてラップするためのJCAプロバイダを含んでおり、設計時に生成されたWSDLファイルに基づいてWebサービス・メッセージからJCA相互作用メッセージへの変換を実行します。
アウトバウンド起動(リリース11gでは参照)に使用するcomposite.xmlファイルのスニペットを次に示します。
<reference name="insert" ui:wsdlLocation="insert.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/db/DBRetriesApplication/XARollback/insert%2F#wsdl.interface(insert_ptt)"/>
<binding.jca config="insert_db.jca"/>
</reference>
次のリストに、BPEL Process Managerをアウトバウンド相互作用と統合するプロセスの概要を示します。
設計時にアダプタ・サービスがWSDLファイルとして公開され、BPELプロセスのPartnerLinkアクティビティの構成時に消費されます。
.jcaファイルには、リソース・アダプタのJNDIアドレス、InteractionSpecクラス名、InteractionSpecパラメータが含まれています。
実行時に、BPEL Process Managerのinvokeアクティビティを使用して、J2CAリソース・アダプタのアウトバウンド相互作用であるPartnerLinkアクティビティがコールされます。
コンポーネントがコンポジット・アプリケーションにワイヤリングされます。
JCAバインディング・コンポーネントにより、イベントがOracle BPEL PMインスタンスで使用できるようにWebサービス・レスポンスに変換されます。
アウトバウンドJCAアダプタがCCI相互作用を介してEISと通信します。
|
注意: Oracle Mediatorのアウトバウンド相互作用は、Oracle BPEL PMのアウトバウンド相互作用と同じです。 |
BPEL Process Managerは、JCAバインディング・コンポーネントを介してJ2CA 1.5リソース・アダプタからイベントを受信します。アダプタ・フレームワークは擬似J2CA 1.5コンテナであり、アダプタからイベントを受信できるようにメッセージ・インフロー規定を実装します。J2CAインバウンド相互作用は、設計時にWSDLファイルで取得されます。J2CAインバウンドWSDLのバインディング・セクションには、J2CA 1.5のActivationSpecパラメータが含まれています。ActivationSpecパラメータにより、インバウンド接続性とインバウンド相互作用の詳細が(J2CA 1.5仕様に従って)取得されます。J2CAインバウンドWSDLのサービス・セクションには、J2CA 1.5のResourceAdapterクラス名が含まれています。また、サービス・セクションには必要に応じてJNDIロケーションを追加できます。
次のリストに、BPEL Process Managerをインバウンド相互作用と統合するプロセスの概要を示します。
ResourceAdapterクラス名とActivationSpecパラメータが、設計時にJ2CAインバウンド相互作用のWSDLのWSDL拡張セクションで取得され、実行時にBPEL Process ManagerとJCAバインディング・コンポーネントで使用可能になります。
J2CA 1.5のResourceAdapterクラスのインスタンスが作成され、J2CAのResourceAdapterクラスのStartメソッドがコールされます。
BPEL Process Managerプロセスで参照される各インバウンド相互作用操作により、J2CA 1.5のResourceAdapterインスタンスのEndPointActivationメソッドが起動されます。JCAバインディング・コンポーネントにより、J2CAインバウンド相互作用のWSDL拡張セクションにあるActivationSpecの詳細に基づいて、ActivationSpecクラス(Java Bean)が作成され、J2CA 1.5リソース・アダプタのエンドポイントがアクティブ化されます。
JCAバインディング・コンポーネントのMessageEndpoint実装により、javax.resource.cci.MessageListenerインタフェースが実装されます。J2CA 1.5リソース・アダプタでは、バックエンド・アプリケーション・イベントを受信した時点で、このMessageEndpoint内のonMessage()メソッドがコールされます。J2CA 1.5リソース・アダプタにより、endpointActivation中にリソース・アダプタに提供されたMessageEndpointFactoryを介して、MessageEndpoint実装のインスタンスが作成されます。
JCAバインディング・コンポーネントでMessageListenerクラスを介してイベントが受信され、BPEL Process Managerインスタンスのreceiveアクティビティに転送されます。
BPELプロセスが停止すると、関連するすべてのインバウンド・エンドポイントが、リソース・アダプタにより実装されたendPointDeactivationメソッドを介して非アクティブ化されます。
J2CAアダプタ(特にOracleデータベース・アダプタやOracle AQアダプタなどのJDBCベース・アダプタ)の場合、次の2種類の接続管理があります。
インバウンド(エンドポイント)のアクティブ化(BPEL Receive)用
アウトバウンド相互作用(BPEL Invoke)用
インバウンド・アクティブ化の場合、J2CAアダプタは接続の作成とリカバリを全面的に受け持ちます。JCAバインディング・コンポーネントにリクエストできるのは、J2CAのConnectionFactoryハンドルをルックアップし、ActivationSpecを介してアダプタに提供することのみです。これが可能なのは、接続の作成に使用してOracle Application Serverの接続マネージャを通過できる特定のインタフェースを実装する場合のみです。管理対象の(JDBC)接続に障害が発生した場合、アダプタはJ2CA接続ハンドルをクローズし(Oracle Application Serverによりdestroy()がコールされる場合は続いて管理対象の接続をクローズし)、一時的なリカバリ・ループに入ってから、新規接続の再確立を試行する必要があります。
アウトバウンド相互作用(J2CA)の場合、各ポートにより次のタプルがキャッシュされます。
ConnectionFactory
ConnectionSpec
Connection
Interaction
InteractionSpec
通常、BPELエンジンではポートが多数のスレッドと同時に起動されるため、キャッシュのサイズには特定時点の最大の同時実行性レベルが反映されます。キャッシュは、構成済のアイドル期間の後に、未使用のタプルを自動的に失効させるようにチューニングできます(これにより相互作用と接続ハンドルがクローズされます)。キャッシュにより、Retek(毎時間800万トランザクション)のような高負荷環境でのパフォーマンスが大幅に向上します。
キャッシュを使用する単一のJCAアダプタ相互作用がResourceExceptionをスローすると、キャッシュのメンバーがすべてクローズされ、即時にリリース(パージ)されます。このため、新規相互作用はキャッシュにメンバーを再作成(フレッシュ)する必要があります。BPELエンジンには、起動ごとに構成可能なPartnerLinkの再試行という機能があります。したがって、RetryableとしてマークされたResourceException例外をスローするJCAアダプタの起動または相互作用により、エンジンはInvoke(データベース更新)を再試行し、Invokeはポート・キャッシュに再移入します(データベースが再び使用可能になった場合。RACの場合、通常は即時)。ファイル・アダプタのような非トランザクション・アダプタ(adapterMetadata.supportsLocalTransactionDemarcation() == false)の場合、J2CA接続キャッシュにはメンバーが1つ含まれるのみです。したがって、すべてのスレッドの通過は、同じCCI接続ハンドル上で多重化されます。
JCA接続キャッシュは、次のbpel.xmlパートナ・リンク・プロパティを使用して明示的に有効化または構成できます。
<property name="useJCAConnectionPool">true</property>
通常、このプロパティはアダプタの宣言済トランザクション・サポートから導出されます。たとえば、ファイル・アダプタでは、この接続プールは使用されません。これはマルチスレッド・セーフであるためですが、次のプロパティを介してオーバーライドできます。
<property name="maxSizeJCAConnectionPool">500</property>
前述の例に示したプロパティを指定しなければ、接続プールのサイズはバインドされていないものとみなされます。これは、パートナ・リンクごとに適用されます。
<property name="lruConnectionMaxIdleAge">50000</property>
次の例に示すように、ms単位で測定されるDBシャドウ・プロセスなど、高コストの外部リソースへの一部のタイプの接続が保持されるため、プール内のアイドル接続の最大経過時間が重要です。
property name="lruConnectionCheckInterval">10000</property>
最後に、前述の例に示したプロパティにより、接続プールでアイドル接続をスキャンする頻度(ms単位)が決定されます。
インバウンドのポーリングの受信操作(リリース11gではサービス)に使用するcomposite.xmlファイルのコード・スニペットを次に示します。
<service name="poll" ui:wsdlLocation="poll.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/db/DBRetriesApplication/
XARollback/poll%2F#wsdl.interface(poll_ptt)" (http://xmlns.oracle.com/pcbpel/adapter/db/DBRetriesApplication/XARollback/poll%2F#wsdl.interface%28poll_ptt%29)/>
<binding.jca config="poll_db.jca"/>
</service>
composite.xmlファイルがWSDLインタフェース(the interface.wsdlファイル)、リクエストを処理するコンポーネントの名前(binding.jcaファイル)および特定のコールの起動に必要なバインディング情報(the configファイル)にどのようにリンクするかに注意してください。そのため、JCAバインディング・コンポーネントは、リリース10.1.3ではWSIFプロバイダとして登録されていましたが、SCAにbinding.jcaファイルの実装として登録されます(他にbinding.ejbおよびbinding.javaが含まれます)。
現行リリースでは、<binding.jca>要素はcomposite.xmlファイル内にあり、JCAバインディング・コンポーネントがInvokeアクティビティを処理することを明示的に示します。リリース10.1.3では、次の例に示すように、WSDL内の具体バインディングを調べてアダプタの起動かどうかを確認する必要がありました。
<binding name="invokeService_binding" type="tns:invokeService_ptt"> <jca:binding /> <operation name="merge"> <jca:operation>
図3-5に示すように、Oracle BPEL PMの「パートナ・リンク」ダイアログから、Oracle BPEL PMで提供されているアダプタにアクセスできます。
図3-6に示すように「サービスの定義」アイコンをクリックし、「サービスまたはアダプタの設定」ダイアログにアクセスします。
このダイアログを使用すると、Oracle BPELプロセスで使用するアダプタ・タイプ(図3-7を参照)を設定できます。
アダプタ・タイプ(この例では「AQアダプタ」)を選択して「OK」をクリックすると、図3-8に示す「アダプタ構成ウィザード - ようこそ」ページが表示されます。
「次へ」をクリックすると、図3-9に示す「サービス名」ページが表示されます。サービス名の入力を要求されます。
この例では、図3-7に示すように「AQアダプタ」が選択されています。ウィザードが完了すると、BPELプロセスの「アプリケーション・ナビゲータ」にこのサービス名のWSDLファイルが表示されます(この例では、「DequeueDemo.wsdl」という名前です)。このファイルには、このウィザードで指定するアダプタ構成設定が含まれます。その他の構成ファイル(ヘッダー・プロパティやアダプタ固有のファイルなど)も作成され、「アプリケーション・ナビゲータ」に表示されます。
「サービス名」ウィンドウ以降に表示されるアダプタ構成ウィザードのウィンドウは、選択したアダプタ・タイプによって異なります。これらの構成ウィンドウや指定する情報については、このマニュアルの後続の章で説明します。
Oracle JCAアダプタは、Oracle SOA Suiteと統合できます。
この項には、次の項目が含まれます。
SOAコンポジット・アプリケーションは、ビジネス・ニーズを満たすためにまとめて設計されてデプロイされるサービス、サービス・コンポーネント、参照およびワイヤのアセンブリです。
SOAは、接続済エンタープライズ・アプリケーションの構築をサポートするエンタープライズ・アーキテクチャを提供します。SOAにより、統合と再利用が容易なモジュール形式のビジネスWebサービスとしてエンタープライズ・アプリケーションを開発する作業が容易になり、真に柔軟で適合性の高いITインフラストラクチャを作成できます。
コンポジットは、まとめて設計されて単一アプリケーションにデプロイされるサービス、サービス・コンポーネント、ワイヤおよび参照のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。
たとえば、コンポジットには、インバウンド・サービス・バインディング・コンポーネント(インバウンド・アダプタ)、BPELプロセス・サービス・コンポーネントおよびアウトバウンド参照バインディング・コンポーネント(アウトバウンド・アダプタ)が含まれます。このコンポジットの詳細は、composite.xmlファイルに格納されます。
通常、Oracle SOAコンポジットは、次の各部で構成されています。
バインディング・コンポーネント
バインディング・コンポーネントにより、SOAコンポジットと外部との接続性が確立されます。バインディング・コンポーネントには、次の2つのタイプがあります。
サービス・バインディング・コンポーネント
外部にSOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。サービスのWSDLファイルにより、外部アプリケーションに機能が通知されます。これらの機能は、SOAコンポジット・アプリケーションのコンポーネントへの接続に使用されます。サービスのバインディング接続性により、Oracle JCAアダプタなどのサービスと通信できるプロトコルが記述されます。
参照バインディング・コンポーネント
SOAコンポジット・アプリケーションから外部にある外部サービスに送信するメッセージを有効にします。
Oracle SOA Suiteでは、サービスおよび参照をテクノロジ(データベース、ファイルシステム、FTPサーバー、メッセージング: JMS、IBM WebSphere MQなど)およびアプリケーション(Oracle E-Business Suite、PeopleSoftなど)と統合するためのWebサービス(Oracle JCAアダプタなど)を提供します。これには、Oracle AQアダプタ、Oracleデータベース・アダプタ、Oracleファイル・アダプタ、Oracle FTPアダプタ、Oracle JMSアダプタ、Oracle MQ SeriesアダプタおよびOracleソケット・アダプタが含まれます。
サービス・インフラストラクチャ
内部メッセージ・トランスポートを提供します。たとえば、インバウンド・アダプタからメッセージを受信して、処理のためにBPELプロセス・サービス・エンジンにポストします。
サービス・エンジン(サービス・コンポーネントをホストするコンテナ)
サービス・コンポーネントのビジネス・ロジックや処理ルールをホストします。各サービス・コンポーネントには固有のサービス・エンジンがあります。たとえば、Oracle BPELプロセス・エンジンやOracle Mediatorコンポーネントなどです。
アダプタとサービス・エンジンの統合の詳細は、第3.2項「アダプタとOracle Fusion Middlewareの統合」を参照してください。
UDDIとMDS
MDS(メタデータ・サービス)リポジトリには、使用可能なサービスの記述が格納されます。UDDIはこれらのサービスを通知し、実行時に動的にバインディングしたり検出できるようにします。
SOAアーカイブ: コンポジット
コンポジット・アプリケーションを記述するデプロイメント・ユニットです。
コンポジットは、まとめて設計されて単一アプリケーションにデプロイされるサービス(インバウンド・アダプタなど)、サービス・コンポーネント、ワイヤおよび参照(アウトバウンド・アダプタなど)のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。SOAプロジェクトを作成すると、composite.xmlファイルが自動的に作成されます。このファイルでは、サービス、サービス・コンポーネント、参照およびワイヤのコンポジット・アセンブリ全体が記述されます。つまり、composite.xmlファイルではSOAコンポジット全体が記述されます。
次にcomposite.xmlサンプル・ファイルを示します。
Composite.xml (JCA Bindings)<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SOA Modeler version 1.0 at [2/23/09 3:02 PM]. -->
<composite name="MediatorFlatStructure"
revision="1.0"
label="2009-02-23_15-02-00_374"
mode="active"
state="on"
xmlns="http://xmlns.oracle.com/sca/1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:ui="http://xmlns.oracle.com/soa/designer/">
<import namespace="http://xmlns.oracle.com/pcbpel/adapter/file/SOA-FlatStructure/MediatorFlatStructure/MedFlatIn%2F" location="MedFlatIn.wsdl" importType="wsdl"/>
<import namespace="http://xmlns.oracle.com/pcbpel/adapter/file/SOA-FlatStructure/MediatorFlatStructure/MedFlatOut%2F" location="MedFlatOut.wsdl" importType="wsdl"/>
<service name="MedFlatIn" ui:wsdlLocation="MedFlatIn.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/file/SOA-FlatStructure/MediatorFlatStructure/MedFlatIn%2F#wsdl.interface(Read_ptt)"/>
<binding.jca config="MedFlatIn_file.jca"/>
</service>
<component name="MediatorFlat">
<implementation.mediator src="MediatorFlat.mplan"/>
</component>
<reference name="MedFlatOut" ui:wsdlLocation="MedFlatOut.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/file/SOA-FlatStructure/MediatorFlatStructure/MedFlatOut%2F#wsdl.interface(Write_ptt)"/>
<binding.jca config="MedFlatOut_file.jca"/>
</reference>
<wire>
<source.uri>MedFlatIn</source.uri>
<target.uri>MediatorFlat/MediatorFlat</target.uri>
</wire>
<wire>
<source.uri>MediatorFlat/MedFlatOut</source.uri> <target.uri>MedFlatOut</target.uri>
</wire>
</composite>
Oracle SOAコンポジットおよび各種サービス・エンジンとの統合の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
Oracle BPEL Process ManagerおよびOracle Mediatorには、Oracle JCAアダプタ(ファイル、JMSおよびデータベースなど)があり、それぞれがインバウンドまたはアウトバウンドで処理するすべてのメッセージの統計が収集され、パブリッシュされます。統計は、カテゴリと個別タスクにわかれています。次の例に、アウトバウンド(参照)プロセス内で統計がどのようにわかれているかを示します。
アダプタの前処理
InteractionSpecの準備
アダプタの処理
コール可能な文の設定
データベースの起動
結果の解析
アダプタの後処理
アダプタ統計は、Fusion Middleware Controlコンソールで表示できます。アダプタ統計を表示する手順は、次のとおりです。
http://servername:portnumber/emにナビゲートします。
「ターゲット・ナビゲーション・ツリー」(左端のペイン)のSOAフォルダにあるsoa_infraをクリックします。
「soa-infra」ページが表示されます。
図3-10に示すように、「soa-infra」ページの「SOAインフラストラクチャ」メニューで「サービスと参照」をクリックします。
図3-10 Fusion Middleware Controlコンソールでのアダプタ統計の表示
図3-11に示すように、「SOAインフラストラクチャ・ホーム > インタフェース」ページが表示されます。
このページには、現在アクティブなすべてのアダプタのインバウンド相互作用(サービス)およびアウトバウンド相互作用(参照)のリストと、各アダプタで実行される各種ステップの平均実行時間が表示されます。
