|
|
イベント・ブローカを使用するには、準備作業を行う必要があります。次の図は、それらの準備作業、およびアプリケーション管理者またはプログラマのどちらがその作業を行うのかを示しています。
これらの作業を行う手順に関しては、図のボックスをクリックしてください。
| 注意: | イベント・ブローカで行われる処理を理解するには、bankapp (Oracle Tuxedoシステムに同梱のサンプル・アプリケーション)を実行します。bankappのコピー方法とデモとしての実行方法については、『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』のbankapp(複雑なC言語アプリケーション)のチュートリアルに関する項を参照してください。 |
クライアントがイベント・ブローカにアクセスするには、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)」リファレンス・ページを参照してください。
たとえば、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関数リファレンス』および『Oracle Tuxedo ATMI COBOL関数リファレンス』を参照してください。 |
イベント・ブローカでは、図6-2に示すように、各種のイベント通知方法がサポートされています。
どの通知方法を選択しても、その実装方法は同じです。tpsubscribe()への呼出しで、TPEVCTL型の構造体を参照する引数を指定します。
引数の値がNULLの場合、イベント・ブローカは非請求メッセージをサブスクライバに送信します。通知をサービスに送信する方法と、安定したストレージ・キューに送信する方法では、クライアントが通知を直接リクエストすることはできません。サブスクライブするには、クライアントがサービス・ルーチンを呼び出す必要があります。
各サブスクリプションに対して、次の通知方法を選択することができます。つまり、イベント・ブローカでは以下を行うことができます。
T_EVENT_CLIENTクラスの定義を参照してください。ctlパラメータが有効なTPEVCTL構造体を指していることが必要です。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「EVENT_MIB(5)」のT_EVENT_SERVICEクラスの定義を参照してください。eventexprおよびfilterの値のほかに、キュー・スペース、キュー名、相関識別子が指定されています。これは、合致を検出する場合に使用されます。 相関識別子は、同じイベント記述とフィルタ・ルールが定義され、格納先が同じキューである複数のサブスクリプションを区別するために使用されます。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「EVENT_MIB(5)」のT_EVENT_QUEUEクラスの定義を参照してください。EVENT_MIBのT_EVENT_COMMANDクラスを使用して、サブスクライバは実行可能プロセスを呼び出します。合致するデータが検出されると、そのデータは要求されたオプションと、実行可能プロセスの名前として使用されます。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「EVENT_MIB(5)」のT_EVENT_COMMANDクラスの定義を参照してください。EVENT_MIBのT_EVENT_USERLOGクラスを使用して、サブスクライバはシステムUSERLOGメッセージを書き込みます。イベントが検出されて合致すると、これらのイベントはUSERLOGに書き込まれます。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「EVENT_MIB(5)」のT_EVENT_USERLOGクラスの定義を参照してください。
クライアントがtpterm(3c)を呼び出してアプリケーションを終了すると、サブスクリプションが永続として指定されていないかぎり、すべてのサブスクリプションは取り消されます。永続として指定されている場合、クライアントがtpterm()を実行した後でも、サブスクリプションは引き続きポストを受け取ります。クライアントが後でアプリケーションに再度参加し、これらのサブスクリプションを新しくする場合、再度サブスクライブする必要があります。
良く設計されたクライアントは、tpterm()を呼び出す前にサブスクライブを取り消します。その場合、アプリケーションを終了する前に、tpunsubscribe(3c)を呼び出します。
トランザクションでイベント・ブローカを使用する場合は、次の内容に注意してください。
NULL_TMSパラメータを構成する必要があります。TPEVTRANフラグを設定します。サブスクリプションがトランザクションに関与して行われた場合、イベントに応答して行われる処理は、呼出し側のトランザクションの一部として行われます。| 注意: | この方法は、Oracle Tuxedoサービスが呼び出されるサブスクリプション、またはレコードを永続的なキューに登録するサブスクリプションに対してのみ使用できます。 |
ポスト元とサブスクライバがトランザクションをリンクすることに合意すると、ボーティング・フォームが作成されます。ポスト元では、なんらかの条件が合致するとアサーションを出力し、メッセージをトランザクションに対応付けます。つまり、元のプロセスを離れたメッセージは、トランザクションと対応付けられていると見なされます。そのトランザクションはイベント・ブローカに渡されます。
サービスの呼び出しやサブスクライバに対してメッセージをキューに格納することなど、イベント・ブローカの処理も同じトランザクションの一部です。実行中のサービス・ルーチンがエラーを検出すると、そのルーチンはトランザクションを失敗させることができます。その場合、トランザクションに関与するほかのすべてのサブスクリプションおよびポストされた元のトランザクションなど、ほかのサービスを呼び出していたり、ほかのデータベース処理を行っていたすべての処理がロールバックされます。ポスト元は(「ポスト元」がこの処理を行うという)アサーションを出力し、データを提供し、そのデータをトランザクションとリンクさせます。
数多くの無名サブスクライバ、つまりポスト元が認識していないサブスクライバは、トランザクションに関与して呼び出されます。サブスクライバがその処理をポスト元の処理とリンクできなかった場合、トランザクション全体がロールバックされます。トランザクションに関与するすべてのサブスクライバは、その処理をポスト元の処理とリンクする必要があります。リンクしないと、すべての処理がロールバックされます。ポスト元がそのトランザクションでポストすることを許可していない場合、イベント・ブローカによって別のトランザクションが開始され、トランザクションに関与するすべてのサブスクリプションがそのトランザクションに集められます。これらのトランザクションのいずれかが失敗すると、トランザクションに関与するサブスクリプションの代わりに行われたすべての処理はロールバックされます。ただし、ポスト元のトランザクションはロールバックされません。このプロセスは、TPEVTRANフラグによって制御されます。
株式売買が、取引売買アプリケーションで完了しようとしています。取引トランザクションで、各種のサービスによって数多くのデータベース・レコードが更新されました。イベントがポストされると、取引が今行われようとしていることが通知されます。
このような取引の監査を記録するアプリケーションは、このイベントをサブスクライブしています。つまり、このアプリケーションでは、このようなイベントがポストされたら、指定されたキューに必ずレコードを格納するように要求しています。サービス・ルーチンは取引を実行できるかどうかを決定し、このようなイベントをサブスクライブしています。また、そのような取引が行われる場合は通知されます。
すべての処理が問題なく行われると、取引が完了し、監査が記録されます。
キューでエラーが発生し、監査が記録されなかった場合、株式取引全体がロールバックされます。同様に、サービス・ルーチンが失敗すると、トランザクションがロールバックされます。すべての処理が正常に行われると、取引が行われてトランザクションがコミットされます。
  
|