| Oracle® Fusion Middlewareテクノロジ・アダプタの理解 12 c (12.1.3) E57554-05 |
|
 前 |
 次 |
この章では、アダプタを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アプリケーションを保護したり、最良のセキュリティ管理ソリューションを表すエンタープライズ単位のセキュリティ管理システムの一部として使用できます。
Oracle JCAアダプタは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 Service Busでのサービスの開発ガイドの「JCAトランスポートとJCAアダプタの使用」を参照してください。Open Service Bus (OSB)の場合の唯一の違いは、.jcaファイルがcomposite.xml自体により参照されるのではなく、OSBではこのファイルがプロキシ/ビジネス・サービスにより参照されることです。
この項には、次の項目が含まれます。
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ファイルに格納されます。
この項では、次の内容について説明します。
アダプタを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に、Oracle JCAアダプタで使用される設計時ツールのJDeveloperを示します。
図3-4に、パッケージ・アプリケーション・アダプタの構成に使用する設計時ツールを示します。この図では、設計時ツールを使用して、アダプタ・メタデータがWSDLファイルとして公開されています。WSDLファイルは、実行時にBPEL Process Managerにより消費されます。
Oracle Application Serverアダプタは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を参照)を設定できます。
アダプタ・タイプ(この例では「AQアダプタ」)を選択して「OK」をクリックすると、図3-8に示すアダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックすると、図3-9に示す「サービス名」ページが表示されます。サービス名の入力を要求されます。
この例では、図3-7に示すように「AQアダプタ」が選択されています。ウィザードが完了すると、BPELプロセスの「アプリケーション・ナビゲータ」にこのサービス名のWSDLファイルが表示されます(この例では、「DequeueDemo.wsdl」という名前です)。このファイルには、このウィザードで指定したアダプタ構成設定が含まれます。その他の構成ファイル(ヘッダー・プロパティやアダプタ固有のファイルなど)も作成され、「アプリケーション・ナビゲータ」に表示されます。
「サービス名」ウィンドウ以降に表示されるアダプタ構成ウィザードのウィンドウは、選択したアダプタ・タイプによって異なります。これらの構成ウィンドウや指定する情報については、このガイドの後続の章で説明します。
Oracle JCAアダプタは、Oracle SOA Suiteと統合できます。
この項には、次の項目が含まれます。
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アダプタなど)を提供します。これには、Oracle AQアダプタ、Oracleデータベース・アダプタ、Oracleファイル・アダプタ、Oracle FTPアダプタ、Oracle JMSアダプタ、Oracle MQ SeriesアダプタおよびOracleソケット・アダプタが含まれます。
サービス・インフラストラクチャ
内部メッセージ・トランスポートを提供します。たとえば、インバウンド・アダプタからメッセージを受信して、処理のために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アプリケーションの開発の「SOAコンポジット・アプリケーションの開発の開始」などの項を参照してください。
Oracle BPEL Process ManagerおよびOracle Mediatorには、Oracle JCAアダプタ(ファイル、JMSおよびデータベースなど)があり、それぞれがインバウンドまたはアウトバウンドで処理するすべてのメッセージの統計が収集され、パブリッシュされます。統計は、カテゴリと個別タスクにわかれています。次の例に、アウトバウンド(参照)プロセス内で統計がどのようにわかれているかを示します。
アダプタの前処理
InteractionSpecの準備
アダプタの処理
コール可能な文の設定
データベースの起動
結果の解析
アダプタの後処理
アダプタ統計は、Fusion Middleware Controlコンソールで表示できます。アダプタ統計を表示する手順は、次のとおりです。
図3-10 診断レポートを使用したFusion Middleware Controlコンソールでのアダプタ統計の表示
図3-11に示すように、「SOAインフラストラクチャ・ホーム > インタフェース」ページが表示されます。
このページには、現在アクティブなすべてのアダプタのインバウンド相互作用(サービス)およびアウトバウンド相互作用(参照)のリストと、各アダプタで実行される各種ステップの平均実行時間が表示されます。
このリリースの新機能であるアダプタ・レポートなど、SOAアダプタの監視および構成の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の、特に「Oracle JCAアダプタの監視」と「Oracle JCAアダプタの構成」の各章を参照してください。「SOAコンポジット・アプリケーションの問題の診断」の章には、アダプタに関連するSOAコンポジット・アプリケーションの問題の診断に役立つアダプタ・ログの使用方法が記載されています。
