前の部分では、DB2 コネクトをアプリケーション・サーバーと組み合わせて使う方法について説明しました。 アプリケーション・サーバーを利用すれば、 多数のユーザーが最小限のシステム・リソースでアプリケーションを実行できます。
アプリケーション・サーバーを拡張して、調整されたトランザクションを、 そのアプリケーション・サーバーが実行するアプリケーションから呼び出せるようにすることができます。 このトランザクション調整機能は一般に、トランザクション処理 (TP) モニターとして知られています。 TP モニターはアプリケーション・サーバーと連携して機能します。
トランザクション は、 組織の日常業務を処理するときに生じる定型的なイベント (通常はサービス要求) とみなすことができます。 トランザクションの規則正しい処理が、TP モニターで想定されている作業のタイプとなっています。
どの組織にも、どのようにそれが運営されるかを表現したルール (法則) と手順が存在します。 これらのルールを具体化するユーザー・アプリケーションのことを、 ビジネス・ロジック と呼ぶことができます。 また、これらのビジネス・アプリケーションが実行するトランザクションのことを、 しばしばトランザクション処理、あるいはオンライン・トランザクション処理 (OLTP) と呼びます。
商用 OLTP の主要な特性は以下のとおりです。
この図では、DB2 コネクト エンタープライズ・エディションが API とともに、 アプリケーション・サーバーとバックエンドのデータベース・サーバーとの間の接続機構を提供しています。
現在、市販されている代表的な TP モニターには以下のものがあります。
Microsoft Transaction Server Remote S/390、AS/400、 LAN などのデータベース・サーバーは、これらの TP モニターで調整されたトランザクション内で使用できます。
DB2 コネクト バージョン 6 以前では、Tuxedo ベースのアプリケーションによる、 ホストおよび AS/400 のデータベース・サーバーに対するアクセスが、 読み取り専用アクセスに限定されていました。 DB2 コネクト バージョン 7 ではこの制限がなくなっており、 Tuxedo ベースのアプリケーションは、 Tuxedo の調整トランザクション内にあるホストおよび AS/400 のデータベース・サーバーを更新できるようになりました。 構成の面では、特別な要件と制約事項が適用されます。 詳細については、DB2 コネクトの接続コンセントレーターを参照してください。
単一のトランザクションで複数のリソースを更新するのに、 ビジネス・ロジックを実行するアプリケーションが必要になることがあります。 たとえば、ある口座から別の口座への送金を実現する銀行業務アプリケーションは、 一方のデータベース (送金元口座) からの引き落とし処理と、 もう一方のデータベース (送金先口座) への入金処理を必要とするかもしれません。
これら 2 つのデータベースが別々のベンダーのものである可能性もあります。 たとえば、一方のデータベースが DB2 ユニバーサル・データベース (OS/390 版) で、 もう一方が Oracle データベースになっている場合があります。 このような場合、それぞれのデータベース・ベンダー独自のトランザクション・インターフェースを TP モニターごとに実装するのではなく、 TP モニターと、アプリケーションがアクセスするリソースとの間に共通のトランザクション・インターフェースが定義されています。 このインターフェースは XA インターフェース として知られているものです。 XA インターフェースを使用する TP モニターのことを XA 準拠トランザクション・マネージャー (TM) と呼びます。 また、XA インターフェースを実装する更新可能なリソースのことを XA 準拠リソース・マネージャー (RM) と呼びます。
上記の TP モニターはすべて XA 準拠 TM です。 リモート・ホスト、AS/400、および DB2 UDB の LAN ベースのデータベース・サーバーは、 DB2 コネクト経由でアクセスを行うときは XA 準拠 RM になります。 そのため、XA 準拠 TM を有する TP モニターであれば、 トランザクションを実行するビジネス・アプリケーション内にある、 ホスト、AS/400、および LAN ベースの DB2 UDB のデータベース・サーバーを使用できます。
ここでは、TP モニターで S/390 と AS/400 のデータベース・サーバーを使用するのに必要な構成手順について説明します。 これは、すでに操作可能な TP モニターがあって、DB2 コネクトがインストールされていることを前提にしています。 また、ホストまたは AS/400 のデータベース・サーバーへの接続の構成とテストも済んでいなければなりません。 詳細については、DB2 コネクト 概説およびインストール を参照してください。
よく使われている TP モニターを構成するのに必要な手順は、 管理の手引き に記載されています。 LAN ベースの DB2 UDB データベース・サーバーへのアクセスと、ホストまたは AS/400 のデータベース・サーバーへのアクセスとでは、 構成作業に違いはありません。 以下の手順は、管理の手引き に明記されていない TP モニターの一般的な構成手順を示したものです。
DB2 コネクトが TP モニター内にある S/390 と AS/400 のデータベース・サーバーを使用するように構成するには、 以下の手順に従ってください。
SPM は DB2 コネクトの構成要素の 1 つで、XA の 2 フェーズ・コミット・プロトコルを、 ホストと AS/400 のデータベース・サーバーが使用する 2 フェーズ・コミット・プロトコルにマップします。 省略時の状態では、DB2 インスタンスに SPM 構成パラメーターの事前定義値が指定されています。 最も重要なパラメーターは、データベース・マネージャーの構成パラメーター SPM_NAME です。 TCP/IP ホスト名の最初の 7 文字からとった名前が省略時値になっています。
TCP/IP を使って DB2 (OS/390 版) への接続を行うときは、 省略時の設定値はどれも変更する必要はありません。 この場合、SPM はすでに動作可能になっているため、SPM の構成作業は不要です。 ホストまたは AS/400 のデータベース・サーバーへのアクセスに SNA を使用するときは、 SPM_NAME 値がネットワークの有効な SNA LU を表すようにしなければなりません。 デフォルトの SPM_NAME 値をそのまま使うことができない場合は、 「複数サイト更新 (Multisite Update)」ウィザードでこの値を変更してください。