DB2® アプリケーションからの MQSeries® の使用

Dan Wolfson, Senior Technical Staff Member, IBM Database Technology Institute for e-Business

Dan Wolfson は、IBM Database Technology Institute for e-Business のシニア・テクニカル・スタッフ・メンバー兼マネージャー。分散コンピューティングに関して 15 年以上の経験を有し、その関心はデータベース、メッセージングおよびトランザクション・システムに及ぶ広範囲にわたります。現在は、XML、および WebSphere や MQSeries との DB2 の統合を中心としたアーキテクトの中でリーダーとしての役割を担っています。



2001年 8月 06日

要旨

本書では、DB2 UDB V7.2 で提供される新機能を使用して MQSeries メッセージングをデータベース・アプリケーションと簡単に統合する方法について説明します。これらの機能は、標準の SQL ステートメント内で MQSeries メッセージングへのシームレスなアクセスを提供し、単純なイベント通知からオペレーショナル・データ・ストア作成に至るまで幅広いアプリケーションをサポートします。


1. はじめに

多くの DB2 ユーザーは、そのアプリケーション環境でメッセージング、キューイング、あるいはパブリッシュ/サブスクライブのシステムも使用しています。これらのシステムは、異なるアプリケーションの連携から、リアルタイムの情報配信、データ統合、外部パートナーとの通信まで、用途はさまざまです。このような用途に、同一アプリケーション内でデータベース操作とメッセージング操作を組み合せることがよくあります。これには、現時点ではアプリケーション・プログラマーがこれら 2 つの非常に異なるモデルを組み合わせてアプリケーションを作成する必要があります。本書は、DB2 7.2 の新機能により、アプリケーション開発が簡素化される様子と、DB2 と MQSeries を組み合わせた能力をいかに活用できるかを説明することを主眼としています。

DB2 7.2 は、新しい MQSeries 統合機能を数多く提供しています。これには、SQL ステートメント内から呼び出し可能な一連の MQSeries 関数、DB2 表へのキューのマップを容易にする MQSeries Assistant、XML エクステンダーを使用した XML メッセージのサポート、およびデータ・ウェアハウス・センターからの新しい種類のデータ・ソースとしての MQSeries のサポートが含まれます。本書では、主に、MQSeries サポートの中核である、SQL への MQSeries の統合に焦点を当てます。その他の機能もすべてこの基本機能を活用しています。その他の機能については、後続の文書で解説します。

本書は、次のように構成されています。セクション 2 は、MQSeries の簡単な概要から始めます。MQSeries 統合機能の概要がこれに続きます。セクション 4 では、異なる使用シナリオに即して MQSeries 関数を説明します。最後のセクションでは、簡単なレビューとまとめを提供します。


2.MQSeries の概要

MQSeries は MQSeries 製品ファミリーの中核です。MQSeries は圧倒的なマーケット・シェアを持ち、企業の世界全体で使用される最先端のメッセージング・ミドルウェアです。MQSeries は柔軟性に富むメッセージング・システムで、これを使用するとアプリケーションは異種混合の分散環境で通信できます。柔軟なメッセージング・システムです。MQSeries 製品ファミリーには、MQSeries、MQSeries Integrator (MQSI)、MQSeries Workflow、および MQSeries Adapter Offering などがあります。

MQSI はメッセージ・ブローカーおよびパブリッシュ/サブスクライブ・サーバーです。メッセージ・ブローカーは、一連の規則に基づいてメッセージを経路指定および変換できます。MQSI は、異種アプリケーションを統合する企業アプリケーション・ソリューションでしばしば使用されます。MQSI の中核にあるデータフロー・エンジンは、キューからメッセージを受け入れユーザー定義のデータフローで記述される操作シーケンスに従って処理します。操作には、メッセージの内容の変換、データベース操作の実行、および 1 つ以上の宛先へのメッセージのルーティングの機能が含まれます。

MQSeries Workflow は、ユーザー指向のワークフローとプロセス指向のワークフローの両方をサポートする総合的なワークフロー環境です。ワークフローは、操作の「ステートフルな」流れです。個々の操作は、MQSeries メッセージによってトリガーされる 1 つのスタンドアロン・アプリケーションである場合もあります。

MQSeries Adapter Offering は、事前定義されたいくつかの統合ライブラリーを提供することにより、また新しい統合ライブラリーの作成を簡素化することにより、パッケージ・アプリケーションの統合を簡単にする新製品です。

2.1 MQSeries メッセージングのスタイル

MQSeries は、データグラム、パブリッシュ/サブスクライブ (p/s)、および要求/応答 (r/r) の 3 つのメッセージング・モデルをサポートしています。データグラムとして送信されるメッセージは、単一の宛先に送信され、応答は期待しません。p/s モデルでは、1 人または複数のパブリッシャーがパブリケーション・サービスにメッセージを送信し、このサービスが、関心を持っているサブスクライバーにメッセージを配信します。要求/応答はデータグラムと似ていますが、送信側は応答を受信することを期待しています。

MQSeries は、さまざまな方法で使用されています。単純なデータグラムは、複数のアプリケーションの調整、情報の交換、サービスの要求、および興味の対象となるイベントの通知の提供のために交換されます。パブリッシュ/サブスクライブは、リアルタイムの情報をタイムリーに配信するためにもっともよく使用されます。要求/応答スタイルは、一般に、擬似同期リモート・プロシージャー・コールの単純な形式として使用されます。もちらん、これらの基本的なスタイルを組み合せて、さらに複雑なモデルを構成できます。

これらの基本的なメッセージング・テクニックは、きわめて多様な方法で使用されます。MQSeries は、非常に広範囲のプラットフォームにわたって使用できるため、よく似た環境や異種環境の、異なるアプリケーション同士を連携するという重要なメカニズムを提供しています。MQSeries は、SAP などのパッケージ・アプリケーションを既存の環境にリンクしたり、追加機能でこれらのアプリケーション・パッケージの拡張を支援するために、EAI (Enterprise Application Integration) 構成で使用されることがよくあります。MQSeries は保証されたメッセージ配信を提供しているため、多くの企業が、基幹業務システム内でアプリケーション間の重要な情報の伝達の中核となるメカニズムとして使用しています。これらのアプリケーションは、メッセージで伝達する情報のソースまたは宛先として、データベースと相互作用することもよくあります。

2.2 メッセージ構造

MQSeries 自体は、移送するメッセージに特定の構造を必要としたり、特定の構造だけをサポートしているわけではありません。MQSeries Integrator (MQSI) などのその他の製品は、C、Cobol、または XML ストリング形式のメッセージをサポートしています。MQSI の構造化メッセージはメッセージ・リポジトリーで定義されます。XML メッセージは、通常は自己記述型のメッセージ構造を持ち、リポジトリーでも管理できます。メッセージは構造化しなくてもよく、その場合はユーザー・コードでメッセージの内容を解析または構成する必要があります。これらのメッセージは、しばしば半構造化されます。つまり、バイト位置や決まった区切り文字を使用して、メッセージ内でフィールドに区切られます。

2.3 MQSeries API

MQSeries では 3 つの主なアプリケーション・プログラミング・インターフェースが提供されています。もっとも普及しているのは MQI で、単純なインターフェースがいくつかあるだけですが、オプションとパラメーターを数多く備えています。MQI プログラマーは通常、メッセージ要求を、MQSeries を制御するのに必要な情報と混在させます。MQI には、プロシージャー型とオブジェクト型の両方のインターフェースがあり、数多くの一般的なプログラミング言語をサポートします。

MQSeries のアプリケーション・メッセージング・インターフェース (AMI) では、メッセージ操作と、それらの操作の実行方法を規定する定義は明確に分離されます。これらの定義は、外部リポジトリー・ファイルに保持され、AMI 管理ツールを使用して管理されます。このため、AMI アプリケーションは開発と管理が非常に簡単になります。AMI は比較的新しいため、すべてのプラットフォームで完全にサポートされているわけではありません。AMI のパフォーマンス・オーバーヘッドは、MQI よりもいくらか高くなります。

最後に、Java Messaging Service (JMS) は、MQSeries に対する標準の Java インターフェースを提供しています。JMS はよく使われますが、Java に限定され、オーバーヘッドも MQI よりいくらか高くなります。

これらのインターフェースは、それぞれ MQSeries と相互作用するためのメカニズムを提供していることに注意することが重要です。特定の環境内や異なるバックグラウンドを持つ開発者によっては、特定のインターフェースの方が使いやすいかもしれません。しかし、ある種類のインターフェースによって構成され送信されたメッセージが、1 つ以上の他のアプリケーションで受信される可能性もあります。したがって、AMI の「C」クライアント・プログラムが、MQI の Cobol アプリケーションと円滑に通信する可能性もあります。


3. 機能の概要

DB2 7.2 では、SQL ステートメントにメッセージ操作を含めることができるよう、一連の MQSeries 関数が提供されています。これは、このサポートが、サポートされる任意の言語で作成された、いかなるデータベース・インターフェースを使用するアプリケーションでも使用できることを意味します。関数は、データベース・クライアントでもストアード・プロシージャーでも使用できます。単純にするために、この後で示す例はすべて SQL です。この SQL は、あらゆる標準的な方法で、多くのプログラミング言語から使用できます。上記で説明した MQSeries メッセージング・スタイルは、すべてサポートされます。

この後で示すような基本的な構成では、MQSeries サーバーは DB2 とともにデータベース・サーバー・マシン上に配置されています。MQSeries 関数は DB2 にインストールされ、MQSeries サーバーへのアクセスを提供します。DB2 クライアントは、DB2 サーバーにアクセスできるマシンであれば、どのマシン上にあってもかまいません。複数のクライアントが、データベースを介して MQSeries 関数に同時にアクセスできます。DB2 クライアントは、提供されている関数を介して、SQL ステートメント内でメッセージ操作を実行できます。このメッセージ操作により、DB2 アプリケーションは、DB2 アプリケーション同士や、ほかの MQSeries アプリケーションと通信できます。これにより、たとえば、DB2 アプリケーションがデータベース・イベントをリモート MQSeries アプリケーションにパブリッシュする、MQSeries Workflow を介してワークフローを開始する、または MQSeries Integrator 経由で SAP などのパッケージ・アプリケーションと通信するためのもっとも簡単な方法が提供されます。CICS® や IMS® などの環境へのアクセスを提供するために、ゲートウェイもいくつか存在しています。

[基本的な DB2/MQ 構成]
基本的なDB2/MQ構成

MQSeries の機能は、enable_MQFunctions コマンドを使用して DB2 データベースで有効にされます。このコマンドは、DB2 を MQSeries 関数用に構成し、その他の管理作業なしでもクライアント・アプリケーションが利用できる単純なデフォルト構成を設定します。デフォルト構成により、アプリケーション・プログラマーは簡単に開発を始めることができ、開発用の単純なインターフェースを利用できます。追加機能は、必要に応じて徐々に構成できます。

たとえば、デフォルトの構成を使用して単純なメッセージを送信するには、SQL ステートメントは次のようになります。

例 1:
values MQSEND('simple message')

これは、「simple message」というメッセージを、MQSeries キュー・マネージャーと、デフォルト構成で指定されたキューに送信します。

例をシンプルに保つために、スキーマ名 DB2MQ で修飾した完全 DB2 関数名では示されていないことに注意してください。この例で完全な関数名を使用するには、次のように発行します。

例 2:
values DB2MQ.MQSEND('simple message')

SQL で短縮関数名だけを使用する場合は、次のように発行して、DB2MQ が関数パス上にあるように定義できます。

例 3:
set current function path = current function path, DB2MQ

DB2 で提供される MQSeries 関数は、AMI MQSeries インターフェースに基づいています。AMI では、構成情報を格納する AMI リポジトリーという名前の外部構成ファイルの使用をサポートしています。デフォルトの構成には、DB2 とともに使用するよう構成された MQSeries AMI リポジトリーが含まれています。

DB2 MQSeries 関数には、MQSeries AMI の 2 つの主な概念であるサービス・ポイントとポリシーが推し進められています。サービス・ポイントは、メッセージの送受信元になる論理的なエンド・ポイントです。AMI リポジトリーには、各サービス・ポイントが MQSeries キュー名およびキュー・マネージャーとともに定義されています。ポリシーは、特定のメッセージ操作に使用すべきサービス・オプションの特性を定義します。サービスの主要な特性には、メッセージの優先順位と永続性が含まれます。デフォルトのサービス・ポイントとポリシーの定義が用意されており、開発者はこれを使用してアプリケーションを簡素化することもできます。例 1 は、デフォルトのサービス・ポイントとポリシー名を明示的に指定するために、次のように書き直すことができます。

例 4:
values MQSEND('DB2.DEFAULT.SERVICE',
'DB2.DEFAULT.POLICY', 'simple message')

キューは、キューの存在するサーバー上で 1 つ以上のアプリケーションによってサービスされます。多くの構成では、異なるアプリケーションや目的をサポートするために、複数のキューが定義されます。このため、MQSeries 要求を行うときに、異なるサービス・ポイントを定義することがしばしば重要になります。次の例でこれを示します。

例 5:
Values MQSEND('ODS_Input', 'simple message')

ここでは、デフォルトのサービス・ポイントでなく、ODS_Input (ODS は、オペレーショナル・データ・ストアの一般的な略称) というタイトルのサービス・ポイントにメッセージを送信しています。この例では、ポリシーが指定されていないため、デフォルトのポリシーが使用されることに注意してください。

3.1 制限事項

MQSeries では非常に豊富な機能とオプションが提供されますが、現時点でそのすべてがDB2でサポートされているわけではありません。完全性よりも簡素化に失するように試みました。同様に、MQSeries はさまざまな方法で構成できます。テストはもっとも一般的であると思われる方法で実施しました。ユーザーからの意見はすべて歓迎しています。

MQSeries は、メッセージ操作とデータベース操作を最小の (アトミック) トランザクションとして 1 つの作業単位に結合する機能を提供します。この機能は、Unix および Windows 上の MQSeries 関数では最初はサポートされません。この機能を今後の製品リリースでサポートする計画が、現在検討されています。


4. 使用シナリオ

ここで説明する MQSeries 関数は、さまざまなシナリオで使用できます。ここでは、よくあるシナリオであると予想されるものを検討します。ここで説明する内容には、基本的なメッセージング、アプリケーション接続およびデータ・パブリケーションが含まれます。MQSeries DB2 関数の使用方法の例と、一般的なアプリケーション構成についても述べます。MQSeries 関数の構文の詳細は、『DB2 7.2 リリース情報』にあります。

4.1 基本的なメッセージング

MQSeries DB2 関数でのメッセージングのもっとも基本的な形態は、データベース・アプリケーションがすべて同一の DB2 サーバーに接続した状態です。これは、次の図はこの状態を表しており、ここでは 2 つの DB2 クライアント・アプリケーションがあります。クライアントは、データベース・サーバーにローカル接続しても、ネットワーク環境に分散されていてもかまいません。

次の単純なシナリオでは、クライアント A が MQSEND 関数を起動してデフォルトのサービス・ロケーションにユーザー定義のストリングを送信します (ステップ 1a)。そこで、MQSeries 関数がデータベース・サーバー上の DB2 内で実行されます。しばらく後で、クライアント B が、MQRECEIVE 関数を起動して、デフォルトのサービスで定義されたキューの一番上にあるメッセージを削除し、これをクライアントに返します。(1b)。この作業を実行する MQSeries 関数が、再度 DB2 によって実行されます。

[基本的なローカル・メッセージング]
基本的なローカル・メッセージング]

データベース・クライアントは、いくつかの方法で簡単なメッセージングを使用できます。メッセージングの一般的な使用法には、次のものがあります。

データ収集 -
情報は、1 つ以上の多様な情報ソースからメッセージの形式で受信されます。情報ソースは、SAP などの商用アプリケーションでも、社内開発されたアプリケーションでもかまいません。このようなデータはキューから受信され、さらなる処理または分析のためにデータベース表に保管できます。

負荷分散 - 作業要求は、同一アプリケーションの複数のインスタンスによって共用されるキューにポストされます。インスタンスが何らかの作業を実行する準備ができると、実行対象の作業要求が含まれているキューの一番上からメッセージを受信します。このテクニックを使用して、要求が溜まっている単一のキューによって表される負荷を、複数のインスタンスで共用できます。

アプリケーションのシグナル方式 - いくつかのプロセスが協業する場所では、それぞれの働きを調整するためにメッセージを使用することがよくあります。これらのメッセージには、作業を実行するためのコマンドや要求を含めることができます。通常、この種のシグナルは一方通行です。つまり、メッセージを発行した側は、応答を期待していません。要求/応答メッセージングは、4.4.1 で説明します。

アプリケーション通知 - 通知は、応答を期待しない開始側からデータが送信されるという点で、シグナルに似ています。ただし、通知には、通常、起こったビジネス・イベントに関するデータが含まれています。パブリッシュ/サブスクライブ・メッセージングは、通知の高度な形式で、4.4.2 で説明します。次のシナリオでは、基本のシナリオを拡張してリモート・メッセージングを組み込んでいます。つまり、メッセージがマシン A とマシン B の間で送信されます。

[基本的なリモート・メッセージング]
基本的なリモート・メッセージング図

手順の流れは、次のようになります。

  1. DB2 クライアントは、マシン B のリモート・キューを表すよう定義されたターゲット・サービスを指定して、MQSEND 呼び出しを実行します。
  2. MQSeries DB2 関数が実際の MQSeries 作業を実行してメッセージを送信します。マシン A 上の MQSeries サーバーは、メッセージを受け入れて、マシン A のサービス・ポイント定義と現在の MQSeries 構成で定義された宛先に配信することを保証します。サーバーは、これがマシン B 上のキューであると判断し、マシン B 上の MQSeries サーバーへのメッセージの配信を、必要に応じて透過的に再試行しながら試みます。
  3. マシン B 上の MQSeries サーバーはマシン A 上のサーバーからのメッセージを受け入れ、マシン B 上にある宛先キューに置きます。
  4. マシン B 上の MQSeries クライアントは、キューの一番上にあるメッセージを要求します。[注意:MQSeries 「クライアント」とは、ここおよび本書全体を通して、MQSeries サーバーのサービスを使用するプログラムというアプリケーション的な意味で使用されています。これは、クライアント・アプリケーションが MQSeries サーバーを使用して MQSeries に接続するか、クライアント・バインディングを使用して接続するかにはむ関係です。

上記の説明が示すように、MQSeries は複数の MQSeries サーバー間でメッセージを透過的に確実に配信します。これは、幅広い構成と要件を処理するのに簡単であると同時に十分洗練されています。

4.2 メッセージの送信

MQSEND を使用して、DB2 ユーザーや開発者は、どのデータをいつどこへ送信するかを選択するだけです。業界では、このことを一般に「Send and Forget (送って忘れる)」といいます。これは、送信側は MQSeries の保証された配信プロトコルを信頼してメッセージを送信するだけで、メッセージは必ず宛先に送信されることを意味しています。次の例は、これを示しています。ユーザー定義のストリングを、ポリシー highPriority を使用してサービス・ポイント myplace に送信するには、次のようにします。

例 6:
		values MQSEND('myplace','highPriority','test')

ここで、ポリシー highPriority は、AMI リポジトリーに定義された、MQSeries 優先順位を最高レベルに設定するポリシーを指します。このポリシーは、おそらく永続性などのほかのサービス特性も調整します。メッセージの内容は、SQL とユーザー指定データの任意の有効な組み合わせで構成できます。これには、ネストした関数、演算子、およびキャストが含まれます。たとえば、varchar 列 LASTNAME、FIRSTNAME、および DEPARTMENT を持つ表 EMPLOYEE がある場合、DEPARTMENT 5LGA の各社員に関するこの情報を含んでいるメッセージを送信するには、次のようにします。

例 7:
select MQSEND(LASTNAME || ' ' || FIRSTNAME || ' ' ||
DEPARTMENT) from EMPLOYEE
where DEPARTMENT = '5LGA'

この表に整数列 AGE もある場合、これは次のようにして含めることができます。

例 8:
select MQSEND(LASTNAME || ' ' || FIRSTNAME || ' ' ||
DEPARTMENT|| ' ' ||char(AGE)) from EMPLOYEE
where DEPARTMENT = '5LGA'

最後に、次の例は、任意の有効な SQL 式を使用してメッセージの内容がどのように配信できるかを示します。varchar 列 DEPT_NO および DEPT_NAME が含まれている第 2 の表 DEPT がある場合、社員の LASTNAME と DEPT_NAME を含むメッセージは次のように送信できます。

例 9:
select MQSEND(e.LASTNAME || ' ' || d.DEPTNAME)
from EMPLOYEE e, DEPT d
where e.DEPARTMENT = d.DEPTNAME

4.3 メッセージの取り出し

MQSeries DB2 関数では、メッセージは受信または読み取りができます。読み取りと受信の違いは、読み取りではメッセージをキューから削除せずにキューの一番上に戻しますが、受信操作ではメッセージがキューから削除されます。このため、受信操作を使用して取り出したメッセージは一度しか受信できませんが、読み取り操作を使用して取り出したメッセージは、同一のメッセージを何度でも取り出せます。次の例は、これを示しています。

例 10:
values MQREAD()

この例は、デフォルトのサービス・ポリシー特性を使用して、デフォルトのサービスによって定義されたキューの一番上にあるメッセージを含んでいる varchar ストリングを返します。読み取り可能なメッセージがない場合は、NULL 値が返されれることに注意してください。この操作では、キューは変更されません。

例 11:
values MQRECEIVE('Employee_Changes')

上記の例は、デフォルトのポリシーを使用して、Employee_Changes サービスによって定義されるキューの一番上からメッセージを削除する方法を示しています。

DB2 の非常に強力な機能の 1 つは、ユーザー定義の (または DB2 提供の) 関数から表を生成する機能です。この表関数機能を活用して、キューの内容を DB2 表として実体化できます。次の例は、そのもっとも単純な形を示しています。

例 12:
select t.* from table ( MQREADALL()) t

この照会は、デフォルトのサービスによって定義されるキュー内のすべてのメッセージと、それらのメッセージに関するメタデータで構成される表を返します。返される表構造の完全な定義は、『DB2 7.2 リリース情報』に定義されており、最初の列はメッセージの内容を参照し、残りの列にはメタデータが含まれています。このため、メッセージだけを返すには、上の例は次のように書き直すことができます。

例 13:
select t.MSG from table (MQREADALL()) t

表関数によって返される表は、データベースから直接取り出される表と違いはありません。これは、この表をさまざまな方法で使用できることを意味します。たとえば、表の内容を別の表と結合したり、キュー内のメッセージの数をカウントできます。

例 14:
select t.MSG, e.LASTNAME from table (MQREADALL() ) t, EMPLOYEE e
where t.MSG = e.LASTNAME
例 15:
select count(*) from table (MQREADALL()) t

表関数を使用した上にビューを作成することで、表のソースがキューであるという事実を隠すこともできます。たとえば、次の例では、NEW_EMPLOYEES というサービスによって参照されるキューに関して NEW_EMP という視点を作成します。

例 16:
create view NEW_EMP (msg) as
select t.msg from table (MQREADALL()) t

この場合、メッセージ全体を含む単一の列のみでビューが定義されています。メッセージが単純に構成されている場合、たとえば、2 つの固定長フィールドを含んでいる場合、DB2 組み込み関数を使用してメッセージを 2 つの列に解析するのが簡単です。たとえば、特定のキューに送信されるメッセージに常に 18 文字のラスト・ネームと、それに続く 18 文字のファースト・ネームが含まれていることがわかっている場合、各フィールドが別の列として含まれているビューは、次のようにして定義できます。

例 17:
create view NEW_EMP2 as
select left(t.msg,18) as LNAME, right(t.msg,18) as FNAME
from table(MQREADALL()) t

メッセージの解析の詳細な説明は、今後予定している技術白書に掲載します。最後に、1 つ以上のメッセージの内容をデータベースに保管したい場合がよくあります。これは、メッセージの内容を操作および保管する SQL のフルパワーを使用して行うことができます。おそらく、そのもっとも単純な例は、次のようなものです。

例 18:
insert into MESSAGES
select t.msg from table (MQRECEIVEALL()) t

単一の varchar(2000) 列を持つ表 MESSAGES がある場合、上記のステートメントはメッセージをデフォルトのサービス・キューから表に挿入します。さまざまな状況に対応して、一般的な方式に変化を付けることができます。

まとめると、ここでは、MQSeries DB2 を SQL のフルパワーとともにいかにさまざまな方法で使用できるかを説明しました。SQL

ステートメント内からメッセージを送受信でき、キューをデータベース表として操作できる一連の基本的な素材を示してきました。基本的に、基本的なメッセージングとデータベース操作を、どのようにして簡単かつ自然な方法で組み合せることができるかを示してきました。

4.4 アプリケーション間の接続

アプリケーションの統合は、多くのソリューションに共通の要素です。購入したアプリケーションを既存のインフラストラクチャーに統合するのか、新しく開発したアプリケーションを既存の環境に統合するだけかなのにかかわらず、異種のサブシステムの集まりを結び付けて全体として 1 つにまとめる作業に直面することがよくあります。MQSeries は、アプリケーションを統合するための基本的なツールと一般に見なされています。MQSeries は、ほとんどのハードウェア、ソフトウェアおよび言語環境でアクセスできるため、種類の非常に異なるアプリケーションの集合を相互接続する手段を提供します。

ここでは、いくつかのアプリケーション統合シナリオと、その DB2 での使用法を簡単に説明します。テーマが非常に広いため、アプリケーション統合の総合的な扱いは、本書の範囲を超えています。実際、2 つの簡単なテーマ、要求/応答通信と MQSeries Integrator およびパブリッシュ/サブスクライブに関する簡単な説明にとどめます。

4.4.1 要求/応答通信

要求/応答 (R/R) 通信手法は、1 つのアプリケーションが別のアプリケーションのサービスを要求するための非常に一般的なテクニックです。これを行う方法の 1 つは、要求側がサービス・プロバイダーに対して、実行すべきいくつかの作業を要求するメッセージを送信することであることは、すでに示しました。作業が完了すると、プロバイダーは要求側に結果を送信するか (または完了を確認するにとどめるか) どうかを決定できます。しかし、これまでに説明した基本的なメッセージング・テクニックを使用する場合、送信側の要求をサービス・プロバイダーの応答と結び付けるものは何もありません。要求側が処理を続行する前に応答を期待して待機しないかぎり、何らかの手段を使用してそれぞれの応答をその要求と関連付ける必要があります。MQSeries では、開発者にこのようなメカニズムを作成させるのでなく、1 つのメッセージ群を別のメッセージ群と関連付けるために使用できる相関 ID を提供しています。このメカニズムは数多くの方法に使用できますが、もっとも単純なのは、たとえば次のように要求側が既知の相関 ID でメッセージに印を付ける方法です。

例 19:
MQSEND ('myRequester', 'myPolicy','SendStatus:cust1','Req1')

このステートメントでは、要求の相関 ID を示すために、上記の MQSEND ステートメントに最後のパラメーター Req1 を追加しています。これで、この特定の要求に対する応答を受信するために、対応する MQRECREIVE ステートメントを使用して、この相関 ID に一致する指定サービスによって定義された最初のメッセージを、次のように選択的に取り出すことができます。

例 20:
MQRECEIVE('myReceiver','myPolicy','Req1')

要求をサービスするアプリケーションがビジー状態で、応答が送信される前に要求側が上記の MQRECEIVE を発行した場合、この相関 ID に一致するメッセージは見つかりません。

[サービス要求側とサービス・プロバイダー間のメッセージング]
サービス要求側とサービス・プロバイダー間のメッセージング図

上の図は、これを詳細に示しています。この図では、2 つのアプリケーションによる処理を示しています。1 つはサービス要求側で、もう 1 つはサービス・プロバイダーです。要求側によって要求メッセージ (M1) が開始され、aServer によって記述されるキューに送信されます。サービス・プロバイダーは、新しい作業を実行する準備ができると、要求 (M1) を受信し、要求されたサービスを実行します。サービス要求と相関 ID の両方を受信するには、次のようなステートメントを使用します。

例 21:
Select msg, correlid from table (MQRECEIVEALL('aServer','myPolicy',1)) t

これは、サービス aServer からの最初の要求のメッセージと相関 ID を返します。

サービスが実行されると、応答メッセージ (M2) が、aRequester によって記述されるキューに送信されます。その間、サービス要求側はほかの作業を行うことができます。事実、最初のサービス要求が一定時間内に応答される保証はないため、このようなアプリケーション・レベルのタイムアウトは、開発者が管理する必要があります。実際、要求側は応答があるかどうかを検出するためにポーリングする必要があります。

このように時間に依存しない非同期プロセッシングの利点は、要求側とサービス・プロバイダーが互いに完全に独立して実行することです。これは、アプリケーションが断続的に接続される環境だけでなく、処理する前に複数の要求や応答が集められる、よりバッチ指向の環境を受け入れるためにも使用できます。この種の集合は、データ・ウェアハウスやオペレーショナル・データ・ストアを定期的に更新するデータウェアハウス環境でよく使用されます。

4.4.2 パブリッシュ/サブスクライブ

ここでは、DB2 MQseries 関数でのパブリッシュ/サブスクライブ (pub/sub) テクニックの実装を説明します。pub/sub は、単純な配信リストから MQseries Integrator を用いた完全な pub/sub まで複数の方法で実装できます。さらに、メッセージのパブリッシュの動作は、明示的なプログラム制御の下でも、自動化された定義を介しても実行できます。ここでは、これらのテクニックそれぞれについて説明します。

単純なデータ・パブリケーション

アプリケーション統合のもう 1 つの一般的なシナリオは、1 つのアプリケーションがほかのアプリケーションに、興味のあるイベントについて通知するケースです。これは、別のアプリケーションによって監視されているキューにメッセージを送信することで、簡単に実現できます。メッセージの内容は、ユーザー定義のストリングでも、データベースの列から構成されてもかまいません。MQSEND 関数を使用して送信する必要があるのが単純なメッセージだけであることがよくあります。このようなメッセージを複数の受信側に同時に送信する必要がある場合は、MQSeries AMI の配信リスト機能を使用できます。

配信リストは、AMI 管理ツールを使用して定義します (注: AMT.XML ファイルを直接編集しても可)。配信リストは、個々のサービスのリストからなります。配信リストに送信されたメッセージは、リスト内に定義されたすべてのサービスに転送されます。これは、少数のサービスが常にすべてのメッセージに興味を持っていることがわかっている場合、特に役立ちます。次の例は、interestedParties 配信リストへのメッセージの送信を示しています。

例 22:
MQSEND('interestedParties', 'information of general interest');
[単純なデータ・パブリケーション]
単純なデータ・パブリケーション図

どのサービスがどのメッセージを受信するか、より細かい制御が必要な場合は、パブリッシュ/サブスクライブ機能が必要です。パブリッシュ/サブスクライブ・システムは、通常、多数のサブスクライバーが複数のパブリッシャーからのメッセージを受信するよう登録できる、スケーラブルで安全性の高い環境を提供します。この機能をサポートするには、MQPublish インターフェースを MQSeries Integrator とともに使用するか、または MQSeries パブリッシュ/サブスクライブ機能のみでも使用できます。

MQPublish により、ユーザーはメッセージに関連付けるトピックをオプションで指定できます。トピックを使用すると、サブスクライバーは、受信するメッセージをより明確に指定できます。上の図は、MQSeries Integrator を使用する手順の流れを示します。手順の流れは、次のようになります。

  1. MQSeries 管理者は、MQSeries Integrator パブリッシュ/サブスクライブ機能を構成します。
  2. 興味を持ったアプリケーションは、MQSI 構成によって定義されたサブスクリプション・ポイントにサブスクライブし、オプションで自分にとって興味のあるトピックを指定します。各サブスクライバーは、適切なトピックを選択し、さらに、MQSeries Integrator V2 のコンテンツ・ベースのサブスクリプション・テクニックも利用できます。[注意:詳細は、MQSeries Integrator V2 のマニュアルを参照してください。]キューは、サービス名で表されるように、サブスクライバーを定義することに注意してください。
  3. DB2 アプリケーションは、メッセージをサービス・ポイント Weather にパブリッシュします。オースチンのトピックでは、天気がみぞれであると示されているため、関心を持っているサブスクライバーには、オースチンの天気がみぞれ (Sleet) であることが通知されます。
  4. 実際にメッセージをパブリッシュするメカニズムは、DB2 の提供する MQSeries 関数によって処理されます。メッセージは、Weather というサービスを使用して MQSeries Integrator に送信されます。
  5. MQSI は Weather サービスからメッセージを受け取り、MQSI 構成によって定義された処理をすべて実行し、どのサブスクリプションを満足させるかを判断します。そこで、MQSI は、条件が一致しているサブスクライバー・キューにメッセージを送信します。
  6. Weather サービスにサブスクライブしオースチンに関する興味を登録しているアプリケーションは、着信サービスで「Sleet」(みぞれ) というメッセージを受信します。

前述の社員の例に戻ると、部門「5LGA」の全社員の名前、部門および年齢をパブリッシュする場合、次のステートメントを発行します。このデータでは、デフォルトのパブリケーション・サービスとポリシー、および NULL トピックを使用しています。

例 23:
select MQPUBLISH(LASTNAME || ' ' || FIRSTNAME || ' ' ||
DEPARTMENT|| ' ' ||char(AGE)) from EMPLOYEE
where DEPARTMENT = '5LGA'

パラメーターをすべて指定し、LASTNAME だけが含まれるようにメッセージを簡素化すると、ステートメントは次のようになります。

例 24:
select MQPUBLISH('HR_INFO_PUB', 'SPECIAL_POLICY',
'MANAGER', 'ALL_EMP:5LGA', LASTNAME)
from EMPLOYEE where DEPARTMENT = '5LGA'

このステートメントは、送信側が MANAGER サービスであることを示す SPECIAL_POLICY を使用して、メッセージを HR_INFO_PUB パブリケーション・サービスにパブリッシュします。トピック・ストリングは、「:」を使用して連結すれば複数のトピックを指定できることを示しています。この例では、2 つのトピックを使用することで、サブスクライバーは、ALL_EMP または 5LGA のみのいずれかに対してメッセージを受信するよう登録できます。

パブリッシュされたメッセージを受信するには、最初に、特定のトピックを含んでいるメッセージに関する興味を登録し、メッセージの送信先となるサブスクライバー・サービスの名前を指定する必要があります。AMI サブスクライバー・サービスは、ブローカー・サービスとレシーバー・サービスを定義することに注意してください。ブローカー・サービスはサブスクライバーがパブリッシュ/サブスクライブ・ブローカーと通信する方法で、レシーバー・サービスはサブスクリプション要求に一致するメッセージの送信先です。次のステートメントは、トピック ALL_EMP に関する興味を登録します。

例 25:
MQSUBSCRIBE('aSubscriber', 'ALL_EMP')

アプリケーションが一度サブスクライブすると、トピック ALL_EMP でパブリッシュされたメッセージは、サブスクライバー・サービスによって定義されたレシーバー・サービスに転送されます。アプリケーションは、複数のサブスクリプションを同時に持つことができます。自分のサブスクリプションに一致するメッセージを取り出すには、標準のメッセージ取り出し関数ならどれでも使用できます。たとえば、サブスクライバー・サービス aSubscriber で aSubscriberReceiver がレシーバー・サービスになるよう定義されている場合、次のステートメントは最初のメッセージをそのまま読み取ります。

例 26:
MQREAD('aSubscriberReceiver')

メッセージとそれがパブリッシュされたトピックの両方を検索するには、表関数の 1 つを使用できます。次のステートメントは、aSubscriberReceiver から最初の 5 個のメッセージを受信して、メッセージとトピックの両方を表示します。

例 27:
Select t.msg, t.topic from table (MQRECEIVEALL('aSubscriberReceiver',5)) t

トピック ALL_EMP を持つメッセージをすべて読み取るには、次のように発行することで SQL の機能を活用できます。

例 28:
Select t.msg from table (MQREADALL('aSubscriberReceiver')) t where t.topic = 'ALL_EMP'

注意:制約とともに MQRECEIVEALL を使用した場合、トピック ALL_EMP でパブリッシュされたメッセージだけでなく、キュー全体が消費されることを自覚してください。これは、表関数は、制約が適用される前に実行されるためです。

特定のトピックに対してサブスクライブすることに興味がなくなった場合は、次のようなステートメントを使用して明示的にサブスクライブを解除する必要があります。

例 29:
MQUNSUBSCRIBE('aSubscriber', 'ALL_EMP')

このステートメントを発行すると、パブリッシュ/サブスクライブ・ブローカーは、このサブスクリプションに一致するメッセージを配信しなくなります。

自動パブリケーション

データベース・メッセージングのもう 1 つの重要なテクニックは、自動パブリケーションです。DB2 のトリガー機能を使用すると、メッセージをトリガー起動の一部として自動的にパブリッシュできます。自動化されたデータ・パブリケーション用にはほかの方法も存在していますが、トリガー・ベースの方法では、管理者や開発者がメッセージの内容を自由に構成でき、トリガーの動作を柔軟に定義できます。トリガーの使用に関しては、実行の頻度とコストに注意をはらう必要があります。次の例では、MQSeries DB2 関数でトリガーを使用する方法を示します。

次の例では、新しい社員が雇われるたびにメッセージをパブリッシュするのがいかに簡単であるかを示しています。NEW_EMP に関する興味を登録して HR_INFO_PUB サービスにサブスクライブするすべてのユーザーやアプリケーションが、各新入社員の入社日、名前および部門の含まれたメッセージを受信します。

例 30:
CREATE TRIGGER new_employee AFTER INSERT ON employee
REFERENCING NEW AS n
FOR EACH ROW MODE DB2SQL
VALUES MQPUBLISH('HR_INFO_PUB', 'NEW_EMP', current date ||
' ' || LASTNAME || ' ' || DEPARTMENT)

トリガー機能を使用して、異種混合環境で非常に単純なデータ・レプリケーションを実行することもできます。DB2 DataPropagatorR の威力と洗練さの代わりにはならないにしろ、この手法は、着信メッセージの内容を変換し、変換されたデータを 1 つ以上のデータベースに潜在的に格納するために MQSeries Integrator を使用する場合に役立ちます。


5. まとめ

本書では、DB2 と MQSeries の組み合わせにより、さまざまな開発ニーズを解決できることを示してきました。新しい DB2 メッセージング機能は、使いやすく、機能や関数の強力なレパートリーを提供しています。基本的なデータグラムからより洗練されたパブリッシュ/サブスクライブ・メッセージングに至るまで、これらの機能はデータベース・アプリケーションの幅を広げ、アプリケーションの統合を簡素化し、一連の異種プラットフォーム間でデータを有効に共用するために使用できます。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=326474
ArticleTitle=DB2 アプリケーションからの MQSeries の使用
publish-date=08062001