(57)【特許請求の範囲】
【請求項１】
イベントに対する動作を分類分けした複数のステージを有し、各ステージにおけるステージイベントに対し、各ステージイベントに対応する処理を実行するためのコールバック関数を、プロセスのステージ毎に格納するステージマップと、
他のプロセスから、前記イベントに対応するコマンドとデータとを有するメッセージを受信し、前記メッセージに含まれるコマンドに対応するイベントの情報と、前記メッセージに対して処理するためのプロセスにおけるステージとに基づいて、前記ステージマップを参照して、前記ステージに応じた、前記コマンドに対する処理を実行するための前記コールバック関数を呼び出し、プログラムの低レベル入出力を行なうミドルウエア上で動作するフレームワークを実行するコンピュータと、
を含むメッセージ処理装置。
【請求項２】
前記コンピュータのフレームワークは、コマンド及びデータからなるメッセージを、条件に応じて複数のステージを含む前記ステージマップの各ステージに振り分けるディスパッチャを有し、各ステージの各処理に対応したコールバック関数を呼び出すようにしたことを特徴とする請求項１記載のメッセージ処理装置。
【請求項３】
前記ステージマップは、ステージ移行条件及び移行ステージが設定され、イベントハンドラの戻り値が指定され、使用するイベント一つにつき１個ずつイベントファンクション構造体が準備され、コマンド文字列、イベントハンドラ、ステージ指示テーブルのポインタ、及びコメントが作成され、使用するステージ一つにつき一つのイベントテーブルの配列が準備され、使用するステージ構造体がすべて格納されたステージテーブルを備えたことを特徴とする請求項１記載のメッセージ処理装置。
【請求項４】
前記ステージマップは、少なくとも初期起動のステージ、動作要求のステージ、デバッグレベル通知のステージ、及びプロセス消去通知のステージを備えたことを特徴とする請求項１記載のメッセージ処理装置。
【請求項５】
イベントに対する動作を分類分けした複数のステージを有し、各ステージにおけるステージイベントに対し、各ステージイベントに対応する処理を実行するためのコールバック関数を、ステージマップが、プロセスのステージ毎に格納し、
コンピュータは、他のプロセスから、前記イベントに対応するコマンドとデータとを有するメッセージを受信し、前記メッセージに含まれるコマンドに対応するイベントの情報と、前記メッセージに対して処理するためのプロセスにおけるステージとに基づいて、前記ステージマップを参照して、前記ステージに応じた、前記コマンドに対する処理を実行するための前記コールバック関数を呼び出し、プログラムの低レベル入出力を行なうミドルウエア上で動作するフレームワークを実行するメッセージ処理方法。
【請求項６】
前記コンピュータのフレームワークは、アプリケーションの開発を行うためコマンド及びデータからなるメッセージの通信手続きを含み、前記コマンド及び前記データからなるメッセージを、ディスパッチャが条件に応じて複数のステージからなるステージマップの各ステージに振り分け、各ステージの各処理に対応したコールバック関数を呼び出すことを特徴とする請求項５記載のメッセージ処理方法。
【請求項７】
前記コンピュータは、ステージ指示テーブルを準備し、イベントの戻り値及び移行ステージを設定し、イベントハンドラの戻り値を指定し、使用するイベント一つにつき１個ずつＣイベントファンクション構造体を準備し、コマンド文字列、イベントハンドラ、ステージ指示テーブルのポインタ、及びコメントを作成し、使用するステージ一つにつき一つのイベントテーブルの配列を準備し、使用するステージ構造体を前記ステージ指示テーブルに格納することで作成されることを特徴とする請求項５記載のメッセージ処理方法。
【請求項８】
前記ステージマップは、少なくとも初期起動のステージ、動作要求のステージ、デバッグレベル通知のステージ、及びプロセス消去通知のステージを備えたことを特徴とする請求項５記載のメッセージ処理方法。
【請求項９】
コンピュータに、イベントに対する動作を分類分けした複数のステージを有し、各ステージにおけるステージイベントに対し、各ステージイベントに対応する処理を実行するためのコールバック関数を、プロセスのステージ毎に格納するステージマップを参照させる手順と、
前記コンピュータに、他のプロセスから、前記イベントに対応するコマンドとデータとを有するメッセージを受信し、前記メッセージに含まれるコマンドに対応するイベントの情報と、前記メッセージに対して処理するためのプロセスにおけるステージとに基づいて、前記ステージマップを参照して、前記ステージに応じた、前記コマンドに対する処理を実行するための前記コールバック関数を呼び出し、プログラムの低レベル入出力を行なうミドルウエア上で動作するフレームワークを実行する手順と、を実行させるプログラム。
【請求項１０】
前記コンピュータに、アプリケーションの開発を行うためコマンド及びデータからなるメッセージを、ディスパッチャが条件に応じて複数のステージからなるステージマップの各ステージに振り分ける処理、各ステージの各処理に対応したコールバック関数を呼び出す処理を実行させることを特徴とする請求項９記載のプログラム。
【請求項１１】
前記コンピュータに、前記ステージマップが、ステージ指示テーブルを準備する手順、イベントの戻り値及び移行ステージを設定する手順、イベントハンドラの戻り値を指定する手順、使用するイベント一つにつき１個ずつＣイベントファンクション構造体を準備する手順、コマンド文字列、イベントハンドラ、ステージ指示テーブルのポインタ、及びコメントを作成する手順、使用するステージ一つにつき一つのイベントテーブルの配列を準備する手順、使用するステージ構造体をすべて格納したテーブルを準備する手順を実行することを特徴とする請求項９記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージ処理方法、メッセージ処理装置、及びプログラムに関する。
【背景技術】
【０００２】
図７は、本発明に関連するメッセージ処理方法の概念図である。図８は、本発明に関連するメッセージ処理方法の説明図である。
アプリケーションの開発においては、図７に示すように複数のイベントａ、ｂ、ｃ、…に対し、それぞれ処理ａ’、ｂ’、ｃ’、…の処理を書けば終了する。これによりコールバック関数Ｃ−１，Ｃ−２，Ｃ−３，…が得られた。
【０００３】
この種のアプリケーション開発に関する技術が特許文献１に記載されている。
特許文献１に記載の発明は、「アプリケーション管理方法」に関する発明であり、「複数のアプリケーションモードを有するシステム、または、多機能プリンターシステムにおけるアプリケーション管理方法であって、システム状態管理スタックと、イベントディスパッチを行なうイベントディスパッチステップと、アプリケーションモード遷移制御を行なう遷移制御ステップと、システム状態遷移制御を行なう遷移制御ステップと、遷移要求イベントキューイングを行なうイベントキューイングステップと、ＩＤ付与を行なうＩＤ付与ステップと、を備える」ものである。
このアプリケーション管理方法によれば、アプリケーション管理システムを導入し、イベント伝達系のインターフェイスを統一することで個別モジュールのモジュール性を高めることができるので、結果としてシステムの拡張性を高めることができるという効果があるとしている。
【特許文献１】特開２００６−１４６６９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、大量のデータに対して条件が一定、例えば、時間が経過しても常に同じ処理（例えば同一のパラメータを用いて計算する）する場合にはステージは不要であるが、朝、昼、夜と条件を変える場合、例えば３種類のパラメータを用いて計算する場合には複数のステージが必要となる。
【０００５】
しかしながら、各ステージに対してそれぞれ個別の処理が必要となるので、処理が煩雑になってしまう。すなわち、大量のプログラムを作成する場合、プログラムの起動時にメモリに書かなければならない点、ソケットを他のプロセスに対して接続する準備をしなければならない点、他からのメッセージがくるのですぐ処理しなければならない点、メッセージを調べなければならない点、メッセージに応じた処理をしなければならない点があり、このような場合でもそれらに対応したプログラムを作成しなければならない。しかも、この場合、直接低レベル入出力管理ミドルウエアを利用することになるので、低レベル入出力管理ミドルウエアの手続きを熟知する必要があり、技術について教育しなければならない。このため、アプリケーションを開発するプログラマにはソフトウェアの開発だけでなく、教育工数が必要となるので多大な時間がかかる。
【０００６】
そこで、本発明の目的は、プログラマが直接低レベル入出力管理ミドルウエアを利用せずにプログラミング開発に専念できるメッセージ処理方法、メッセージ処理装置、及びプログラムを提供することにある。
【課題を解決するための手段】
【０００７】
本発明の装置は、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成し、フレームワークのプログラムの先頭部分にメッセージを書き込むことにより、アプリケーションの開発を容易化したことを特徴とする。
【０００８】
本発明の方法は、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成し、フレームワークのプログラムの先頭部分にメッセージを書き込むことにより、アプリケーションの開発を容易化することを特徴とする。
【０００９】
本発明のプログラムは、コンピュータに、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上でのアプリケーション開発のためのフレームワークを作成する手順、フレームワークのプログラムの先頭部分にメッセージを書き込む手順を実行させることにより、アプリケーションの開発を容易化することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成することで、概要設計、詳細設計の定義部分につきソース内の定数として書き込むことにより、プロセス間通信設定、イベントドリブンステージマップを実現することができ、プログラマは業務アプリケーションの機能のプログラミングに専念することができる。
【発明を実施するための最良の形態】
【００１１】
本メッセージ処理方法は、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエアをラッピングしたフレームワークを利用することにより暗黙の宣言や動作をあらかじめ内部で実行することでイベントドリブン型の各アプリケーションを簡単に作成できるものである。
【００１２】
本発明に係るメッセージ処理装置の一実施の形態は、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成し、フレームワークのプログラムの先頭部分にメッセージを書き込むことにより、アプリケーションの開発を容易化したことを特徴とする。
ここで、ステージマップとは、イベントに対する動作をステージ毎に分類し、処理を分けるためのマップである。フレームワークとは、ステージマップを実現するための手段であり、メッセージを受信したときに呼び出されるイベント関数(の候補)のリストである。
ステージマップは、受信したメッセージのメッセージ文字列と、ステージマップに書かれているイベント文字列とが一致するかを調べ、呼び出されるイベント関数が決定される。
【００１３】
上記構成によれば、設計段階においてプログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成することで、概要設計、詳細設計の定義部分につきソース内の定数として書き込むことにより、リソースアクセス、プロセス間通信設定、イベントドリブンステージマップを実現することができ、プログラマは業務アプリケーションの機能の設計に専念することができる。
【００１４】
本フレームワークは、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア関数群を使用したプロセスの中でよく使用されていると考えられる典型的な処理を、より利用しやすい形で提供するものである。
このフレームワークでサポートされていない、より特殊と考えられる処理は、低レベル入出力管理ミドルウエア関数群を直接呼び出す事によって実現することになる。
【００１５】
本発明に係るメッセージ処理装置の他の実施の形態は、上記構成に加え、フレームワークは、アプリケーションの開発を行なうためコマンド及びデータからなるメッセージを、条件に応じて複数のステージからなるステージマップの各ステージに振り分けるディスパッチャを有し、各ステージの各処理に対応したコールバック関数を呼び出すようにしたことを特徴とする。
【００１６】
ここで、メッセージとは、複数アプリケーション間の送受信データが抽象化されたものである。
送信情報としてメッセージの属性を示す8文字からなるメッセージ文字列(例:”EXEC____”)と、データ本体(任意サイズだがフレームワーク内部でサイズ制限あり)とからなる。
受信時には、送信元情報(プロセスインデックス等)も得ることができる。
【００１７】
フレームワークで管理することができる資源オブジェクトとしてのリソースは次のものが挙げられる。
・    共有メモリ(shm系)
・    共有メモリ(mmap系)
・    ソケット
・    サーバソケット
・    セマフォ
それぞれのリソースは、使用するリソースをリソーステーブルに記述することで定義でき、取得(アタッチ)/解放(デタッチ)操作を自動または手動で行なうことが出来る。また、各リソース個別に容易されたメソッドを呼び出すことによってなんらかの処理を行なうことが出来る(例:ソケット送信、セマフォ取得)。
【００１８】
本発明に係るメッセージ処理装置の他の実施の形態は、上記構成に加え、ステージマップは、イベントの戻り値及び移行ステージが設定され、イベントハンドラの戻り値が指定され、使用するイベント一つにつき１個ずつＣイベントファンクション構造体が準備され、コマンド文字列、イベントハンドラ、ステージ指示テーブルのポインタ、及びコメントが作成され、使用するステージ一つにつき一つのイベントテーブルの配列が準備され、使用するステージ構造体がすべて格納されたステージテーブルを備えたことを特徴とする。
【００１９】
本発明に係るメッセージ処理装置の他の実施の形態は、上記構成に加え、ステージマップのうちの第一のステージでは、イベントＡでは初期処理中のため処理できないという返事を返す処理αが定義され、イベントＢでは初期処理中でも通常の返事をする処理βが定義され、イベントＣに対して初期処理中は何もしない処理γが定義され、処理中ステージである第２のステージに遷移したとき、ステージの変更を受けてイベントＡに対しては処理δ、イベントＢに対しては処理β、イベントＣに対しては処理εに定義をそれぞれ変更することにより、イベントＡに対して処理結果を返す処理δが動くようにしたことを特徴とする。
【００２０】
本発明に係るメッセージ処理装置の他の実施の形態は、上記構成に加え、ステージマップは、少なくとも初期起動のステージ、動作要求のステージ、デバッグレベル通知のステージ、及びプロセス消去通知のステージを備えたことを特徴とする。
【００２１】
本発明に係るメッセージ処理方法の一実施の形態は、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成し、フレームワークのプログラムの先頭部分にメッセージを書き込むことにより、アプリケーションの開発を容易化することを特徴とする。
【００２２】
上記構成によれば、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成することで、概要設計、詳細設計の定義部分につきソース内の定数として書き込むことにより、リソースアクセス、プロセス間通信設定、イベントドリブンステージマップを実現することができ、プログラマは業務アプリケーションの機能のプログラミングに専念することができる。
【００２３】
本発明に係るメッセージ処理方法の他の実施の形態は、上記構成に加え、フレームワークは、アプリケーションの開発を行なうためコマンド及びデータからなるメッセージを、ディスパッチャが条件に応じて複数のステージからなるステージマップの各ステージに振り分け、各ステージの各処理に対応したコールバック関数を呼び出すことを特徴とする。
【００２４】
本発明に係るメッセージ処理方法の他の実施の形態は、上記構成に加え、ステージマップは、ステージ指示テーブルを準備し、イベントの戻り値及び移行ステージを設定し、イベントハンドラの戻り値を指定し、使用するイベント一つにつき１個ずつＣイベントファンクション構造体を準備し、コマンド文字列、イベントハンドラ、ステージ指示テーブルのポインタ、及びコメントを作成し、使用するステージ一つにつき一つのイベントテーブルの配列を準備し、使用するステージ構造体を前記ステージ指示テーブルに格納することで作成されることを特徴とする。
【００２５】
本発明に係るメッセージ処理方法の他の実施の形態は、上記構成に加え、ステージマップのうちの第一のステージでは、イベントＡでは初期処理中のため処理できないという返事を返す処理αが定義され、イベントＢでは初期処理中でも通常の返事をする処理βが定義され、イベントＣに対して初期処理中は何もしない処理γが定義され、処理中ステージである第２のステージに遷移したとき、ステージの変更を受けてイベントＡに対しては処理δ、イベントＢに対しては処理β、イベントＣに対しては処理εに定義をそれぞれ変更することにより、イベントＡに対して処理結果を返す処理δが動くようにすることを特徴とする。
【００２６】
本発明に係るメッセージ処理方法の他の実施の形態は、上記構成に加え、ステージマップは、少なくとも初期起動のステージ、動作要求のステージ、デバッグレベル通知のステージ、及びプロセス消去通知のステージを備えたことを特徴とする。
【００２７】
ここで、フレームワークの機能について述べる。
＜１＞スケルトン(骨組み)ソースの提供
新たにプログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア環境に対応したアプリケーションを作成し始める場合に使用できる、「何もしない」プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア対応アプリケーション（スケルトンプログラム）のソースを提供する。これによって、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア対応アプリケーションできまって必要な各種スクリプト、いわゆる「おまじない」を書くことなく、すぐに各業務プロセスにおける独自処理を書き始めることが出来る。
【００２８】
＜２＞アプリケーション制御 (dataget_client.c L109〜L134,dataget_server.c L133〜L158 参照)
フレームワークを使用する場合、そのソースプログラムは「イベントドリブン」な構造のコーディングスタイルで記述することになる。具体的には、プロセス起動直後にプロセスの制御権をフレームワークに引き渡すようにする。それによってフレームワークがアプリケーションの制御権を獲得した状態でとどまり、必要に応じてユーザ定義の関数を呼び出すという動作をおこなうようになる。
【００２９】
＜３＞リソースのアタッチ／デタッチ (dataget_client.c L44〜L68,dataget_server.c L45〜L91 参照)
使用する共有メモリやソケットなどの「リソース」をリソーステーブルに定義することによって、自動的にアプリケーション起動時に取得(アタッチ)し使える状態にして、終了時に後始末(デタッチ)するようにフレームワークに指示することが出来る。
【００３０】
これによって、リソースを扱うための手続きの簡略化、リソースの後始末のし忘れの防止、リソーステーブルを見ることでそのアプリケーションがどのようなプロセスの外部に対するインターフェイスを持つかを把握することが出来る、などのメリットが得られる。
また、特殊な動作をさせるためにアタッチ/デタッチを任意のタイミングで行なうことも可能である。
【００３１】
＜４＞他アプリケーションからのメッセージの受信に対する動作 (dataget_client.c L70〜L98,dataget_server.c L93〜L122 参照)
ステージマップテーブルを定義することによって、他アプリケーションからの「メッセージ」を受信した場合に呼び出されるイベントコールバック関数を指定することができる。
ステージマップテーブルはメッセージ文字列と、そのメッセージ文字列を受けたときに呼び出されるイベントコールバック関数、そしてイベントコールバック関数の戻り値によってどのようにステージ遷移(後述)を行なうかを定義するテーブル(ステージ遷移テーブル)の3つを持つ構造体を、必要数配列として定義したテーブルとなる。
【００３２】
＜５＞イベントコールバック関数 (dataget_client.c L188〜L211,dataget_server.c L222〜L279 参照)
イベントコールバック関数は、「int OnEventFunc( CEventInfo* pEventInfo );」という関数スペックで定義する。pEventInfoの中には「メッセージ」の情報、送信元の情報等が入っており、それらの情報を使用して該当のイベントにおいて必要な処理を行なう。
戻り値は、典型的には「RESULT_OK」を返してイベント処理を終了させるようにする。
戻り値によってステージ変更をしたり、プロセスの正常/異常終了したりすることも可能で、戻り値とその後の挙動の対応関係はステージマップ中のステージ遷移テーブルで指定する。
【００３３】
＜６＞他アプリケーションへのメッセージ送信 (dataget_client.c L194,dataget_server.c L232〜L237 参照)
メッセージ送信関数を使用することによって、他のアプリケーションへ「メッセージ」を送信することが出来る。送られた「メッセージ」は、送信先のアプリケーションにおいて「ステージマップ」の記述に応じて処理が行われる。
【００３４】
＜７＞ステージ遷移
ステージマップは複数セット持つことが出来る。その際、複数あるそれぞれのステージマップは、ステージ0、ステージ1、ステージ2、…と番号付けをすることによって管理される。
ステージ遷移の行われ方はステージマップテーブルのそれぞれのレコードに指定されているステージ遷移テーブルによって行われる。
ステージ遷移テーブルは、イベントコールバック関数の戻り値と次回ステージ番号指定とを1つの組として、必要数を配列として定義したテーブルとなる。このテーブルはイベントコールバック関数からのリターン時に、フレームワークがチェックし戻り値に対応したステージに遷移する。新しいステージマップは次回メッセージ受信時から適用される。
また、ステージ遷移テーブルに記述可能な次回ステージ番号として、特殊なステージ番号(負の数)があり、ステージを変更しない、プロセス正常終了、およびプロセス異常終了を指定することが可能である。
【００３５】
＜８＞デフォルトのイベント処理関数の提供 (dataget_client.c L78〜L88,dataget_server.c L101〜L111 参照)
典型的な業務プロセスにおいて、必ず使用され、かつ特殊な一部の場合を除いて同一の処理となるイベントコールバック関数について、ライブラリの一部として提供する。例えば次のような関数が挙げられる。
・    プロセス終了要求処理関数
・    ソケット接続受け付け通知関数
ソケット切断通知関数
タイムベースのタイムアップ通知関数
なおスケルトンプログラムにおいて、上記関数はすでにステージマップ定義中に記述されているため、通常は意識することなく使用されていることになる。
【００３６】
＜９＞プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア関数群の簡易版呼び出し関数
デバッグログ出力
プロセスモニタ出力
タイムベース
ネームサービス
...
【００３７】
また、フレームワーク使用時の処理の流れについては、以下の（ａ）〜（ｍ）のようになる。
（ａ）プロセスの開始
（ｂ）main()関数
（ｃ）CContextTable構造体の初期化、設定
（ｄ）Main関数の呼び出し
（ｅ）OnPrepareTable()...テーブル準備処理
（ｆ）リソースの自動アタッチ
（ｇ）OnConstruct()...初期化処理
（ｈ）OnChangeStage()...ステージ変更
（ｉ）メッセージループ
OnChangestage()...ステージ変更時
OnDiagnostic()
OnClientConnect()
OnUnsupportedEvent()
ステージマップにより定義されたイベント関数
（ｊ）  OnDestruct()...終了時の処理
（ｋ）  リソースの自動デタッチ
（ｌ）  Main関数の終了
（ｍ）  プロセスの終了
【００３８】
5.    リソーステーブルの書式
(1)    共有メモリ(shm)テーブル (dataget_client.c L44〜L47,dataget_server.c L45〜L55 参照)
【００３９】
≪テーブル書式≫
CShareMemTable shm0 =
SHAREMEMRECORD_INDIRECT( メモリポインタのアドレス,
共有メモリ(shm)識別キー, モード, フラグ, コメント);
CShareMemTable shm[] = [ &shm0, NULL ];
【００４０】
≪例≫
char* pMem;
CShareMemTable shm0 =
SHAREMEMRECORD_INDIRECT( &pMem, 333, 0, SHM_RDONLY, "shm" );
CShareMemTable shm[] = [ &shm0, NULL ];
【００４１】
≪使用方法≫
アタッチ後、ポインタpMemに共有メモリのアドレスが入る。
(2)    共有メモリ(mmap)テーブル (dataget_client.c L49〜L52,dataget_server.c L57〜L60 参照)
【００４２】
≪テーブル書式≫
CMMapTable mmap0 =
MMAPRECORD_INDIRECT( メモリポインタのアドレス,
共有メモリ(mmap)識別キー, 必要サイズ, モード, コメント);
CMMapTable mmap[] = [ &mmap0, NULL ];
【００４３】
≪例≫
char* pMMap;
CMMapTable mmap0 =
MMAPRECORD_INDIRECT( &pMMap, "/tmp/test.dat", 1024, 0, "mmap" );
CMMapTable mmap[] = [ &mmap0, NULL ];
【００４４】
≪使用方法≫
アタッチ後、ポインタpMMapに共有メモリのアドレスが入る。
(3)    ファイルテーブル (dataget_client.c L54〜L57,dataget_server.c L62〜L72 参照)
【００４５】
≪テーブル書式≫
CFileTable fil0 =
FILERECORD_INDIRECT( ファイル構造体のポインタのアドレス,
ファイル識別キー, モード, オープンフラグ, コメント);
CFileTable fil[] = [ &fil0, NULL ];
【００４６】
≪例≫
FILE* fp;
CFileTable fil0 =
FILERECORD_INDIRECT( &fp, "/tmp/test.log", 0, "a+", "ログ" );
CFileTable fil[] = [ &fil0, NULL ];
【００４７】
≪使用方法≫
アタッチ後、fpにファイル構造体ポインタが入る。
(4)    ソケット接続テーブル (dataget_client.c L59〜L68,dataget_server.c L74〜L91 参照)
【００４８】
≪テーブル書式≫
/* クライアント接続 */
CSocketTable sock0 =
SOCKRECORD_CLIENT( インデックス番号, モード, コメント );
/* サーバ接続受け付け管理 */
CSocketTable sock1 =
SOCKRECORD_ACCEPT( インデックス番号, モード, コメント );
/* 接続元不定サーバ接続受け付け管理 */
CSocketTable sock2 =
SOCKRECORD_ANYONE( モード, コメント );
CSocketTable sock[] = [ &sock0, &sock1, &sock2, NULL ];
【００４９】
≪例1(クライアント側) ≫
CSocketTable sock0 =SOCKRECORD_CLIENT( 555, 0, "toサーバ" );
CSocketTable sock[] = [ &sock0, NULL ];
【００５０】
≪例2(サーバ側) ≫
/* サーバ接続受け付け管理 */
CSocketTable sock1 = SOCKRECORD_ACCEPT( 666, 0, "toクライアント" );
CSocketTable sock[] = [ &sock1, NULL ];
【００５１】
≪例3(サーバ側(接続元不定) ≫
CSocketTable sock2 = SOCKRECORD_ANYONE( 0, "toクライアント" );
CSocketTable sock[] = [ &sock2, NULL ];
【００５２】
≪例4(接続確立時の送信) ≫
char buff[ 512 ];
SendSocket( &sock0, MSGT_TEST, buff, sizeof( buff ) );
SendSocket_0( &sock0, MSGT_TEST ); /* データ部不要の場合 */
【００５３】
≪使用方法≫
クライアント側プロセスのソケットテーブルに「例1」を指定する。
サーバ側プロセスのソケットテーブルに「例2」または「例3」を指定する。
あらかじめ接続元プロセスインデックスが決まっている場合「例2」、そうでない場合「例3」を指定する。
【００５４】
クライアント→サーバの接続が確立すると、サーバ、クライアント双方から「例4」のような形で他方へメッセージを送信する事ができる。
送信先のプロセスでメッセージ文字列に応じたイベント関数が呼び出される。
【００５５】
6.    ステージマップ (dataget_client.c L70〜L98,dataget_server.c L93〜L122 参照)
≪テーブル書式≫
/* ステージ指示テーブル */
CMoveStageTable mov0[] = [
[ イベントの戻り値, 移行ステージ ],
...
EndOfMoveStageTable
];
/* イベントテーブル */
CEventFunc stg0[] = [
STAGERECORD( コマンド文字列, イベントハンドラ,
ステージ指示テーブルのポインタ ),
...
]
/* ステージテーブル */
CStageTable* stg[] = [ stg0, ];
【００５６】
≪例≫
CMoveStageTable mov0[] = [
[ RESULT_OK, STAGE_STAY ],
[ RESULT_NG, STAGE_ABORT ],
[ RESULT_END, STAGE_EXIT ],
EndOfMoveStageTable
];
CEventFunc stg0[] = [
/* スケルトンがハンドラを用意しているイベント */
STAGERECORD( MSGT_CLOSE, OnDefaultCloseConnection, mov0 ),
STAGERECORD( MSGT_ABORT, OnDefaultAbortConnection, mov0 ),
STAGERECORD( MSGT_CONNECT, OnDefaultAcceptConnection, mov0 ),
...
【００５７】
/* プロセス独自イベント */
STAGERECORD( MSGT_EXEC, OnExec, mov0 ),
]
CStageTable* stg[] = [ stg0 ];
【００５８】
≪使用方法≫
イベントテーブルに、処理する受信コマンド文字列１つにつき１行のテーブルを定義する。
スケルトンプログラムにはあらかじめデフォルトのハンドラ定義が登録されているため、通常はプロセス独自のイベントを必要に応じて追加する事になる。
自プロセスがメッセージを受けたときに、メッセージ処理が、このテーブルを検索し、対応するイベント関数を呼び出す。
【００５９】
呼び出されるイベント関数の型は次のようになる。
int EventFunction( CEventInfo* pEventInfo );
引数pEventInfoには発生したイベントに関する情報が入っている。
【００６０】
CEventInfo構造体のメンバは次の通りである。
int fdEvent;                            /* 送信元fd */
int indexEvent;                                 /* 送信元idx番号 */
char* pcEvent;                          /* 送信元ホスト名 */
char pcCommand[ CommunicationExpandSize ];      /* コマンド文字列 */
char* pMessage;                                 /* メッセージバッファへのポインタ */
int lenMessage;                                 /* メッセージのサイズ */
【００６１】
7.プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア関数群の簡易版呼び出し関数
(1)    デバッグログ出力 (dataget_client.c L204 等参照)
【００６２】
≪書式≫
void _dprint( int iLevel, char* pcFormat, ... );
iLevel:デバッグレベル比較値として
70(最も重要)から 89(重要度低、詳細)を指定する。
pcFormat,... :表示する文字列(printf等で使われる書式付き可変長引数)
【００６３】
≪例≫
_dprint( DEBUG_F_TRACE, "フラグ:%dで通過", flag );
【００６４】
≪使用方法≫
指定文字列を画面またはファイルに出力する。
現在のデバッグレベルが50〜69である場合、標準出力に出力される。
現在のデバッグレベルが70〜89である場合、ファイルに出力される。
(2)    プロセスモニタ表示更新 (dataget_client.c L207 参照)
【００６５】
≪書式≫
void _dmoni( char* pcFormat, ... );
pcFormat,... 表示する文字列(printf等で使われる書式付き可変長引数)
【００６６】
≪例≫
_dmoni( "ファイル:%sを処理中", pcFilename );
【００６７】
≪使用方法≫
指定文字列で自プロセスのプロセスモニタ表示を更新する。
【００６８】
1.      クライアント側の処理
(1)     サーバプロセスにソケット接続する。
(2)     「EXEC____」メッセージを受け取ったらサーバプロセスにデータ取得要求「DATAREQ_」を送信する。
(3)     サーバからデータ受信「DATA____」を受けたら、メッセージデータ部を文字列として認識し、プロセスモニタ表示を更新する。
【００６９】
2.      サーバ側の処理
(1)     データテーブル共有メモリをアタッチし、初期化する。
(2)     ログ用ファイルをアタッチする。
(3)     一定時間ごとにデータテーブルに データ(文字列)を作成し格納する。
同時にログにその旨を出力する。
(4)     データ取得要求「DATAREQ_」を受け取ったら、
データテーブルからデータを取り出し、送信元へ送信する「DATA____」。
同時にログにその旨を出力する。
もし、データテーブルにデータが無い場合、何もしない。
【００７０】
≪ログ解説≫
(1)サーバプロセスにソケット接続(クライアント→サーバ)
(2)「EXEC____」メッセージを受け取った。(クライアント)
(3)サーバプロセスにデータ取得要求「DATAREQ_」を送信する。(クライアント→サーバ) 
(4)データ取得要求「DATAREQ_」を受け取ったら、データテーブルからデータを取り出し、
送信元へ送信する「DATA____」。(サーバ→クライアント) 
(5)「EXEC____」メッセージを受け取った。(クライアント)
(6)サーバプロセスにデータ取得要求「DATAREQ_」を送信する。(クライアント→サーバ) 
(7)エラーの為、送信元へ送信する「DATA____」を送信していない。(サーバ) 
(8)クライアントプロセスの終了に伴い、ソケット接続をデタッチ(クライアント→サーバ)
【００７１】
＜プログラム及び記憶媒体＞
以上で説明した本発明のメッセージ処理装置は、コンピュータでメッセージ処理を実行させるプログラムによって実現されている。コンピュータとしては、例えばパーソナルコンピュータやワークステーションなどの汎用的なものが挙げられるが、本発明はこれに限定されるものではない。
【００７２】
本発明に係るプログラムの一実施の形態は、コンピュータに、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成する手順、フレームワークのプログラムの先頭部分にメッセージを書き込む手順を実行させることにより、アプリケーションの開発を容易化することを特徴とする。
【００７３】
上記構成によれば、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成することで、概要設計、詳細設計の定義部分につきソース内の定数として書き込むことにより、リソースアクセス、プロセス間通信設定、イベントドリブンステージマップを実現することができ、プログラマは業務アプリケーションの機能のプログラミングに専念することができる。
【００７４】
本発明に係るプログラムの他の実施の形態は、上記構成に加え、コンピュータに、フレームワークが、アプリケーションの開発を行なうためコマンド及びデータからなるメッセージを、ディスパッチャが条件に応じて複数のステージからなるステージマップの各ステージに振り分ける処理、各ステージの各処理に対応したコールバック関数を呼び出す処理を実行させることを特徴とする。
【００７５】
本発明に係るプログラムの他の実施の形態は、上記構成に加え、コンピュータに、ステージマップが、ステージ指示テーブルを準備する手順、イベントの戻り値及び移行ステージを設定する手順、イベントハンドラの戻り値を指定する手順、使用するイベント一つにつき１個ずつＣイベントファンクション構造体を準備する手順、コマンド文字列、イベントハンドラ、ステージ指示テーブルのポインタ、及びコメントを作成する手順、使用するステージ一つにつき一つのイベントテーブルの配列を準備する手順、使用するステージ構造体をすべて格納したテーブルを準備する手順を実行することを特徴とする。
【００７６】
本発明に係るプログラムの他の実施の形態は、上記構成に加え、コンピュータに、ステージマップのうちの第一のステージでは、イベントＡでは初期処理中のため処理できないという返事を返す処理αを定義する手順、イベントＢでは初期処理中でも通常の返事をする処理βを定義する手順、イベントＣに対して初期処理中は何もしない処理γを定義する手順、処理中ステージである第２のステージに遷移したとき、ステージの変更を受けてイベントＡに対しては処理δ、イベントＢに対しては処理β、イベントＣに対しては処理εに定義をそれぞれ変更することにより、イベントＡに対して処理結果を返す処理δが動くようにする手順を実行させることを特徴とする。
【００７７】
これにより、プログラムが実行可能なコンピュータ環境さえあれば、どこにおいても本発明のメッセージ処理装置を実現することができる。
このようなプログラムは、コンピュータに読み取り可能な記録媒体に記憶されていてもよい。
ここで、記録媒体としては、例えば、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（CD Recordable）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記録媒体、ＨＤＤ（Hard Disc Drive）、フラッシュメモリ、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＦｅＲＡＭ（強誘電体メモリ）等の半導体メモリが挙げられる。
【００７８】
なお、上述した実施の形態は、本発明の好適な実施の形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【実施例】
【００７９】
図１は、本発明に係るメッセージ処理方法の概念図である。
本メッセージ処理方法は、プログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成し、フレームワークのプログラムの先頭部分にメッセージを書き込むことにより、アプリケーションの開発を容易化するものである。
すなわち、コマンド及びデータからなるメッセージＭがフレームワークＦＷに入力されると、フレームワークＦＷは、条件に応じてメッセージＭを各ステージＳに振り分ける。各ステージＳ（１，２，３）ではデータに応じて各処理ａ，ｂ，ｃ，…がなされ、各処理に対応するコールバック関数ＣＦが呼ばれる。
【００８０】
ここで、アプリケーション同士でメッセージを通信し、共有メモリ等を介してデータを他のプロセスと授受するものとする。
プロセス間通信は、通常、個別のネットワークライブラリにはよく見られるが、フレームワークの中でネットワーク通信概略だけにあり、最初の８〜１０文字がイベントであり、残りの部分がデータであるメッセージで行われる。
【００８１】
プロトコル間通信には、メッセージの授受にＴＣＰ／ＩＰ  ＵＮＩＸ（登録商標）ソケットが用いられ、大きなデータの授受に使う共有メモリに対するアクセスがある。共有メモリに対するアクセスとは、通常はＵＮＩＸ（登録商標）で多く使われる（ｓｈｍｇｅｔ）機能を使うのが多いが、ｍｍａｐ機能を用いてラッピングされた共有定義により共有メモリ機能を実装している。
【００８２】
図２は、本発明に係るメッセージ処理に用いられるステージの作成方法を示すフローの一例である。
まず、ステージ指示テーブルを準備する（ステップＳ１）。
イベントの戻り値及び移行ステージを設定する（ステップＳ２）。
イベントハンドラの戻り値を指定する（ステップＳ３）。
使用するイベント一つにつき１個ずつＣイベントファンクション構造体を準備する（ステップＳ４）。
コマンド文字列、イベントハンドラ、ステージ指示テーブルのポインタ、及びコメントを作成する（ステップＳ５）。
使用するステージ一つにつき一つのイベントテーブルの配列を準備する（ステップＳ６）。
使用するステージ構造体をステージ指示テーブルに格納することでステージが作成される（ステップＳ７）。
【００８３】
次に、ステージマップによるステージ遷移とコールバック関数との対応関係にて述べる。
図３は、本発明に係るメッセージ処理方法の説明図である。
同図において、イベント、ステージマップ、及びコールバック関数が示されている。
イベントとしては、例えば、ヘルスチェック、ヘルスチェックＯＫか、リクエスト、などの命令（動作イベント）が挙げられる。
イベントは、初期起動、第１変換要求、動作要求、第２変換要求、デバッグレベル通知、及びプロセス消去通知を含む。
【００８４】
ステージマップは、複数（図では三つであるが限定されない。）のステージを有するものである。ステージ１は、初期起動、第１変換要求、動作要求、第２変換要求、及びデバッグレベル通知を有する。
ステージ２は、初期起動、第１変換要求、動作要求、第２変換要求、及びデバッグレベル通知を有するが、このうち初期起動は行なわないものとする。
ステージ３は、初期起動、第１変換要求、動作要求、第２変換要求、及びデバッグレベル通知を有するが、このうち初期起動はステージ２同様に行なわないものとする。
【００８５】
コールバック関数は、初期起動処理、第１変換処理、第１変換ＮＧ処理、第１動作処理、第２変換処理、第２変換ＮＧ処理、第２動作処理、ステージ違いＮＧ処理、デバッグレベル変換処理、及びプロセス終了処理を有する。
【００８６】
例えば、イベントがステージ１の初期起動をすべく初期起動を行なうと、ステージ１では初期起動処理を行なうように初期起動処理のコールバック関数を呼ぶ。これに対して、イベントがステージ２の初期起動を要求してもステージ２では初期起動が行われず、したがってこの場合、初期起動処理のコールバック関数は呼ばれない。ステージ２では初期起動以外は行われる。ステージ３もステージ２と同様である。
【００８７】
このステージマップによって、ステージとイベントに対する呼ばれるコールバック関数が決定される。尚、ステージは、系の状態に準拠してもよく、オリジナルのステージ遷移を行っても良い。
【００８８】
本メッセージ処理方法は、通信プロトコル等は意識する必要がなくフレームワーク内で処理をするためイベントを登録して対応するコールバック関数を定義して設計書に処理を書くだけでよい。後は各種暗黙のイベント処理（ヘルスチェック等は暗黙の処理である）のフレームワークの中に入っているので、これは設計書には書かなくてよい。終了についても同様である。本当の業務だけを作ればよい。たとえば「計算しなさい」という命令だけを書けばよい。
【００８９】
図４（ａ）は、本発明に係るメッセージ処理方法に用いられる設計書のうちの１ステージ一覧の一例であり、図４（ｂ）は、１ステージマップの一例である（ステージ番号は横並びになっている）。
図４（ａ）に示すように１番はINTステージであり、起動後、初期処理中、及び業務受付前の処理を行なう。２番はSTAGE Sステージであり、待機状態の処理を行なう。３番はSTAGE Aであり、第１から第２遷移中状態の処理を行なう。４番はSTAGE Bであり、第２状態の処理を行なう。５番はSTAGE Cであり、第２から第１遷移中状態の処理を行なう。６番はSTAGE TESTであり、試験状態の処理を行なう。
【００９０】
図４（ｂ）は、ステージイベントと、動作とが示されている。例えば、コールバック関数は「m00」、「m01」、「m01d」、…であり、「RET NG」は異常発生により終了することを意味し、「RET OK」は状態をそのままにすることを意味する。もし条件が変わってｘに状態遷移しなければならないときは、「RET OK→ｘ」とすればよい。
【００９１】
各プロセスは同じメモリ空間内にあるものもあり、ネットワーク上で離れているものもある。
メッセージのデータはネットワークを流れる一連のデータである。マシン名またはサブシステム名クラスタの場合は主系・待機系、等とアプリケーションとを指定して送るだけである。
中でＴＣＰ／ＩＰやＵＮＩＸソケット等のプロトコルに応じたネームサービスがあり名前解決を行なうがプログラマはその違いやネームサービスは意識する必要が無く、フレームワークに「これを渡せ」と指示するだけですむ。具体的にはプログラムでアプリケーションにあるように、ＩＰアドレス、ポート番号については、意識しなくて良い。
図５は、本発明に係るメッセージ処理方法に用いられるフレームワークの説明図である。
同図に示すように、本フレームワークは、ＯＳ（Operating System）上にプロセス制御、リソース制御、及びプロセス間通信制御を行なうミドルウエアが構成され、その上に構成されており、本フレームワーク上に各種業務アプリケーションが構成されるのである。
このようにプログラムの低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエア上にアプリケーション開発のためのフレームワークを作成することで、プログラマは低レベル入出力などの手続きを熟知する必要なく、業務アプリケーションの機能のプログラミングに専念することができる。
【００９２】
ここで、関連技術では、プログラムを作る場合プログラムソースコード内の定義部分で共有メモリの内容を定義し、プログラムの処理の中でその定義に従って共有メモリを取得しなさいという、命令があって、フレームワークが内部処理で共有メモリを確保して、アドレスを確保する。
しかしプログラムソースコード上では確保されたアドレスにアクセスするコードを書くことによって処理することができるため、共有メモリ確保のための長いスクリプトが必要ない。
フレームワークの場合は、プログラムソースコード内では各種の定義すべきリソースはテーブルになっており、データという形で定義されている。ひとつのリソースについて１行分の必要な事項を記入するという形で表現される。たとえばメモリの確保については、１つのメモリテーブルについて１行の必要事項を書き、１０個メモリがあるならば１０行書く、これにより１０個のメモリの確保ができる。同じようにイベントに対するコールバックの設定も別のイベント用テーブルの１行に表現されるためイベント数分行を書けばあとはフレームワークの内部処理の中で必要な処理がなされるようになる。
【００９３】
本実施例の特徴的な点は、イベントドリブンのイベントに対する割り当て処理に対して、ステージの概念をもち、ステージマップにしたがって、ステージごとのイベントに対する処理の割り当てを変えることができる点である。
具体的には初期状態（ステージ_１）で、イベントＡに対して処理α、イベントＢに対して処理β、イベントＣに対して処理γが定義されているとして、初期処理中なのでイベントＡでは初期処理中のため処理できないという返事をかえす処理αだったり、イベントＢに対しては初期処理中でも通常の返事をする処理βだったり初期処理中のイベントＣに対しては何もしないγだったりする。
ここでステージが変わり処理中ステージ（ステージ_２）に遷移したとき、フレームワークはステージの変更を受けてイベントＡに対して処理δ、イベントＢに対して処理β、イベントＣに対して処理εに定義を変更するこのことにより、イベントＡに対して処理結果を返す処理δが開始される。
【００９４】
図６は、本発明に係るメッセージ処理方法を用いたネットワークライブラリの一例である。
複数（図では三つであるが限定されない。）のプログラムにおいて、プロセス間の通信の確立イベント振り分けをラッピングするものであり、プロセス間通信をラッピングして面倒な通信手順の確立やイベント振り分けの仕組みを作る必要が無い。通信機能、名前解決等の仕組みは低レベル入出力、動作監視を含む各種低レベル制御を行なうミドルウエアの機能を利用することができる。
【００９５】
以上において、本実施例によれば、プログラマが作成するコード部分が簡略化される。このため各種低レベル制御を行なうミドルウエアの定型手続きだけで５分の１程度ですむ。関連技術では、プログラムの作成に際して準備に多くの時間がかかっていた。しかしながら、共通で使われるプログラムがフレームワークの中にすでに作成されているので、改めて作成する必要がない。
関連技術との違いは、プロセスの管理ができる点、プロセス間通信に関する機能ＵＮＩＸ（登録商標）系ＯＳのアプリケーションで利用するリソースの管理が一元化できる点である。
【図面の簡単な説明】
【００９６】
【図１】本発明に係るメッセージ処理方法の概念図である。
【図２】本発明に係るメッセージ処理に用いられるステージの作成方法を示すフローの一例である。
【図３】本発明に係るメッセージ処理方法の説明図である。
【図４】（ａ）は、本発明に係るメッセージ処理方法に用いられる設計書のうちの１ステージ一覧の一例であり、（ｂ）は、１ステージマップの一例である。
【図５】本発明に係るメッセージ処理方法に用いられるフレームワークの説明図である。
【図６】本発明に係るメッセージ処理方法を用いたネットワークライブラリの一例である。
【図７】本発明に関連するメッセージ処理方法の概念図である。
【図８】本発明に関連するメッセージ処理方法の説明図である。
【符号の説明】
【００９７】
ＣＦ    コールバック関数
ＦＷ    フレームワーク
Ｍ    メッセージ
Ｓ    ステージ
【図１】
0005251197.tif 000002
【図２】
0005251197.tif 000003
【図３】
0005251197.tif 000004
【図４】
0005251197.tif 000005
【図５】
0005251197.tif 000006
【図６】
0005251197.tif 000007
【図７】
0005251197.tif 000008
【図８】
0005251197.tif 000009