WLIデータベース・イベント・ジェネレータとOracleデータベース・アダプタの比較

Nacho Lafuente、Miquel Lopez-Miralpeix著

2009年4月公開

関連するダウンロード・リンク Oracle SOA Suite

[ 1ページ] [ 2ページ] [ 3ページ]

Oracle Application Server Adaptersには、テクノロジー、パッケージ・アプリケーション、およびレガシー・アプリケーションの3種類があります。

以下のOracle ASテクノロジー･アダプタは、標準で提供されています。

• ファイル・アダプタ
• FTPアダプタ
• データベース・アダプタ
• AQアダプタ
• JMSアダプタ
• MQアダプタ
• 電子メール・エージェント
• HTTPエージェント

Oracle BPEL PMとアダプタ

BPELプロセスとのやり取りがあるすべてのサービスは、パートナー・リンクと呼ばれます。 Oracle BPEL PMには、SOAPパートナー・リンクに対するネイティブ・インタフェースがありますが、そのほかのやり取りについてはアダプタが使用されます。 アダプタ・サービスは、BPELにおいて、そのほかのパートナー・リンクと同じように表されます。 BPELプロセスは、SOAPパートナー・リンクとやり取りする際も、アダプタ・パートナー・リンクとやり取りする際も、違いはありません。

Oracle BPEL PMのアダプタ向けクラスタリング・サポート

注目すべき点は、アダプタがクラスタリングを完全にサポートしているため、基盤となるテクノロジーに最適なソリューションが提供されるということです。 アクティブ-アクティブ・クラスタ構成は、基盤となるテクノロジーがサポートしない場合があるため、すべてのアダプタに適しているわけではありません（ファイル・アダプタなど：多くのファイル・システムでは、同時実行性を制御できません）。このため、Oracle BPELのアダプタ・フレームワークでは、インバウンド・アダプタ・サービスのアクティブ・フェイルオーバーをサポートしています。 次の例に示すとおり、特定のJCAアクティブ化エージェントにプロパティを追加する（BPELプロセスのすべてのパートナー・リンクと、アクティブ化エージェントを格納したbpel.xmlファイルで指定する）ことで、これを実行できます。

<activationAgents>
                                    


  <activationAgent className="..." partnerLink="MyInboundAdapterPL">
                                    


    <property name="clusterGroupId">myBpelCluster</property>
                                    


                                  

クラスタ内のOracle BPEL PMサーバー（JVM）は、TCP/IPのサブネット境界にまたがって配置できます。これを実行するには、属性clusterAcrossSubnet=trueを追加します。

クラスタ・グループにおいて、同じアダプタ（たとえば、ファイル・アダプタ）のアクティブ化エージェントが、（特定のパートナー・リンクに対して）複数アクティブ化されると、そのクラスタ内でアクティブな、すべてのアダプタ・フレームワーク・インスタンスによって暗黙的かつ自動的に検出がおこなわれます。 実際にメッセージの読取りまたはパブリッシュを開始できるのは、1つのアクティブ化だけです。 アダプタ・フレームワーク・インスタンスの中から、プライマリのアクティブ化を引き受ける1つのインスタンスがランダムに決定されます。 クラスタ内の残りのアクティブ化（インスタンス）はホット・スタンバイ状態を開始しますが、実際には、JCAリソース・アダプタに対してエンドポイントをアクティブ化しません。

ある時点で、プライマリのアクティブ化が応答しなくなった場合、手動で無効化をおこないます。プライマリがクラッシュまたは終了した場合は、クラスタ・グループの残りのアダプタ・フレームワーク・メンバーのうちの1つによってすぐに検出され、スタンバイしているいずれかのアクティブ化エージェントに、アクティブ化のプライマリとしての役割が再割当てされます。 この機能の実装には、内部で、JGroupsのclusterGroupIdプロパティが使用されています。

バッチおよびデバッチのサポート

バッチ機能とデバッチ機能をサポートしているのは、Oracle AS Adapters for Files、Oracle AS Adapters for FTP、およびOracle AS Adapters for Databasesです。 Oracle AS Adapters for FileとOracle AS Adapters for FTPは、1つの大きなファイルを数個のバッチにデバッチするためのリーダーで構成されており、最適なメッセージ・サイズを選択できます。 設計時の設定において、バッチ・サイズを指定しておく必要があります。 また、アダプタには、一連のメッセージを1つのファイルにバッチ化するライターが含まれています。

Oracle AS Adapters for Databasesは、一連の表をポーリングしてイベントを検出するパブリッシュ・コンポーネントで構成されています。 このコンポーネントは、BPELプロセスにイベントを発生させる際、一度に1レコードまたは複数レコードを処理できます。

同様に、バッチ書込みを使用して、1回の起動で複数レコードをデータベースに挿入できます。

Oracle AS Adapters for Databases（DBAdapter）

Oracle AS Adapters for Databasesでは、XMLデータ（オブジェクト）からリレーショナル・スキーマへ、またその逆へのマッピングに使用するテクノロジーとして、Oracle Toplinkを使用しています。 多くの場合、SQLコーディングの必要はなく、ほとんどの設定はアダプタ･ウィザードからおこなえます。

上記アーキテクチャの結果として、JDBCに準拠したすべてのデータベースがサポートされており、また、接続の詳細は、プロセス・レベルでもアダプタ・レベルでも、またはJEEコンテナ・データソースとしても供給できるため、ほかのアプリケーションとのプール共有が可能になります。 これにより、あらゆる状況に適した、きわめて柔軟な接続管理が実現されます。

アウトバウンド・インタラクションの場合、次のとおり、多数の処理が実行できます。

• Insert：データベースへ新規レコードを挿入します。
• Update：データベースにある既存レコードを更新します。
• Write：レコードが存在するかどうか気にせず、レコードを挿入または更新します。
• Delete：データベースからレコードを削除します。
• Merge：はじめにデータベースから該当レコードを読み取り、変更を算出してから、最小限の更新を実行します。
• Select：特定の条件に合ったレコードを検索します。 複数の問合せを別々の処理として定義することもできます。
• PureSQL：TopLinkのバイパスにより任意のSQLを実行します。 SQLを入力すると、ウィザード内でイントロスペクトおよび実行され、対応するXSD（こちらも編集可能）が生成されます。
• QueryByExample：SELECT処理とは違い、設計時に選択条件を指定する必要はありません。
• プロシージャまたはファンクションを実行します。

インバウンド・インタラクションの場合、以下のいずれかのポーリング計画を選択できます。

• 物理削除ポーリング計画では、データベース表でレコードをポーリングし、処理したあと削除します。
• 論理削除ポーリング計画では、処理された各行の特別フィールドを更新し、処理済みの行を除外するために、実行時にWHERE句を更新します。
• 順序表：最終読取りID ポーリング計画では、順序値を保存するためにヘルパー表が使用されます。
• 順序表：最終更新 ポーリング計画では、last_updated値を保存するためにヘルパー表が使用されます。
• 制御表ポーリング計画では、まだ処理されていないすべての行の主キーを保存するために、制御表が使用されます。 このポーリング・アプローチは、SEQUENCING_HELPER表を別のデータベースに作成することで、完全な簡素化を実現しています。 ソース表やそのスキーマに対する変更はおこなわれず、ソース表に対して実行されるDML文のみがポーリング対象となります。 （WLIのイベント・ジェネレータが作成するような）トリガーつきのシャドウ表を作成する必要はありません。 このポーリング・アプローチは、子表に対する更新のポーリングもサポートしています。 たとえば、注文表と明細項目表の両方にlast_updated列があれば、既存の注文に対して新たな明細項目が追加された場合も、その注文が選択され、再度処理されます。

設計時に、ユーザーは複数の関連表をインポートできます。 DBAdapterによってすべての外部キーが調査され、可能性があるすべての関係が提示されるため、ユーザーはここから選択できます。 または、論理制約を使用して、ユーザーが独自にウィザード内で関係をモデリングすることもできます。

生成されたXML構造は、選択された表をルートのXML要素として、そして結合された表をサブタイプやコレクションとして、ネストされています。

次に、このようなデータ構造の例を示します。

   <xs:complexType name="Departments">
                                    


      <xs:sequence>
                                    


         <xs:element name="departmentId" type="xs:int"/>
                                    


         <xs:element name="departmentName" minOccurs="0">
                                    


            <xs:simpleType>
                                    


               <xs:restriction base="xs:string">
                                    


                  <xs:maxLength value="30"/>
                                    


               </xs:restriction>
                                    


            </xs:simpleType>
                                    


         </xs:element>
                                    


         <xs:element name="locationId" type="xs:int" minOccurs="0" nillable="true"/>
                                    


         <xs:element name="manager" type="Employees" minOccurs="0" nillable="true"/>
                                    


         <xs:element name="departmentCollection" minOccurs="0">
                                    


            <xs:complexType>
                                    


               <xs:sequence>
                                    


                  <xs:element name="Employees" type="Employees" minOccurs="0" maxOccurs="unbounded"/>
                                    


               </xs:sequence>
                                    


            </xs:complexType>
                                    


         </xs:element>
                                    


      </xs:sequence>
                                    


   </xs:complexType>
                                    


                                  

このデータ構造では、Employeesというタイプの要素managerが、部門と従業員のN対1関係を表しており、もう1つの要素departmentCollectionが、部門と従業員の1対N関係を表す従業員リストに相当していることがわかります。

以上のとおり、Oracle BPEL PMは、常にネイティブでXML構造を処理し、SQLタイプやコマンドへの変換をおこなうアダプタの役割を果たします。

次に、データベース・アダプタのアーキテクチャを論理的に見た図を示します。

インバウンドDBAdapterは、次の順序で各処理を実行します。

• スケジュール（設定可能）に従ってアクティブ化する。
• ポーリング計画に従ってプロセッサをアクティブ化する。
• すべてのポーリング計画で、次のパラメータを設定できます。
  • スレッド数（10.1.3.1以降）。
  • 1回のデータベース読取りで取得できる最大行数。
  • 1つのメッセージとしてBPELに送信される最大行数。
  • バッチによる行の削除－この機能はWLIで提供されていません。

DBAdapterの高度な概念

DBAdapterの設定

高度な設定について詳しくは、『 Oracle® Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド』を参照してください。 DBAdapterに適用される各種の設定については、十分に注意してください。

メッセージ構造

DBAdapterパートナー・リンクは、設計時のパートナー・リンク生成で定義されたXMLスキーマに準拠したメッセージをパブリッシュ（インバウンド）および受信（アウトバウンド）します。 BPELプロセスの観点から見ると、一般的なSOAPパートナー・リンクとDBAdapterパートナー・リンクの間で、メッセージ操作に違いはありません。

1回のポーリングとイベントで処理できる最大行数

DBAdapterの1回のポーリングとイベントで処理できる行数は、次のパラメータを設定することで制御できます。

• NumberOfThreads： データベースを読み取る同時スレッド数
• MaxTransactionSize： 1回のトランザクションで、データベースからアダプタにフェッチされる最大行数
• MaxRaiseSize： 1つのメッセージとしてアダプタからBPELに送信される最大行数

トランザクションの動作

すべてのBPELプロセスはトランザクション型であり、DBAdapterにもこの動作によるメリットがあります。 インバウンド・インタラクションの場合、パラメータdeliveryPersistPolicy（off.immediateまたはon）の値によって、取得プロセスと削除プロセスがBPELプロセスのトランザクションに含まれるケースと、別のトランザクションになるケースがあります。

deliveryPersistPolicyがon（デフォルト値）に設定されている場合、メッセージはデリバリ・サービス（DS）に保持され、処理可能になったMDBスレッドによって処理されます。

deliveryPersistPolicyがoff.immediateに設定されている場合、メッセージはDSに保持されず、アダプタ・スレッドがBPELプロセスを実行します。 プラットフォームの問題によってメッセージが処理されない場合、トランザクションはロールバックされ、次回、再度読み取られます。 WLIの場合、この機能が提供されていないため、処理は常に、メッセージ取得（1つのスレッド）とそのあとのメッセージ処理（非同期で有効化されるもう1つのスレッド）に分かれます。

これにより、データベース・トラフィックを削減する必要がある場合に、信頼性を損なうことなくこれを実現できるため、BPELプロセス のチューニングの柔軟性が大幅に向上します。

アウトバウンド・インタラクションは、BPELプロセス・トランザクションの内部で処理されます。 データソースがJEEコンテナ・レベルでどのように定義されているか（グローバル・トランザクションまたはローカル・トランザクション）、また、実行対象となるデータベースのプロシージャまたはファンクションにCOMMITやROLLBACKが含まれているかどうかを考慮に入れることが重要です。

ユースケースの例

WebLogic Administration Consoleを使用してJDBCデータソースを作成する方法については、『 JDBC データソースの作成』を参照してください。 このサンプルでは、Oracle Thin/XAドライバを使用して、databaseEGPoolというデータベース・プールを作成しています。このドライバは、Oracle 10g XEに同梱されているHuman Resources（HR）スキーマを参照します。

データベース・イベントを処理するWLIプロセスの作成

データベースで生成されたイベントを処理するために、サンプルのWLIプロセスを作成します。 このプロセスはイベント受信の説明のみを目的としており、そのほかの処理は実行しません。 "databaseeg"という名前の新規パッケージを作成します。 このパッケージ、"DatabaseEGWeb"プロジェクトの"Java resources"フォルダ内に作成されます。

1. 「 DatabaseEGWeb」プロジェクトをクリックして、選択可能なサブフォルダの一覧を表示します。
2. 「 Java Resources」を開きます。
3. 「 src」フォルダを右クリックし、ポップアップ・メニューから「 New」→「 Package」の順に選択します。
4. パッケージに"databaseeg"という名前をつけてから、「 OK」をクリックします。

このプロセスはメッセージ・ブローカ・チャネルを介して有効化されるため、新規チャネル定義を作成する必要があります。 このチャネル定義は、先ほど作成した"DatabaseEGWeb"プロジェクトの"databaseeg"Javaパッケージ内に作成します。

1. "DatabaseEGWeb"プロジェクトへ移動し、「 Java Resources」 →「 src」→「 databaseeg」の順に展開します。
2. 「 databaseeg」パッケージ・フォルダを右クリックし、ポップアップ・メニューから「 New」 →「 Channel Definition」の順に選択します。
3. チャネル定義ファイル名として、"DatabaseEG.channel"を使用します。
4. チャネル定義ファイルを編集して、"SimpleXml"という名前のシンプルなXMLチャネルを作成します。 このチャネル・タイプは指定しません。 次に、このチャネル定義を抜粋したものを示します。

<?xml version="1.0"?>
                                    


<channels xmlns="http://www.bea.com/wli/broker/channelfile"
                                    


channelPrefix="/DatabaseEventGenerator"
                                    


xmlns:eg="http://www.bea.com/wli/eventGenerator"
                                    


xmlns:dp="http://www.bea.com/wli/control/dynamicProperties">
                                    


       <!- A simple channel passing XML ->
                                    


       <channel name ="SimpleXml" messageType="xml"/>
                                    


</channels>
                                    


                                  

チャネル定義を作成したら、データベース・イベントを処理する新しいWLIプロセスの作成を開始します。

1. パッケージ・フォルダ「 databaseeg」を右クリックします。
2. 「 New」→「 Process」の順に選択します。
3. プロセス名として、"DatabaseEG"を指定します。

この結果作成される、空のWLIプロセスを次の図に示します。

メッセージ・ブローカ・チャネルがメッセージを受信すると、このプロセスは有効化されます。

開始ノードをダブルクリックすると、ダイアログが表示され、プロセスの起動方法を選択できます。 「 Subscribe to a Message Broker Channel...」を選択します。

開始ノードをダブルクリックして、「 General Settings」タブを選択します。 このプロセスがリスニングするチャネル名として、先ほど作成したチャネル定義「 /DatabaseEventGenerator/SampleXml」 を選択します。