| Oracle Application Server Wireless開発者ガイド 10gリリース2（10.1.2） B15742-02 |
|
 戻る |
 次へ |
項ごとに様々なトピックを記載しています。各項の内容は、次のとおりです。
Oracle Sensor Edge Serverは、センサーや、その他のコマンドまたはレスポンスを示す装置をアプリケーションと統合する中間層コンポーネントです。
|
注意: Oracle Sensor Edge Serverの使用方法と管理方法の詳細は、『Oracle Application Server管理者ガイド』を参照してください。 |
Oracle Sensor Edge Serverは、（センサーからの）センサー・データとアプリケーションを統合します。センサーは、RFID、半導体レーザー、温度センサーなど、状態の一定の変化を測定するハードウェアまたはソフトウェアのエンド・ポイントです。
RFIDは、電子シリアル番号（ESN）またはメモリーが埋め込まれた小型のトランスポンダを使用して、1つ以上の周波数でIDを発信します。トランスポンダは、メモリー内に他の情報も保持でき、離れた場所からでも読取りや書込みが可能です。
次に、このテクノロジの理解に役立つ用語を示します。
タグ: チップ、1つ以上のアンテナおよび電源を含む単一のユニット。タグ自体が電源（電池、電気接続など）を備えている場合、そのタグをアクティブ・タグと呼びます。電源が電磁誘導（つまり、リモートで生成された電磁波を利用して電力を生成する光電効果を使用）の場合は、パッシブ・タグと呼びます。
チップ: タグには、エンベデッド・メモリーを搭載したシリコン・チップが使用されます。情報はチップ内に格納されます。チップはワイヤレス・プロトコルおよびエンベデッド・メモリーへのアクセス機能を実装しています。アクティブ・タグの場合は、単一のチップではなくボード全体を指します。
アンテナ: タグには、アンテナが1つ以上あります。通信リンクの反対側にあるリーダーも、アンテナを持っている必要があります。同時に複数のアンテナを使用するリーダーもあります。アンテナは、プロトコル、周波数およびアプリケーションにより、表面に貼られた薄く細長いメタルから、数メートルの長さのゲート型のポータル・アンテナまで様々です。
リーダー: タグからの読取りや書込みを行います。通常、リーダーにはシリアル・インタフェースがあり、ホスト・コンピュータとの通信に使用されます。このプロトコルで広く適用されている標準はありません。
デバイス: センサーベースのアーキテクチャのエンド・ポイントです。デバイスには、RFIDリーダー、ドライ接点、半導体レーザー、カルーセル、ロボット・ピッカーなどがあります。
Oracle Sensor Edge Server: すべてのリーダーとアプリケーションの間にある中間層です。すべてのリーダーとのインタフェースとして機能し、標準化されたデータをアプリケーション・サーバーに戻します。
この項では、Oracle Sensor Edge Serverアーキテクチャの特長について説明します。図13-1は、エンタープライズ・インストールに含まれるOracle Sensor Edge Serverアーキテクチャを示しています。
デバイス・グループは、管理者がデバイスを論理的なグループにまとめて効率的に管理する目的で使用します。Oracle Sensor Edge Serverでは、1つまたは複数のデバイス・グループを設定できます。各デバイス・グループには、それぞれの管理するデバイス・ドライバがあります。
フィルタ・ルールは、不要なイベントや低レベル・イベントを除去します。フィルタ・ルールは、着信データのソート処理に使用できます。このルールは、個々のデバイスまたはデバイス・グループに適用できます。
イベント・プロセッサは、イベント配信のための中央処理エンジンです。このプロセッサは、残りのコンポーネントである、ドライバ・マネージャや（起動時には）イベント・ディスパッチャをロードします。内部的には、イベント・プロセッサは構成を読み取り、ロードするイベント・ディスパッチャを決定します。このプロセスは起動時に開始されます。
ドライバ・マネージャは、デバイス・グループとデバイス・ドライバをロードし、そのライフ・サイクルを管理します。ドライバ・マネージャのインスタンスは、各Oracle Sensor Edge Serverに1つずつあります。デバイス・ドライバが構成情報を取り出せるように、ドライバ・マネージャは、アクセス可能なコンテキストをデバイス・ドライバに提供します。続いて、デバイス・グループをロードし、デバイス・ドライバにバインドします。ドライバ・マネージャは内部にスレッドを持ちませんが、サーバーが実行されている間は、イベント・プロセッサのインスタンスによってスレッドのインスタンスが保持されます。
イベント・プロセッサとドライバ・マネージャは、各Oracle Sensor Edge Serverに1つずつあります。ドライバ・マネージャは、複数のデバイス・グループをロードします。また、各デバイス・グループも、デバイス・ドライバをいくつでも持つことが可能です。ただし、各デバイス・ドライバが属することができるのは、1つのデバイス・グループのみです。
ディスパッチャは、アプリケーションとの双方向通信を可能にするプラグインです。Oracle Sensor Edge Serverの主な出力は、フィルタ処理されたデータ・イベントです。このデータ・イベントは、最小化および標準化された状態で提供されます。データ・イベントは、デフォルトでサポートされている次のいずれかの方法で配信できます。
Streams/AQ
JMS
Webサービス
HTTP Post
カスタム・イベント・ディスパッチャを作成すると、他の転送方法もサポート可能です。
|
注意: センサー・サービスの管理の詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。 |
Oracle Sensor Edge Serverでは、データをOracle Streamsに転送し、そのデータをアプリケーションとエージェントに配信できます。Streamsによるディスパッチは、データの転送方法として最も堅牢で柔軟性があります。ルールベースの処理およびエージェントベースのテクノロジを完全にサポートしているのは、このディスパッチ方法のみです。
この他のディスパッチ方法では、イベントの多くは一時的なものでエントリ・ポイントに直接送信されますが、Streamsディスパッチャでは、着信イベントがイベント・コンシューマのエントリ・ポイント（アプリケーション）に直接マッピングされない、はるかに複雑なモデルがサポートされています。
イベントはステージング・エリアに入れられるデータです。Oracle Sensor Edge Serverでは、各種コンシューマに対してデータの様々な集約方法が定義されています。イベントを解釈するのはOracle Sensor Edge Serverでもアプリケーションでもありません。この処理は、データベース内のセンサー・データ・ハブによって行われます。このレイヤーでは、通知の内容とタイミングを定義するルールベースの処理がサポートされています。
イベントのステージングが終了した後、データのアーカイブ、変換、および管理が、アプリケーションおよびOracle Sensor Edge Serverから独立して行われます。そのため、Oracle Sensor Edge Serverは、アプリケーションやセンサーに依存せず、目的ベース・モデルとビジネス・インテリジェンス・モデルに高品質で詳細な処理データを提供できます。
Streamsディスパッチャは、イベントをステージング・エリアに渡します。ステージング・エリアに入れられたデータは、様々な方法で処理できます。
ルール評価ジョブは、イベントをステージング・エリアから取得し、Oracle Sensor Edge Serverのルールセットに対して実行します。ルールセットの各ルールには、そのルールの条件が満たされた場合に実行されるアクションがあります。
定義されるアクションでは様々な処理を実行できます。たとえば、PL/SQLコールバックの呼出しや、別のアプリケーションで使用できるように他のキューへの伝播が可能です。
ルール評価前のRAWイベントを受信する必要のあるアプリケーションは、AQ通知、AQ伝播またはJMSを使用してステージング・エリアに直接接続できます。
要約すると、アプリケーションの起動方法は次のとおりです。
PL/SQLコールバック（ルールベース）
キューの伝播（ルールベース）
センサー・データ・ハブのマイニング
ステージング・エリアへの接続による未処理イベントの伝達
ディスパッチ方法としてStreams/AQが選択されている場合、クライアントはStreamsのステージング・エリアへの接続情報を提供する必要があります（この接続情報は、そのユーザー名が参照しているスキーマにあります）。Streams/AQの接続パラメータを、表13-1に示します。
表13-1 Streams/AQの接続パラメータ
| パラメータ | 形式 | 説明 |
|---|---|---|
|
url |
テキスト（URL） |
ステージング・エリアがあるデータベースへの接続文字列です。管理者は、イベントと測定値のアクセスとアーカイブに最も適したアプリケーション・データベースを指定する必要があります。 |
|
username |
テキスト |
指定されたデータベース接続への接続に使用する名前（このリリースではedgeである必要があります）。 |
|
password |
テキスト |
ユーザーのパスワード。 |
|
注意: Oracle Sensor Edge Serverは、エンタープライズ・モードおよびスタンドアロン（Java）モードで実行します。どちらのモードでも実行するアプリケーションを開発する場合は、すべてのパラメータ名が1語で構成され、それ以外の文字（アポストロフィや特殊文字など）が含まれていないことを確認してください。 |
EDG_EVENT ADT（Advanced Data Type）は、イベントを表すカスタム定義のデータ型です。イベントには、測定またはデバイスへの命令があります。次の表に、EDG_EVENT型の内部フィールドを示します。
表13-2 EDG_EVENT型のフィールド
| 列 | 型 |
|---|---|
|
TYPE |
NUMBER |
|
SUBTYPE |
NUMBER |
|
ID |
CLOB |
|
SITENAME |
VARCHAR2 |
|
DEVICENAME |
VARCHAR2 |
|
DATA |
CLOB |
|
TIME |
TIMESTAMP |
|
SOURCENAME |
VARCHAR2 |
|
CORRELATIONID |
VARCHAR2 |
これらのフィールドの使用方法の詳細は、表13-16「イベントの形式」を参照してください。
EDGEスキーマには、インストール時に次の2つの内部キューが設定されます。
EDG_EVENT_Q: 内部のADT AQ。ペイロードには、イベントADT型が使用されます。このキューへのアタッチおよびこのキューからのデキューは、ルール・ジョブを中断せずに実行できます。このテクニックは、Oracle Sensor Edge Serverからのすべてのイベントを読み取る場合に便利です。
EDG_INSTR_IN_Q: アプリケーションがイベント命令をOracle Sensor Edge Serverに送り返す際に使用します。これも、イベントADT型をベースにしたADT AQです。
ルールはいつでも定義できます。ルールは必要な数だけ追加できます。ルールセットの使用方法の詳細は、Oracle DBMSのマニュアルを参照してください。
ルールは、標準のdbm_ruleパッケージを使用してStreamsデータベースで定義します。Oracle Sensor Edge Serverで使用するルールセットの名前はEDG_RULESETです。それぞれのルールには、次の要素が含まれます。
名前: ルールの名前。この名前はルールセット内で一意のルール名であることが必要です（例: EDG_RULESET）。
条件: 評価式。結果がtrueの場合には、ルールが適用されます。式は、SQLのWHERE句です（ただしWHEREキーワードは使用しません）。edg_eventには、tab.user_dataでアクセスできます。
アクション・コンテキスト: ルールが有効になったときに実行するOracle Sensor Edge Serverの動作を定義します。Action_Contextは、ルールが有効になったときに実行する動作をOracle Sensor Edge Serverに指示します。
評価コンテキスト（オプション）: ルール・パッケージの上級ユーザー向けに用意されています。評価コンテキストを使用すると、開発者は他のスキーマの表に別名を付けることができます。必要なオブジェクトへのアクセス権があるPL/SQLコールアウトを使用してください。評価コンテキストを指定する場合、Edgeユーザーは、このオブジェクトに対する評価権限を持っている必要があります。コンテキストは、名前と値がペアになったリストです。含まれている名前は次のとおりです。
表13-3 Action_Contextのルール
| 名前 | 形式 | 説明 |
|---|---|---|
|
TYPE |
テキスト |
実行するコマンドを評価エンジンに指示する文字列。次のコマンドがサポートされています。call: PL/SQLコールバックを呼び出します。コールバックの名前は、paramフィールドで定義します。queue: 別のキューに伝播します。その他のキューの名前は、paramフィールドで定義します。 |
|
PARAM |
テキスト |
コマンドのパラメータ。形式は、使用するコマンドによって異なります。 |
次に、edg_utl.add_ruleプロシージャを使用してルールを追加する例を示します。
例13-1 ルールの追加（edg_utl.add_ruleプロシージャを使用）
begin
edg_utl.add_rule(
ruleName => 'my_callback',
condition => 'tab.user_data.type = 0 AND tab.user_data.subtype = 2',
param => 'my_schema.my_package.my_callback',
command => 'call');
end;
/
これによって、タイプが0でサブタイプが2（システムのエラー・メッセージ）のedg_eventを受信した場合に呼び出されるコールバックが登録されます。ルール・エンジンは、my_schemaスキーマのmy_packageというPL/SQLパッケージのmy_callbackというPL/SQLプロシージャを呼び出します。
次に、edg_utl.remove_ruleプロシージャを使用してルールを削除する例を示します。
例13-2 ルールの削除（edg_utl.remove_ruleプロシージャを使用）
begin
edg_utl.remove_rule(
ruleName => 'my_callback')
end;
/
これにより、my_callbackルールがルールセットから削除されます。
Streamsを使用することで、クライアント・アプリケーションは様々な方法でイベントを受信できます。次のアクション・タイプがサポートされています。
PL/SQL Callback: パラメータは、修飾されたスキーマ名を呼び出すPL/SQLプロシージャの名前です。
Queue Propagation: パラメータは、修飾されたスキーマ名の伝播先のキュー名です。
PL/SQLコールバックを使用してクライアントが呼び出される場合、PL/SQLにはパラメータが渡されます。このパラメータは、EDG_EVENTという名前のADT型で定義されています。
次に、コールバックの例を示します。
定義されたルールがキューの伝播を使用する場合、ルールが有効になると、対象となったイベントが、指定されたキューにコピーされます。コピー先は、このリリースでは、EDG_EVENT型を使用してADTキューとして定義する必要があります。これで、アプリケーションは、関連するデータをこのカスタム・キューから読み取ることができます。
|
注意: エッジ・スキーマの所有者には、使用しているキューに対するエンキュー権限が必要です。詳細は、使用するデータベースのマニュアルを参照してください。 |
デフォルトでは、次のルールがルールセットに追加されます。これらのルールはすべてオプションであり、このようなアーカイブが不要な場合には削除できます。これらのアーカイブを自動的に消去するシステム・ジョブはありません。必要な場合は、手動で削除する必要があります。
sdh_callback: すべての着信イベントを表SDH_EVENTSに挿入してアーカイブします。一部のイベントのみをアーカイブする場合は、このデフォルトのルールを削除してください。
sdh_perf_callback: パフォーマンスに関するすべてのイベントをSDH_FILTER_PERF表に挿入します。sdh_error_callback: エラー状況の報告に関連するすべてのイベントをSDH_DEVICEFAILURE表に挿入します。チェック・タグ・エラーに関するイベント（CheckTagフィルタを使用した場合）は、SDH_CHECKTAG_ERROR表に挿入されます。
センサー・データ・アーカイブは、Oracle Sensor Edge Serverに必要なセンサー関連のデータを保存している一連の表です。管理者は、エッジ・ルールセットのルールを変更または追加して、アーカイブするデータ型をカスタマイズできます。デフォルト・ルールを変更してアーカイブ条件をカスタマイズすることもできますが、デフォルト・ルールの変更はお薦めしません。このルールを変更すると、製品のサポートが非常に困難になる場合があります。
表には、sdh_events（表13-4）、sdh_checktag_error（表13-5）、sdh_devicefailure（表13-6）、sdh_filter_perf（表13-7）の4種類があります。
sdh_eventsには、収集されたすべてのイベントがアーカイブされています。形式は、create table sdh_eventsです。
sdh_checktag_errorには、チェック・タグ・フィルタのエラーが記載されます。形式は、create table sdh_checktag_errorです。
sdh_devicefailureには、デバイスのエラーが記載されます。形式は、create table sdh_devicefailureです。
sdh_filter_perfには、フィルタのパフォーマンスが表示されます。形式は、create table sdh_filter_perfです。
イベントに対応する際（または任意の時点で）、アプリケーションからデバイスに命令を送信する必要がある場合（たとえば、積層表示灯を点灯する場合）、アプリケーションは、edg_instr_q_inという名前のADTキューにイベントをポストします。
イベントやその他の状態を受信した際にアラートと命令を送り返す宛先をアプリケーションで把握できるように、イベント・ソースを宛先のリストにマッピングするための抽象化レイヤーが追加で用意されています。
宛先は、積層表示灯やメッセージ・ボードのように、物理的にイベントのソースに近い場合があります。また、電話などの他の（リモート）デバイスにアラートを送信することも可能です。このようなリモート通知を行うには、別途開発作業が必要です。
アプリケーションで、カスタム条件を一連の動作にマッピングすることもできます。
ルート・マップは、一定の条件を宛先のリストにマッピングするものです。条件は、次の要素で定義されます。
SITE_NAME
DEVICE_NAME
CONDITION_NAME
PRIORITY
SITE_NAME、DEVICE_NAME、カスタムのCONDITION_NAME、およびPRIORITYを指定することで、edg_utlのroute_map_fire_instructionプロシージャは、一定の条件に呼応して、事前定義済の命令を様々なデバイスに転送します。たとえば、あるデバイスによるセンサーの測定値によって、別の（ターゲット）デバイスのオンまたはオフが決定されます。命令をマッピング表に登録しプロシージャを呼び出すことで、一定の条件が満たされたときに命令を送信できます。関連する各宛先にはそれぞれに関連付けられた優先順位を設定でき、命令の順序を決定できます。ルート・マップから宛先が解決されると、SITE_NAME/DEVICE_NAME/CONDITION_NAMEの組合せに関連付けられている命令が、適切な宛先に一定の優先順位で送信されます。次に、このAPIの使用例を示します。
edg_utl PL/SQLパッケージには、センサー・データ・ハブへのアクセスに必要な一般的なタスクを簡素化するユーティリティ関数が含まれています。パッケージは、EDGEユーザー・スキーマの下に作成されています。次の表に、edg_utlパッケージで公開されているすべての関数を示します。
表13-9 edg_utlの関数
| 関数 | パラメータ | 説明 |
|---|---|---|
|
ADD_RULE |
RULENAME: ルールの名前 CONDITION: ルールの条件 EVAL_CTX: コンテキスト（通常はNULL） ACT_CTX: アクション・コンテキスト（通常はNULL） PARAM: アクションのパラメータ ACTION: アクション |
RULENAMEで指定する名前で新しいルールを作成します。EVAL_CTXとACT_CTXの詳細は、Streamsのマニュアルを参照してください。 ACTIONには、callまたはqueueを指定できます。 |
|
REMOVE_RULE |
RULENAME: ルールの名前 EVAL_CTX: 評価コンテキスト（通常はNULL） |
RULENAMEで定義された名前の作成済ルールを削除します。 |
|
CHECK_DISPATCH_JOB_EXIT |
なし |
自動評価ジョブが終了していれば、trueを返します。これは、エラー状態を表します。ジョブは、正常な状態で実行する必要があります。ほとんどの場合、この関数は内部的に使用されます。 |
|
SET_LOG_LEVEL |
LEVEL: 現在のログ・レベル |
現在のログ処理レベルはLEVELに設定してください。0に設定すると、ログ処理は行われません。 |
|
SENDTOEDGE |
TYPE: イベントのタイプ SUBTYPE: イベントのサブタイプ ID: 識別子のリスト SITENAME: 送信先のサイト名 DEVICENAME: データの送信先のデバイス名 DATA: イベントのデータ・ペイロード TIME: イベントが最初に生成された時刻 SOURCENAME: 送信元の名前 CORRELATIONID: 相関ID |
イベントをEdgeサーバーに送信します。この関数は、命令イベントをEdgeサーバーのデバイスに送信するために使用します。 |
|
SENDTOSTAGE |
TYPE: イベントのタイプ SUBTYPE: イベントのサブタイプ ID: 識別子のリスト SITENAME: ソースのサイト名 DEVICENAME: ソース・デバイス DATA: イベントのデータ・ペイロード TIME: イベントが最初に生成された時刻 SOURCENAME: 送信元の名前 CORRELATIONID: 相関ID |
Streamsのステージング・エリアにイベントを送信します。これは、Edgeサーバーとシミュレータを設定せずにルールをテストする場合に便利です。ステージング・エリアに送信されるすべてのイベントは、ルールセットによって評価されます。 |
|
CHECKDEVICE |
SITENAME: デバイスがあるサイトの名前 DEVICENAME: 確認するデバイスの名前 |
デバイスが稼働中かどうかを確認します。デバイスからは同じ相関IDのメッセージが返信され、そのデータ・ペイロードにUPまたはDOWNが示されます。 |
|
STARTDEVICE |
SITENAME: デバイスがあるサイトの名前 DEVICENAME: 起動するデバイス |
|
|
STOPDEVICE |
SITENAME: デバイスがあるサイトの名前 DEVICENAME: 停止するデバイス |
デバイスを停止します。 |
|
ROUTE_MAP_FIRE_INSTRUCTION |
DEVICENAME: デバイスの名前 SITENAME: デバイスがあるサイト COND: 検索する条件 MSG: 表示するメッセージ |
指定された条件が満たされていれば、一連の命令をデバイスに送信します。 |
たとえば、タイプが105、サブタイプが2のイベントをMyLightというデバイスに送信する場合は、次のようにします。
例13-5 イベントを送信するedg_utl
SQL> edg_utl.sendToEdge( 105, 2, 'MySite', 'MyLight', 'dummyData', CURRENT_TIMESTAMP, '', '' );
MyLightというデバイスを起動するには、次のようにします。
Java Message Service（JMS）は、J2EEコンポーネントで通信に使用する標準的なメッセージAPIです。Oracle Sensor Edge ServerにはJMSディスパッチャが用意されており、ユーザーはそのディスパッチャを使用してイベントをJMSトピックに中継できます。
イベントのポスト先のキューにJMSディスパッチャを接続するには、管理者は、次の表に示す構成パラメータを指定する必要があります。
表13-10 JMSのパラメータ
| パラメータ | 形式 | 説明 |
|---|---|---|
|
provider |
テキスト（URI） |
トピックが格納されているOC4Jインスタンスへの接続に使用するURIです。このURIは、サーバーに接続するために、oc4j ormiによって内部で使用されます。たとえば、ormi://oc4j.us.oracle.comと入力します。 |
|
password |
テキスト |
OC4Jインスタンスを使用するためのパスワード。 |
|
username |
テキスト |
OC4Jインスタンスを使用するためのユーザー名。 |
|
ack |
テキスト |
値をautoまたはclientに設定します（オプション）。デフォルトはautoです。 |
|
enterprise_mode |
テキスト |
エンタープライズの一部として動作しているか、スタンドアロンとして動作しているかを（JMSパラメータに）示します。デフォルトはfalseです。 |
|
注意: Oracle Sensor Edge Serverは、エンタープライズ・モードおよびスタンドアロン（Java）モードで実行します。どちらのモードでも実行するアプリケーションを開発する場合は、すべてのパラメータ名が1語で構成され、それ以外の文字（アポストロフィや特殊文字など）が含まれていないことを確認してください。 |
JMSキューを設定するには、管理者はedgeTopicというJMSトピックを構成し、Oracle Sensor Edge Serverコンポーネントからアクセス可能にする必要があります。また、JMS TopicConnectionFactoryの構成も必要です（名前はedgeEventsConnectionFactoryです）。oc4jコンテナの下にあるjms.xmlファイルを構成することで実行できます。JMSキューの構成方法の詳細は、OC4Jのマニュアルを参照してください。
JMSディスパッチャは、（起動時に）コンテナのJNDIを使用してedgeTopicというJMSトピックを検索します。このリソースが検出されない場合、ディスパッチャはエラーを返して終了します。
JMSディスパッチャは、新しいイベントをOC4J JMSキュー・トピックにポストします。
JMSリスナーは、JMSサーバー内のこれらのキューにサブスクライブできます。イベントを受信すると、イベントのフィールドがメッセージ・プロパティで指定されます。これらのプロパティのキーは、javaクラスoracle.edge.rt.RTConstantsで定義されます。エンタープライズ・バージョンの場合、このクラスはORACLE_HOME/wireless/lib/wireless.jarにあります。スタンドアロン・バージョンの場合、このクラスはORACLE_HOME/j2ee/home/applications/edge/edge-web/WEB-INF/lib/edge.jarにあります。
表13-11に、これらのメッセージ・プロパティのキーとタイプを示します。
表13-11 メッセージ・プロパティのキー
| キー | 型 |
|---|---|
|
RTConstants.DISPATCH_PROPERTY_TYPE |
文字列 |
|
RTConstants.DISPATCH_PROPERTY_SUBTYPE |
文字列 |
|
RTConstants.DISPATCH_PROPERTY_ID |
文字列 |
|
RTConstants.DISPATCH_PROPERTY_SITENAME |
文字列 |
|
RTConstants.DISPATCH_PROPERTY_DEVICENAME |
文字列 |
|
RTConstants.DISPATCH_PROPERTY_DATA |
文字列 |
|
RTConstants.DISPATCH_PROPERTY_TIME |
long（ミリ秒） |
|
RTConstants.DISPATCH_PROPERTY_SOURCENAME |
文字列 |
|
RTConstants.DISPATCH_PROPERTY_CORRELATIONID |
文字列 |
Oracle Sensor Edge Serverでは、Webサービス（具体的にはSOAPコール）を使用してイベントを配信することもできます。
クライアントは、新しいメッセージの配信が必要なときに、サーバーから起動可能なSOAPコールを登録できます。クライアントは、次のパラメータを指定する必要があります。
WebService EndPoint URL: このURLは、Webサービスのエンド・ポイントを示します。
ディスパッチ方法としてWebサービスを選択した場合、クライアントは、イベントを受け取ったときにWebサービスをどのように呼び出すかをOracle Sensor Edge Serverに指示する必要があります。次の表に示すパラメータは必須パラメータです。このパラメータは、構成フレームワークの下に保存されます。
表13-12 Webサービスのパラメータ
| パラメータ | 形式 | 説明 |
|---|---|---|
|
url |
テキスト（URL） |
クライアント・コールが記述されたWSDLファイルを指すURL。WSDLファイルには、PortタイプのEdgeClientCallbackが含まれ、その中にはcall processEventが含まれている必要があります。 |
|
注意: Oracle Sensor Edge Serverは、エンタープライズ・モードおよびスタンドアロン（Java）モードで実行します。どちらのモードでも実行するアプリケーションを開発する場合は、すべてのパラメータ名が1語で構成され、それ以外の文字（アポストロフィや特殊文字など）が含まれていないことを確認してください。 |
イベントを受信すると、Webサービス・ディスパッチャは、WebサービスのprocessEventメソッドを呼び出します（このURLは、URLパラメータで指定されます）。このWebサービスのシグネチャは、次のとおりです。
public void processEvent( long type, long subtype, String tagid, String siteName, String deviceName, String data, Date time )
表13-13 コールバック・インタフェースのパラメータ
| 要素（パラメータ名） | 形式 | 説明 |
|---|---|---|
|
sitename |
テキスト |
このタグを読み取るサイトの名前。 |
|
devicename |
テキスト |
このタグを読み取るデバイスの名前。 |
|
time |
Time |
測定が行われた日時。 |
|
type |
Long |
イベントのタイプ。詳細は、表13-16「イベントの形式」を参照してください。 |
|
subtype |
Long |
値は、使用するカスタムのドライバおよびフィルタによって異なります。 |
|
data |
テキスト |
タグから読み取るオプションのデータ（base64形式）。 |
HTTPクライアント・インタフェースを選択した場合、サーバーは、標準のHTTP 1.0プロトコルを使用してクライアントと通信します。
クライアントは、Oracle Sensor Edge Serverのポスト先のURLを指定する必要があります。Oracle Sensor Edge Serverは、イベントを受信すると、指定されたURLに対してHTTP Postコマンドを実行します。データは、Postデータ形式で提供されます。ポストはイベントごとに別々に行われます。すべてのポストは順番に実行されるため、あるポストがブロックされると、他のポスト処理も実行されません。
ディスパッチ方法としてHTTPを選択した場合、クライアントは、イベントを受信した際にデータをどこにポストするかをOracle Sensor Edge Serverに指示する必要があります。次のパラメータは必須パラメータです。このパラメータは、構成フレームワークの下に保存されます。
表13-14 HTTPインタフェースのパラメータ
| パラメータ | 形式 | 説明 |
|---|---|---|
|
url |
テキスト（URL） |
クライアント・アプリケーションを指すURL。ディスパッチする新しいイベントがあるたびに、Oracle Sensor Edge ServerはこのURLにポストします。 |
|
注意: Oracle Sensor Edge Serverは、エンタープライズ・モードおよびスタンドアロン（Java）モードで実行します。どちらのモードでも実行するアプリケーションを開発する場合は、すべてのパラメータ名が1語で構成され、それ以外の文字（アポストロフィや特殊文字など）が含まれていないことを確認してください。 |
ディスパッチ方法としてHTTPを選択すると、Sensor Edge Serverは、パラメータで指定されたURLを呼び出します。そのときに使用されるポストのパラメータは次のとおりです。
表13-15 コールバック・インタフェースのパラメータ
| 要素（パラメータ名） | 形式 | 説明 |
|---|---|---|
|
siteName |
テキスト |
このタグが最初に読み取られたサイトのID。 |
|
deviceName |
テキスト |
このタグが最初に読み取られたデバイスのID。 |
|
time |
テキスト（英数字） |
タグが読み取られたときのタイムスタンプを返します。この値は、現在の時刻と1970年1月1日との差（ミリ秒単位）です。 |
|
type |
テキスト（数字） |
イベントのタイプを定義するテキスト（数字）。 |
|
subType |
テキスト（数字） |
イベントのサブタイプを定義するテキスト（数字）。 |
|
id |
テキスト（16進数） |
読み取られたタグの識別子（16進数）。 |
|
data |
テキスト |
タグIDとともに読み取られるオプションのデータ。 |
Oracle Sensor Edge Serverでは、実行時にカスタム・ディスパッチャをロードできます。このディスパッチャの構成はxmlファイルで指定し、Oracle Sensor Edge Serverにロードする必要があります。ディスパッチャには、イベントを送信し、命令などのコマンドを受信できる機能を実装する必要があります。ディスパッチャを実装するには、『Oracle Application Server管理者ガイド』を参照してください。
センサー・データ・ハブ（SDH）とは、デフォルトでサポートされている標準のビューおよびデータ・オブジェクトのコレクションです。この構造体は、ほとんどのアプリケーションが利用する一般的な機能を提供しており、アプリケーションの開発期間を短縮します。
前述のすべてのクライアント・インタフェースでは、これから述べるイベント・クラスまたはイベント・タイプが使用されます。この項では、イベント・タイプのフィールドの形式と詳細な使用方法を説明します。
イベント・タイプは、あるコンポーネントから別のコンポーネントに送信されるメッセージを表します。イベントの形式は固定されていますが、イベントのタイプに応じて既存フィールドを異なる意味にマッピングすることで拡張できます。
次の表に、イベントの一般的な形式を示します。
表13-16 イベントの形式
| セクション | フィールド | 形式 | 説明 |
|---|---|---|---|
|
ルーティング・ヘッダー |
sourceName |
テキスト |
イベントの作成元を示します（オプション）。 |
|
|
correlationId |
テキスト |
命令にレスポンスを関係付けます（オプション。クライアントで生成されます）。 |
|
メッセージ・ヘッダー |
siteName |
テキスト |
メッセージが生成されたサイト。 |
|
|
deviceName |
テキスト |
メッセージが生成されたデバイス（またはアプリケーション）。 |
|
|
time |
Time |
測定またはメッセージが作成された日時。 |
|
タイプ情報 |
type |
Long |
イベントのタイプ。 |
|
|
subtype |
Long |
イベントのサブタイプ。 |
|
ペイロード |
id |
テキスト |
命令の読取り識別子または命令のターゲットの識別子。 |
|
|
data |
テキスト |
オプションのデータ。 |
イベントは、次のセクションで構成されます。
ヘッダー: 配信情報のみが含まれます。ヘッダー・セクションには、次のフィールドがあります。
correlationId: クライアントによって設定されます。特定のクライアントへのメッセージ・レスポンスに使用されます。この値が設定されるかどうかは、クライアントに依存します。クライアントへのレスポンスで返信するメッセージがある場合は、同じIDが使用されます。sourceName: ルーティングを効率よく行うために、通常はクライアントの名前が設定されます。このIDにより、ディスパッチ方法でクライアント名を使用してルーティングするかどうかが決定されます。この値が設定されるかどうかは、クライアントに依存します。
タイプ情報: このイベントのペイロード・セクションの形式を示す情報です。イベントのタイプ情報のtypeフィールドは、送受信するメッセージのタイプを定義します。typeフィールドの値は、メッセージのタイプに応じて次の範囲で割り当てられます。
0-99: システム・メッセージ
100-199: 命令/コマンド
200-299: 測定値
他のタイプも定義できますが、現在使用可能なタイプは次のとおりです。
0: 不明 - イベントのタイプが0に設定されている場合は、不正なイベントまたはシステム内部イベントです。無視してください。
1: メッセージ・イベント - 確認メッセージです。通常は対応するリクエストされた命令のリターン結果コードです。
100: 一般的な命令 - デバイスを制御するための一般的な命令。
101: RFID命令 - RFIDデバイスへの命令。
200: RFID測定値 - メッセージはRFIDの測定値。
201: RTLS。
202: 物理的接触 - 半導体レーザー、ドライ接点など。
203: 気温。
204: 湿度。
205: 重量。
206: 不正変更。
207: オーディオ。
208: メッセージ・ボード。
イベント・ペイロード: 特定のデータ形式を持つイベント固有のセクション（形式は、イベントまたは命令のタイプにより異なります）。
102: プリンタへの命令
103: 積層表示灯への命令
システム・イベントは、システムが各種レイヤーに報告するメッセージです。メッセージには、情報、警告、エラーがあります。これらのイベントのトラップやイベントに対するルールの書込みを行うことで、アプリケーションによる、より効率的なエラーのリカバリやエラー処理の報告および実現が可能になります。
メッセージ・イベントは、状態、エラー状況、または確認を報告するために送信するイベントです。次の表に、このイベント・データ型のフィールドの使用方法を示します。
通常、命令イベントは、特定のデバイスに処理の実行を指示するためにアプリケーションによって送信されます。
一般的な命令イベント: 次の表に、一般的な命令イベント・データ型のフィールドの使用方法を示します。
表13-18 一般的な命令イベント・データ型
| フィールド | 説明 |
|---|---|
|
type |
100に設定 |
|
subtype |
コード: 0: ステータスの取得 1: オン 2: オフ |
|
id |
デバイスの二次番号または名前 |
|
data |
デバイス固有のパラメータ |
RFID命令イベント: RFID命令イベントは、ラベルの印刷を指示するためにアプリケーションによって送信されます。次の表に、RFID命令イベント・データ型のフィールドの使用方法を示します。
表13-19 RFID命令イベント・データ型
| フィールド | 説明 |
|---|---|
|
type |
101に設定 |
|
subtype |
コード: 0: タグへの書き込み 1: タグの破棄 2: 電界強度の取得 3: タグのペイロードの読取り |
|
id |
タグID |
|
data |
デバイス固有のパラメータ |
印刷命令イベント: ラベルの印刷をシステムに指示するためにアプリケーションによって送信されます。次の表に、印刷命令イベント・データ型のフィールドの使用方法を示します。
表13-20 印刷命令イベント・データ型
| フィールド | 説明 |
|---|---|
|
type |
102に設定 |
|
subtype |
0: テンプレートによる印刷 1: 直接印刷 |
|
id |
テンプレート名 |
|
data |
XMLファイルまたは印刷データ・ファイル |
印刷データは、印刷されるすべてのフィールドを含むXMLファイルか、実際の印刷のRAWデータ・ファイルです（subtypeコードによります）。XMLデータ・ファイルでは、名前/値ペアのリストが指定されます。このフィールドは、ラベル・タイプとEDG_PRINTCAP表のメタ・データに基づいて、実際のプリンタ記述子フィールドにマッピングされます。
EDG_PRINTCAP表の形式は、次のとおりです。
積層表示灯命令: 積層表示灯命令は、システムで積層表示灯に関係する処理を実行するよう指示するためにアプリケーションによって送信されます。表13-22に、このイベント・データ型のフィールドの使用方法を示します。
測定イベントは、タグの付いたアイテムの存在（またはステージの変化）をセンサーが確認したときにセンサーによって生成されます。
RFID測定イベント: RFIDリーダーが新しいタグを読み取ったときに送信されます（すべてのフィルタを通過したと仮定）。次の表に、このイベント・データ型のフィールドの使用方法を示します。
表13-23 RFID測定イベントのイベント・データ型
| フィールド | 説明 |
|---|---|
|
subtype |
コード: 0: 不明または不正なメッセージ 1: In Fieldイベント 2: Out Fieldイベント 3: Pass Thruイベント 4: Pallet In Fieldイベント 5: Pallet Out Fieldイベント 6: Pallet Pass Thruイベント 7: Containerイベント |
|
id |
読み取られたタグのRFIDタグID（16進数）です。複数のIDがカンマで区切られて列挙されていることもあります。 |
|
data |
タグに追加ペイロード（追加メモリー）がある場合は、ここに格納されます。 |
このチュートリアルでは、独自のカスタム・アプリケーションの構築方法を示します。Oracle Sensor Edge Serverの他のチュートリアルは、Oracle Technology Networkに公開されています。
このチュートリアルでは、Oracle Database StreamsテクノロジとOracle Sensor Edge Serverを使用して、アプリケーションとルールベースのエージェントを構築する方法について説明します。
開始する前に、Oracle Sensor Edge ServerとOracle Streamsがどのように連携して動作するかについて説明します。
Oracle Streamsにより、1つまたは複数のデータベースにおけるデータ・ストリーム内のデータ、トランザクションおよびイベントの伝播や管理が可能になります。また、Streamsデータベース内の大量のデータの管理と変換も可能になります。センサーのデータは、Streamsで管理可能なデータ・ソースです。
Streamsには、次の3つの段階があります。
取得: 様々なソースからデータを取得し、データ処理ができるようにステージング・エリアにアップロードします。ステージング・エリアは、アドバンスト・キューまたは単純な表です。
ステージング: データとイベントの取得が完了すると、イベントはステージング・エリアに置かれます。これがステージング段階です。サブスクライバは、ステージング・エリアの内容を確認してから、イベントをどのように処理するか決定します。
消費: イベントとデータがデータベースに適用されます。独自のカスタムStreamsを構築して、データを処理できます。
Oracle Sensor Edge Serverでは、Streamsを配信方法として使用できます。Streamsは柔軟性が高く堅牢で機能も豊富なため、Streamsの使用をお薦めします。
デバイスで読み取られたイベントは、ドライバによって標準化され、フィルタ処理を実行するために送り出されます。データのクレンジングとフィルタリングが終了すると、データはディスパッチャに渡され配信されます。
Streamsとアプリケーションは直接的には通信しません。Streamsは、Streamsディスパッチャを使用してイベントをStreamsのステージング・エリアに渡します（次の図を参照）。
イベントをステージング・エリア（内部キュー）に配置すると、Oracle Sensor Edge Serverのジョブは終了です。その後の処理は、データベースによって行われます。
Oracle Sensor Edge ServerからStreamsのサポート用にインストール後のスクリプトをインストールした場合は、次に説明する機能が追加されます。
ステージング・エリアに配置されたイベントは、バックグラウンド・ジョブによって取り出され、一連のルールに対して評価されます。ルールとは、イベントが一致するか一致しないかのどちらかである条件です。イベントが条件に一致すると、アクションが実行されます。このアクションは、条件と同様に、ユーザーが定義します。
ステージングされたイベントは、システムのルールに対して評価されます。ルールに一致したイベントがある場合には、そのルールに関連付けられたアクションが実行されます。ルールは、次の内容で構成されます。
名前
条件
コマンド
パラメータ
名前は、ルールを作成した呼出し元によって指定された一意のルール名です。作成したルール名は、検索、変更または削除できます。
条件は、WHERE句に似ていますが、WHEREキーワードは使用しません。たとえば、タグIDが159で始まるすべてのタグを一致させる場合は、条件tab.user_data.tagid LIKE '159%'を使用します。接頭辞tab.user_dataは、現在のイベントをコンテキストとして使用することを示します。
条件が満たされた場合は、関連付けられたアクションが実行されます。アクションは、さらに次の内容で構成されます。
コマンド
パラメータ
コマンドには、PL/SQLプロシージャを呼び出すcall、またはイベントを別のキューに入れるqueueなどがあります。
パラメータは、コマンドのパラメータです。callはPL/SQLの名前で、queueはキューの名前です。
まず、インタフェース・モデルを次の中から選択します。
PL/SQL Callback: イベントを受信するたび、または目的の条件に一致するたびに呼び出されるPL/SQLプロシージャを記述する場合は、このモデルを選択します。
Queue Propagation: Oracle Sensor Edge Serverでは、異なる条件に基づいて様々なキューにイベントが伝播され、アプリケーションがそれらのキューを処理します。
Querying the Sensor Data Archive: 従来のプルベースおよび問合せベースのアプリケーションでは、イベントおよびデータをセンサー・データ・アーカイブに問い合せることができます。
アプリケーションが非同期またはイベント・ドリブンの場合（特定の条件に限って対応する、またはイベントを受信した際に対応する場合）は、「Queue Propagation」と「PL/SQL Callback」のどちらかを選択する必要があります。
アプリケーションがPL/SQLベースで、長い処理時間を必要としない場合は、単純でデバッグしやすい「PL/SQL Callback」を使用します。
処理に時間がかかり、データ率を維持できるかどうかが懸念される場合は、「Queue Propagation」を使用します。
Javaでアプリケーションを作成する場合は、「Queue Propagation」を使用し、JMSを直接使用してイベントを処理するか、コンポーネントをMDBとして構築します。詳細は、Oracle Technology NetworkにあるJMSのチュートリアルを参照してください。
使用するモデルの選択は簡単です。アプリケーションがユーザー・インタフェースベースまたはバッチ処理ベースの場合には、プル・モデルが必要です。
このチュートリアルではこれらのモデルを1つずつ使用するので、それぞれのメリットとデメリットを確認できます。ただし、どのモデルを選択する場合にも、インストール後の基本設定を実行する必要があります。
Streamsディスパッチャを使用する前に、データベース・インスタンスを設定して、Streamsのステージング・エリア、ルール、キュー、センサー・データ・アーカイブ、およびその他の関連データを設定しておく必要があります。スキーマの準備が完了した後、Oracle Sensor Edge Serverのディスパッチャにスキーマを指定して、データの収集を開始できます。
データベースのインスタンスを設定します。Standard EditionまたはEnterprise Editionのデータベースを使用できますが、リリースは9.0.2以降である必要があります。インスタンスを作成した後、GDN（Global Data Name）および管理者のユーザー名とパスワードを記録してください。
|
注意: Streamsディスパッチャが指定するデータベースでは、Oracle Database 9iリリース2以降が実行されている必要があります。これは、Streamsディスパッチャが、Oracle Database 9iリリース2で導入されたデータベースのStreamsパッケージに依存しているためです。 |
データベース・インスタンスがOracle Sensor Edge Serverとは別のマシンにある場合は、Oracle Sensor Edge ServerマシンのORACLE_HOME/network/admin/tnsnames.oraを編集して、GDNを追加する必要があります。
データベース・インスタンスの設定が終了した後、Streamsディスパッチャで使用するスキーマを設定する必要があります。この処理を行うには、コマンドラインから次の手順を実行してください（ここに示すスクリプトは、すべて¥wireless¥repository¥sqlディレクトリにあります）。
ORACLE¥HOME¥wireless¥repository¥sqlに移動します。
SQL*Plusを起動し、そこから管理者（ユーザーdba）としてデータベース・インスタンスに接続します。
create_edg_user.sqlを実行して、必要なユーザー権限を作成します。このスクリプトでは、ユーザーEDGEのパスワードを入力するよう求められます。必要なパスワードを入力し、参照用にそのパスワードを控えておきます。
SQL*Plusからログアウトします。
今度はユーザーEDGEとして、SQL*Plusに再度ログインします。たとえば、ユーザーのGDN名がSDHの場合には、sqlplus edge@sdhを実行します。
スクリプトedg_create_streams.sqlを実行して、内部キュー、ルールセット、およびStreamsに関連するその他のデータとスキーマを作成します。
スクリプトedg_create_sdh.sqlを実行して、センサー・データ・ハブのスキーマを作成します。センサー・データ・ハブが不要な場合は、この手順をスキップします。
スクリプトを実行すると、データベース内にEDGEというユーザーが作成されます。必要なすべてのスキーマおよびデータは、このユーザーで作成します。バックグラウンド・ジョブも自動的に起動されます。たとえば、データベースの名前がmydbで、Sensor Edge ServerがC:/oracle/edgeにインストールされ、管理者パスワードがmanagerの場合には、次のコマンドを実行してデータベースを設定できます。
例13-7 データベースの設定に使用するコマンド
C:/> cd /oracle/edge C:/oracle/edge> sqlplus system/manager@mydb @create_edg_usr.sql SQL> password: edge <-- Enter your password, here we will use "edge" SQL> exit C:/oracle/edge> sqlplus edge/edge@mydb SQL> @edg_create_streams.sql .... SQL> @edg_create_sdh.sql .... SQL> exit C:/oracle/edge>
この処理が終了すると、スキーマを確認できます。select * from sdh_eventsを実行して確認してください。
これでデータベースの準備は完了し、センサーの測定値をデータベースに送信する処理を開始できます。
|
注意: Streamsディスパッチャへの切替え方法または設定方法の詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。 |
Streamsディスパッチャを構成するには、次のようにします。
Webブラウザで、Wireless Webtoolにある「センサー・サービス」タブに接続します。
「Edgeディスパッチャを管理」をクリックします。
ドロップダウン・リストから「StreamDispatcher」を選択します。
パスワード・パラメータでEDGEユーザーのパスワードを変更します。
使用するデータベース・インスタンスを指定するように、パラメータurlを変更します。
「OK」をクリックします。
Sensor Edge Serverを再起動します。Sensor Edge Serverがシミュレータまたは実際のデバイスに接続されている場合は、データベースへのイベントが表示されます。
ディスパッチャが正しく接続されていることを確認するには、wireless¥logs¥log.xmlの内容を確認します。次のような行が表示されます。
Tue Sep 14 19:06:15 PDT 2004: StreamsDispatcher: Attempting to create Q connectionsTue Sep 14 19:06:15 PDT 2004: StreamsDispatcher: Creating topic connectionTue Sep 14 19:06:21 PDT 2004: StreamsDispatcher: Creating topic sessionTue Sep 14 19:06:22 PDT 2004: StreamsDispatcher: Creating topic publisherTue Sep 14 19:06:22 PDT 2004: StreamsDispatcher: Creating topic subscriberTue Sep 14 19:06:26 PDT 2004: StreamsDispatcher: Finished initialization
初期化に失敗した場合は、接続文字列またはパスワードが正しくないか、データベースが正しく組み込まれていません。
着信イベントをテストするには、SQL*PlusからEDGEユーザーとしてログインし、SELECT * FROM SDH_EVENTSを実行します。測定イベントは、すべてここにアーカイブされます。ここでは、イベントの増加を確認できます。増加しない場合は、シミュレータを実行し、イベントが送信されていることを確認してください。
これでOracle Sensor Edge Serverの準備が終了し、コーディングを開始できます。
インスタンスにルールを追加するには、次の手順を実行します。
ユーザーEDGEとしてデータベースに接続します（たとえば、sqlplus edge/edge@mydb）。
次のPL/SQLプロシージャを実行します: call edg_utl.add_rule( 'RuleName', 'Condition', NULL, NULL, 'Parameter', 'Command' );
ここで、
RuleNameはルールの一意の名前、Conditionはルールの条件、Parameterはルールのパラメータ、Commandは条件が満たされている場合に起動するコマンドです。
ルールは、Sensor Edge Serverの実行中でもテストできます。
ルールをテストするには、次のようにします。
ユーザーEDGEとしてデータベースに接続します（たとえば、sqlplus edge/edge@sdh）。
ユーティリティ関数を次のようにして呼び出します: call edg_utl.sendToStage( type, subtype, id, siteName, deviceName, data, time, sourceName, correlId );
いずれかのルールにイベントが一致すると、コールバックが呼び出されるか、イベントがキューに伝播されます（どちらの処理が実行されるかは、使用したコマンドにより異なります）。
実行エラーを確認するには、select message from edg_log order by msg_time;を実行します。
ユーティリティ関数edg_util.sendToStage()はイベントをステージング・エリアに直接送信します。イベントは、ルールによって評価されます。
EDG_LOG表には、実行中に発生したエラーがすべて保存されます。
ルールのアクションは、条件句が満たされると実行されます。
条件は、基本的にSQL文のWHERE句ですが、若干の違いがあります。評価するイベントは、コンテキストtab.user_dataで定義します（詳細は、DBMS Streamsのマニュアルのこの構造体に関する項目を参照してください）。イベントのフィールドを確認するには、desc edg_eventを実行します。これにより、EDG_EVENT ADT型の定義が表示されます。たとえば、タイプの値が203で、IDがepc:で始まるすべてのイベントを検索する場合は、次の条件を使用します。
tab.user_data.type.type = 203 AND tab.user_data.id LIKE 'epc:%'
より複雑なルール（他の参照表との結合など）の場合は、PL/SQL関数の作成や、Streamsコンテキストの使用が可能です（詳細は、DBMS Streamsのマニュアルを参照してください）。
条件を定義した後、その条件が満たされた場合にOracle Sensor Edge Serverで実行する動作を指定する必要があります。これは、コマンド・フィールドとパラメータ・フィールドで指定します。
このリリースでは、2種類のコマンドがサポートされています。
callは、PL/SQLコールバックを呼び出します。
queueは、イベントを他のキューに伝播します。
コマンドがcallの場合は、パラメータ・フィールドを次のように設定する必要があります。
'schema.package.procedure'
たとえば、スキーマedgeのパッケージmy_pkg内にtestprocという名前のプロシージャが定義されている場合、パラメータは次のようになります。
edge.my_pkg.testproc
コマンドがqueueの場合は、伝播先のキューの名前をパラメータに設定します。このキューはEDG_EVENT ADT型をベースに作成されている必要があります（今後のリリースでは、他のキュー・フォーマットへのマーシャリングもサポートされる予定です）。
インスタンスを消去し、再初期化して最初からやり直すには、Oracle Sensor Edge ServerからEDGEユーザーを削除します。なお、EDGEユーザーに組み込まれたデータとPL/SQLもすべて消去されるため、必要なデータがある場合は、バックアップしてから次の手順を実行してください。
ログインします（たとえば、sqlplus edge/edge@sdh）。
exec edg_utl.deschedule_jobを実行します。
ログアウトします。
管理者としてデータベースに接続します（たとえば、sqlplus edge/edge@sdh）。
SQLコマンドdrop user edge cascade;を実行してユーザーを削除します。
SQL*Plusを終了します。
これらの手順が完了した後で、インスタンスを再初期化できます。
このチュートリアルでは、アプリケーションのAQにイベントを伝播するルールの定義方法を示します。Oracle Sensor Edge Serverの他のチュートリアルは、Oracle Technology Networkに公開されています。
|
注意: イベント（シミュレートされたイベントも含む）に表示されるSiteNameは、Enterprise Managerを使用して設定されたSiteNameです。セキュリティ上の理由から、サイト名は、Enterprise ManagerのSiteNameで常に上書きされます。他の名前は無視されます。 |
このチュートリアルでは、アプリケーションのAQにイベントを伝播するルールの定義方法について説明します。このチュートリアルは、設定用のチュートリアルを終了してから実行してください。
このサンプル・プロジェクトを使用するには、次のコンポーネントが必要です。
J2SE 1.4.x（Sun社のWebサイトhttp://www.javasoft.comからダウンロード可能）
Oracle Sensor Edge Server
Oracle Database 9.2以降
使用する開発モデルを決定します。Streamsディスパッチャを使用する場合は、次のオプションがあります。
PL/SQL Callback: イベントを受信するたび、または目的の条件に一致するたびに呼び出されるPL/SQLプロシージャを記述する場合は、このモデルを選択します。
Queues Propagation: Sensor Edge Serverでは、異なる条件に基づいて様々なキューにイベントが伝播され、アプリケーションがそれらのキューを処理します。
Querying the Sensor Data Archive: 従来のプルベースおよび問合せベースのアプリケーションでは、イベントおよびデータをセンサー・データ・アーカイブに問い合せることができます。
このチュートリアルでは、様々なキューに伝播するルールの定義方法を示します。
まず、イベントを受け取るキューを作成する必要があります。次のコードでは、my_qというキューが作成されます。データベースに（ユーザーEDGEとして）接続してから実行してください。
EXECUTE DBMS_AQADM.CREATE_QUEUE_TABLE( queue_table => 'my_q_table', queue_payload_type => 'EDG_EVENT' ); EXECUTE DBMS_AQADM.CREATE_QUEUE(
queue_name => 'my_q', queue_table => 'my_q_table' ); EXECUTE DBMS_AQADM.START_QUEUE( queue_name =>'my_q' );
これで、キューの作成が完了し、そのキューを伝播先としたルールを設定できます。
IDがepcで始まるすべてのイベントを取り出すルールを作成するには、次の手順に従います。
データベースに接続します（たとえば、sqlplus edge/edge@sdh）。
次のコマンドを実行します: call edg_utl.add_rule( 'MyTestRule3', 'tab.user_data.id LIKE ''epc:%'' ', NULL, NULL, 'my_q', 'queue' );
これでルールの設定が完了し、テストを実行できます。
シミュレートしたイベントをシミュレータから送信します。Sensor Edge Serverを使用せずにイベントを送信することも可能です。
SQL*Plusを使用してデータベースに接続します。
次のコマンドを実行します: call edg_utl.sendToStage( 1, 1, 'epc:12345', 'MySite', 'MyDevice', 'data', sysdate, 'src', 'cor' );
このプロシージャは、IDがepc:12345のダミー・イベントを生成し送信します。正しく動作したことを確認するには、センサー・データ・アーカイブを参照します。このイベントを確認できます（SELECT id FROM SDH_EVENTS;）。
キュー表からSELECTを実行するかキュー表からデキューすると、着信するイベントを確認できます。
このチュートリアルでは、測定値への対応、またはEdgeデバイスへのイベントを作成するアプリケーションをデータベース内に作成する方法を示します。Oracle Sensor Edge Serverの他のチュートリアルは、Oracle Technology Networkに公開されています。
このチュートリアルでは、測定値への対応、またはEdgeデバイスへのイベントの作成を行うアプリケーションをデータベース内に作成する方法を示します。このチュートリアルは、Streamsの設定用のチュートリアルを終了してから実行してください。
このサンプル・プロジェクトを使用するには、次のコンポーネントが必要です。
J2SE 1.4.x（J2DKは、Sun社のWebサイトhttp://www.javasoft.comからダウンロード可能）
Oracle Sensor Edge Server
Oracle Database 9.2以降
使用する開発モデルを決定します。Streamsディスパッチャを使用する場合は、次のオプションがあります。
PL/SQL Callback: イベントを受信するたび、または目的の条件に一致するたびに呼び出されるPL/SQLプロシージャを記述する場合は、このモデルを選択します。
Queues Propagation: Sensor Edge Serverでは、異なる条件に基づいて様々なキューにイベントが伝播され、アプリケーションがそれらのキューを処理します。
Querying the Sensor Data Archive: 従来のプルベースおよび問合せベースのアプリケーションでは、イベントおよびデータをセンサー・データ・アーカイブに問い合せることができます。
次に、使用するモデルの選択方法を示します。
アプリケーションがユーザー・インタフェースベース、またはバッチ処理ベース（主に、検出するアイテムに関する問合せ情報）の場合には、センサー・データ・アーカイブへの問合せを行うプル・モデルが必要です。アプリケーションが非同期またはイベント・ドリブンの場合（特定の条件に限って対応する、またはイベントを受信した際に対応する場合）は、「Queue Propagation」か「PL/SQL Callback」のどちらかを使用できます。
この2つのモデルのどちらを選択するかの判断基準は次のとおりです: アプリケーションがPL/SQLベースで、長い処理時間を必要としない場合は、単純でデバッグしやすい「PL/SQL Callback」を使用します。処理に時間がかかり、データ率を維持できるかどうが懸念される場合は、「Queue Propagation」を使用します。
最後に、Javaでアプリケーションを作成する場合は、「Queue Propagation」を使用し、JMSを直接使用してイベントを処理するか、コンポーネントをMessage-Driven Beanとして構築します。なお、Streamsを使用する場合、Message-Driven Beanは使用できません。Message-Driven Beanは、OC4J JMSのみで動作します。この詳細は、Oracle Technology NetworkにあるJMSのチュートリアルを参照してください。
このチュートリアルには、ソース・コード、構成ファイルおよびプロジェクト・ファイルが含まれています。ファイルは、http://www.oracle.com/technology/products/iaswe/edge_server/からダウンロードできます。
このチュートリアルでは、単純な盗難の条件の検出ルールを定義して、その条件が満たされたときにPL/SQLコードを呼び出す簡単なアプリケーションを作成する方法を示します。
まず、盗難の条件を定義します。定義には、次のような単純な参照表を使用します。
create table lookup ( id varchar2(128), state number );
lookup.id列は、商品のタグ・アイテムです。商品の代金が支払われると、lookup.stateは0に設定されます。ある商品を検出したことを知らせるイベントをゲートから受信し、そのタグIDがこの表に記載されていて、かつ状態が0以外の場合は、この単純な状況では盗難を示します。この条件が満たされた場合は、コールバック・プロシージャを呼び出すようにします。
PL/SQLパッケージには、盗難の条件が満たされた場合にtrueを返すisTheftと、コールバック関数myCallBackの2つの関数があります。
例13-8のように、参照表を作成し、データを設定してください。
例13-8 参照表の作成
-- Create lookup table DROP TABLE lookup; CREATE TABLE lookup( id varchar2(128), state NUMBER ); -- Seed lookup table INSERT INTO lookup values ( '123', 0 ); INSERT INTO lookup values ( '456', 1 ); INSERT INTO lookup values ( '789', 1 ); -- Create table to store theft info DROP TABLE stolen; CREATE TABLE stolen ( ev EDG_EVENT ); commit; / In this case, 123 is paid for, but 456 and 789 are not. The following package interface defines these procedures: -- Create Package CREATE OR REPLACE PACKAGE test_pkg Authid Current_User IS FUNCTION isTheft ( l_id IN VARCHAR2 ) RETURN NUMBER; PROCEDURE myCallBack ( ev IN EDG_EVENT ); end test_pkg; /
例13-9に示すように、2つの必須関数を定義します。
例13-9 必須関数
-- Create Package
CREATE OR REPLACE
PACKAGE test_pkg
Authid Current_User IS
FUNCTION isTheft ( l_id IN VARCHAR2 ) RETURN NUMBER;
PROCEDURE myCallBack ( ev IN EDG_EVENT );
end test_pkg;
/
-- Now the Body
CREATE OR REPLACE PACKAGE BODY test_pkg IS
-- Returns 1 if it is stolen
FUNCTION isTheft ( l_id IN VARCHAR2 ) RETURN NUMBER
IS
TYPE num_tab IS TABLE OF NUMBER;
states num_tab;
begin
-- See if id is in lookup table
SELECT id BULK COLLECT INTO states FROM lookup WHERE id = l_id AND state <> 0;
IF SQL%ROWCOUNT > 0
THEN
RETURN 1;
ELSE
RETURN 0;
END IF;
end;
PROCEDURE myCallBack ( ev IN EDG_EVENT )
IS
BEGIN
DBMS_OUTPUT.PUT_LINE( 'Got Event!' );
INSERT INTO stolen values ( ev );
END;
end test_pkg;
/
SQL*Plusを使用してこの内容をデータベースに適用するとテストできます。機能をテストするには、次のコマンドを実行して456が盗難されているかどうかを確認します。
SQL> select test_pkg.ISTHEFT('456') from dual;
この戻り値は1です（1は、そのアイテムの代金が支払われていないことを意味します）。次に、ルールを作成します。
必要な処理の大半は関数isTheft()の内部で実行されるため、条件は比較的単純です。次の手順に従ってルールを作成します。
データベースに接続します（たとえば、sqlplus edge/edge@mydb）。
次のコマンドを実行します: call edg_utl.add_rule( 'MyTestRule2', 'test_pkg.isTheft(tab.user_data.id) = 1', NULL, NULL, 'test_pkg.myCallBack', 'call' );
この処理が終了すると、テストを実行できます。
シミュレートしたイベントをシミュレータから送信します。Sensor Edge Serverを使用せずにイベントを送信することも可能です。
SQL*Plusを使用してデータベースに接続します。
次のコマンドを実行します: call edg_utl.sendToStage( 1, 1, '456', 'MySite', 'MyDevice', 'data', sysdate, 'src', 'cor' );
このプロシージャは、IDが456のダミー・イベントを生成し送信します。正しく動作したことを確認するには、センサー・データ・アーカイブを参照します。このイベントを確認できます（SELECT id FROM SDH_EVENTS;）。
次に、stolen表を参照して、コールバックが起動されたかどうかを確認します（SELECT*FROM stolen;）。
イベントが表示されます。
Oracle Sensor Edge Serverには、ユーザーがドライバを最初から開発するためのインタフェースが含まれています。また、この製品で提供されているドライバ・クラスの中には、拡張可能なものもあります。用意されている基盤を利用し、変更が必要なクラスのみを修正することで、開発時間を短縮できます。
|
注意: Oracle Sensor Edge Serverとアップグレードに関しては、次の点に注意してください。標準的なエンタープライズ・インストールでは拡張機能が自動的にアップロードされますが、リリース9.0.4から10.1.2へのアップグレード時にはアップロードされません。既存の拡張機能を保持するには、次のようにします。
|
フィルタ・タイプ
表13-24 Oracle Sensor Edge Serverの組込みフィルタ
| フィルタ名 | 機能 | デバイス・グループに適用されるか（グループ・レベルのフィルタリングのサポート） | デバイスに適用されるか（デバイス・レベルのフィルタリングのサポート） |
|---|---|---|---|
|
Check Tag IDフィルタ |
指定された間隔中にデバイスがタグを読み取っているかどうかを確認する診断ツール。 |
× |
○ |
|
Cross-Reader Redundantフィルタ |
デバイス・グループのデバイスから送信された冗長イベントをブロックします。 |
○ |
× |
|
Debugフィルタ |
イベントを追跡し、それらのイベントをログ・ファイルに書き込みます。 |
× |
○ |
|
Passフィルタ |
タグがデバイスのゲート、読取り範囲または伝達範囲を通過したことをアプリケーションに通知します。デバイスがタグを検出したときに、一連の複数イベントではなく1つのイベントが生成されるように、このフィルタはイベントのブロックも行います。 |
× |
○ |
|
Shelfフィルタ |
アイテムがデバイス・リーダーの読取り範囲またはゲートに入ったこと、または出たことを通知します。 |
× |
○ |
|
Pallet Pass-Thruフィルタ |
コンテナまたはパレットにあるアイテムのすべてのタグIDを確認できるようにし、読取りの重複を排除します。 |
× |
○ |
|
Pallet Shelfフィルタ |
新しいコンテナまたはパレットがデバイス・リーダーの読取り範囲またはゲートウェイに入ったこと、または出たことを通知するイベントを送信します。 |
× |
○ |
Oracle Sensor Edge Serverには、デバイス・ドライバの実装に使用するデバイス・インタフェースが用意されています。このインタフェースは、各デバイス・インスタンスの一意の識別、構成可能パラメータによる初期化、非同期イベントの受信、処理結果が戻される命令の送信、セルフ・クリーン・アップなどの機能を備えています。このインタフェースでは、デバイスとOracle Sensor Edge Serverとの間の通信チャネルに特定の制限はありません。デバイスは、TCPソケット、HTTP、またはイベント・シリアル通信を使用してOracle Sensor Edge Serverと通信できます。Oracle Sensor Edge Serverには、フィルタ処理用のインタフェースが用意されています。フィルタ・オブジェクトは、それぞれ3種類のフィルタリング・レベル（デバイス前フィルタリング、デバイス後フィルタリング、デバイス・グループ・フィルタリング）で実行できます。デバイス前フィルタリングは、イベントがデバイスにルーティングされるまで、入ってきたイベント全体に対してフィルタリングを実行します。デバイス後フィルタリングは、デバイス・グループ・レベルにマージされるまで、イベントに対してフィルタリングを実行します。デバイス・グループ・フィルタリングは、エッジ・クライアントに配信されるまで、イベントに対してフィルタリングを実行します。次の図に、フィルタの配置を示します。
デバイス・インタフェースは、デバイス・ドライバの作成で最もよく使用するインタフェースです。
表13-25 デバイス・ドライバのインタフェース
| メソッド | 説明 |
|---|---|
|
getName() |
デバイス・インスタンスの一意の名前を返します。 |
|
getDescription() |
ドライバ自体の詳しい説明を返します。この情報は、インスタンス固有のものではありません。 |
|
getVersion() |
実装されたドライバのバージョン番号を返します。 |
|
doInit() |
ライフ・サイクル管理の一環: このメソッドは、ロード時にドライバ・マネージャによって呼び出されます。 |
|
start() |
ライフ・サイクル管理の一環: このメソッドは、デバイスが使用可能になると、ドライバ・マネージャによって呼び出されます。 |
|
stop() |
ライフ・サイクル管理の一環: このメソッドは、Oracle Sensor Edge Serverがデバイスの停止をリクエストされたときに、ドライバ・マネージャによって呼び出されます。 |
|
destroy() |
デバイス破棄時にクリーン・アップを行います。 |
|
isAlive() |
デバイスの動作状態を報告します。 |
|
processInstruction() |
着信するそれぞれの命令イベントを処理します。 |
表13-26 フィルタ・インタフェースのメソッド
| メソッド | 説明 |
|---|---|
|
getName() |
フィルタの名前を返します。 |
|
getDescription() |
ドライバの詳しい説明を返します。この情報は、インスタンス固有のものではありません。 |
|
getVersion() |
実装されたフィルタのバージョン番号を返します。 |
|
doInit() |
ライフ・サイクル管理の一環: このメソッドは、フィルタのロード時にデバイス・マネージャによって呼び出されます。 |
|
preFilterDeviceEvents() |
着信する一群のイベントを対象として、そのイベントがデバイスのイベント・バッファに格納される前にフィルタリングを行います。これは、デバイス・レベルのフィルタリングで使用されます。 |
|
postFilterDeviceEvents() |
デバイス・バッファに格納されたイベントを対象として、そのイベントが、デバイス・グループ内に収集された他のデバイス・バッファ・イベントとマージされる直前にフィルタリングを行います。これは、デバイス・レベルのフィルタリングで使用されます。 |
|
filterDeviceGroupEvents() |
デバイス・グループによって収集されたイベントを対象として、そのイベントがディスパッチャに配信される直前にフィルタリングを行います。 |
|
start() |
フィルタを開始します。 |
|
stop() |
フィルタを停止します。 |
|
destroy() |
デバイス破棄時にクリーン・アップを行います。 |
ドライバ、ディスパッチャ、フィルタなどのカスタム拡張機能をアップロードするには、その前に拡張ファイルを拡張アーカイブにパッケージ化する必要があります。拡張アーカイブには、すべての拡張機能のバイナリ、起動データおよび構成情報が含まれます。各拡張アーカイブには1つの拡張機能の実装のみが含まれ、実行時にロードされます。拡張アーカイブには次のディレクトリが含まれます。
META-INF
classes
lib
Meta-INF
このディレクトリには、アーカイブに関するメタ情報が含まれます。このディレクトリに拡張アーカイブ記述子ファイルを含める必要があります。拡張アーカイブ記述子ファイルはMETA-INFディレクトリにあるXMLファイルで、Oracle Sensor Edge Serverで拡張機能をロードおよび管理するために必要な情報が含まれています。拡張アーカイブ記述子ファイルの名前はext.xmlです。ext.xml用のDTDを例13-10に簡略化して示します。このDTDの要素は表13-27で説明します。
例13-10 拡張アーカイブ記述子ファイル（ext.xml）のDTD
<?xml version="1.0" encoding="UTF-8"?> <!ELEMENT Extension (name, version, className, type, Parameters)> <!ELEMENT name (#PCDATA)> <!ELEMENT version (#PCDATA)> <!ELEMENT className (#PCDATA)> <!ELEMENT type (#PCDATA)> <!ELEMENT Parameters (Parameter+)> <!ELEMENT Parameter (valueType)> <!ATTLIST Parameter name CDATA #REQUIRED displayName CDATA #IMPLIED defaultValue CDATA #IMPLIED description CDATA #IMPLIED encrypted (true|false) #IMPLIED isClearText (true|false) #IMPLIED required (true|false) #IMPLIED> <!ELEMENT valueType EMPTY> <!ATTLIST valueType type (int | string | double | boolean) #REQUIRED
表13-27 拡張アーカイブ記述子ファイルのDTDの要素と属性
| 要素 | 属性またはテキスト | 説明 |
|---|---|---|
|
Extension |
|
拡張機能のプロパティを定義します。 |
|
name |
#text |
拡張機能の名前。ユーザーがフィルタの作成、デバイス、ディスパッチャの選択などの拡張機能を選択するときに、この名前が表示されます。 |
|
type |
#text |
ドライバ、フィルタまたはディスパッチャなどの拡張機能のタイプ。大/小文字は区別されませんが、テキストに余分なスペースや特殊文字を含めないようにしてください。予約されている値は、Device、Filter、Dispatcherです。 |
|
version |
#text |
拡張機能のバージョン番号を示すテキスト。 |
|
className |
#text |
ドライバをロードし、インスタンス化するクラスの名前。これは、標準の拡張機能インタフェースの1つを実装するエントリ・クラスです。完全修飾されたクラス名にするためにパッケージ名を含める必要があります。 |
|
Parameters |
|
拡張機能がアップロードされた後に、センサー・サービス・ツールを使用してユーザーが編集できるパラメータ。 |
|
Parameter |
次の属性があります。
|
|
|
valueType |
type |
パラメータのタイプです。次のいずれかの値を選択できます。 int: パラメータが32ビット符号付き整数の場合。 string: 可変長文字列の場合。 double: 倍精度の数値の場合。 boolean（true、false） |
classes
このディレクトリには、すべてのクラス・ファイル、ネイティブ・バイナリ、関連ファイルまたは静的データが含まれます。JARファイルにパッケージ化されたクラス・ファイルは、このディレクトリの最上位に展開する必要があります。このリリースでは、JARライブラリのローディングはサポートされません。
lib
拡張アーカイブ・ファイルには、libディレクトリも含まれます。このディレクトリではサード・パーティのライブラリを指定します。Alienデバイス・ドライバの拡張アーカイブ・ファイルを例13-11に示します。libディレクトリに、Alienデバイス・ドライバに固有のライブラリGateway.jarが含まれています。
例13-11 Alienデバイス・ドライバの拡張アーカイブ・ファイル
meta-inf/ext.xml meta-inf/Manifest.mf classes/oracle/edge/impl/driver/AlienReader.class lib/Gateway.jar
拡張アーカイブ・ファイルをパッケージ化するには、次のようにします。
サンドボックス・ディレクトリを作成します。このディレクトリをJARソース・ディレクトリとして使用します。
このディレクトリの最上位に、META-INFおよびclassesディレクトリを作成します。
すべてのクラス・ファイルとプロパティ・ファイル（ある場合）をclassesディレクトリにコピーします。META-INFディレクトリに、ext.xml（拡張アーカイブ記述子ファイル）を作成します。
ファイルをアーカイブします。JDKに含まれているJARツール、またはその他の標準的な圧縮ユーティリティを使用できます。サンドボックスの最上位ディレクトリからJARツールを実行します。たとえば、jar cvMf test.jarを実行すると、サンドボックス・ディレクトリのファイルがtest.jarにアーカイブされます。これで、test.jarをOracle Sensor Edge Serverにアップロードできます。META-INFおよびclassesディレクトリをサンドボックス・ディレクトリの一部としてアーカイブしないでください。たとえば、コマンドc:/work> jar tvf test.jarを実行すると、正しくアーカイブされたtest.jar内のファイルが次のように表示されます。
0 Thu Apr 08 14:36:56 PDT 2004 META-INF/71 Thu Apr 08 14:36:56 PDT 2004 META-INF/ext.xml0 Thu Apr 08 13:42:52 PDT 2004 classes/0 Thu Apr 08 13:42:52 PDT 2004 classes/my/0 Thu Apr 08 13:42:58 PDT 2004 classes/my/test.class
|
注意: META-INFおよびclassesディレクトリの前には、スラッシュやその他のディレクトリ識別子は表示されません。JARにパス全体を含めると、Oracle Sensor Edge Serverは拡張アーカイブ記述子ファイルやクラスを見つけられません。そのため、拡張機能をデプロイできなくなります。 |
