|
|
次の項では、Oracle Tuxedo Message Queue製品の概要を説明します。
Oracle Tuxedo Message Queue (OTMQ)コンポーネントは、Oracle Tuxedoのキューイング・サービスを改善および拡張します。Oracle Tuxedo /Qコンポーネントの既存のキューイング機能に加え、OTMQでは、信頼性の高いメッセージ配信、同期/非同期メッセージング、パブリッシュ/サブスクライブ、メッセージ・フィルタリング、動的キュー・エイリアス(ネーミング)、ジャーナルといった、より豊富なキューイング機能が提供されます。また、OTMQはOracle Tuxedoインフラストラクチャに基づいて実装されているため、トランザクション、セキュリティ、スケーラビリティおよびHAがサポートされます。
Oracle MessageQ (OMQ)アプリケーションの互換性のために、PAMS APIがサポートされています。OMQアプリケーションは、再コンパイルおよび再リンクした後で、OTMQを使用して実行できます。詳細は、「Oracle Tuxedo Message Queue PAMSプログラミング・ガイド」を参照してください。
OTMQには、その動作を定義する複数の属性があります。詳細は、「Oracle Tuxedo Message Queueコマンド・リファレンス」のtmqadminを参照してください。
キュー・タイプは、キューのライフ・サイクルによって次のように分けられます。
永続キューは、事前に割り当てる必要があります。永続キューには、永続または一時のアクティブ・プロパティがあります。永続アクティブ・キューは、記憶域割当て制限を超過しないかぎり、それにアタッチしているアプリケーションがなくても、常にメッセージを受信して格納できます。一時アクティブ・キューは、アプリケーションによってアタッチされている場合にのみ、メッセージを受信して格納できます。永続キューは、tmqadmin qcreateコマンドによって作成されます。
永続キューには、作成時に次のタイプのうちの1つを指定します。
プライマリ・キューは、ユーザー・プロセスのメイン・メールボックスとして動作し、別のプロセスからのメッセージを受信します。アタッチできるのは、1つのキュー・クライアントのみです。アプリケーションで保持できるのは、1つのプライマリ・キューのみですが、別のタイプのキューとの関連付けが可能です。
セカンダリ・キューは、ユーザー・プロセスの代替メールボックスとして動作し、メッセージを受信します。アプリケーションは、アタッチすることでセカンダリ・キューを所有します。アプリケーションで、セカンダリ・キューの所有者であるプライマリ・キューにアタッチすると、それと同時に、そのアプリケーションは自動的にセカンダリ・キューにもアタッチされます。アプリケーションがそのプライマリ・キューからデタッチすると、関連するすべてのセカンダリ・キューもデタッチされます。
マルチリーダー・キューは事前割当てです。同時に複数のキュー・クライアントがそれにアタッチできます。
無制限キューの動作は、従来のTuxedo /Qキューとまったく同じです。アプリケーションでは、無制限キューからデキューするために無制限キューにアタッチする必要はありません。
一時キューは、実行時にアプリケーションでアタッチをリクエストしたときに作成されます。一時キューにアタッチしているプロセスはそのキューの所有者となり、他のプロセスはそのキューにアタッチすることも、キューからメッセージを受信することもできません。アプリケーションが一時キューからデタッチすると、そのキューに残されたすべてのメッセージは削除されます。一時キューの数および範囲は、tmqadmin qspacecreateコマンドで指定します。
OTMQでは、確実に受信者へメッセージを正常に配信できる、信頼性の高いメッセージ配信が提供されます。
詳細は、『Oracle Tuxedo Message Queueプログラミング・ガイド』の「リカバリ可能メッセージングの使用」を参照してください。
配信インタレスト・ポイント(DIP)は、メッセージ配信中のチェックポイントです。メッセージが指定したチェックポイントを通過すると、ACK通知メッセージが送信元アプリケーションに返信され、メッセージ配信のステータスが示されます。
SAF: リカバリ可能メッセージがローカルのキュー・スペース記憶域に格納されたときDQF: リカバリ可能メッセージがターゲットのキュー・スペース記憶域に格納されたときMEM: リカバリ不可メッセージがターゲットのキューに格納されたときDEQ: リカバリ不可メッセージがターゲットのキューからデキューされたときACK: 受信者がtpqconfirmmsg(3c)コマンドを使用してACK通知を返信し、リカバリ不可メッセージが明示的に確認されたときCONF: リカバリ可能メッセージがDQFからターゲットのキューに正常に配信され、tpqconfirmmsg(3c)を使用して明示的に確認されたときOTMQアプリケーションでは、次に示すモードでメッセージをエンキュー/送信できます。
アプリケーションでは、ターゲットにメッセージを送信した後、確認応答があるまで待機します。メッセージが特定の配信インタレスト・ポイントに送信されるまで待つ、という選択もできます。
アプリケーションでは、メッセージ送信後の待機は行わず、明示的にtpdeqplus(3c)を呼び出してACK通知メッセージを取得し、メッセージがターゲットに正常に配信されたことを確認します。
アプリケーションでは、メッセージ送信後の待機は行わず、確認メッセージも期待しません。このモードは、パフォーマンスを重視するケースのためのものです。
配信不可メッセージ・アクション(UMA)は、メッセージの送信者が確認応答の通知の失敗を受信したときのアクションです。
信頼性の高いメッセージ配信が有効の場合、UMAは、メッセージのSAF/DQF記憶域への格納に失敗したときのアクションです。
そうでない場合は、UMAは、メッセージの配信が失敗した場合のアクションです。
メッセージは、キューに対して別の順序を指定しないかぎり、FIFOの順序でキューから読み出されます。また、OTMQでは、メッセージ・フィルタが提供され、それに定義した選択基準に一致するメッセージのみを読み取ることができます。詳細は、『Oracle Tuxedo Message Queueプログラミング・ガイド』の「フィルタの使用」を参照してください。
パブリッシュおよびサブスクライブ機能は、メッセージを、メッセージ・ブロードキャスト・ストリームからの受信情報に登録されている複数の受信者に送信します。それは、メッセージをキューイングするクライアントおよびサーバー内のイベントの非同期ルーティングです。
OTMQアプリケーションでは、標準のtpqpublish関数を使用してブロードキャスト・メッセージを送信できます。送信側アプリケーションでは、受信側プログラムの場所や数を知らなくてもブロードキャスト・メッセージを生成できます。
OTMQアプリケーションでは、最初にブロードキャスト・ストリームにサブスクライブすることで、選択的にブロードキャスト・メッセージを受信できます。メッセージ・ストリームを受信するには、受信側アプリケーションで、まずtpqsubscribeを使用してメッセージ・ストリームにサブスクライブします。その後、そのアプリケーションでブロードキャスト・メッセージが有効になり、標準のtpdeqplus関数を使用した処理により、受信者のキューに流れ込みます。
詳細は、『Oracle Tuxedo Message Queueプログラミング・ガイド』の「パブリッシュ/サブスクライブ」を参照してください。
ネーミングは、アプリケーションでキュー名のかわりにエイリアスでキューを参照できるようにする強力な機能です。ネーミングにより、アプリケーションが現在の環境構成の詳細から切り離され、システム管理者は、開発者にアプリケーションの変更を依頼することなしに構成を変更できるようになります。
詳細は、『Oracle Tuxedo Message Queueプログラミング・ガイド』の「ネーミングの使用」を参照してください。
OTMQでは、リカバリ可能と指定されたメッセージの格納にメッセージ・リカバリ・ジャーナル・キューが使用されます。
ローカルのキュー・スペース上のメッセージ・ジャーナル・キューは、ストア・アンド・フォワード(SAF)と呼ばれます。リモートのキュー・スペース上のメッセージ・ジャーナル・キューは、宛先キュー・ファイル(DQF)と呼ばれます。リカバリ可能メッセージが配信できなかった場合、SAFまたはDQFのいずれかに格納され、自動的にターゲットに再送されます。
配信不能キュー(DLQ)は、自動リカバリのために格納できなかった配信不可メッセージを格納するメモリー・ベースのメカニズムです。DLQと同様に、使用不能のレター・ジャーナル(DLJ)は、自動リカバリのために格納できなかった配信不可メッセージを格納するディスク・ベースのメカニズムです。
もう1つの補助的なジャーナル・キューが、事後確認ジャーナル(PCJ)です。受信者による確認の成功したリカバリ可能メッセージは、監査のためにPCJに書き込むことができます。
OTMQでは、これらのジャーナル・キューからメッセージをダンプするため、tpqreadjrn関数が提供されます。
詳細は、『Oracle Tuxedo Message Queueプログラミング・ガイド』の「リカバリ可能メッセージングの使用」を参照してください。
WSモードでは、リカバリ可能配信モードを使用して送信されるOTMQメッセージは、サーバー・システムへの接続が使用できない場合、ローカルのストア・アンド・フォワード(SAF)ジャーナル・ファイル(tmqsaf.jrn)に書き込まれます。
| 注: | このWS SAF機能は、WSクライアントが「シングルコンテキスト」モードの場合にのみ使用可能です。詳細は、『Oracle Tuxedo関数リファレンス』のtpinit(3c)に関する項を参照してください。 |
OTMQのQSPACEは、64ビットのUNIXプラットフォームで、永続および非永続メッセージの両方で2Gのサイズ制限を超えることができます。
tmqadminで、サブコマンドのcrdlがQSPACE用の永続デバイスを作成します。このコマンドの最大値は2147483647で、これはシステム値であり、単位はシステム・ブロック・サイズです。このため、永続QSpaceの最大サイズは、2147483647*ブロック(バイト)です。
tmqadmin->qspacecreateコマンドには-nオプションがあり、このオプションは、キュー・スペース内のすべてのキューの非永続メッセージのために共有メモリー内に予約される領域のサイズを指定します。サイズは、バイト(b)またはブロック(B)で指定し、ブロック・サイズはディスクのブロック・サイズと同じです。qspacecreate -nコマンドのブロック(B)とバイト(b)の両方の引数について、最大値は2147483647です。ブロック(B)引数を使用する場合、予約される非永続メッセージの最大サイズは、2147483647*ブロックです。
| 注: | 64ビット・プラットフォームのHPUXでは、hpux_ma.hの中で_TMSIGNLESHMが1に定義されており、これは、1つのプロセスが1つの共有メモリー・セグメントを作成し、それをアドレス空間にアタッチすることを表します。このため、tmqadminコマンドで2Gを超える共有メモリーを作成する場合は、Oracle Tuxedo環境変数のTM_ENGINE_TMSHMSEGSZを、システムで定義されるSHMAXの値を超えない、より大きな値に設定します。 |
| 注: | もう1つの環境変数TM_QM_NAPTIMEがあり、これはスレッドのスリープ時間をナノ秒で定義します。この変数の使用は、キューのデッド・ロック状態を検出するための時間間隔を拡張する可能性があることに注意してください。 |
Oracle Tuxedo APIのtpinitには、シングル・コンテキスト・モードとマルチコンテキスト・モードの2つの動作モードがあります。OTMQでは、アプリケーションで明示的にtpinitを呼び出しても、OTMQは自動的にはマルチコンテキスト・モードにはなりません。
アプリケーションでtpinitを呼び出さない場合、それに続くtpqattachの呼出しでOTMQは自動的にマルチコンテキスト・モードになります。WSクライアントでは、マルチコンテキスト・モード関連の自動化は使用できません。
OTMQでは、キューイング・サービスのため、次に示すシステム・レベルのコンポーネントが提供されます。
キューイング・サービスをサポートするため、OTMQでは、OTMQキュー・スペースを管理するX/OPEN XA準拠のリソース・マネージャ・インタフェースとして、新規のトランザクション・マネージャ・サーバーTMS_TMQMが提供されます。
OTMQには、基本的なキューイング・サービス以外の追加機能もあります。これらの機能をサポートするためのOTMQのシステム・レベル・コンポーネントを次に示します。
TMQ_NAOTMQネーミング・サーバー。これにより、実行時のキューのエイリアス・バインディングおよびルックアップが可能となるネーミング・サービスが提供されます。
TMQEVT OTMQイベント・ブローカ。 tpqpublishを使用してトピックがパブリッシュされたときの通知に使用されます。トピックをサブスクライブするには、tpqsubscribe(3c)を使用します。
TMQFORWARDPLUS メッセージ転送サーバー。これは、後で処理するためにtpenqueue(3c)/tpenqplus(3c)を使用して格納されているメッセージを転送します。アプリケーション管理者は、*SERVERSセクションでこのサーバーをアプリケーション・サーバーとして指定することにより、アプリケーション・サーバーのメッセージ処理を自動化できます。
OTMQは、Oracle Message Queue (OMQ)と相互運用することもできます。メッセージ・レベルでの相互運用性を実現するためのOTMQの2つのシステム・レベル・コンポーネントを次に示します。
  
|