この章では、アダプタをOracle SOA SuiteおよびOracle WebLogic Serverと統合する方法について説明します。
この章の内容は次のとおりです。
Oracle JCAアダプタはJ2CA 1.5仕様に基づいており、Oracle WebLogic Serverにデプロイされます。リソース・アダプタは、Fusion Middlewareと同じJava仮想マシン(JVM)で実行されます。この項では、Oracle WebLogic Serverの概要と、アダプタとの設計時および実行時の統合について説明します。
この項には次のトピックが含まれます:
Oracle WebLogic Serverは、スケーラブルなエンタープライズ対応のJavaプラットフォームであり、Enterprise Edition(Java EE)のアプリケーション・サーバーです。WebLogic Serverインフラストラクチャは、様々なタイプの分散アプリケーションのデプロイをサポートしています。サービス指向アーキテクチャ(SOA)に基づくアプリケーションを構築する上で理想的な基盤です。
すべてのクライアント・アプリケーションは、Oracle WebLogic Server環境で実行されます。Oracle WebLogic Serverクライアント・アプリケーションをリソース・アダプタと統合するには、Common Client Interface (CCI)を使用します。Oracle WebLogic Serverアダプタ・クライアントには、CCIアプリケーション・プログラム・インタフェース(API)を実装するサーブレット、EJBまたはJavaアプリケーション・クライアントがあります。CCIでは、アプリケーション・コンポーネントがバックエンド・アプリケーションにアクセスするための標準的なクライアントAPIが定義されます。
これに対して、Oracle WebLogic Serverコンテナとリソース・アダプタの間の規定は、サービス・プロバイダ・インタフェース(SPI)により定義されます。規定により、Oracle WebLogic Serverとアダプタの間の標準が定義されます。これらの規定はシステムにより自動的に処理され、アプリケーション開発者から隠されます。図3-1 に、CCIとSPIの規定を示します。
Oracle WebLogic Serverアーキテクチャには、次に示すシステム・レベルの一連の規定が含まれています。
接続管理: アプリケーション・コンポーネントがバックエンド・アプリケーションに接続して、Oracle WebLogic Serverコンテナの接続プーリング・サポート機能を利用できるようにします。これにより、バックエンド・アプリケーションへのアクセスを必要とする多数のコンポーネントをサポートできるスケーラブルで効果的な環境が得られます。詳細は、「アダプタ・コネクション・ファクトリの追加」を参照してください。
トランザクション管理: アプリケーション・サーバーがトランザクション・マネージャを使用して、複数のリソース・マネージャ間のトランザクションを管理できるようにします。ほとんどのアダプタではローカル・トランザクション(1フェーズ・コミット)のみがサポートされ、XAトランザクション(2フェーズ・コミット)はサポートされていません。詳細は、「メッセージの損失がないことをOracle JCAアダプタで保証する方法」を参照してください。
すべてのOracle JCAアダプタはトランザクションについて適切な値を使用して事前に構成されており、この構成はOracle WebLogic Server管理コンソールで変更しないでください。
セキュリティ管理: WebLogic Serverのセキュリティ・アーキテクチャは、Web上でアプリケーションを使用可能にするというセキュリティ上の課題に対処するように設計された包括的で柔軟なセキュリティ・インフラストラクチャを提供します。WebLogicのセキュリティは、スタンドアロンで使用してWebLogic Serverアプリケーションを保護したり、最良のセキュリティ管理ソリューションを表すエンタープライズ単位のセキュリティ管理システムの一部として使用できます。
J2CA 1.5仕様に基づいており、このリリースではOracle WebLogic ServerコンテナにJ2CAリソース・アダプタとしてデプロイされます。J2CAリソース・アダプタは、Javaアーカイブ(JAR)フォーマットを使用してリソース・アダプタ・アーカイブ(RAR)にパッケージされます。RARファイルには、適切にフォーマットされたデプロイメント・ディスクリプタ(/META-INF/ra.xml)
が含まれています。さらに、Oracle WebLogic Serverとリソース・アダプタの間の規定に関する宣言情報も含まれています。
Oracle WebLogic Serverでは、J2CAアダプタのデプロイメント中に対応するweblogic-ra.xml
ファイルが生成されます。weblogic-ra.xml
ファイルは、リソース・アダプタ用のデプロイメント・ディスクリプタです。これにはリソース・アダプタをOracle WebLogic Serverにデプロイするためのデプロイ構成が含まれています。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface (JNDI)名、接続プーリング・パラメータ、リソースのプリンシパル・マッピング・メカニズムおよび構成などが含まれます。
アダプタ設計時ツールを使用して、アダプタのリクエスト-レスポンス・サービス用のWSLD、XSDおよびJCAアーティファクトを生成します。これらのアーティファクトに含まれる情報は、JCA相互作用の作成時に使用されます。Oracle WebLogic Serverクライアントでは、これらのXSDファイルが実行時に使用されて、J2CAアウトバウンド相互作用がコールされます。
パッケージ・アプリケーション・アダプタでは、OracleAS Adapter Application Explorer (アプリケーション・エクスプローラ)が使用され、レガシー・アダプタではOracleAS Studioが使用され、テクノロジ・アダプタではOracle JDeveloper (JDeveloper)が使用されます。
詳細は、「設計時」を参照してください。
アダプタにより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テクノロジ・アダプタでは、処理するすべてのインバウンドおよびアウトバウンド・メッセージの統計を収集およびパブリッシュします。詳細は、「監視」を参照してください。
アダプタとOracle Service Busの使用の詳細は、『Oracle® Fusion Middleware Oracle Service Bus開発者ガイド』のアダプタの使用に関する説明を参照してください。Open Service Bus (OSB)では、.jcaファイルがcomposite.xml自体によって参照されるのではなく、プロキシ/ビジネス・サービスによって参照されることが唯一の違いです。
この項には、次の項目が含まれます。
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バインディング・コンポーネントが使用されています。WSDLファイルおよびJCAバインディングが生成され、Webサービスとして基礎になる相互作用が公開されます。
アダプタ・サービスへのインタフェース(入力/出力XML要素)は、WSDLファイルを介して記述されます。ただし、リリース11gでは、バインディング要素が削除され、WSDLファイルが抽象になっています。かわりに、JCAバインディング・コンポーネント(以前のリリースにおけるアダプタ・フレームワーク)とアダプタが特定のEIS上で特定のコールについて起動するために必要とするバインディング情報は、個別のbinding.jca
ファイルに格納されます。
この項では、次の内容について説明します。
アダプタをOracle BPEL PMおよびOracle Mediatorと統合する間に、基礎となるアダプタ・サービスがJ2CA拡張を使用するWSDLファイルとして公開されます。次の表に、各種アダプタ用のWSDLファイルとJCAファイルの生成に使用する設計時ツールを示します。
アダプタ | ツール |
---|---|
Oracleテクノロジ・アダプタ |
Oracle JDeveloper |
メインフレームおよびTPモニター・アダプタ |
Oracle Studio |
パッケージ・アプリケーション・アダプタ |
アプリケーション・エクスプローラ |
Oracle Applications用のOracleアダプタ |
Oracle JDeveloper |
WSDLファイルは、アダプタのリクエスト-レスポンス・サービスとイベント通知サービスの両方について作成されます。J2CA拡張には、JCAバインディング・コンポーネントで実行時にWebサービス・メッセージをJ2CA相互作用との間で変換するために必要なJ2CA要素が含まれています。J2CAのWSDL拡張要素には、JCAバインディング・コンポーネントでリクエスト-レスポンス・サービスをコールし、インバウンドJ2CA 1.5エンドポイントをアクティブ化してインバウンド・イベントを受信するためのメタデータが含まれています。リクエスト-レスポンス・サービス用のJ2CA拡張要素には、アウトバウンド相互作用をコールするためのJNDIロケーションとInteractionSpec
の詳細が含まれています。イベント通知サービス用のJ2CA拡張要素には、J2CAインバウンド相互作用を介してアダプタ・イベントをパブリッシュするための、リソース・アダプタ・クラス名とActivationSpec
パラメータが含まれています。
図3-3に、使用される設計時ツールのJDeveloperを示します。
図3-4 に、パッケージ・アプリケーション・アダプタの構成に使用する設計時ツールを示します。この図では、設計時ツールを使用して、アダプタ・メタデータがWSDLファイルとして公開されています。WSDLファイルは、実行時にBPEL Process Managerにより消費されます。
アダプタはJ2CA 1.5仕様に基づいており、BPELはOracle WebLogic Serverで実行時にデプロイされます。JCAバインディング・コンポーネントは、実行時に標準のJ2CA 1.5リソース・アダプタをOracle BPEL Process ManagerおよびOracle Mediatorと結び付けて統合するレイヤーとして機能します。
BPEL Invokeアクティビティにより開始されたWebサービスの呼出しはJ2CA CCIアウトバウンド相互作用に変換され、J2CAレスポンスはWebサービス・レスポンスに変換されます。
図3-5 に示すように、Oracle BPEL PMの「パートナ・リンク」ダイアログから、Oracle BPEL PMで提供されているアダプタにアクセスできます。
図3-6 に示すように「サービスの定義」アイコンをクリックし、「サービスまたはアダプタの設定」ダイアログにアクセスします。
このダイアログを使用すると、Oracle BPELプロセスで使用するアダプタ・タイプ(図3-7 を参照)を設定できます。
アダプタ・タイプを選択(この場合)し、「OK」をクリックすると、図3-8に示すように、「アダプタ構成ウィザード」 - 「ようこそ」ページが表示されます。
「次へ」をクリックすると、図3-9 に示す「サービス名」ページが表示されます。サービス名の入力を要求されます。
この例では、図3-7 に示すように「AQアダプタ」が選択されています。ウィザードが完了すると、BPELプロセスの「アプリケーション・ナビゲータ」にこのサービス名のWSDLファイルが表示されます(この例では、「DequeueDemo.wsdl」
という名前です)。このファイルには、このウィザードで指定したアダプタ構成設定が含まれます。その他の構成ファイル(ヘッダー・プロパティやアダプタ固有のファイルなど)も作成され、「アプリケーション・ナビゲータ」に表示されます。
「サービス名」ウィンドウ以降に表示されるアダプタ構成ウィザードのウィンドウは、選択したアダプタ・タイプによって異なります。これらの構成ウィンドウや指定する情報については、このガイドの後続の章で説明します。
SOAコンポジット・アプリケーションは、ビジネス・ニーズを満たすために設計されてデプロイされるサービス、サービス・コンポーネント、参照およびワイヤのアセンブリです。
SOAは、接続済エンタープライズ・アプリケーションの構築をサポートするエンタープライズ・アーキテクチャを提供します。SOAは、統合と再利用が容易で、柔軟かつ順応性のあるITインフラストラクチャを作成するモジュール型ビジネスのWebサービスとして、エンタープライズ・アプリケーションの開発を促進します。
コンポジットは、設計されて単一アプリケーションにデプロイされるサービス、サービス・コンポーネント、ワイヤおよび参照のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。
たとえば、コンポジットには、インバウンド・サービス・バインディング・コンポーネント(インバウンド・アダプタ)、BPELプロセス・サービス・コンポーネントおよびアウトバウンド参照バインディング・コンポーネント(アウトバウンド・アダプタ)が含まれます。このコンポジットの詳細は、composite.xml
ファイルに格納されます。
通常、Oracle SOAコンポジットは、次の各部で構成されています。
バインディング・コンポーネント
バインディング・コンポーネントにより、SOAコンポジットと外部との接続性が確立されます。バインディング・コンポーネントには、次の2種類があります。
サービス・バインディング・コンポーネント
外部に対してSOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。サービスのWSDLファイルにより、外部アプリケーションに機能が通知されます。これらの機能は、SOAコンポジット・アプリケーション・コンポーネントとの接続に使用されます。サービスのバインディング接続性により、Oracle JCAアダプタなどのサービスと通信できるプロトコルが記述されます。
参照バインディング・コンポーネント
SOAコンポジット・アプリケーションから外部にある外部サービスに送信するメッセージを有効にします。
Oracle SOA Suiteでは、サービスおよび参照をテクノロジ(データベース、ファイル・システム、FTPサーバー、メッセージング: JMS、IBM MQなど)およびアプリケーション(Oracle E-Business Suite、PeopleSoftなど)と統合するためのWebサービス(Oracle JCAアダプタなど)を提供します。これには次が含まれます。
サービス・インフラストラクチャ
内部メッセージ・トランスポートを提供します。たとえば、インバウンド・アダプタからメッセージを受信して、処理のためにBPELプロセス・サービス・エンジンにポストします。
サービス・エンジン(サービス・コンポーネントをホストするコンテナ)
サービス・コンポーネントのビジネス・ロジックまたは処理ルールをホストします。各サービス・コンポーネントには固有のサービス・エンジンがあります。たとえば、Oracle BPELプロセス・エンジンやOracle Mediatorコンポーネントなどです。
アダプタとサービス・エンジンの統合の詳細は、「アダプタとOracle Fusion Middlewareの統合」を参照してください。
UDDIとMDS
MDS(メタデータ・サービス)リポジトリには、使用可能なサービスの記述が格納されます。UDDIでは、これらのサービスが通知され、実行時における検出と動的バインディングを可能にします。
SOAアーカイブ: コンポジット
コンポジット・アプリケーションを記述するデプロイメント・ユニット。
コンポジットは、設計されて単一アプリケーションにデプロイされるサービス(インバウンド・アダプタなど)、サービス・コンポーネント、ワイヤおよび参照(アウトバウンド・アダプタなど)のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。SOAプロジェクトを作成すると、composite.xml
ファイルが自動的に作成されます。このファイルでは、サービス、サービス・コンポーネント、参照およびワイヤのコンポジット・アセンブリ全体が記述されます。つまり、composite.xml
ファイルではSOAコンポジット全体が記述されます。
composite.xml
のサンプルの詳細は、次の例を参照してください。
例 - 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 SOA SuiteでのSOAアプリケーションの開発』を参照してください。
Oracle BPEL Process ManagerおよびOracle Mediatorには、Oracle JCAアダプタ(ファイル、JMSおよびデータベースなど)があり、それぞれがインバウンドまたはアウトバウンドで処理するすべてのメッセージの統計が収集され、パブリッシュされます。統計は、カテゴリと個別タスクにわかれています。次の例に、アウトバウンド(参照)プロセス内で統計がどのようにわかれているかを示します。
アダプタの前処理
InteractionSpec
の準備
アダプタの処理
コール可能な文の設定
データベースの起動
結果の解析
アダプタの後処理
アダプタ統計は、Fusion Middleware Controlコンソールで表示できます。アダプタ統計を表示する手順は、次のとおりです。