4 環境の管理
環境の管理
統合プロジェクトは、そのライフサイクル中に様々な環境(開発、テスト、本番)に存在し、さらに本番では様々な環境で実行される場合があります(複数サイトのデプロイ)。Oracle Data Integratorを使用すると、トポロジを使用して、これらの環境、およびこれらの環境にまたがるプロジェクトのライフサイクルの定義と保守をより簡単に実行できます。
トポロジでは、情報システムの物理アーキテクチャと論理アーキテクチャが記述されます。トポロジを使用すると、様々なサーバー、環境およびエージェントを非常に柔軟な方法で管理できます。トポロジの情報はすべてマスター・リポジトリに格納され、最適な管理のために集中管理されます。作業リポジトリ内で操作されるすべてのオブジェクトがトポロジを参照します。このため、トポロジは、アーキテクチャの定義および計画時の最も重要な開始点です。
トポロジは、データ・サーバー、物理スキーマと論理スキーマ、およびコンテキストで構成されます。
データ・サーバーでは、実際の物理的なアプリケーション・サーバーとデータベースに対する接続が記述されます。たとえば、次のものを表すことができます。
-
Apache Hive
-
Oracleインスタンス
-
IBM DB2データベース
-
Microsoft SQL Serverインスタンス
-
Sybase ASEサーバー
-
ファイル・システム
-
XMLファイル
-
Microsoft Excelワークブック
-
その他。
実行時に、サーバーに接続するために記述した接続情報がOracle Data Integratorによって使用されます。
物理スキーマは、データ・サーバー内のデータストア(表、ファイル、トピック、キュー)の物理的な場所を示します。アクセス対象とする必要がある物理スキーマは、対応するデータ・サーバーに登録されなければなりません。物理スキーマは、オブジェクト名に接頭辞として付けて、それらの修飾名でそれらにアクセスするために使用されます。物理スキーマの作成時に、実行時に必要な一時オブジェクトまたは永続オブジェクトを格納する一時スキーマまたは作業スキーマを指定する必要があります。
論理スキーマは、同一のデータストア構造が保持されているすべての物理スキーマに一意の名前を与えることを可能にする別名です。論理スキーマの目的は、異なる設計時環境とランタイム環境でプロシージャおよびモデルの移植性を確保することです。
コンテキストは、これらの環境の1つを表し、同じ環境に属する物理リソースをグループ化するために使用されます。コンテキストは、同じ環境に属する物理リソースをグループ化するために使用されます。
一般的なプロジェクトには、開発、テストおよび本番用に別々の環境を設定します。プロジェクトによっては、複数の重複したテスト環境または本番環境が存在する場合もあります。たとえば、独自の本番システムを実行している子会社に対して複数の本番コンテキスト(本番ニューヨーク、本番ボストンなど)を設定する場合があります。図4-1に示すように、情報システムの論理ビューとその物理実装の間には明らかに違いがあります。
論理ビューでは、既存アプリケーションの物理実装とは関係なく、その物理スキーマを表す論理スキーマが記述されます。これらの論理スキーマは、コンテキストを介して物理リソースにリンクされます。
設計者は常に、トポロジで定義された論理ビューを参照します。したがって、完成したすべての開発は、処理するリソースの物理的な場所とは無関係になります。実行時に、適切なコンテキストを指定すると、論理情報が物理リソースにマップされます。様々なコンテキストを指定するのみで、同じシナリオを様々な物理サーバーおよびアプリケーションで実行できます。この結果、使用するサーバーの基礎となる物理実装を開発者が気にする必要のない、非常に柔軟なアーキテクチャが実現します。