ヘッダーをスキップ
Oracle® Database Provider for DRDAユーザーズ・ガイド
12c リリース1 (12.1.0.2) for Linux x86-64
E98592-01
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

1Oracle Database Provider for DRDAの概要

この項では、Oracle Database Provider for DRDAテクノロジの概念について説明します。

この章には次のトピックが含まれます:

Oracle Database Provider for DRDAとは

Oracle Database Provider for DRDAは、Distributed Relational Database Architecture (DRDA)プロトコルを使用してクライアント・プログラムからOracle Databaseに接続できるようにするネットワーク・フロントエンドです。

Oracle Database Provider for DRDAは、互換性を実現するため、完全なDRDAバージョン4仕様のサブセットと、その他のDRDAサーバー製品(IBMのDB2など)の様々な側面を実装しています。これはデータベースに依存しないプロトコルであり、Oracle Databaseで使用可能な機能のみを提供します。Oracle Database Provider for DRDA製品により、既存のDB2アプリケーションをご利用のお客様は、DB2サーバーからの移行中に、投資したアプリケーション・テクノロジを利用できます。

DRDAプロトコルを使用するクライアント・プログラムまたはシステムは、アプリケーション・リクエスタ(AR)と呼ばれます。DRDAプロトコル・サービス(Oracle Database Provider for DRDAなど)を提供するサーバー・プログラムまたはシステムは、アプリケーション・サーバー(AS)と呼ばれます。

直接的なARとして、または中間インタフェース(埋込みSQLなど)を介してDRDAプロトコルを使用するように作成されたアプリケーションの場合、通常はOracle Database Provider for DRDAからOracle Databaseに接続するために既存のコードを変更する必要はありません。Oracle Databaseを使用するようにクライアント・アプリケーション環境を変更する際に必要となる変更は、最小限のアプリケーション構成変更(ターゲット再設定など)のみです。

DB2クライアント・アプリケーション

DB2アプリケーションは一般に次の2種類に分類されます。

リモートDB2アプリケーション

リモート・アプリケーションは、DRDAデータ・プロトコルを使用してターゲット・サーバー・データベースと通信します。このプロトコルのアーキテクチャは次の要素を含むクライアント/サーバー・モデルです。図1-1にこれを示します。

  • クライアント・コンポーネント、DRDAアプリケーション・リクエスタ(AR)

  • 基盤となるネットワーク(TCP/IPネットワークまたはSNA/APPCネットワークなど)

  • サーバー・コンポーネント、アプリケーション・サーバー(AS)

図1-1 DRDA接続モデル

図1-1については周囲のテキストで説明しています。

アプリケーションは、ARを使用してASと通信し、ASはデータベースと通信します。この構成では、ARがネットワークに接続するため、アプリケーションは間接的にネットワークを認識します。アプリケーションがネットワーク接続を直接認識する必要はありません。

通常、DRDA AR実装にはアプリケーション開発者がコーディングする直接コール可能なAPI (ODBCなど)があります。このAPIは、埋込みSQL文を含むソース・コードを同等の埋込みAPIコールに変換する言語プリプロセッサの一部として起動することもできます。これは、概念的にOracleのOCI API製品およびOracleのPro*Cプリプロセッサ製品と似ています。どちらの場合でも、アプリケーションは実際のデータベース接続を認識しません。特定のAPIコールのみがアプリケーションをデータベースにアタッチします。Oracle® Call Interfaceプログラマーズ・ガイドおよびPro*C/C++プログラマーズ・ガイドを参照してください。

ネットワーク内のクライアント/サーバー・アーキテクチャにはクロス・プラットフォームの相互運用性があります。クライアントとサーバーは、サポートされているコンピュータ・プラットフォームであればどのプラットフォームでも実行できます。たとえば、IBMのDB2データベース・サーバー製品は、AS/400、z/OS、VM、VSE、Linux、様々なUNIXプラットフォームおよびMicrosoft Windowsで使用できます。また、IBMはDB2 Connect製品などのクライアントを様々なプラットフォームで使用できるようにしています。これにより、クライアントは様々なサーバーと通信でき、同一ホストまたは異なるリモート・ホスト上の異なるサーバーへ容易にリダイレクトできます。

リモート・アプリケーションの例を次に示します。

  • ODBCベースのアプリケーション

  • Java/JDBCベースのアプリケーション

  • DB2データベース(リモート・データベース間接続に使用)

  • DB2 Connect (ネイティブ・アプリケーションのリダイレクトに使用)

  • 各種AR実装のいずれかを使用するカスタム・アプリケーション

ODBC対応アプリケーションおよびJDBC対応アプリケーションでは、アプリケーション自体に対する変更をほとんど行わずに、Oracle Database Provider for DRDAを使用するようにターゲットを再設定できます。

IBMのDB2製品ではDRDAがネイティブでサポートされており、DB2をリクエスタ、サーバーまたはこの両方として使用できます。このマニュアルでは、DB2がOracle Serverへのリクエスタであるシナリオについてのみ説明します。

ネイティブDB2アプリケーション

ネイティブ・アプリケーションはOracle Database Provider for DRDAでサポートされていますが、ネットワークをリダイレクトするには既存のDB2データベース・サーバーを必要とします。これは、ネイティブDB2アプリケーションはDB2サーバーとより緊密に連携しているためです。このクラスのアプリケーションは、ローカルの専用APIを使用して特定のDB2サーバーと直接通信します。このようなアプリケーションは他のデータベースには直接接続できませんが、リモート・ノード接続メカニズムを使用してリモート・データベースに間接的に接続できます。これを図1-2に示します。

図1-2 ネイティブ・アプリケーション・リモート接続モデル

図1-2については周囲のテキストで説明しています。

完全なDB2サーバーを使用して単にリモート・アクセスをネイティブ・アプリケーションに提供する処理は、非常に高いコストがかかるため、これは理想的な方法ではありません。これはライセンス・モデルの「プロセッサ単位」の構造と、ディスクおよびメモリーのフットプリントの両方に起因しています。

リモート接続を提供する場合、完全なマルチプロセッサDB2サーバーに代わる、より適切な手段として、DB2 Connectなどのローカル・アプリケーションを使用する方法があります。この場合、図1-3に示すように、アプリケーションのアクセスをDRDA経由でのネットワーク接続に変えることができます。

図1-3 DB2サーバー接続モデルでのDB2 Connect置換

図1-3については周囲のテキストで説明しています。

場合によっては、DB2データベース・サーバーを代替のネイティブ・アプリケーション・イネーブラに置き換えることができないことがあります。このようなアプリケーションには次のものがあります。

  • z/OS上のCICS DB2接続アプリケーション

  • DB2/400ネイティブ・アプリケーション

  • DB2 for z/OSネイティブ・アプリケーション

  • DB2 for Linux, Unix, and Windowsネイティブ・アプリケーション

このような状況では、アプリケーションをプロキシ経由(ローカルDB2データベース・サーバーを介して)で接続できます。これは理想的な方法ではありませんが、DB2サーバー製品への投資が削減されます。アプリケーションがDB2データベース製品を使用していない場合、DB2サーバーの数を、アプリケーション・プロキシとして必要なDB2インスタンスの数まで削減できます。

Oracle Database Provider for DRDAの使用例

Oracle Database Provider for DRDAのいくつかの使用例をリモートDB2アプリケーションおよびネイティブDB2アプリケーションで説明しています。Oracle Database Provider for DRDAを介してOracle Databaseを使用するように、リモート・アプリケーションおよびネイティブ・アプリケーションの両方でターゲットを再設定できます。

Oracle Database Provider for DRDAはネットワーク・ソリューションであるため、ネットワーク・インフラストラクチャに、ネイティブ・アプリケーションのターゲット再設定時のロード増加に対応できる十分な容量が必要です。リモート・アプリケーションの場合、クライアントとサーバー間のデータ・フローが大きく変化することはありません。

ほとんどの例では標準的なAR (通常はIBMによって提供されるAR)が中心となっていますが、廃止されたOracle Access Manager for AS/400のかわりにアプリケーション・サーバーが使用されるケースがあります。Access Managerは、ネイティブDB2/400アプリケーションがリモートDB2データベースと同様の方法でOracle Databaseに接続できるようにするクライアント側プログラムです。Access Managerは、DB2/400 APIプラグインとしてAS/400上で実行され、OCIメソッドを使用してOracle Databaseに接続します。これを図1-4に示します。

図1-4 Access Managerプラグイン・アーキテクチャ接続モデル

図1-4は前後のテキストで説明されています。

DB2/400のプラグイン・インタフェースAPIはDRDAと同様に動作し、システムに対してはOCIおよびSQL*Netを内部で使用してOracle Databaseに接続するアプリケーション・リクエスタのように見えます。AS/400からネイティブ・アプリケーションをOracle Databaseに接続する必要があるお客様にとっては、Oracle Database Provider for DRDAはよりコスト効率の高いソリューションであることがわかります。このアプローチを図1-5に示します。

図1-5 DB2/400ネイティブDRDA使用接続モデル

図1-5は、周囲のテキストで説明されています。

Access Managerの例は、アプリケーション・サーバー経由でOracle Database インスタンスへネイティブ・アプリケーションのターゲットを再設定できる例の1つです。

ここで説明したすべての使用例では、Oracle Database Provider for DRDAを使用してOracle Databaseに接続できます。