|
|
イベント・ブローカを使用するには、準備作業を行う必要があります。次の図は、それらの準備作業、およびアプリケーション管理者またはプログラマのどちらがその作業を行うのかを示しています。
これらの作業を行う手順に関しては、図のボックスをクリックしてください。
| 注: | イベント・ブローカで行われる処理を理解するには、bankapp (Oracle Tuxedoシステムに同梱のサンプル・アプリケーション)を実行します。bankappのコピー方法とデモとしての実行方法については、『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』のbankapp(完全なC言語アプリケーション)のチュートリアルを参照してください<Default ?Font>。 |
クライアントがイベント・ブローカにアクセスするには、Oracle Tuxedoシステムで提供されている2つのサーバーのいずれかを使用します。つまり、アプリケーション・イベントを処理するTMUSREVT(5)、またはシステム・イベントを処理するTMSYSEVT(5)を使用します。このサーバーは両方ともイベントを処理し、サブスクライバへの通知をトリガーします。
ご使用のシステムにOracle Tuxedoのイベント・ブローカを構成するには、次の例に示すように、この2つのサーバーのいずれかまたは両方をUBBCONFIGファイルのSERVERSセクションで設定します。
*SERVERS
TMSYSEVT SRVGRP=ADMIN1 SRVID=100 RESTART=Y GRACE=900 MAXGEN=5
CLOPT="-A --"
TMSYSEVT SRVGRP=ADMIN2 SRVID=100 RESTART=Y GRACE=900 MAXGEN=5
CLOPT="-A -- -S -p 90"
TMUSREVT SRVGRP=ADMIN1 SRVID=100 RESTART=Y
MAXGEN=5 GRACE=3600
CLOPT="-A --"
TMUSREVT SRVGRP=ADMIN2 SRVID=100 RESTART=Y
MAXGEN=5 GRACE=3600
CLOPT="-A -- -S -p 120"
どちらのサーバーもネットワーク上の任意の場所に配置できます。ただし、MASTERサイトには主要サーバーを割り当てることをお薦めします。
| 注: | イベント・ポストとイベント通知に起因するネットワーク・トラフィックは、ネットワーク上の別のマシンにセカンダリ・サーバーを割り当てると減らすことができます。 |
セカンダリ・サーバーは、プライマリ・サーバーをポーリングして現在のサブスクリプション・リストを取得します。このリストには、フィルタリングと通知に関するルールが定義されています。デフォルトでは、ポーリングは30秒間隔で行われます。必要に応じて、この間隔は変更することができます。
ポーリング間隔(秒単位)を設定するには、構成ファイルのTMUSREVT(5)またはTMSYSEV(5)エントリに-pコマンド行オプションを使用します。
-p poll_secondsサブスクリプションが追加されている間と、セカンダリ・サーバーが更新されている間は、イベント・メッセージが失われたように見えます。
Oracle Tuxedoアプリケーション管理者は、クライアント・プロセスとサーバー・プロセスのかわりに、EVENT_MIB(5)のT_EVENT_COMMANDクラスへの呼出しを行って、サブスクリプションをリクエストできます。プログラムでtpsubscribe(3c)関数を呼び出して、イベントをサブスクライブすることもできます。
図6-1は、クライアントとサーバーがイベント・ブローカを使用して、イベントのサブスクライブ、ポスト、サブスクライブ解除を行うプロセスを示しています。
クライアントまたはサーバーがイベントをサブスクライブするには、tpsubscribe(3c)を呼び出します。tpsubscribe()の引数はeventexpr (必須)だけです。eventexprの値はワイルドカード文字列で、ユーザーに通知する必要があるイベント名を識別します。ワイルドカード文字列については、『Oracle Tuxedo ATMI C言語関数リファレンス』のtpsubscribe(3c)のリファレンス・ページを参照してください<Default ?Font>。
たとえば、UNIXシステム・プラットフォーム上のユーザーに、ネットワーキング・カテゴリに関するすべてのイベントを通知する必要があるとします。その場合、eventexprに次の値を指定します。
\.SysNetwork.* ピリオド(.)の前のバックスラッシュは、ピリオドがリテラルであることを示します。(ピリオドの前にバックスラッシュがない場合は、ピリオドは改行文字以外の任意の文字として解釈されます。)\.SysNetwork.*の最後にある.*は、改行文字以外の0個以上の任意の文字として解釈されます。
また、クライアントまたはサーバーがイベント・データをフィルタするには、tpsubscribe()の呼出し時にfilter引数(オプション)を指定します。filterの値は、ブール値のフィルタ・ルールを含む文字列です。イベント・ブローカがイベントをポストする場合、このルールが正常に評価されることが必要です。
たとえば、ユーザーに重大度レベルがERRORであるシステム・イベントだけを通知する必要があるとします。その場合、filterに次の値を指定します。
”TA_EVENT_SEVERITY=’ERROR’” イベント名がポストされ、それがeventexprに合致すると、イベント・ブローカはeventexprに対応付けられているフィルタ・ルールでポストされたデータをテストします。データがフィルタ・ルールに違反していない場合、またはイベントに対するフィルタ・ルールが存在しない場合、サブスクライバはイベント通知およびイベントと共にポストされたすべてのデータを受け取ります。
アプリケーションからイベント・ブローカにアクセスするには、ATMIまたはEVENT_MIB(5)を使用します。表6-1は、この2つの方法について説明しています。
| 注: | tppost(3c)、tpsubscribe(3c)、およびtpunsubscribe(3c)はC言語の関数です。これらの関数に相当するルーチン(TPPOST(3cbl)、TPSUBSCRIBE(3cbl)、およびTPUNSUBSCRIBE(3cbl))がCOBOLプログラマ用に提供されています。詳細は、『Oracle Tuxedo ATMI C言語関数リファレンス』<Default ?Font>および『Oracle Tuxedo ATMI COBOL関数リファレンス』<Default ?Font>を参照してください。 |
クロス・ドメイン環境でブローカ・イベントのサブスクライブ、ポストおよびサブクスライブ解除を行うための機能がTuxedoに追加されています。
この機能を有効にするには、静的イベント入出力情報を管理するために、DM_EVT_INおよびDM_EVT_OUTという2つの新しいセクションがDMCONFIGに追加されています。
DM_EVT_INおよびDM_EVT_OUTの詳細は、Tuxedoリファレンス・ガイドのDMCONFIG(5)を参照してください。
| 注: | UBBCONFIGでは、GWTサーバーの前にEvtBrokerサーバーを構成する必要があります。これは、GWTが起動時にEvtBrokerへの構成済イベントをサブスクライブするためです。 |
次の図6-2は、クロス・ドメイン環境におけるブローカ・イベントのサブスクライブ、ポストおよびサブクスライブ解除の一般的な処理フローを示します。
この使用事例では、DMCONFIGがどのように構成されるかを詳しく説明します。
図6-2で示すように、2つのクライアント(クライアントAおよびクライアントB)が2つのドメイン(ドメインAおよびドメインB)に設置され、各ドメインにはSHMモードのマシンが1台ずつ(マシンAおよびマシンB)含まれます。
マシンAについて、dmloadcfを使用して、次に示すようにDMCONFIGの追加構成を有する新しいBDMCONFIGを作成し、次にtmboot Tuxedoを使用します。
*DM_EVT_IN
MACHINEB_EVT
LACCESSPOINT=DOMAINA
*DM_EVT_OUT
MACHINEA_EVT
LACCESSPOINT= DOMAINA
RACCESSPOINT= DOMAINB
マシンBについて、dmloadcfを使用して、次に示すようにDMCONFIGの追加構成を有する新しいBDMCONFIGを作成し、次にtmboot Tuxedoを使用します。
*DM_EVT_IN
MACHINEA_EVT
LACCESSPOINT=DOMAINB
*DM_EVT_OUT
MACHINEB_EVT
LACCESSPOINT= DOMAINB
RACCESSPOINT= DOMAINA
上記のとおりに構成した後、2つのクライアントごとに次に示す2段階のテストを実行します。
結果: DMCONFIGが正しく構成されていれば、クライアントBはイベントMACHINEA_EVTを受信します。
クロス・ドメイン環境では、すべてのイベントが明示的にインポート/エクスポートされます(不明なドメインへのリクエストは受け入れられません)。正しく構成されると、GWTサーバーはTuxedoの起動時にローカル・イベント・ブローカへのすべての構成済イベントを自動的にサブスクライブします。リモート・イベント・メッセージを受信すると、ローカルGWTはそのリクエストをイベント・ブローカに転送します。一方、ローカル・イベントがポストされると、イベント・ブローカはそのイベントをローカルGWT (そのイベントをサブスクライブ済)に転送します。その後、ローカルGWTはそのイベントを構成済リモート・ドメインのGWTに転送します。
ユーザーが上記のとおりに静的構成を設定できるようになる以外にも、Tuxedoでは、システムをシャットダウンせずに必要に応じてイベント構成を動的に変更するための2種類の管理方法(dmadminコマンドおよびMIB操作)を使用できます。
「dmadmin」コマンドでは、イベント構成を動的にサポートするサブコマンド(「advertiseevent」および「unadvertiseevent」)ならびに2つのセクション(「EVENTS_IN」および「EVENTS_OUT」)が追加されます。関連クラスがMIB操作に追加されます。
詳細は、Tuxedoコマンド・リファレンスのdmadmin(1)およびTuxedoリファレンス・ガイドのDM_MIB(5)を参照してください。
クロス・ドメイン・イベント・ブローカ機能がサポートされるのは、GWTおよびEvtBrokerの両方がOracle Tuxedo 12cリリース1 (12.1.1)以上で実行されている場合のみです。
EventBrokerでは、図6-3で示すとおりにサブスクライバにイベントを通知する様々な方法をサポートしています。
どの通知方法を選択しても、その実装方法は同じです。tpsubscribe()への呼出しで、TPEVCTL型の構造体を参照する引数を指定します。
引数の値がNULLの場合、イベント・ブローカは非請求メッセージをサブスクライバに送信します。通知をサービスに送信する方法と、安定したストレージ・キューに送信する方法では、クライアントが通知を直接リクエストすることはできません。サブスクライブするには、クライアントがサービス・ルーチンを呼び出す必要があります。
各サブスクリプションに対して、次の通知方法を選択することができます。つまり、イベント・ブローカでは以下を行うことができます。
T_EVENT_CLIENTクラスの定義を参照してください<Default ?Font>。)ctlパラメータが有効なTPEVCTL構造体を指していることが必要です。(『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のEVENT_MIB(5)エントリのT_EVENT_SERVICEクラスの定義を参照してください<Default ?Font>。)eventexprおよびfilterの値のほかに、キュー・スペース、キュー名、相関識別子が指定されています。これは、合致を検出する場合に使用されます。 相関識別子は、同じイベント記述とフィルタ・ルールが定義され、格納先が同じキューである複数のサブスクリプションを区別するために使用されます。(『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のEVENT_MIB(5)エントリのT_EVENT_QUEUEクラスの定義を参照してください<Default ?Font>。)EVENT_MIBのT_EVENT_COMMANDクラスを使用して、サブスクライバは実行可能プロセスを呼び出します。合致するデータが検出されると、そのデータは要求されたオプションと、実行可能プロセスの名前として使用されます。(『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のEVENT_MIB(5)エントリのT_EVENT_COMMANDクラスの定義を参照してください<Default ?Font>。)EVENT_MIBのT_EVENT_USERLOGクラスを使用して、サブスクライバはシステムUSERLOGメッセージを書き込みます。イベントが検出されて合致すると、これらのイベントはUSERLOGに書き込まれます。(『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のEVENT_MIB(5)エントリのT_EVENT_USERLOGクラスの定義を参照してください<Default ?Font>。)
クライアントがtpterm(3c)を呼び出してアプリケーションを終了すると、サブスクリプションが永続として指定されていないかぎり、すべてのサブスクリプションは取り消されます。(永続として指定されている場合、クライアントがtpterm()を実行した後でも、サブスクリプションは引き続きポストを受け取ります。)クライアントが後でアプリケーションに再度参加し、これらのサブスクリプションを新しくする場合、再度サブスクライブする必要があります。
良く設計されたクライアントは、tpterm()を呼び出す前にサブスクライブを解除します。その場合、アプリケーションを終了する前に、tpunsubscribe(3c)を呼び出します。
トランザクションでイベント・ブローカを使用する場合は、次の内容に注意してください。
NULL_TMSパラメータを構成する必要があります。TPEVTRANフラグを設定します。サブスクリプションがトランザクションに関与して行われた場合、イベントに応答して行われる処理は、呼出し側のトランザクションの一部として行われます。| 注: | この方法は、Oracle Tuxedoサービスが呼び出されるサブスクリプション、またはレコードを永続的なキューに登録するサブスクリプションに対してのみ使用できます。 |
ポスト元とサブスクライバがトランザクションをリンクすることに合意すると、ボーティング・フォームが作成されます。ポスト元では、なんらかの条件が合致するとアサーションを出力し、メッセージをトランザクションに対応付けます。(つまり、元のプロセスを離れたメッセージは、トランザクションと対応付けられていると見なされます。)そのトランザクションはイベント・ブローカに渡されます。
サービスの呼び出しやサブスクライバに対してメッセージをキューに格納することなど、イベント・ブローカの処理も同じトランザクションの一部です。実行中のサービス・ルーチンがエラーを検出すると、そのルーチンはトランザクションを失敗させることができます。その場合、トランザクションに関与するほかのすべてのサブスクリプションおよびポストされた元のトランザクションなど、ほかのサービスを呼び出していたり、ほかのデータベース処理を行っていたすべての処理がロールバックされます。ポスト元はアサーションを実行(「私がこれを行います」と表明)し、データを提供し、そのデータをトランザクションとリンクさせます。
数多くの無名サブスクライバ、つまりポスト元が認識していないサブスクライバは、トランザクションに関与して呼び出されます。サブスクライバがその処理をポスト元の処理とリンクできなかった場合、トランザクション全体がロールバックされます。トランザクションに関与するすべてのサブスクライバは、その処理をポスト元の処理とリンクする必要があります。リンクしないと、すべての処理がロールバックされます。ポスト元がそのトランザクションでポストすることを許可していない場合、イベント・ブローカによって別のトランザクションが開始され、トランザクションに関与するすべてのサブスクリプションがそのトランザクションに集められます。これらのトランザクションのいずれかが失敗すると、トランザクションに関与するサブスクリプションの代わりに行われたすべての処理はロールバックされます。ただし、ポスト元のトランザクションはロールバックされません。このプロセスは、TPEVTRANフラグによって制御されます。
株式売買が、取引売買アプリケーションで完了しようとしています。取引トランザクションで、各種のサービスによって数多くのデータベース・レコードが更新されました。イベントがポストされると、取引が今行われようとしていることが通知されます。
このような取引の監査を記録するアプリケーションは、このイベントをサブスクライブしています。つまり、このアプリケーションでは、このようなイベントがポストされたら、指定されたキューに必ずレコードを格納するように要求しています。サービス・ルーチンは取引を実行できるかどうかを決定し、このようなイベントをサブスクライブしています。また、そのような取引が行われる場合は通知されます。
すべての処理が問題なく行われると、取引が完了し、監査が記録されます。
キューでエラーが発生し、監査が記録されなかった場合、株式取引全体がロールバックされます。同様に、サービス・ルーチンが失敗すると、トランザクションがロールバックされます。すべての処理が正常に行われると、取引が行われてトランザクションがコミットされます。
  
|