クライアント / サーバー型のアプリケーションが登場したとき、 アプリケーション設計者は Windows や OS/2 といったプラットフォーム上で アプリケーションにグラフィカル・ユーザー・インターフェースを持たせることにより、 ユーザビリティー (使いやすさ) を向上させてトレーニング・コストを削減することが可能になりました。 同時に、多様なオペレーティング・システムとハードウェア・プラットフォーム上にある堅固なデータベース・サーバーに、 データベース管理機能を柔軟な方法で送ることも可能になりました。
アプリケーション・ロジックがクライアント・ワークステーションに配布されるこのクライアント / サーバー・モデルのことを、 通常は 2 層クライアント / サーバー と呼びます。 この 2 層モデルでは、アプリケーションはクライアント層に配置され、 データベース・サーバーはサーバー層もしくはバックエンド層に実装されます。 直接的なデータベース・アクセスに図示されているように、 DB2 コネクトは DB2 (OS/390 版)、DB2 (MVS/ESA 版)、DB2 (AS/400 版)、 および DB2 (VM および VSE 版) がデータベース・サーバーとなっている 2 層クライアント / サーバー・アプリケーションを完全にサポートします。
クライアント / サーバー・アプリケーションのサイズが拡大するにつれて、 2 層クライアント / サーバー・モデルには重大な限界があることが明らかになってきました。 大量のビジネス・ロジックを何百もの、時には何千ものクライアント・ワークステーションに配布することは、 変更管理の作業を複雑で費用のかかるものにしてしまいました。 また、ビジネス・ルールに何か変更を加えると、アプリケーションのクライアント部分を置き換えなければなりません。 アプリケーションのそのような置き換えは多くの場合、 ビジネス・ルールが一貫して適用されるようにするために、 企業内のすべてのクライアント・ワークステーションで一斉に行うことが必要です。
システムの規模に関して明白になってきた 2 層クライアント / サーバー・モデルの別の欠点は、 そのようなアプリケーションが消費するリソースの量です。 何百もの、または何千ものファット・クライアント (太ったクライアント。2 層モデルにおけるクライアントはしばしばこのように呼ばれる) を配置することによって、 各クライアント・ワークステーションにより高い処理能力と大きなディスク容量が要求されるようになりました。 さらに、それぞれのクライアントが専用のデータベース接続を必要とし、 そのような接続を保持することに関連したリソースも必要とされるため、 データベース・サーバーの要件も非常に高くなっています。 ビジネス・ロジックを配布することに対する 2 層クライアント / サーバーの依存性は、 ストアード・プロシージャーを広範囲にわたって使うことである程度軽減できますが、 その他の欠点については、モデルを変更する以外に簡単に解決する方法はありません。
2 層クライアント / サーバー・アプリケーションにかかるコストとその複雑さが増大するにつれ、 大型アプリケーションの大部分は、多層からなるクライアント / サーバーの方向に発展しました。 多層モデルでは、データベース層の役割は変わっていませんが、 クライアント層には 1 つまたは複数の中間層が追加されます。 追加される層は普通は 1 つであるため、 このモデルは 3 層 という名前になっています。
3 層モデルでは、クライアントの処理はユーザーとの対話だけにとどまり、 ビジネス・ロジックは何も組み込まれません。 また、中間層は 1 つまたは複数のアプリケーション・サーバーで構成されます。 アプリケーション・サーバーを利用する目的は、 ビジネス・プロセスとビジネス・ルールの背後にあるロジックを、 堅固かつ費用効率の高い方法で実装することにあります。 2 層モデルの場合にそうであったように、ビジネス・ルールの実装には多くの場合、 パフォーマンスを向上させるためにストアード・プロシージャーが補足的に使われます。
クライアント・ワークステーションは大量のアプリケーション・ロジックを実装せずに、 ユーザーとの対話だけを処理すればよくなるため、 クライアント層のリソース要件は大幅に軽減されます。 そのような理由から、3 層モデルにおけるクライアント層はよくシン・クライアント (やせたクライアント) と呼ばれます。 さらに、中心となるアプリケーション・サーバーがすべてのクライアントからの要求を処理するため、 そのアプリケーション・サーバーはすべてのクライアント間のデータベース接続などのリソースを共用することが可能です。 その結果、データベース・サーバーがアプリケーション・ユーザーごとに専用の接続を保持する必要がなくなります。
現在、業界には 3 層アプリケーション・サーバーの応用例がいくつも存在しています。 ほとんどの ERP (エンタープライズ・リソース・プランニング) ベンダーは 3 層モデルを使って自社のアプリケーションを実装しています。 これには、SAP R/3 や PeopleSoft V7 といったアプリケーションが含まれます。 それ以外の例としては、Siebel や Vantive などの 代表的なエンタープライズ・リレーションシップ・マネージメント・ベンダーが含まれています。
DB2 コネクト エンタープライズ・エディションのサーバーは、 多層アプリケーションを総合的にサポートします。 DB2 コネクトによるサポートは、 アプリケーション・ロジックを開発するのに使用できる 各種の API (ODBC、 ADO、 DB2 CLI、組み込み SQL、JDBC、SQLJ など) だけでなく、 DB2 ファミリーのデータベース・サーバーと対話するための完全な通信基盤をも含んでいます。
DB2 コネクトはさらに、データベース層が DB2 ファミリーの複数のデータベース・サーバーで構成されているようなシステムもサポートします。 これにより、アプリケーション・サーバーは複数のデータベース・サーバー上に置かれているデータを 1 回のトランザクションで更新するトランザクションを実装できます。
そのような分散トランザクションの整合性は、 DB2 コネクトが提供する 2 フェーズ・コミットのプロトコル・サポートによって保証されます。 たとえば、アプリケーションは同一トランザクション内で DB2 (OS/390 版) データベースと DB2 UDB (Windows NT 版) のデータを更新することが可能です。 また、分散要求サポートがインストールされて有効になっている場合は、 アプリケーションは同一トランザクション内で Oracle データベースの読み取りと DB2 ファミリーのデータベースの更新を行うことができます。
下記の図では、DB2 コネクト エンタープライズ・エディションにより、 アプリケーション・サーバーとバックエンドのデータベース・サーバーとの間の接続機構および API が提供されています。
接続プール (接続のプールを参照) や 接続コンセントレーター (DB2 コネクトの接続コンセントレーターを参照) といった DB2 コネクトの先進機能を利用すれば、 アプリケーションのリソース要件は大幅に軽減され、 アプリケーション・サーバーの実装も単純化できます。
アプリケーション・サーバーを使用するには、DB2 コネクト エンタープライズ・エディション (単体の製品として、 あるいは DB2 Connect Unlimited Edition 製品のパッケージの一部として入手可能) が必要です。 DB2 コネクト パーソナル・エディションはアプリケーション・サーバーをサポートしておらず、 それに必要なライセンスも含んでいません。 さらに、アプリケーション・サーバーを実装する予定があれば、 ご使用の DB2 コネクトの使用許諾条件をよく読み、入手する必要のあるライセンスの数を把握してください。
アプリケーション・サーバー環境では、DB2 コネクトを配置する方法が 2 つあります。 DB2 コネクト エンタープライズ・エディションは次のいずれかにインストールされます。
ほとんどのケースでは、DB2 コネクトをアプリケーション・サーバーと同じサーバー上にインストールすることをお勧めします。 DB2 コネクトをアプリケーション・サーバー上にインストールすることで、 アプリケーション・サーバーで実装しようとしているフェールオーバーおよびロード・バランシングの仕組みに DB2 コネクトを関与させることができます。 このようにセットアップすると、DB2 コネクトを別のサーバー上にインストールした場合に必要とされる余分のネットワーク・ホップがないため、 パフォーマンスの向上を期待できます。 さらに、別のサーバーをもう 1 つインストールして保守することも不要であるため、 管理作業も単純化されます。
DB2 コネクトを別のサーバーにインストールした方がよいケースもあります。 アプリケーション・サーバーが稼働しているオペレーティング・システムやハードウェア・プラットフォームに DB2 コネクト エンタープライズ・エディションが対応していない場合がそうです。 たとえば、アプリケーション・サーバーが Silicone Graphics (SGI) または SCO UnixWare のサーバー上に配置されている場合は、 DB2 コネクト エンタープライズ・エディションがそれらのプラットフォームに対応していないため、 DB2 コネクトを別のサーバーに配置する以外に方法はありません。