10g（10.1.3.1.0）
B31900-01
 目次 |
 索引 |
| Oracle Application Server Adapter概要 10g（10.1.3.1.0） B31900-01 |
|
Oracle Application Serverアダプタは、Oracle Containers for J2EE（OC4J）、Oracle Application Server InterConnect、Business Process Execution Language for Web services（BPEL）Process Manager、およびOracle Enterprise Service Busなど、様々なコンポーネントと統合できます。この章では、OC4J、BPEL Process ManagerおよびOracleAS Integration InterConnectとアダプタを統合する方法を説明します。
この章の内容は、次のとおりです。
Oracle Application Serverアダプタは、OC4Jコンテナ内にJ2EE Connector Architecture（J2CA）1.0リソース・アダプタとしてデプロイされます。このリソース・アダプタは、Oracle Application Serverのアドレス空間で使用されます。この項では、OC4Jの概要、および設計時と実行時のアダプタとの統合について説明します。この項の内容は、次のとおりです。
OC4JはOracle Application ServerのコアJ2EEランタイム・コンポーネントです。OC4Jは標準JDK 1.4 Java仮想マシン（JVM）で動作するJ2EE 1.3準拠のコンテナであり、JavaServer Pages（JSP）ファイル、サーブレット、Enterprise JavaBeans（EJB）、WebサービスおよびすべてのJ2EEサービスを完全にサポートしています。さらに、OC4Jは、J2CAリソース・アダプタをホスティングするためのJ2CAコンテナで構成されています。J2CAは、J2EEサーバーと各種バックエンド・アプリケーションの統合を簡略化するための標準Javaインタフェースを定義します。
すべてのクライアント・アプリケーションは、OC4J環境内で動作します。OC4Jクライアント・アプリケーションをリソース・アダプタと統合するには、Common Client Interface（CCI）を使用します。OC4Jアダプタ・クライアントには、CCI Application Program Interface（API）を実装するサーブレット、EJBまたはJavaアプリケーション・クライアントが含まれます。CCIは、アプリケーション・コンポーネントがバックエンド・アプリケーションにアクセスするための標準クライアントAPIを定義します。
これに対して、OC4Jコンテナとリソース・アダプタ間の規約は、Service Provider Interface（SPI）によって定義されます。この規約によって、OC4Jとアダプタ間の標準が定義されます。これらの規約はシステムによって自動的に処理され、アプリケーション開発者には明示されません。次の図は、CCIとSPI間の規約を説明しています。
OC4Jアーキテクチャには、次のシステム・レベルの規約があります。
Oracle Application ServerアダプタはJ2CA 1.5ベースのアダプタで、インストール時にOC4J内にデプロイされます。このリリースでのOC4Jコンポーネントがサポートするのは、J2CA 1.0仕様のみです。J2CAリソース・アダプタは、Javaアーカイブ（JAR）形式を使用して、リソース・アダプタ・アーカイブ（RAR）ファイルにパッケージ化されています。RARファイルには、正しく書式設定されたデプロイメント・ディスクリプタ(/META-INF/ra.xml)が含まれています。さらに、OC4Jとリソース・アダプタ間の規約に関する宣言情報も含まれています。
OC4Jでは、J2CAアダプタのデプロイ時に、対応するoc4j-ra.xmlファイルが生成されます。このoc4j-ra.xmlファイルは、リソース・アダプタ用のデプロイメント・ディスクリプタです。このファイルには、リソース・アダプタをOC4Jにデプロイするためのデプロイ構成が含まれており、これには、リソース・アダプタのデプロイメント・ディスクリプタに指定されているバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface（JNDI）の名前、接続プーリング・パラメータ、およびリソース・プリンシパル・マッピング・メカニズムと構成が含まれます。
アダプタのリクエスト/レスポンス・サービス用にXMLスキーマ定義（XSD）ファイルを生成するには、アダプタ設計時ツールを使用します。OC4Jクライアントは、実行時にこのXSDファイルを使用して、J2CAアウトバウンド相互作用をコールします。 パッケージ・アプリケーション・アダプタはOracleAS Adapter Application Explorer（Application Explorer）を、レガシー・アダプタはOracleAS Studioを、テクノロジ・アダプタはJDeveloperをそれぞれ使用します。
Oracle Application ServerアダプタはJ2CA 1.5仕様に基づいていますが、このリリースでは、J2CA 1.0リソース・アダプタとしてOC4Jコンテナ内にデプロイされています。J2CA 1.0仕様は、リクエスト/レスポンス・サービス（アウトバウンド相互作用とも呼ばれます）に対応していますが、アダプタによるバックエンド・イベントの非同期発行には対応していません。J2CA 1.5仕様は、ライフ・サイクル管理、メッセージ・インフロー（アダプタ・イベント発行用）および作業管理の規約に対応しています。
Oracle Application ServerアダプタはBPEL Process Managerに統合できます。この項の内容は、次のとおりです。
BPEL Process Managerは、BPELビジネス・プロセスを作成、デプロイおよび管理する包括的なソリューションです。BPEL Process Managerはサービス指向アーキテクチャ（SOA）に基づいて、柔軟性、相互運用性、再利用性、拡張性および迅速な実装を提供します。BPEL Process Managerを使用すると、既存のビジネス・プロセスの管理、変更、拡張および再デプロイ全般にわたるコストを削減できます。各ビジネス・アクティビティは自己完結型で自己記述的なモジュール・アプリケーションであり、WSDLファイルで定義されたインタフェース、およびWebサービスとしてモデル化されたビジネス・プロセスを使用します。
次の項では、テクノロジ・アダプタが、BPEL Process Manager 10.1.3内で、インバウンドまたはアウトバウンドで処理するすべてのメッセージの統計を、どのように収集および公開するかを説明します。
BPEL Process Manager 10.1.3では、ファイル、JMS、データベースなどのテクノロジ・アダプタが、インバウンドまたはアウトバウンドで処理するすべてのメッセージについて、統計を収集および公開します。 この統計はカテゴリおよび各タスクに分類されています。 アウトバウンド・プロセスにおける統計の分類の例を次に示します。
このアダプタ統計は、BPELコンソールから、BPELエンジンの統計と同じページで参照できます。 次に、BPELコンソールでアダプタ統計を表示する手順を説明します。
ここに現在アクティブなインバウンドおよびアウトバウンドのアダプタ相互作用の全リスト、および各アダプタが実行する様々なステップの平均実行時間が示されています。
統計収集をリセットするには、リンク「統計データの消去」をクリックします。
J2CA 1.5リソース・アダプタとBPEL Process Managerの双方向統合には、アダプタ・フレームワークが使用されます。アダプタ・フレームワークは標準に基づいており、Web Service Invocation Framework（WSIF）テクノロジを採用して、基礎となるJ2CA相互作用をWebサービスとして公開します。
アダプタをBPEL Process Managerに統合する間、基礎となるアダプタ・サービスは、J2CA拡張要素が指定されたWSDLファイルとして公開されます。次の表は、各種アダプタ用にWSDLファイルを生成する際に使用される設計時ツールのリストです。
| アダプタ | ツール |
|---|---|
|
テクノロジおよびOracleAS Adapter for Oracle Applications |
JDeveloper |
|
パッケージ・アプリケーション |
Application Explorer |
|
レガシー |
Oracle Studio |
WSDLファイルは、アダプタのリクエスト/レスポンス・サービスとイベント通知サービスの両方に対して作成されます。J2CA拡張機能にはJ2CA要素が含まれています。これらの要素は、実行時にJ2CA相互作用との間でWebサービス・メッセージの変換を行うアダプタ・フレームワークに必要です。J2CA WSDL拡張要素には、アダプタ・フレームワークがリクエスト/レスポンス・サービスをコールし、インバウンドのJ2CA 1.5エンドポイントをアクティブ化してインバウンド・イベントを受信するためのメタデータが含まれます。リクエスト/レスポンス・サービスのJ2CA拡張要素には、アウトバウンド相互作用をコールするためのJNDIロケーションおよびInteractionSpec詳細が含まれます。イベント通知サービスのJ2CA拡張要素には、J2CAインバウンド相互作用を介してアダプタ・イベントを発行するためのリソース・アダプタ・クラス名およびActivationSpecパラメータが含まれます。
図5-2は、テクノロジ・アダプタで使用する設計時ツールのJDeveloperを図で説明しています。
図5-3は、パッケージ・アプリケーション・アダプタとレガシー・アダプタを構成するための設計時ツールを図で説明しています。この図では、アダプタ・メタデータをWSDLファイルとして公開するために、設計時ツールが使用されています。このWSDLファイルは、実行時にBPEL Process Managerによって処理されます。
Oracle Application ServerアダプタはJ2CA 1.5仕様に基づいており、Oracle BPEL Process Managerを使用して同じOC4Jコンテナにデプロイされます。アダプタ・フレームワークは、実行時に標準J2CA 1.5リソース・アダプタをOracle BPEL Process Managerと統合するグルー・レイヤーとして機能します。Oracle Application Server OC4Jコンテナのサポート対象はJ2CA 1.0のみですが、アダプタ・フレームワークは疑似J2CA 1.5コンテナとして機能し、実装を可能にします。
アダプタ・フレームワークは、J2CA相互作用をWebサービスとしてラップするためのWSIF J2CAプロバイダで構成されています。さらに、アダプタ・フレームワークは、設計時に生成されたWSDLファイルに基づいて、Webサービス・メッセージをJ2CA相互作用メッセージに変換します。
WSIFプロバイダは、Webサービス起動（BPEL PMのinvokeアクティビティからの）をJ2CAアウトバウンド相互作用コールに変換し、逆方向の変換も実行します。つまり、BPELのinvokeアクティビティによって起動したWebサービス起動は、J2CA CCIアウトバウンド相互作用に変換され、J2CAレスポンスは元のWebサービス・レスポンスに変換されます。このエンドツーエンドの起動は同時に行われます。WSIFプロバイダは、一方向の非同期J2CAアウトバウンド相互作用の起動もサポートしています。WSIFプロバイダ要素では、J2CA実装詳細をBPEL Process Managerプロセスに明示せず、Webサービス詳細をJ2CA 1.5リソース・アダプタに明示しません。
BPEL Process Managerは、WSIFテクノロジを使用して、リソース・アダプタのリクエスト/レスポンス・サービスを開始します。WSIFは、Webサービスをコールし、Webサービス定義の抽象部分を物理バインド（転送とプロトコル）から分離して、サービス指向アーキテクチャ（SOA）を生成するために使用されます。次に、BPEL Process Managerとアウトバウンド相互作用を統合するプロセスを要約して説明します。
PartnerLinkアクティビティの構成時に処理されます。
InteractionSpecクラス名およびInteractionSpecパラメータが指定されます。
PartnerLinkアクティビティがコールされます。
ConnectionFactoryクラスのJNDI名が格納されています。
InteractionSpec Beanオブジェクトを作成します。
InteractionSpec、InputRecordおよび空のOutputRecordパラメータを渡してJ2CAアウトバウンド相互作用を開始します。
BPEL Process Managerは、疑似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とアダプタ・フレームワークで使用可能になります。
ResourceAdapterクラスのインスタンスが作成され、そのJ2CA ResourceAdapterクラスのStartメソッドがコールされます。
ResourceAdapterインスタンスのEndPointActivationメソッドが起動します。アダプタ・フレームワークは、J2CAインバウンド相互作用のWSDL拡張セクションに存在するActivationSpec詳細に基づいてActivationSpecクラス（JavaBeans）を作成し、J2CA 1.5リソース・アダプタのエンドポイントをアクティブ化します。
MessageEndpoint実装ではjavax.resource.cci.MessageListenerインタフェースが実装されます。 J2CA 1.5リソース・アダプタは、バックエンド・アプリケーション・イベントを受信した際に、このMessageEndpointでonMessage()メソッドをコールします。 J2CA 1.5リソース・アダプタは、endpointActivationの処理中にリソース・アダプタに提供されたMessageEndpointFactoryを介して、MessageEndpoint実装のインスタンスを作成します。
MessageListenerクラスを介してイベントを受信し、そのイベントをBPEL Process Managerインスタンスのreceiveアクティビティに転送します。
endPointDeactivationメソッドを介して非アクティブ化されます。
J2CAアダプタの場合、特にDBアダプタやAQアダプタなどJDBCベースのものついては、2種類の接続管理が行われます。1つはインバウンド（エンドポイント）のアクティブ化（BPEL受信）用、もう1つはアウトバウンド相互作用（BPEL起動）用です。
インバウンドのアクティブ化の場合、J2CAアダプタが接続作成およびリカバリ全般を管理します。 アダプタ・フレームワーク（AF）は、J2CA ConnectionFactoryハンドルをルックアップし、ActivationSpecを介してアダプタに提供するためにのみリクエストされます。 これは、接続の作成に使用可能な、Application Server接続マネージャを経由する特定のインタフェースを実装している場合にのみ可能です。 管理対象（JDBC）接続がうまくいかない場合、アダプタは、J2CA接続ハンドルを閉じ（Application Serverでdestroy()がコールされた場合は、これに続いて管理対象接続も閉じ）、テンポラリ・リカバリ・ループに入り、新しい接続の確立を試みます。
アウトバウンド相互作用（WSIFまたはJ2CA）の場合には、各WSIFポートは次のタプルをキャッシュします。
BPELエンジンでは通常、WSIFポートがいくつかの数のスレッドと同時に起動されるため、キャッシュ・サイズには常にその時点で最も高い並行処理レベルが反映されています。 このキャッシュは、設定したアイドル期間後に使用されていないタプルを自動的に期限切れにするように調整できます（その後、相互作用および接続ハンドルもクローズします）。このキャッシュによって、高負荷の環境、たとえばRetek（800万トランザクション/時）などの環境におけるパフォーマンスを大幅に改善できます。
キャッシュを使用するJCAアダプタ相互作用の1つのみがResourceExceptionをスローしても、キャッシュのすべてのメンバーがクローズされ即時解放（パージ）されるので、新しい相互作用はキャッシュに（新規に）メンバーを再作成する必要があります。 BPELエンジンには、パートナ・リンク再試行という機能があります。この機能は、起動のたびに実行されるように設定できます。 これにより、JCAアダプタの起動または相互作用でResourceExceptionがRetryableとマークされてスローされた場合はすべて、エンジンで起動（DB更新）が再試行され、この起動によってWSIFポート・キャッシュが再移入されます（DBが再び使用可能となった場合。主にRACの場合で即時）。
ファイル・アダプタなどの非トランザクション・アダプタ（adapterMetadata.supportsLocalTransactionDemarcation() == false）の場合は、J2CA接続キャッシュには1つのメンバーしか含まれていません。 そのため、入ってくるスレッドはすべて同じCCI接続ハンドルに多重に送られます。
JCA接続キャッシュは、次のbpel.xmlのパートナ・リンク・プロパティを使用して明示的に有効化または設定できます。
<property name="useJCAConnectionPool">true</property>
通常、このプロパティはアダプタの宣言済のトランザクション・サポートから導出されます。 たとえば、ファイル・アダプタではこの接続プールをマルチスレッド・セーフであるため使用しませんが、これは次のプロパティで上書きできます。
<property name="maxSizeJCAConnectionPool">500</property>
前述の例のプロパティが指定されていない場合、接続プールのサイズは無制限とみなされます。 これは、WSIFPort（パートナ・リンク）1つ当たりを基準に適用されます。
<property name="lruConnectionMaxIdleAge">50000</property>
プール内のアイドル接続の最長期間は、接続のタイプによっては高コストの外部リソースを保持することになるため、重要です。たとえば、ミリ秒で計測されるDBのシャドウ・プロセスなどです。次に例を示します。
property name="lruConnectionCheckInterval">10000</property>
前述の例のプロパティでは、アイドル接続についてどのくらいの頻度で接続プールをスキャンするかを、これもミリ秒単位で決定しています。
OracleAS Adapter for PeopleSoft、OracleAS Adapter for SAP R/3、OracleAS Adapter for SiebelおよびOracleAS Adapter for J.D. Edwardsを含むパッケージ・アプリケーション・アダプタは、OracleAS Integration InterConnectに統合できます。J2CAデプロイ以外に、パッケージ・アプリケーション・アダプタは、Business Service Engine（BSE）と呼ばれるWebサービス・サーブレット・デプロイをサポートしています。この統合は、エンタープライズ内、またはインターネットを介してエンタープライズ境界間でデプロイできます。OracleAS Integration InterConnectは、ハブ・アンド・スポーク・システムとして設計されています。このシステムでは、スポークは、他のアプリケーションおよびシステムにアクセスするOracleAS Integration InterConnectアダプタとして機能します。ハブは、スタンドアロンJavaアプリケーションであるOracleAS Integration InterConnectリポジトリ・サーバーとして機能します。OracleAS Integration InterConnectリポジトリは、設計時のメタデータ定義を保存するデータベースです。
BSEはOracleAS Integration InterConnect製品と統合され、パッケージ・アプリケーションにアクセスできます。インターネットによって異機種間情報システムに単純で一貫性のある接続を提供する標準を実装することで、このようなシステムをより迅速かつ高いコスト効率で一様に統合できます。ビジネス機能およびデータはWeb Serviceとして公開され、その他のプラットフォーム上のツールでは、これらのサービスを最小限の労力で使用できます。OracleAS Adapter Business Services Engineは、次の標準をサポートしています。
これらのサービスを生成するためのプログラミングの知識は不要です。これらのサービスは、ERPまたはCRMシステム、レガシー・アプリケーションおよび様々なデータ・ソースの機能を再利用します。
BSEはOracle Application ServerのOC4Jコンテナ内のサーブレットとしてデプロイされ、スケーラビリティおよび高可用性についてはOC4Jコンテナに依存します。Swingベースの設計時ツールであるApplication Explorerは、BSEに渡されるEISメタデータを参照するために使用されます。アダプタは、様々なアダプタ・サービス用のWSDLを作成し、XMLベースのファイル・リポジトリまたはOracle DatabaseリポジトリにWSDLスキーマを格納します。BSEは、設計時および実行時に実行する必要があります。
OracleAS Integration InterConnect EIS Adapter Pluginは、XSD形式とDTD形式の間でXMLペイロードを変換することで、OracleAS Web ServicesアダプタをOracleAS Integration InterConnectと統合します。
OracleAS Integration InterConnect製品は、実装済プロシージャ（リクエスト/レスポンス・サービス）、サブスクライブ（一方向のリクエスト・サービス）、パブリッシュ（イベント・サービス）および起動済プロシージャの4つのメッセージ・パラダイムをサポートしています（この場合、OracleAS Integration InterConnectはサーバーであり、EISはリクエストを行うクライアントです）。
OracleAS Integration InterConnect EIS Adapter Pluginは、最初の3つのメッセージ・パラダイムのみをサポートしています。 実装済プロシージャおよびサブスクリプションにはSOAP、リクエスト/レスポンスおよびイベント通知サービスにはRMIが使用されます。
OracleAS Integration InterConnectとの統合には、次のコンポーネントが使用されます。
Application Explorerは設計時にBSEを構成します。標準のWSDLスキーマ以外に、BSEはDTDスキーマを生成し、ユーザーが指定したファイル・システム内にローカルに保存します。OracleAS Integration InterConnect iStudioツールにはDTDブラウザ・プラグインが含まれています。このDTDブラウザ・プラグインを使用すると、DTDスキーマをネイティブのOracleAS Integration InterConnectスキーマに変換し、OracleAS Integration InterConnectリポジトリに格納できます。 具体的には、設計時に次の手順でリクエスト/レスポンスおよびイベント通知のシナリオを構成します。
OracleAS Integration InterConnect EIS Adapter Pluginは、独自のAPIを使用して、OracleAS Integration InterConnectリポジトリからメタデータをロードします。OracleAS Integration InterConnect EIS Adapter PluginはEISアプリケーションとインタフェースして、EISネイティブ形式と「アプリケーション・ビュー」（OracleAS Integration InterConnectで認識される形式）の間でデータを変換します。 この相互作用を図6に示します。次の手順で、より具体的にリクエスト/レスポンスおよびイベント通知のシナリオの実行時の動作を示します。
OracleAS Integration InterConnectハブは、OracleAS Integration InterConnect EIS Adapter Pluginにリクエストを送信します。OracleAS Integration InterConnect EIS Adapter Pluginは、SOAPクライアント・リクエストを作成して、BSEをコールします。アダプタはEISを起動して、EISレスポンスをSOAPレスポンスとしてOracleAS Integration InterConnect EIS Adapter Pluginに転送します。OracleAS Integration InterConnect EIS Adapter Pluginは、SOAPレスポンスを適切なOracleAS Integration InterConnect形式に変換して、OracleAS Integration InterConnectハブに転送します。
BSEは、チャネル・コンポーネントを介してEISイベント通知を受信します。このイベントは、RMIリクエストとしてOracleAS Integration InterConnect EIS Adapter Pluginに転送されます。OracleAS Integration InterConnect EIS Adapter PluginはRMIサーバーとして機能してこのイベントを処理し、適切なOracleAS Integration InterConnect形式に変換して、OracleAS Integration InterConnectハブに転送します。
OracleAS Adapter J2CAは、リクエスト/レスポンス・サービスなどの同期アウトバウンド相互作用のみをサポートします。イベント通知はサポートしません。実行時に、EJB、サーブレットまたはJavaアプリケーション・クライアントは、CCI APIを介してOracleAS Adapter J2CAと通信します。OracleAS Adapter J2CAは、標準のJ2CA 1.0 Resource AdapterとしてOC4J内にデプロイされ、OC4Jコンテナ内で管理モードで実行されます。OracleAS Adapter J2CAは、BSEと同様に、Application Explorerを使用して構成されます。OracleAS Adapter J2CAは、実際にはアダプタSDKのJ2CAラッパーです。
OracleAS Adapter J2CAは汎用的です。OracleAS Adapter J2CAのリポジトリ・プロジェクトには、複数のEIS接続を含めることができ、複数のEISタイプと対話できます。リポジトリ・プロジェクトは、ファイルまたはデータベース・リポジトリに格納できます。ra.xmlファイルには、リポジトリ接続パラメータおよびリポジトリ・プロジェクト名が含まれます。OC4Jによって生成されるoc4j-ra.xmlファイルには、複数の管理ConnectionFactoryオブジェクトを指定できます。各オブジェクトは、異なるリポジトリ・プロジェクトとJNDI名を指します。特定のEISに接続するには、J2CA CCI ConnectionSpecクラスを使用してEISタイプおよびEIS接続名を指定します。
OracleAS Adapter J2CAでCCIを使用するには、次の手順を実行します。
ConnectionFactoryオブジェクトを検索します。
ConnectionSpecオブジェクトを作成します。
ConnectionFactoryおよびConnectionSpecオブジェクトを使用して、EISへのConnectionを作成します。
Interactionオブジェクトを作成します。
execute()メソッドをコールします。
InteractionおよびConnectionオブジェクトを閉じます。
この項の内容は次のとおりです。
Enterprise Service Bus（ESB）は、エンタープライズ内外を問わず複数のエンドポイント間でデータを移動させます。 Enterprise Service Bus（ESB）は、オープン・スタンダードを使用して、多様なアプリケーション間でビジネス文書を（Extensible Markup Language（XML）メッセージとして）接続、変換およびルーティングします。 これにより、既存のアプリケーションにあまり影響を与ることなく、ビジネス・データの監視および管理が可能になります。 Enterprise Service Busは、サービス指向アーキテクチャ（SOA）およびイベントドリブン・アーキテクチャ（EDA）を提供するための基盤となるインフラストラクチャです。
Oracle Enterprise Service Busは、SOAおよびEDAを使用するサービスのためのベースとなります。 そのコアの部分は疎結合されたアプリケーション・フレームワークで、業界標準を使用する、異機種間に分散されたメッセージ指向の環境において、ビジネスに柔軟性、再利用性および全面的な応答性をもたらします。
接続性は、アダプタ・サービスおよびSimple Object Access Protocol（SOAP）呼出しサービスを通じて提供されます。
Oracle JDeveloper ESB Designerでサービスを作成して、Oracle Enterprise Service Busを、ファイル・システム、データベース表、データベース・キュー、Java Message Services（JMS）、およびOracle E-Business SuiteとすべてのSOAPサービスに統合できます。
サービスはEnterprise Service Busの主要部分です。Oracle Enterprise Service Busの設計では、様々なサービスを作成し、メッセージがService Busへ移動し、Service Bus内を通り、Service Busから出ていくようにします。
Service Busへデータを移動させるには、インバウンド・アダプタ・サービスを使用するか、外部アプリケーションからESBサービスがコールされるようにします。
Service Busからデータを移動させるには、アウトバウンド・アダプタ・サービスを使用するか、外部SOAPサービスを起動します。
Service Bus内でデータを移動させ、データ構造をソース・アプリケーションでの構造からターゲット・アプリケーションで必要とされる構造へ変換させるには、ルーティング・サービスを使用します。
Oracle Enterprise Service Busでは、Oracle Technologyアダプタ用のサービスの作成がサポートされています。 Oracle Technologyアダプタを使用することにより、メインフレームおよびレガシー・アプリケーションをEnterprise Resource Planning（ERP）、Customer Relationship Management（CRM）、データベースおよびメッセージ・システムに統合できます。
Oracle JDeveloper ESB Designerでは、インバウンドおよびアウトバンドのアダプタ・サービスの作成を補助するウィザードが提供されます。 このウィザードでは、サービスを定義するWSDLファイルを生成するために必要な情報を収集します。
アダプタ・サービスは、インバウンドまたはアウトバウンドのアダプタ・サービスとして構成できます。 インバウンド・アダプタ・サービスはOracle Enterprise Service Busにメッセージを送信し、アウトバウンド・アダプタ・サービスはOracle Enterprise Service Busの外部のアプリケーションまたはシステムにメッセージを送信します。
この項では、アダプタ・フレームワークの機能について、リリース10.1.3のOracle Enterprise Service Busでサポートされるものとサポートされないものを説明します。
次の機能は、リリース10.1.3のOracle Enterprise Service Busでサポートされます。
パートナ・リンク/アクティブ化エージェント（bpel.xml）のプロパティ
リリース10.1.3では、アダプタ・フレームワークは、oracle.tip.esb.jca.ESBActivationAgent.activateEventを介してESBActivationAgentに渡されたパートナ・リンクおよび/またはアクティブ化エージェントのプロパティを、java.util.Mapを介して受け取ります。
このマップの起点はBPEL内で使用可能なbpel.xml（BPELアクティブ化フレームワークで提供）ですが、どのようなタイプの名前または値セットもソースにすることが可能です。 これらのプロパティは、最終的にEndpointPropertiesAssociationインタフェースを通じてResourceAdapterに提供されます。
アウトバウンドWSIFでのexecute()の再試行
WSIF操作のexecuteRequestResponseOperation()メソッドは、oracle.tip.esb.serviceimpl.outadapter.OutboundAdapterService.nextService()メソッド内で起動します。
リリース10.1.3では、すべてのWSIFExceptionがEsbServiceExceptionにリンクされ、processBusinessEventから伝播します。
WSIFExceptionにはisRetryable()というブール・フラグがあり、サービス・コールを再試行するか中断するかを決めるために使用できます。
この再試行の編成は、BPELで現行使用されているものと同じパートナ・リンク・プロパティによって制御できます。 たとえばretryInterval（秒）、retryMaxCountなどです。 retryMaxCountはオプションで、省略された場合は無制限となることに注意してください。
インバウンドでのonMessage()の再試行
リリース10.1.3では、ESBListenerImpl.onMessage()からはどのような例外もリソース・アダプタに戻されません。 ただし、次の2つのJCA ResourceExceptionフレーバを考慮する場合があります。
リカバリ不能な（再試行しない）ケース
oracle.tip.adapter.api.exception.PCResourceException（ResourceExceptionを拡張）
リカバリ可能な（再試行する）ケース
oracle.tip.adapter.api.exception.PCRetriableResourceException（PCResourceExceptionを 拡張）
インバウンドでの拒否の処理
アクティブ化エージェント（bpel.xml）のプロパティは現在サポートされていないため、アダプタ・フレームワーク・サポートの拒否処理全般は使用可能ではありません。 ただし、デフォルトの拒否ハンドラが使用できるため、明示的に宣言された例外ハンドラがない場合は、このハンドラを作動できます。
致命的なエラーの処理
ESBListenerImpl.onFatalError()が起動した場合、ESBListenerImpl.javaは現在のところ、単にJCA EndpointDeactivation()を起動します。この結果、リソース・アダプタの作業スレッドが終了します（イベントのプーリングは停止します）。
アラート
ESBListenerImpl.onAlert()が起動した場合、ESBListenerImpl.javaは現在のところ、特に何もしません。 onAlert() APIは、インバウンド・リソース・アダプタから操作コンソールへ、重要またはクリティカルな（あるいはその両方の）状態変更について通信するためのもので、これによって、適時に手動操作を行うことが可能になります。これには、たとえば、データベースや他のEIS機能の再起動などがあります。
Oracle Enterprise Service Bus 10.1.3でサポートされない機能は次のとおりです。
ESBListenerImplのクラスタ化されたインスタンス間での透過的フェイルオーバー
XPathフィルタリング
Oracle Application Serverアダプタでは、社内のほぼすべてのデータ・ソースに双方向でリアルタイムなデータ・アクセスが可能です。
アダプタは、サポートするソース・アプリケーションのイベントをリスニングまたはポーリングします。 イベントをリスニングする場合、アダプタは、イベントをアダプタにプッシュするよう構成されたアプリケーションのリスナーとして登録されます。 また、アダプタはOracle Enterprise Service Busで必要とされるイベントについて、データベースやファイルなどのバックエンド・アプリケーションのポーリングもできます。
Oracle Enterprise Service Busにアダプタを（ウィザードを使用して）登録することにより、外部データ・ソースをOracle Enterprise Service Busに統合し、最終的には相互に統合します。
Oracle Enterprise Service Busサーバーでは、現在、次の表に記載されたOracleアダプタをサポートしており、これにより、インバウンドおよびアウトバウンドのアダプタ・サービスをそれぞれ定義できます。 インバウンド・アダプタ・サービスでは、外部データ・ソースからデータを受信し、これをXMLメッセージに変換します。 アウトバウンド・アダプタ・サービスでは、XMLメッセージを所定のアダプタのネイティブ・フォーマットに変換して、ターゲット・アプリケーションへデータを送信します。
インバウンド・アダプタ・サービスを除き、Oracle Enterprise Service Busサービスとして作成するアウトバウンド・アダプタ・サービスやルーティング・サービスなどのサービスはすべて、SOAPサービスとして、詳細の構成の必要なく自動的に作成されます。 インバウンド・アダプタ・サービスの場合は、手動でSOAPサービスとして構成する必要があります。Oracle Enterprise Service Busでは、構成プロセスの手順に沿ったウィザードが提供されます。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|