JP3944231B2 - フレームワークシステム - Google Patents

Description

本発明は、クライアントからのメッセージに応答して、選択された1又はそれ以上のビジネスロジックを実行するフレームワークシステムに関する。

この種のフレームワークシステムは、典型的には、1又はそれ以上のクライアントと通信可能に接続される１又はそれ以上のサーバによって構成される。この種のフレームワークシステムには、従来からメッセージングサービスと、フレームワークサービスという２つの基本機能が提供されている。メッセージングサービスは、クライアントとサーバ間及びサーバとサーバ間のメッセージ通信を処理するサービスである。フレームワークサービスは、通常複数のビジネスロジック（業務処理プロセス）を有しており、クライアントからのメッセージに応答して、選択された1又はそれ以上のビジネスロジックを同期方式で又は非同期方式で実行することによりトランザクションを遂行する。

しかしながら、上記従来例にあっては、フレームワークサービスにおけるビジネスロジックの処理スケジュールが固定的にプログラムされている。そのため、多種多様なメッセージに応じて複雑なビジネスロジックのフローを柔軟に定義することが困難である。

また、クライアントからのメッセージに応答して、複数のビジネスロジックを逐次に実行する場合がある。例えば、クライアントからの仕入登録リクエストに応答して、仕入登録や在庫更新や買掛金記帳などを行う場合である。このような場合、従来システムでは、例えば仕入登録のようなフロントデスクに関わるビジネスロジックはそのメッセージに同期して実行するが、在庫更新や買掛金記帳のようなバックオフィスに関わるビジネスロジックは夜間のバッチ処理により実行する。そのため、バックオフィスの処理の結果は、翌日まで待たないと参照できない。しかし、新たな取引のチャンスをいち早くキャッチするには、バックオフィスのビジネスロジックも可能な限り早期に実行してその結果が早期に参照できることが望ましい。

また、複数のフレームワークサーバを備えたシステムでは、フレームワークサーバ相互間でもメッセージを送受しながら協働して、一連のビジネスロジックを実行していく。各サーバのステータス（例えば、保有するビジネスロジックの種類、正常に稼動しているか否か、ビジーか否か、など）は、他のサーバとは違うのが普通であり、且つ、時間経過に伴って変化もする。このことは、ビジネスロジックの実行をどのサーバに依頼するかを決めるスケジューリングを複雑にする。

本発明は、ビジネスロジックフローを、プログラムすることなく、定義し変更することが容易なフレームワークシステムを提供することを目的とする。

本発明の別の目的は、フレームワークシステムにおいてP to P通信とP to M通信を可能にすることにある。

本発明のまた別の目的は、一連のビジネスロジックを、完全にリアルタイムではなくても、できるだけリアルタイムに近い態様で、実行することができるフレームワークシステムを提供することにある。

本発明の更に別の目的は、複数のフレームワークサーバを備えたシステムにおいて、一連のビジネスロジックのスケジューリングを、それらサーバのステータスに応じて適切に行えるようにすることにある。

本発明の一つの観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、複数のビジネスロジックと関連付けられ、クライアントからのリクエストのメッセージに応答して、選択された１又はそれ以上のビジネスロジックを実行し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスと；フレームワークサービスに関連付けられたフロー定義ファイルとを備える。リクエストのメッセージは、そのメッセージのサブジェクトに関するサブジェクトIDを含んでいる。フロー定義ファイルは、複数の異なるサブジェクトIDにそれぞれ対応した複数の定義センテンスを含んでおり、各定義センテンスは所定の1又はそれ以上のビジネスロジックのための実行スケジュールを記述している。フレームワークサービスは、メッセージングサービスからリクエストのメッセージを受け取ると、定義ファイル内の受信されたメッセージのサブジェクトIDに対応した定義センテンスを参照し、参照された定義センテンスに記述された実行スケジュールに従って、実行するべき1又はそれ以上のビジネスロジックを選択する。

好適な実施形態では、フレームワークシステムは、フレームワークサービスが稼動している間に、フロー定義ファイルを更新するフロー定義更新コンポーネントを更に備える。

好適な実施形態では、また、フロー定義ファイルには、一つの先行のビジネスロジックと少なくとも一つの後続のビジネスロジックとを含む複数のビジネスロジックの連係された実行のための連係実行スケジュールを記述した定義センテンスを含むことができる(勿論、連係実行スケジュールを定義した定義センテンスを含まなくてもよい)。その連係実行スケジュールは、後続のビジネスロジックの実行に関して同期方式と非同期方式の選択に関する連係モードを含んでいる。そして、フレームワークサービスは、連係実行スケジュールに従って複数のビジネスロジックを実行する場合、連係実行スケジュール内の連係モードに従って、先行のビジネスロジックの実行と同期的に又は非同期的に、後続のビジネスロジックを実行する。

好適な実施形態では、連係実行スケジュールは、先行のビジネスロジックに関する情報と、後続のビジネスロジックのための第2のリクエストのメッセージに関する情報とを含む。そして、フレームワークシステムは、連係実行スケジュールに従って複数のビジネスロジックを実行する場合、先行のビジネスロジックを実行した後、先行のビジネスロジックの実行結果を用いて第2のリクエストのメッセージを生成して、その第2のリクエストのメッセージをメッセージングサービスに送る。その後、フレームワークシステムは、メッセージングサービスから上記第2のリクエストのメッセージを受けると、その第2のリクエストのメッセージに対応する定義センテンスの実行スケジュールに従って、後続のビジネスロジックを実行する。

好適な実施形態では、また、メッセージングサービスが、前記第2のリクエストのメッセージを保証する為の不揮発性のメッセージキューを備える。このメッセージキューは、第2のリクエストメッセージがフレームワークサービスへ送られた後も、その第2のリクエストメッセージを消さずに保存する。そして、メッセージグサービスは、その不揮発性のメッセージキューで保存されている第2のリクエストのメッセージを、必要に応じて、フレームワークシステムへ再送信することができる。

本発明の別の観点に従うクライアントと通信可能に接続されるフレームワークシステムは、クライアントからのリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスとを備える。そして、メッセージングサービスは、上記リクエストとリプライのメッセージのようなP to P通信のメッセージだけでなく、クライアントとフレームワークサービスとの間のP to M通信のメッセージをも中継する。

好適な実施形態では、メッセージングサービスが、P to M通信のメッセージを一時的に待たせるためのリングバッファを有する。

好適な実施形態では、また、P to P通信のメッセージの各々には、メッセージ保証の要否に関する保証モードが含まれている。そして、メッセージングサービスは、メッセージ保証が不要なP to Ｐ通信のメッセージを一時的に待たせるための第1のメッセージキューと、メッセージ保証が必要なP to Ｐ通信のメッセージを一時的に待たせるための不揮発性の第2のメッセージキューとを有する。

本発明のまた別の観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、クライアントと接続された少なくとも一つのメッセージングサービスを含んだ、相互にメッシュ接続されている複数のメッセージングサービスと；複数のメッセージングサービスにそれぞれ接続された複数のフレームワークサービスとを備える。そして、複数のフレームワークサービスの各々は、予め定められたサブジェクトIDをもったリクエストのメッセージを待ち受け、その予め定められたサブジェクトIDをもったリクエストのメッセージを受信すると、受信されたリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力することができる。そして、上記複数のメッセージングサービスは、クライアントと上記複数のフレームワークサービスの間でのメッセージの中継、及び、上記複数のフレームワークシステム相互間でのメッセージの中継を行う。

好適な実施形態では、各メッセージングサービスが、他の1又はそれ以上のメッセージングサービスの稼動を監視し、他の或るメッセージングサービスについて正常な稼動を検出できなかった場合は、その正常に稼動してないメッセージングサービスへメッセージを中継する代わりに、他の正常に稼動しているメッセージングサービスへメッセージを中継する。

好適な実施形態では、また、各メッセージングサービスが、各々に接続されたフレームワークサービスの状態を監視し、監視された状態に応じて、クライアントからのリクエストのメッセージを上記フレームワークサービスに中継するか、他の何れかのメッセージングサービスに中継するかを、選択する。

好適な実施形態では、また、各メッセージングサービスは独自の管理テーブルを有し、各管理テーブルには、各メッセージングサービスに接続されたフレームワークシステムが待ち受けるメッセージのサブジェクトID、及び、各メッセージングサービスに接続された他の1又はそれ以上のメッセージングサービスがそれぞれ待ち受けるメッセージのサブジェクトIDが登録されている。そして、各メッセージングサービスは、メッセージを受信したとき、それ独自の管理テーブルを参照して、受信されたメッセージのサブジェクトIDにマッチするサブジェクトIDを待ち受けるフレームワークサービス又は他のメッセージングサービスを探し、見つかったフレームワークサービス又は他のメッセージングサービスへ、受信されたメッセージを中継する。

好適な実施形態では、さらに、各メッセージングサービスは、それ独自の管理テーブルの内容に基づいて、そのメッセージングサービスが待ち受けるメッセージのサブジェクトIDを、他の1又はそれ以上のメッセージングサービスに通知する。その通知を受けた他のメッセージングサービスの各々は、通知された内容が、それ独自の管理テーブルに未だ登録されていなければ、その通知内容を、それ独自の管理テーブルに追加登録する。

本発明の更に別の観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、クライアントからのリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスとを備える。クライアントからのリクエストのメッセージは所与の優先順位を有している。そして、メッセージングサービスは、上記リクエストのメッセージを一時的に待たせるためのメッセージキューと、メッセージキューの入出力を管理するキュー管理コンポーネントとを備える。キュー管理コンポーネントは、メッセージキューに複数のメッセージが蓄積されているとき、各メッセージの優先順位に応じて、複数のメッセージのメッセージキューからの出力順序を制御する優先モードと；メッセージキューに複数のメッセージが蓄積されているとき、メッセージキューから先に取り出されたメッセージの処理が前記フレームワークサービスにおいて完了するまで、メッセージキューに蓄積されている他のメッセージの取り出しを禁止するシーケンス保証モードとを備える。

以下、本発明の一実施形態を図面を参照して説明する。図１は、本実施形態の全体構成を示す。

本システムは、プレゼンテーション層１、ビジネスロジック層２、及びデータサービス層３から構成されている。

プレゼンテーション層１は、ウェブ(World Wide Web)クライアント１１、ウェブ（World Wide Web）サーバ１２、又はＶＢ（Visual Basic）クライアント１３を含んでいる。

ビジネスロジック層２には、本発明の原理に従うフレームワークアークテクチャ（この明細書では「RtFA: Real Time Framework Architecture」という）が適用されたサーバコンピュータシステムであるRtFAサーバ１４が設けられている。RtFAサーバ１４は、メッセージングサービスを行うサーバコンピュータシステム（以下、簡単に「メッセージングサービス」という）１５と、フレームワークサービスを行うサーバコンピュータシステム（以下、簡単に「フレームワークサービス」という）１６とを備えている。典型的には、メッセージングサービス１５とフレームワークサービス１６は、それぞれ、別のコンピュータマシン又は別のコンピュータマシンのセットを用いて具現化される。しかし、必ずしもそうでなければならないわけではなく、同一のコンピュータマシン又はコンピュータマシンのセットを用いて、メッセージングサービス１５とフレームワークサービス１６の双方がインプレメントされることも可能である。

メッセージングサービス１５は、クライアント１１，１３とRtFAサーバ１４間のメッセージのやり取りを制御する。すなわち、メッセージングサービス１５は、クライアント１１，１３から、或る処理のためのリクエストのメッセージを受信し、そのリクエストのメッセージを、リクエストされた処理を行なうことができるフレームワークサービス１６に渡す。また、メッセージングサービス１５は、フレームワークサービス１６から、実行された処理の結果を示すリプライのメッセージを受信し、更に、場合によっては、後続の追加の処理のための追加のリクエストのメッセージも受信する。そして、メッセージングサービス１５は、そのリプライのメッセージをクライアント１１，１３に送ったり、追加のリクエストのメッセージをフレームワークサービス１６に再び渡したりする。

メッセージングサービス１５によって取り扱われる全てのメッセージの各々には、そのメッセージのサブジェクト（例えば、仕入登録リクエスト、在庫更新リクエスト、買掛登録リクエストなど）を示す識別コードであるサブジェクトIDが含まれている。このサブジェクトIDは、後述するように、メッセージングサービス１５又はフレームワークサービス１６によって、そのメッセージの宛先を選択する目的に利用され、そのため、「宛先サブジェクトID」とも呼ばれる。

フレームワークサービス１６は、様々な種類のメッセージをそれぞれ処理するための複数のビジネスロジック(例えば、仕入処理ビジネスロジック、在庫処理ビジネスロジック、買掛処理ビジネスロジック、メッセージ変換ビジネスロジックなど)を有している。フレームワークサービス１６は、メッセージングサービス１５から或るメッセージを受け取ると、そのメッセージのサブジェクトIDからそのメッセージを処理するためのビジネスロジックを選び、その選んだビジネスロジックを呼び出す。呼び出されたビジネスロジックは、そのメッセージの内容に応じた処理を行い、データサービス層９のデータを更新する。メッセージングサービス１５及びフレームワークサービス１６のためのコンピュータプログ
ラムは、例えば、JAVA言語（商標）によって記述されている。
データサービス層３は、データベースサーバ（DBサーバ）１７を備えている。

ウェブクライアント１１とウェブサーバ１２の間にはHTTP又はソケットによる通信コネクションが確立され得る。ウェブクライアント１１とRtFAサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。VBクライアント１３とRtFAサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。また、ウェブサーバ１２とRtFAサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。更に、RtFAサーバ１４とDBサーバ１７との間にはJDBＣによる通信コネクションが確立され得る。

図２は、RtFAサーバ１４が取り扱うメッセージの構成を示す。

図２に示すように、メッセージ１０は、複数のサーバ制御項目と業務データとから構成される。サーバ制御項目は、RtFAサーバ１４を制御するための各種のデータであり、例えば、メッセージ種別、保証モード、優先順位、サブジェクトID（宛先サブジェクトID）及び送信元情報などが含まれている。

「メッセージ種別」は、そのメッセージがP to P（Point to Point）通信のメッセージであるか、P to M （ Point to Many）通信のメッセージであるかを区別する。ここで、P to P通信とは、或る１つのコンピュータシステムから別の１つのコンピュータシステムへとメッセージが送られる通信、つまり、1対１通信のことをいう。P to P 通信の一例は、或るクライアントからの仕入登録リクエストのメッセージを、仕入処理を実行する或る一つのフレームワークサービスへ送る場合である。一方、P to M通信とは、或る１つ又は複数のコンピュータシステムから別の複数のコンピュータシステムへとメッセージが送られる通信、つまり、１対複数又は複数対複数の通信のことをいう。P to M 通信の一例は、或る１つのフレームワークサービスからの在庫更新結果を示すメッセージを、フロントデスクの仕事を担う複数のクライアント端末へ送信する場合である。

「保証モード」は、メッセージ保証（すなわち、そのメッセージが確実に送信及び処理されることの保証）をする（"Ｇ"）か否か（"Ｎ"）を区別する。保証モードが"Ｎ"のメッセージを受信したとき、メッセージングサービス１５は、そのメッセージを、揮発性の半導体メモリを用いたメッセージキュー（以下、「メモリキュー」という）に入れる。一方、保証モードが"Ｇ"のメッセージを受信したとき、メッセージングサービス１５は、そのメッセージを、不揮発性のディスクストレージを用いたメッセージキュー（以下、「DB（データベース）キュー」という）に入れ、そのメッセージを送信した後も、そのメッセージをDBキューで保存しておく。従って、保証モードが"Ｇ"のメッセージについては、送信失敗やシステムダウンなどの問題が生じたとしても、後に再度、同じメッセージを送信することができる。

「優先順位」は、そのメッセージの処理の優先レベルを示す。例えば、ハイ（"Ｈ"）、ノーマル（"Ｎ"）及びロー（"Ｌ"）の3種類の優先順位がある。後述するように、メッセージングサービス１５は、メッセージキュー内で複数のメッセージが待っているとき、それらのメッセージをメッセージキューから取り出す順序を、それらのメッセージのそれぞれの優先順位に応じて制御することができる。

「サブジェクトID（宛先サブジェクトID）」は、既に述べたとおり、そのメッセージのサブジェクトの種別を示す識別コードである。後述するように、メッセージングサービス１５は、メッセージを受信すると、そのメッセージのサブジェクトIDに基づいて、そのメッセージの宛先となるべきコンピュータシステム（例えば、クライアント、フレームワークシステム、他のメッセージングサービスなど）を選択する。また、フレームワークサービス１６は、メッセージを受信すると、そのメッセージのサブジェクトIDに基づいて、そのメッセージを処理するために呼び出すべきビジネスロジックを選択する。

「送信元情報」は、そのメッセージの送信元のサブジェクトやＩＰアドレスやコンピュータ名などを表す。

図３は、RtFAサーバ１４の構成図である。

既に参照した図１では、１つのRtFAサーバ１４しか示されていなかった。しかし、実際には、図３に示すように、複数のRtFAサーバ１４を設けることができる。図３に示す例では、２つのRtFAサーバ１４が設けられているが、もっと多くのRtFAサーバ１４を設けることができる。

図３に示すように、各RtFAサーバ１４には、一つのメッセージングサービス１５と、１又は複数のフレームワークサービス１６が設けられ、メッセージングサービス１５とフレームワークサービス１６は相互に通信可能に接続されている。メッセージングサービス１５は、また、１又は複数のクライアント１１，１３とも通信可能に接続されている。メッセージングサービス１５は、クライアント１１，１３及びフレームワークサービス１６とそれぞれ通信する複数のスレッド１７１を並列に処理している。

複数のRtFAサーバ１４が存在するので、メッセージングサービス１５とフレームワークサービス１６の組は複数組存在している。そして、複数のRtFAサーバ１４のメッセージングサービス１５は、相互に通信可能に接続されている。各RtFAサーバ−１４のメッセージングサービス１５は、他のRtFAサーバ１４のメッセージングサービス１５との通信を処理するスレッド１７１も備えている。各メッセージングサービス１５が持つ複数の通信スレッド１７１は、それぞれキープアライブ機能を有し、この機能により、そのメッセージングサービス１５にコネクションされたクライアント１１，１３、他のメッセージングサービス１５、及びフレームワークサービス１６と相互の正常な稼動を確認しあっている。

また、各メッセージングサービス１５には、図４に例示するような管理テーブル１８が関連付けられている。管理テーブル１８には、そのメッセージングサービス１５が伝達すべきメッセージの経路、換言すれば、そのメッセージングサービス１５が取り扱う様々なメッセージの送り先、が管理される。図４に示すように、管理テーブル１８には、そのメッセージングサービス１５に接続された全てのコンピュータシステム（クライアント１１，１３、他のメッセージングサービス１５、及びフレームワークサービス１６）の各々について、種別、コンピュータID、IPアドレス、P to PサブジェクトID、P to MサブジェクトID及び処理中フラグなどが登録される。

「種別」は、そのコンピュータシステムの種別、例えば、フレームワークサービス（Ｆ）、メッセージングサービス（Ｍ）、クライアント端末ターミナル（Ｔ）の区別を示す。

「コンピュータID」及び「IPアドレス」は、そのコンピュータシステムの固有の識別コードとIPアドレスを示す。

「P to PサブジェクトID」は、そのコンピュータシステムが待ち受ける（つまり、そのコンピュータシステムが、そのメッセージの宛先になり得る）P to P 通信用のメッセージのサブジェクトID（宛先サブジェクトID）を示す。各コンピュータシステムごとに、複数のP to PサブジェクトIDを登録することができる。

「P to MサブジェクトID」は、そのコンピュータシステムが待ち受ける（つまり、そのコンピュータシステムが、そのメッセージの宛先になり得る）P to M 通信用のメッセージのサブジェクトID（宛先サブジェクトID）を示す。各コンピュータシステムごとに、複数のP to MサブジェクトIDを登録することができる。

「処理中フラグ」は、そのコンピュータシステムとの通信のためのスレッド１７１が、P to P 通信の処理中である（「１」）か否（「０」）かを示す。

図４に示した管理テーブル１８の登録内容は、図３中の左側のメッセージングサービスMes1の場合の例であり、そこには、左側のメッセージングサービスMes1に接続された全てのコンピュータシステム、すなわち、２つのフレームワークサービスFrm1、Frm2、右側のメッセージングサービスMes2及び３つのクライアント端末PC1、Pc2及びPC3が登録されている。この例によれば、１番目のフレームワークサービスFrm1は、P to P 通信に関しては"A"、"B"、"C"及び"D"というサブジェクトIDをそれぞれもった４種類のメッセージを待ち受けており、また、P to M 通信に関しては"O"、"P"、"Q"及び"R"というサブジェクトIDをそれぞれもった４種類のメッセージを待ち受けている。また、図中右側のメッセージングサービスMes2は、左側のメッセージングサービスMes1からのP to P 通信のメッセージとして、"D"、"E"、"F"、"H"、"I"及び"J"というサブジェクトIDをそれぞれもった７種類のメッセージを待ち受けており、また、左側のメッセージングサービスMes1からのP to M 通信のメッセージとして"P"、"Q"、"R"、"S"、"T"及び"U"というサブジェクトIDをそれぞれもった６種類のメッセージを待ち受けている。

再び図３を参照して、各メッセージングサービス１５は、メッセージを受信すると、そのメッセージがP to P 通信のものかP to M 通信のものかを判断する。P to P 通信のメッセージを受信したときは、メッセージングサービス１５は、そのメッセージングサービス１５に関連付けられている図４に例示したような管理テーブル１８を参照して、その受信メッセージのサブジェクトIDとマッチするP to PサブジェクトIDのメッセージを待ち受けているコンピュータシステムを探し、見つかった１以上のコンピュータシステムの中から処理中フラグが"０"である１つのコンピュータシステムを選び、そして、選ばれた１つのコンピュータシステムにその受信メッセージを送信する。また、P to M 通信のメッセージを受信したときは、メッセージングサービス１５は、そのメッセージングサービス１５に関連付けられている図４に示したような管理テーブル１８を参照して、その受信メッセージのサブジェクトIDとマッチするP to MサブジェクトIDのメッセージを待ち受けてるコンピュータシステムを全て選び、そして、選ばれた全てのコンピュータシステムにそのメッセージを送信する。

図５は、複数のRtFAサーバ間の接続構成図である。図６は、複数のRtFAサーバ内のメッセージングサービスとフレームワークサービスの接続構成図である。

図５の上段又は下段に示すように、各RtFAサーバ１４は他の全てのRtFAサーバ１４と相互に通信可能に接続されている。すなわち、図６に示すように、各RtFAサーバ１４のメッセージングサービス１５が、他の全てのRtFAサーバ１４のメッセージングサービス１５と相互に通信可能に接続されている。このように複数のコンポーネントの各々が他の全てのコンポーネントと通信可能に接続されることを「メッシュ接続」という。また、図６に示すように、各メッセージングサービス１５に対しては複数のフレームワークサービス１６を直接連絡させることも可能である。

このように複数のメッセージングサービス１５のメッシュ接続の下で、各メッセージサービス１５は、所定の時期、例えばその起動時に、上述したキープアライブ機能を実行する。すなわち、各メッセージングサービス１５は、起動すると、自分の管理テーブル１８に既に登録されている他のメッセージングサービスの全てと逐次に接続して、自分と接続されているフレームワークシステム１６及びクライアント１１，１３が待ち受けるメッセージのサブジェクトIDを、接続された他のメッセージングサービスの全てに通知する。通知されたサブジェクトIDは、そのメッセージングサービス１５が他のメッセージングサービスから待ち受けるメッセージのサブジェクトIDとして、他のメッセージングサービスの管理テーブルに登録される。また、各メッセージングサービス１５は、他のメッセージングサービスと接続しようとしたときに接続できなかった場合には、その後に一定間隔で複数回接続をリトライする。また、各メッセージサービス１５は、自分の管理テーブル１８に未だ登録されていない他のメッセージングサービスから接続要求を受けたときには、その未登録のメッセージングサービスと接続して、未登録のメッセージングサービスとそれぞれが待ち受けるサブジェクトIDなどを交換し合い、そして、そのメッセージングサービスを自分の管理テーブル１８に登録する。このようなキープアライブ機能のおかげで、特定のメッセージングシステム１５が正常に稼動してない(例えば、システムダウンした)場合には、他の正常に稼動している各メッセージングサービス１５は、その正常に稼動してない特定のメッセージングシステム１５をメッセージの中継経路から除外し、自分の管理テーブル１８を参照して、自動的に別の中継経路を選択することができる。

次に、図７乃至図９に基づいて、メッセージングサービス１５が提供する通信サービスの種類を説明する。メッセージングサービス１５が提供するデータ配信サービスには、P toM (1対多) 通信処理と、P to P (1対１) 通信処理の2種類がある。

P to M通信処理は、前述したように、図４に例示したような管理テーブル１８に登録されている各コンピュータシステムのP to MサブジェクトIDに基づいて、メッセージングサービス１５が、受信したP to Mメッセージを、それを待ち受ける全てのコンピュータシステムに配信する処理である。例えば、マーケット情報が更新される都度、更新されたマーケット情報のメッセージを、１乃至ｎ個のRtFAサーバからｎ個のクライアントに配信する場合に、P to M通信処理が行われる。

一方、P to P通信処理は、前述したように、図４に例示したような管理テーブル１８に登録されている各コンピュータシステムのP to PサブジェクトIDに基づいて、メッセージングサービス１５が、受信したP to Pメッセージを、それを待ち受けるコンピュータシステムの中の一つに送信する処理である。例えば、クライアントからの或る処理のためのリクエストのメッセージを、その処理を行うビジネスロジックを有した一つのフレームワークサービスに送る場合に、P to P通信処理が行われる。

図７は、P to M通信処理のメッセージ中継方法の一例を示している。パブリッシャーとしての或るフレームワークサービス１６から出力された或るP to Mメッセージは、そのメッセージを待ち受ける全てのメッセージングサービス１５に配信され、そして、それらのメッセージングサービス１５から、そのメッセージを待ち受ける全てのクライアント１１、１３に配信される。

図８は、P to M通信処理の一例を示すフローチャートである。まず、サブスクライバの一つであるクライアントＴ１は、所定のメッセージングサービスMes1との間で、ソケットによるコネクションを確立する。また、クライアントＴ１から当該メッセージングサービスMes1に対し自己が待ち受けるP to MメッセージのサブジェクトID"Ｘ"を登録する。当該メッセージングサービスMes1は、自己に関連付けられた管理テーブル１８に、クライアントＴ１のP to MサブジェクトID"Ｘ"を追加する。一方、クライアントＴ１は、メッセージングサービスMes1からのメッセージの配信を待つ。その後、メッセージングサービスMes1に接続する他のメッセージングサービスMes2,Mes3が起動したとき、メッセージングサービスMes1の管理テーブル１８に既に登録されたクライアントＴ１のP to MサブジェクトID"Ｘ"は、他のメッセージングサービスMes2及びMes3にも通知されて、それらの管理テーブル１８に、メッセージングサービスMes1のP to MサブジェクトIDとして"Ｘ"が追加される。

ここで、パブリッシャーとしてのフレームワークサービスFrm3からサブジェクトID"Ｘ"をもつP to Mメッセージが配信されると、これを受けたメッセージングサービスMes3は、自己に関連付けられた管理テーブル１８を参照し、サブジェクトID"Ｘ"を待ち受ける全てのメッセージングサービスMes1及びMes2をピックアップし、それらに当該メッセージを引き渡す。

クライアントＴ１とコネクトされたメッセージングサービスMes1は、当該メッセージを受信すると、自己に関連付けられた管理テーブル１８からサブジェクトID"Ｘ"を待ち受けるクライアントＴ１をピックアップし、当該メッセージをそのクライアントＴ１に配信する。

図示してないが、各フレームワークサービスも、そのフレームワークサービスと直接連絡可能なメッセージングサービスへ、そのフレームワークサービスが待ち受けるP to MメッセージのサブジェクトIDを通知する。それにより、そのフレームワークサービスが待ち受けるP to M サブジェクトIDが、そのメッセージングサービスの管理テーブルに登録される。その後、そのメッセージングサービスは、その管理テーブルに登録されたフレームワークサービスのP to MサブジェクトIDを、そのメッセージングサービスが待ち受けるP to MサブジェクトIDとして、他の全てのメッセージングサービスに通知する。これにより、他の全てのメッセージングサービスの管理テーブルにも、そのフレームワークサービスが待ち受けるP to MサブジェクトIDが登録されることになる。結果として、そのフレームワークサービスは、P to MサブジェクトIDをもったメッセージを、いずれのメッセージングサービスからも受信できるようになる。

次に図９は、P to P通信処理を示すフローチャートである。

上述したP to Ｍ通信のサブジェクトIDの管理テーブルへの登録と同様に、各メッセージングサービスの管理テーブルには、そのメッセージングサービスが直接連絡可能なクライアント及びフレームワークサービスがそれぞれ待ち受けるP to PサブジェクトID、並びに、他の全てのメッセージングサービスがそれぞれ待ち受けるP to PサブジェクトIDが予め自動的に登録されている。

そのような状態において、図９に示すように、まず或るクライアントＰＣ１は、所定のメッセージングサービスMes1とコネクションを確立する。

続いて、クライアントＰＣ１から或るサブジェクトID"Ａ"を持ったP to Pのリクエストメッセージが送信されると、これを受信したメッセージングサービスMes1は、自己の管理テーブル１８を参照して、そのサブジェクトID"Ａ"を待ち受けるコンピュータシステムの中の一つ、例えば、フレームワークサービスＦｒｍ１を選び、それに当該リクエストメッセージを引き渡す（矢印(1)）。フレームワークサービスＦｒｍ１は、引き受けたリクエストメッセージのサブジェクトID"Ａ"に対応したビジネスロジックを呼び出して、そのメッセージの処理を実行し、その実行結果を示すリプライメッセージをメッセージングサービスMes1に戻す（矢印(3)）。そして、メッセージングサービスMes1は、そのリプライメッセージをクライアントＰＣ１に返信する。そのリプライメッセージを取得したクライアントＰＣ１は、メッセージングサービスMes1とのコネクションを開放する。

或いは、メッセージングサービスMes1は、クライアントＰＣ１から受信したサブジェクトID"Ａ"のリクエストメッセージを、上記の例のようにフレームワークサービスＦｒｍ１へ送る代わりに、サブジェクトID"Ａ"を待ち受ける他のメッセージングサービスMes2へ送る（矢印(2)）こともできる。例えば、フレームワークサービスＦｒｍ１が処理中であるが、メッセージングサービスMes2は処理中でないときには、そのようなことが行われる。その場合、メッセージングサービスMes2は、そのリクエストメッセージを受けると、自己の管理テーブル１８を参照して、サブジェクトID"Ａ"を待ち受ける一つのコンピュータシステム、例えば、フレームワークシステムＦｒｍ２を選んで、それに当該リクエストメッセージを送って処理させる（矢印(4)）。フレームワークシステムＦｒｍ２から処理結果のリプライメッセージが返されると（矢印(5)）、メッセージングサービスMes2は、そのリプライメッセージをメッセージングサービスMes1に返し(矢印(6))、そして、メッセージングサービスMes1は、そのリプライメッセージをクライアントＰＣ１へ返す。

上述したように、メッセージングサービス１５は、自己と直接連絡可能なフレームワークサービス１６へメッセージを送るだけでなく、他のメッセージングサービスを経由して他のフレームワークサービスへメッセージを送ることも可能である。これにより、複数のRtFAサーバ１４間のロードバランシング（負荷平衡）が可能である。

図１０は、メッセージングサービスがもつロードバランシング機能の説明図である。

図１０に示すように、各RtFAサーバ１４において、各フレームワークサービス１６は、メッセージングサービス１５と連絡する複数のスレッド１９を並列に処理している。また、各メッセージングサービス１５は、クライアントから受信したメッセージを一時的に保持するメッセージキュー１５ａを備えている。

各メッセージングサービス１５のキュー１５ａに蓄積された各メッセージは、そのメッセージングサービス１５に関連付けられた管理テーブルに従って、そのメッセージのサブジェクトIDに対応する何れかのフレームワークサービス１６に引き渡される。その場合、メッセージングサービス１５は、自己に直接連絡可能で且つそのサブジェクトIDを待ち受ける特定のフレームワークサービス１６に、そのメッセージを引き渡すことができる。しかし、その時、その特定のフレームワークサービス１６のスレッド１９に空きが無い(つまり、処理中である)場合、メッセージングサービス１５は、その処理中のフレームワークサービス１６ではなく、そのサブジェクトIDを待ち受ける他のメッセージングサービス１５に、そのメッセージを引渡す。そのメッセージを受け取った当該他のメッセージングサービス１５は、当該他のメッセージングサービス１６が直接に連絡可能であり且つそのサブジェクトIDを待ち受ける特定のフレームワークサービス１６に、そのメッセージを引き渡す。このようなメッセージ中継を可能にするために、各メッセージングサービス１５は、自分のメッセージキュー１５ａを常時監視し、そのメッセージキュー１５ａに処理待ちのメッセージが溜まっている場合は、直ちにそのキューからメッセージを取り出し、自分の管理テーブルを参照してそのメッセージの送り先をてきぱきと決定して、そのメッセージを送り出す。これにより、複数のRtFAサーバのロードバランスが適正化される。結果として、どのメッセージも可能な限り早期に処理され、よって、従来は夜間にバッチ処理で行われていたバックオフィスの仕事が、リアルタイムに近い態様で早期に実行できる。

続いて、フレームワークサービス１６の構成について説明する。

図１１は、フレームワークサービス１６の構成を示す。

フレームワークサービス１６の実体は、複数のフレームワークスレッド２５による並列処理で構成されている。各フレームワークスレッド２５は、予め準備された一群のビジネスロジック２０にアクセスし、そして、メッセージングサービス１５から引き渡されたメッセージのサブジェクトIDに対応する特定のビジネスロジック２２をロードして実行する。ここで、ビジネスロジックとは、例えばJAVAコードでプログラムされたプロセスであって、それぞれ固有のメッセージ処理を実行するものである。主要なビジネスロジックの多くは、データベースサーバ１７に管理されるデータベース２１に対し、メッセージの内容に応じた所定の操作を要求する。

図１２は、フレームワークサービス１６の動作説明図である。

フレームワークサービス１６のビジネスロジックの動作方式には、大きく分けて同期方式と、非同期方式の２種類がある。フレームワークサービス１６は、クライアントからの或るリクエストメッセージに応答して、ただ１つのビジネスロジックのみを実行する場合がある。また、フレームワークサービス１６は、リクエストメッセージに直接的に応答して１つのビジネスロジックを実行し、それに連係して、後続の1以上のビジネスロジックを実行する場合もある。図１２には、クライアント１１，１３からの仕入登録リクエストのメッセージに直接的に応答して仕入処理のビジネスロジックが実行され、これに連係して、在庫処理及び会計処理という２つの後続のビジネスロジックが実行される例が示されている。

クライアントからのリクエストメッセージに直接的に応答してただ一つのビジネスロジックのみを実行する場合、フレームワークサービス１６は、その唯一のビジネスロジックを通常は同期方式で実行し、そして、その実行結果を示すリプライメッセージをクライアントへ返す。

一方、クライアントからのリクエストメッセージに直接的に応答して１つのビジネスロジックを実行した後、これに連係して、後続の1以上のビジネスロジックを実行する場合、フレームワークサービス１６は、最初の一つのビジネスロジックは通常は同期方式で実行するが、２番目以降のビジネスロジックは同期方式で実行することもできるし、非同期方式で実行することもできる。図１２には、最初の仕入処理のビジネスロジックのみが同期方式で実行され、後続の在庫処理と会計処理のビジネスロジックは非同期方式で実行される例が示されている。図１２の例のように複数のビジネスロジックが実行される場合、フレームワークサービス１６は、同期方式で実行したビジネスロジックの全てが完了すると、その実行結果を示すリプライメッセージをクライアントへ返す。非同期方式で実行されるべきビジネスロジックは、クライアントからは切り離されたバックグラウンドで（つまり、クライアントからはオフラインで）実行される。

図１２に示すように、フレームワークサービス１６は、フロー定義ファイル２３を有しており、そこには、そのフレームワークサービス１６によるビジネスロジックの実行スケジュール（最初に実行すべき１つのビジネスロジック名、連係する後続の1又はそれ以上のビジネスロジックがある場合にはその後続のビジネスロジックへ渡すメッセージのサブジェクトID及び連係方式（同期か非同期か）、など）が、様々なメッセージのサブジェクトIDごとに定義されている。フレームワークサービス１６は、一つのメッセージを受け取ると、フロー定義ファイル２３を参照して、その受信されたメッセージのサブジェクトIDに対応するビジネスロジック実行スケジュールを選択し、選択されたスケジュールに従って１以上のビジネスロジックを実行する。その選択されたスケジュールには、少なくとも、そのメッセージに応答して直接的に実行されるべき１つのビジネスロジックが記述されているから、フレームワークサービスは、まず、その１つのビジネスロジックをロードして実行する。もし、その選択されたスケジュールに、更に、連係する後続の1以上のビジネスと連係方式とが記述されていたなら、フレームワークサービスは、最初のビジネスロジックの実行後に、その後続のビジネスロジックを、その連係方式で（つまり、同期的に又は非同期的に）実行することになる。なお、先行のビジネスロジックと後続のビジネスロジックは、同一のフレームワークサービスによって実行される場合もあるが、上述したロードバランシングにより別のフレームワークサービスによって実行される場合もある。

図１３は、フロー定義ファイル２３の簡単な例を示す。

図１３に示すように、フロー定義ファイル２３には、サブジェクトIDごとにビジネスロジック実行スケジュールをそれぞれ記述した複数のセンテンス２３１、２３２、２３３、２３４が存在する。フロー定義ファイル２３は、例えばテキストファイルであり、よって、定義センテンス２３１、２３２、２３３、２３４の追加、削除、変更などの編集は、テキストエディタなどを用いて簡単に行える。

図１３の一番上の定義センテンス２３１内に説明されているように、各定義センテンスは、セミコロン"；"で区切られた複数のサブセンテンスから構成される。最初のサブセンテンスには、入力サブジェクトID、ログキュー名、実行ビジネスロジック名などが含まれる。2番目以降の各サブセンテンスには、メッセージ変換ビジネスロジック名、出力サブジェクトID、連係モードなどが含まれる。最初のサブセンテンスは、メッセージに直接的に応答して実行されるべき１つのビジネスロジックに関するものであり、これは全ての定義センテンスに必ず記述される。2番目以降のサブセンテンスは、最初のビジネスロジックに連携して実行される後続の1以上のビジネスロジックに関するものであり、よって、後続のビジネスネスロジックがある場合にのみ記述される。

最初のサブセンテンスの項目の意味は次のとおりである。

ここで、「入力サブジェクトID」は、フレームワークシステムが受信したメッセージのサブジェクトIDである。

「ログキュー名」は、その受信したメッセージをログに書く場合に用いられるログキューの名称である。例えば、"@DEF"はデフォルトのログキューを用いることを意味し、"@NONE"はログに書かれないことを意味する。

「実行ビジネスロジック名」は、そのメッセージに直接応答して実行されるべきビジネスロジックの名称である。図示の定義センテンス２３２〜２３４の例では、入力サブジェクトIDと同じコードが用いられている。

2番目以降の各サブセンテンスの項目の意味は次のとおりである。

「メッセージ変換ビジネスロジック名」は、先行のビジネスロジックの処理結果データを後続のビジネスロジックに渡されるメッセージに変換するために実行されるメッセージ変換ビジネスロジックの名称である。メッセージ変換が不要な場合、ここには"@NONE"と書かれる。

「出力サブジェクトID」は、後続のビジネスロジックに渡されるメッセージのサブジェクトIDである。

「連係モード」は、後続のビジネスロジックを同期方式で実行するか非同期方式で実行するかを示す。例えば、"ＳＹＮＣ"は同期方式を意味し、"ＡＳＹＮＣ"は非同期方式を意味する。

図１３の2番目の定義センテンス２３２は次のスケジュール(1)を例示している。

(1) "BuySelBuy"というサブジェクトIDのメッセージ(例えば、仕入検索リクエスト)に応答して、"BuySelBuy"という名称のビジネスロジック（例えば、仕入検索処理）を実行する。

3番目の定義センテンス２３３は、次のスケジュール(1)〜(3)を例示している。

(1) "BuyUpdBuy"というサブジェクトIDのメッセージ(例えば、仕入更新リクエスト)に応答して、まず、"BuyUpdBuy"という名称のビジネスロジック（例えば、仕入更新処理）を実行する。

(2) 次に、"CnvBuyUpdBuy"という名称の変換ビジネスロジックを用いて、先行する"BuyUpdBuy"ビジネスロジックの出力データのフォーマットを変換して、"InvUpdInv"というサブジェクトIDをもったメッセージ(例えば、在庫更新リクエスト)を作成してメッセージサービスへ出力する。

(3) 出力された"InvUpdInv"というメッセージを処理することになる後続のビジネスロジック(例えば、在庫更新処理)は、同期的に実行される。

さらに、４番目の定義センテンス２３４は、次のスケジュール(1)〜(5)を例示している。

(1) "BuyInsBuy"というサブジェクトIDのメッセージ(例えば、仕入検品更新リクエスト)に応答して、まず、"BuyInsBuy"という名称のビジネスロジック（例えば、仕入検品更新処理）を実行する。

(2) 次に、"CnvBuyInsBuy1"という名称の変換ビジネスロジックを用いて、先行する"BuyInsBuy "ビジネスロジックの出力データのフォーマットを変換して、"InvUpdInv"というサブジェクトIDをもったメッセージ(例えば、在庫更新リクエスト)を作成してメッセージサービスへ出力する。

(3) 出力された"InvUpdInv"というメッセージを処理することになる後続のビジネスロジック(例えば、在庫更新処理)は、非同期的に実行される。

(4) また、"CnvBuyInsBuy２"という名称の変換ビジネスロジックを用いて、先行する"BuyInsBuy "ビジネスロジックの出力データのフォーマットを変換して、"AccDbtBuy"というサブジェクトIDをもったメッセージ(例えば、買掛金登録リクエスト)を作成してメッセージサービスへ出力する。

(5) 出力された"AccDbtBuy"というメッセージを受け取る後続のビジネスロジック(例えば、買掛金登録処理)は、非同期的に実行される。

再び図１２を参照する。各フレームワークサービス１６は、それに関連付けられたフロー定義ファイル２３を参照することにより、処理対象のメッセージに対応するビジネスロジック２２を選択し実行することができ、また、後続処理の必要性を判断し、必要であれば、後続処理のためのリクエストメッセージを作成してメッセージングサービス１５へ戻すことができる。

ここで、一のフレームワークスレッドによる処理の後続処理として、他のフレームワークスレッドによる処理を非同期的に行わせる場合、フレームワークサービス１６は、先行のフレームワークスレッドでのビジネスロジックによる処理のリザルト（後続処理のためのリクエストメッセージ）を一度メッセージングサービス１５のキュー１５ａにインプットし、その後、他のフレームワークスレッドがメッセージングサービス１５のキュー１５ａからそのリクエストメッセージをゲットすることによって、後続処理を行う。ここで、先行の処理を行うフレームワークシステム１６と、後続の処理を行なうフレームワークシステム１６は、同じ場合もあるし、異なる場合もある。各種の処理をどのフレームワークシステム１６に割り当てるかということは、既に説明したメッセージングサービスのロードバランシング機能によって制御される。

各フレームワークサービス１６は、メッセージドリブンの構成を採っている。即ち、メッセージングサービス１５からのメッセージの引渡しをトリガーとしてビジネスロジックのロード及びビジネスロジックによる処理を実行するようになっている。

以上説明した本実施形態によると、フレームワークサービスのビジネスロジックの連係方法に同期方式と非同期方式を用意し、随時に簡単に書き換え可能なフロー定義ファイルの記述によってビジネスロジックの実行スケジュールを制御できるので、複雑なビジネスロジックフローを定義し、また必要に応じて変更することが容易である。

また、上記実施形態では、メッセージングサービスをメッシュ接続すると共に、キープアライブ機能によって、メッセージングサービス相互間、メッセージングサービスとクライアントとの間、及びメッセージングサービスとフレームワークサービスとの間で、相互にステータス(待ち受けるメッセージのサブジェクトID、処理中か否か、など)を通知し合う。そして、各メッセージングサービスは、周囲のクライアント、フレームワークサービス及び他のメッセージングサービスの現在のステータスを、管理テーブルに記憶している。それにより、いずれのRtFAサーバがダウンした場合でも、各メッセージングサービスは、正常に使えるメッセージの中継経路を自動的に選択し、メッセージを正しいシステムへ伝えることができる。結果として、フォルトトレラント性が向上し、システムの稼動の信頼性が向上し、システムの拡張が容易になり、更に、システムメンテナンスも容易に行うことができる。

また、メッセージングサービスは、P to P通信とPtoM通信のような複数種類のデータ配信方法を備え、管理テーブルに登録されているステータスに応じて、どのメッセージをどのコンピュータシステムにどのデータ配信方法で送るかというメッセージングスケジュールを自動的に選択することができる。その結果、柔軟なメッセージングサービスを提供することができる。

また、メッセージングサービスのロードバランシング機能により、複数のRtFAサーバの負荷バランスを自動的に調整することができ、高いパフォーマンスを提供することができる。

ここで、本発明の範囲は、本実施形態に限られない。例えば、JAVAベース以外のプラットフォームを用いることによっても同等のシステムの実現は可能である。また、メッセージングサービスの上述した特徴と、フレームワークサービスの上述した特徴とは、上述した実施形態のように組み合わされている必要は、必ずしも無い。

以下、上記実施形態に具備される幾つかの詳細な機能を説明する。

図１４は、フロー定義ファイル２３の更新システムを示すブロック図である。

フレームワークサービス１６は、定義ファイル２３を更新するためのプログラムモジュールである定義ファイル更新モジュール１０１を備え、この更新モジュール１０１は、外部からリロードコマンド１１１を受付けると、フレームワークサービス１６のメインメモリ１０３内にロードされている現在使用中の定義ファイル２３を、そこに矢印１１３で示すように外部記憶装置(例えば、ディスクストレージ１０７に記憶されている新しい定義ファイル１０９を上書きすることで、更新する。ディスクストレージ１０７内の新しい定義ファイル１０９は、テキストエディタ１０５などを用いて容易に編集することができる。所望の時に、上述したリロードコマンド１１１を入力することで、メインメモリ１０３内の定義ファイル２３が、編集された新しい定義ファイル１０９と同じ内容に更新される。これにより、フレームワークサービス１６の稼動中であっても所望の時に、定義ファイル２３の内容を書き換えて、これをフレームワークサービス１６の以後の動作に反映させることができる。従って、実行するビジネスロジック２２の種類の変更や、後続の処理を行なうか否か、又は、複数のビジネスロジックの連係した動作を同期的に行うか、非同期的に行うか、といった処理スケジュール変更を、システムを稼動させたままの状態で行うことができる。

図１５は、フレームワークサービスのメッセージ変換処理機能を示す。

フレームワークサービス１６のためのコンピュータプログラムは例えばJAVA言語で構築される。図１５に示すように、フレームワークサービス１６は、入力メッセージのフォーマット変換を行うための入力変換機能１０２と、出力メッセージのフォーマット変換を行うための出力変換機能１０３とを備えている。入力変換機能１０２は、メッセージングサービス１５からの例えばXMLファイルの形式の入力メッセージを、JAVAのオブジェクトの形式に変換する。出力変換機能１０３は、メッセージングサービス１５に出力するJAVAのオブジェクトの形式のメッセージを、XML形式に変換する。入力変換機能１０２は、XMLのDTD（文書型定義）の記述に基づいてJAVAクラスのメンバ変数を取得し、これをインスタンス化することによってJAVAオブジェクト化したメッセージを得る。また、出力変換機能１０３は、JAVAクラスのメンバ変数に基づいてXMLのDTDを形成し、XML化したメッセージを得る。

図１６は、メッセージングサービスのメッセージキューの構成を示す。

上述の説明では、メッセージキュー１５ａを単一のキューであるかのごとくに説明した。しかし、実際には、図１６に示すように、メッセージキュー１５ａには３種類のキュー、すなわち、メモリキュー１５３とリングバッファ１５４とDB(データベース)キュー１５５が含まれている。メモリキュー１５３とリングバッファ１５４は、RAM１５１のような高速アクセスが可能な記憶装置に設けられる。DBキュー１５５は、ハードディスク（HDD）のよう不揮発性の大容量の記憶装置に設けられる。

メモリキュー１５３は、メッセージングサービスがクライアントから受信したP to Pのリクエストメッセージのように、そのメッセージを処理した結果を受け取る相手が存在し、メッセージの保証が不要であるというメッセージを、一時的に待たせるために使用される。一方、DBキュー１５５は、メッセージングサービスがフレームワークサービスから受信した非同期の後続処理のためのリクエストメッセージのように、メッセージの保証が必要なメッセージを、一時的に待たせるために使用される。メッセージの保証が必要か否かは、図２に示したメッセージ１０の構成中の「保証モード」で判断される。

リングバッファ１５４は、P to Ｍ通信のメッセージを一時的に待たせるために使用される。各コンピュータシステムは、リンクバッファ１５４を巡回しながらリングバッファ１５４から自分の待ち受けるメッセージを見つけ出して取っていくことができる。図１６では、リングバッファ１５４は一つのバッファのごとくに示されているが、実際には、"Ｈ"、"Ｎ"及び"Ｌ"の3種類の優先順位にそれぞれ対応した３つのリングバッファのセットである。

DBキュー１５５は、メッセージングサービスがフレームワークサービスから受信した後続処理のためのリクエストメッセージのように、メッセージの保証が必要なメッセージを、一時的に待たせるために使用される。

メッセージグサービスは、上述したキュー１５３、１５４、１５５に対するメッセージの書き込みと読み出しを制御するメッセージキュー管理機能１０４を有する。メッセージキュー管理機能１０４は、メモリキュー１５３をDBキュー１５５より優先して調べ、メモリキュー１５３にP to Pメッセージが有れば、そのメッセージをメモリキュー１５３から取り出して、それを待ち受ける一つのコンピュータシステムへそのメッセージを送る。また、もしメモリキュー１５３にP to Pメッセージが１つも無ければ、メッセージキュー管理機能１０４は、DBキュー１５５を調べ、DBキュー１５５内にP to Pメッセージが有れば、そのメッセージをDBキュー１５５から読み、それを待ち受ける一つのコンピュータシステムへそのメッセージを送る。

メッセージキュー管理機能１０４は、図１６に示すように、DBキュー１５５内のメッセージＭに対しては、そのメッセージの処理状態を示すステータス情報Ｓを付加し、そのメッセージが処理されればステータス情報Ｓを「未処理」から「処理済」へと書き換える。また、そのメッセージの処理に関してエラーが生じれば、ステータス情報Ｓを「エラー」とする。エラーの原因としては、データ不整合、プログラムロジックのミスなどがある。DBキュー１５５に一旦入れられたメッセージは、システムダウンやエラーなどの問題が発生したとしても、消されずにDBキュー１５５内に保存される。

メッセージキュー管理機能１０４は、「エラー」のステータス情報Ｓを「未処理」に書き換える機能を有する。そして、システムダウンやエラーなどの問題が発生した場合、後に、メッセージキュー管理機能１０４は、ステータス情報Ｓが「未処理」のメッセージを再度読み出して再送信する。それにより、メッセージの確実な処理が保証される。また、エラーになったメッセージのステータス情報Ｓを追うことにより、エラーの原因究明も可能である。

また、メッセージキューの管理機能１０４は、外部コマンドに応じて、「エラー」のステータス情報Ｓを「処理済」に書き換える機能も備えていている。例えば、システムの状況によっては、エラーステータスのメッセージを未処理ステータスに変更して再出力することが適切でない場合がある。また、メッセージに生じたエラーの程度によっては、フレームワークサービスに再出力して処理させるよりも、コマンド入力により当該メッセージに修正を加えた方が適切な場合もある。このような場合、「エラー」のステータス情報Ｓを「処理済」に書き換える機能が利用される。上述した「エラー」のステータス情報Ｓを「未処理」に書き換える機能と、「処理済」に書き換える機能とは、任意に選択することができる。

さらに、メッセージキュー管理機能１０４は、管理テーブル１８（図４）に登録されている全てのコンピュータシステムの各々ごとに、リングバッファ１５５の読みしアドレスポインタを有し、各コンピュータシステム用の読み出しアドレスポインタでリングバッファ１５５中を巡回しながら、そのコンピュータシステムが待ち受けるP to Ｍメッセージをリングバッファ１５５から見つけ出し、その見つかったP to Ｍメッセージを読んで、そのコンピュータシステムへ送る。

図１７及び図１８は、メッセージキュー管理機能１０４がメッセージキューにメッセージを格納する動作フローを示す。

図１７に示すように、メッセージキュー管理機能１０４は、クライアントからメッセージを受信すると（１６１）、まず、そのメッセージに関して、クライアントから非トランザクションモード（NON-TRANモード）とトランザクションモード(TRANモード)の何れが指定されているかを判断する（１６３）。ここで、NON-TRANモードが指定されている場合、メッセージキュー管理機能１０４は、メッセージを受信すれば直ちに、そのメッセージをメッセージキューに格納する（つまり、そのメッセージの処理を進める）。一方、TRANモードが指定されている場合、メッセージキュー管理機能１０４は、メッセージを受信しても、直ちにはそのメッセージをメッセージキューには格納せず、別の一時キューに溜めておき、クライアントからCOMMIT(実行)コマンドが送られると、そのときにはじめて、そのメッセージをメッセージキューに格納する（つまり、そのメッセージの処理を進める）。クライアントは、TRANモードを指定してリクエストメッセージを発した場合、COMMITコマンドを発しない限り、そのリクエストメッセージを後で撤回したり修正したりすることが可能である。

図１７のステップ１６３の判断の結果がNON-TRANモードである場合、メッセージキュー管理機能１０４は、その受信したメッセージがP to P通信のものかP to M通信のものかを判断する（１６５）。その判断の結果がP to P通信である場合、メッセージキュー管理機能１０４は、その受信したメッセージをキューに入れる（１６７）。キューに入れられたメッセージは、すぐに読み出されてフレームワークサービスへ送られてそこで処理される。その処理の結果として、フレームワークサービスから後続処理のリクエストメッセージが返された場合、メッセージキュー管理機能１０４は、その後続処理のリクエストメッセージをDBキューに入れる（１６９）。そして、メッセージキュー管理機能１０４は、その受信メッセージの処理結果を示す成功メッセージをクライアントへ返す（１７１）。

ステップ１６５の判断の結果がP to M通信である場合、メッセージキュー管理機能１０４は、その受信したメッセージの優先順位(図２)が"Ｈ"、"Ｎ"又は"Ｌ"の何れであるか判別し（１７３）、そして、判別された優先順位に対応したリングバッファに、その受信メッセージを格納する（１７５、１７７又は１７９）。リングバッファに入れられたP to Mメッセージは、それを待ち受ける全てコンピュータシステムに送信されることになる。そして、メッセージキュー管理機能１０４は、その受信メッセージについて成功メッセージをクライアントへ返す（１８１）。

ステップ１６３の判断結果がNON-TRANモードであった場合、処理は図８に示すステップ１８１へ進む。ステップ１８１で、メッセージキュー管理機能１０４は、その受信メッセージを上述したメッセージキューとは別の一時キューに格納する．その後、クライアントから、その受信メッセージに関してCOMMITコマンドを受信すると、メッセージキュー管理機能１０４は、一時キューからそのメッセージを取り出して、そのメッセージについてステップ１８５以降の処理を行う。ステップ１８５以降の処理は、既に説明した図７中のステップ１６５以降の処理と同じである。

図１９は、メッセージキュー管理機能１０４のメッセージ読出機能を示す。

図１９に示すように、メッセージングサービス１５のメッセージキュー管理機能１０４は、クライアント及びフレームワークサービス１６からそれぞれ受信したメッセージを、上述したような構成をもつメッセージキュー１５ａに蓄積する。メッセージキュー管理機能１０４は、メッセージキュー１５ａのうち特に図１６に示したメモリキュー１５３及びDBキュー１５５からメッセージを取り出す動作に関して、優先モード１０４ａとシーケンス保証モード１０４ｂの2種類の機能を有している。優先モード１０４ａは、メッセージの優先順位に基づいてメッセージキューからのメッセージの取り出し順序を制御する。一方、シーケンス保証モード１０４ｂは、メッセージキューから先に取り出されたメッセージの処理がフレームワークサービスにおいて完了するまで、当該メッセージキューに蓄積されている後続のメッセージの取り出しを禁止することにより、複数メッセージの一定の処理順序を保証する。各メッセージのサブジェクトID）に応じて、又は予め設定された各メッセージキューのモード設定に応じて、各メッセージキューについて優先モード１０４ａを実行するか、シーケンス保証モード１０４ｂを実行するか、が選択される。シーケンス保証モード１０４ｂは、例えば、複数のクライアントからそれぞれ売上処理のリクエストメッセージが来たとき、先にリクエストされた売上処理が完了した後に後から来た売上処理のリクエストを実行するというような一定の処理順序を保証したい場合に、適用される。

図２０は、優先モード１０４ａのための記憶域の構成を示す。図２１は、優先モード１０４ａの動作の流れを示す。

図２０に示すように、優先モード１０４ａは、ソータブルスタック２１１とシンプルタック２１３という２つのスタックメモリと、"Ｈ"、"Ｎ"及び"Ｌ"という３つの優先順位にそれぞれ対応した例えば３つのエントリ２１５Ｈ、２１５Ｎ及び２１５Ｌとを使用する。なお、エントリの数をもっと多くすることもできる。例えば、図示の３つのエントリの他に、"Ｈ"に対応したエントリをもう一つ追加するというようにである。

初期的に、各エントリ２１５Ｈ、２１５Ｎ及び２１５Ｌには、それぞれ、インデックスとして、例えば図示のような"５"、"３"及び"１"という数値が設定される。インデックスの初期値が大きいほど、優先的レベルが高いことを意味する。

そして、初期的に、全てのエントリ２１５Ｈ、２１５Ｎ及び２１５Ｌが、図示のようにソータブルスタック２１１に積まれ、一方、シンプルスタック２１３は空である。

ソータブルスタック２１１は、そこに積まれている複数のインデックスの配列を、インデックスの大きい順に、最も大きいインデックスをもったエントリが一番上に、最も小さいインデックスをもったエントリが一番下になるように、自動的に並べ替える。従って、ソータブルスタック２１１からは、インデックスのより大きいエントリほど、より先に取り出される。

シンプルスタック２１３は、単純に、後から入れられたエントリを先に入れられたエントリの上に積む。従って、シンプルスタック２１３からは、入れられた時がより後のエントリほど、より先に取り出される。

優先モード１０４ａは、図２１に示すフローに従って、ソータブルスタック２１１とシンプルスタック２１３との間でのエントリの移動と、エントリのインデックスの操作を行なうことにより、メッセージキュー（メモリキュー１５３又はDBキュー１５５）からメッセージを取り出す順序を制御する。

以下、図２１に示す流れを説明する。まず、優先モード１０４ａは、ソータブルスタック２１１から、一番上の（つまり、インデックスが最も大きい）１つのエントリを取り出し（２２１）、そのエントリをシンプルスタック２１３に積む（２２３）。次に、優先モード１０４ａは、シンプルスタック２１３の一番上のエントリの優先順位とマッチするメッセージがメッセージキューに有るか否かをチェックする（２２５）。その結果、マッチするメッセージが無ければ、処理はステップ２２１へ進む。また、上記チェックの結果、マッチするメッセージが有れば、優先モード１０４ａは、そのマッチしたメッセージをメッセージキューから取り出す（２２７）。取り出されたメッセージは、何れかのフレームワークシステムにて処理されることになる。その後、優先モード１０４ａは、シンプルスタック２１３内のエントリ数が１つか否かをチェックする（２２９）。その結果、シンプルスタック２１３内のエントリ数が２つ以上であれば、シンプルスタック２１３から全てのエントリを順に取り出してソータブルスタック２１１に積む（２３７）。そして、優先モード１０４ａは、ステップ２２７でメッセージキューから取り出したメッセージについて、フレームワークシステムからの処理結果を示すリプライメッセージをクライアントへ返す（２３９）。

ステップ２２９でのチェックの結果、シンプルスタック２１３内のエントリ数が１つである場合、優先モード１０４ａは、シンプルスタック２１３内のエントリのインデックスを１だけ減らす（２３１）。そして、優先モード１０４ａは、その減らされたインデックスが"−１"であるかどうかチェックし（２３３）、"−１"でなければ、処理をステップ２３７へ進め、一方、"−１"であれば、そのインデックスを初期値に戻して（２３５）から、処理をステップ２３７へ進める。

以上の操作により、メッセージキュー内のメッセージの並び順序をそれらのメッセージの優先順位を考慮して修正した順序で、メッセージキューからメッセージの取り出されることになる。すなわち、メッセージキューに入っているメッセージの順序が、優先順位において、例えば図２０に示すような"Ｈ"、"Ｈ"、"Ｌ"、"Ｈ"、"Ｈ"、"Ｈ"、"Ｎ"であった場合、そのメッセージキューから取り出されるメッセージの順序は、優先順位において、"Ｈ"、"Ｈ"、"Ｎ"、"Ｈ"、"Ｈ"、"Ｈ"、"Ｌ"となる。

図２２は、シーケンス保証モード１０４ｂの動作の流れを示す。

図２２に示すように、シーケンス保証モード１０４ｂは、メッセージの取り出し要求が生じると（２４１）、まず、メッセージキューをロックして（２４３、２４５、２５７）、メッセージキューからの他のメッセージ取り出しを禁止する。次に、シーケンス保証モード１０４ｂは、メッセージキューから１つのメッセージを読出す（２４７、２４９）。読み出されたメッセージは、何れかのフレームワークシステムで処理され（２５１）、その処理により然るべきデータベースの更新のコミット（又は処理失敗の場合にはロールバック）が行われる（２５３）。その後、シーケンス保証モード１０４ｂは、メッセージキューのロックを解除する（２５５）。

上記の操作により、先行するメッセージの処理が完了した後に、次のメッセージの処理が実行されるため、メッセージの一定の処理順序が保証される。

図２３は、フレームワークサービス１６のメッセージ判別機能を示す。

図２３に示すように、フレームワークサービス１６は、メッセージ判別ビジネスロジック１０６を有し、メッセージングサービス１５からメッセージを受け取ると、メッセージ判別ビジネスロジック１０６を実行する。メッセージ判別ビジネスロジック１０６は、その受信メッセージのサブジェクトIDにマッチするサブジェクトIDが書かれた定義センテンスを、そのフレームワークシステム１６に関連付けられたフロー定義ファイル２３から探す。マッチした定義センテンスが見つかれば、次に、その定義センテンスに記述されている実行ビジネスロジック２２が実行されることになる。しかし、マッチした定義センテンスが見つからなければ、メッセージ判別ビジネスロジック１０６は、処理できない旨のエラーのリプライメッセージをメッセージングサービス１５へ返信し、そのリプライメッセージはクライアントへ送られる。既に説明したように、メッセージングサービス１５は、管理テーブル１８（図４）に基づいて、各メッセージをそのメッセージを待ち受けるコンピュータシステムにのみ送信するから、原則的には、或るメッセージが誤ったフレームワークシステムに送られることはない。しかし、万が一、クライアントからの或るメッセージが誤ったフレームワークサービスに送られることが発生したとしても、クライアントは直ちに処理できない旨のエラーのリプライメッセージを受け取れるので、長々と待たされること無く、速やかに次の行動に移ることができる。

また、フレームワークサービス１６は、予め登録された識別情報を有するメッセージに限ってフレームワークサービスでの処理を許可するサービス停止中モードを備え、当該モードが設定されている場合に予め登録されていない識別情報を有するメッセージをクライアントから受信した場合は、当該メッセージを受け付けない旨のメッセージをクライアントに返信する。

図２４は、フレームワークサービスがもつメッセージ変換ビジネスロジックを示す。

図２４に示すように、フレームワークサービス１６は、１又はそれ以上のメッセージ変換ビジネスロジック１０５を有している。それらのメッセージ変換ビジネスロジック１０５は、例えば、図１３に示したフロー定義ファイル２３の定義センテンス２３３及び２３４に記述された"CnvBuyUpdBuy"、"CnvBuyInsBuy1"及び"CnvBuyInsBuy2"などである。各メッセージ変換ビジネスロジック１０５は、予め定められた１つのビジネスロジックＢＬ1に対応していうる。或る定義センテンスに従って或るビジネスロジックＢＬ１が実行されると、引き続いて、これに対応したメッセージ変換ビジネスロジック１０５が実行される。メッセージ変換ビジネスロジック１０５は、先行のビジネスロジックＢＬ１から出力される処理結果のメッセージの形式を、後続のビジネスロジックＢＬ２への入力メッセージの形式に適合させるフォーマット変換機能と、先行のビジネスロジックＢＬ１から出力されたメッセージのパラメータに応じて、このメッセージを後続ビジネスロジックＢＬ２に入力するか否かを判定するメッセージフィルタリング機能とを備えている。例えば、先行のビジネスロジックＢＬ１が扱うメッセージのパラメータ配置と、後続ビジネスロジックＢＬ２が扱うメッセージのパラメータ配置が異なる場合、メッセージ変換ビジネスロジック１０５は、前者のパラメータ配置を後者のパラメータ配置に変換する。また、先行ビジネスロジックＢＬ１の出力メッセージの内容が特別のもの(例えば、リクエストの拒否、データベースの更新失敗、トランザクションのロールバックなど)であり、そのため、後続のビジネスロジックＢＬ２の実行が無意味であるという場合がある。そのような場合、メッセージ変換ビジネスロジック１０５は、メッセージフィルタリング機能により、後続ビジネスモデルＢＬ２への入力メッセージの生成をオミットする。ここで、先行ビジネスロジックＢＬ１とメッセージ変換ビジネスロジック１０５との間、又はメッセージ変換ビジネスロジック１０５と後続のビジネスロジックＢＬ２との間には、メッセージを一時保持するメッセージキューを介在させてもよい。

以上の説明は、本発明の説明のための例示にすぎない。本発明は、上述した実施形態のみに限らず、他の多くのシステム構成のバリエーションにおいても実施することができる。

本実施形態の全体構成図である。 RtFAサーバ１４が取り扱うメッセージの構成を示すブロック図である。 RtFAサーバ１４の構成図である。 メッセージングサービス１５に関係付けられる管理テーブル１８の例を示す。 複数のRtFAサーバ間の接続構成図である。 複数のメッセージングサービス間の接続構成図である。 P to M（1対多）通信処理のメッセージ中継方法を示す説明図である。 P to M通信処理の一例を示すフローチャートである。 P to P（1対１）通信処理を示すフローチャートである。 メッセージングサービスのロードバランシング機能の説明図である。 フレームワークサービスの構成を示すブロック図である。 フレームワークサービスの動作説明図である。 フロー定義ファイルの簡単な例を示す。 フロー定義ファイルの更新システムを示すブロック図である。 フレームワークサービスのメッセージ変換処理機能を示すブロック図である。 メッセージングサービスのメッセージキューの構成を示すブロック図である。 メッセージキュー管理機能がメッセージキューにメッセージを格納する動作を示すフローチャートである。 図１７のフローチャートの続きである。 メッセージキュー管理機能のメッセージ読出機能を示すブロック図である。 優先モードのための記憶域の構成を示す。 優先モードの動作の流れを示す。 シーケンス保証モードの動作の流れを示す。 フレームワークサービスのメッセージ判別機能を示すブロック図である。 フレームワークサービスのメッセージ変換ビジネスロジックを示すブロック図である。

Claims (2)

1. クライアントと通信可能に接続されるフレームワークシステムにおいて：
   前記クライアントからのリクエストのメッセージを処理し、そして、前記クライアントへのリプライのメッセージを出力するフレームワークサービスと；
   前記クライアントと前記フレームワークサービスとの間に介在し、前記クライアントと前記フレームワークサービスとの間でメッセージを中継するメッセージングサービスと
   を備え；
   前記リクエストのメッセージは所与の優先順位を有しており；
   前記メッセージングサービスが、前記リクエストのメッセージを一時的に待たせるためのメッセージキューと、前記メッセージキューの入出力を管理するキュー管理コンポーネントとを備え；
   前記キュー管理コンポーネントは、
   前記メッセージキューに複数のメッセージが蓄積されているとき、各メッセージの優先順位に応じて、前記複数のメッセージの前記メッセージキューからの出力順序を制御する優先モードと、
   前記メッセージキューに複数のメッセージが蓄積されているとき、前記メッセージキューから先に取り出されたメッセージの処理が前記フレームワークサービスにおいて完了するまで、前記メッセージキューに蓄積されている他のメッセージの取り出しを禁止するシーケンス保証モードと、
   各メッセージに応じて、又は各メッセージキューに応じて、前記優先モードを実行するか前記シーケンス保証モードを実行するかを選択する手段と、
   所定の異なる優先順位にそれぞれ対応した複数のエントリであって、各エントリは数値をもち、前記各エントリの数値には、前記各エントリに対応する優先順位が高いほど大きい初期値が設定されている、前記複数のエントリと、
   ソータブルスタックと、
   シンプルスタックと、
   初期的に、前記複数のエントリのすべてを前記ソータブルスタックに入れる初期設定手段と、
   前記ソータブルスタック内のエントリ中、最も大きい数値をもつ１つのエントリを、前記ソータブルスタックから取り出して前記シンプルスタックへ入れるエントリ移動手段と、
   前記エントリ移動手段が動作した後、前記シンプルスタックに最後に入れられたエントリに対応する優先順位と一致する優先順位をもつメッセージを、前記メッセージキュー内で探すサーチ手段と、
   前記サーチ手段により前記一致する優先順位をもつメッセージが前記メッセージキュー内で見つからなければ、前記エントリ移動手段を再び動作させる繰り返し手段と、
   前記サーチ手段により前記一致する優先順位をもつメッセージが前記メッセージキュー内で見つかれば、前記見つかったメッセージを前記メッセージキューから前記フレームワークサービスへ出力させるメッセージ出力手段と、
   前記メッセージキューからメッセージが出力された場合、前記シンプルスタック内の前記出力されたメッセージの優先順位に対応するエントリの数値に対して、減らす、前記初期値へ戻す、または変更しない、のいずれかの動作を選択的に行い、その後、前記シンプルスタック内のすべてのエントリを、前記シンプルスタックから取り出して前記ソータブルスタックに入れ、その後、前記エントリ移動手段を再び動作させるエントリ戻し手段と
   を備え；
   前記優先モードが選択された場合、前記複数のエントリ、前記ソータブルスタック、前記シンプルスタック、前記初期設定手段、前記エントリ移動手段、前記サーチ手段、前記繰り返し手段、前記メッセージ出力手段及び前記エントリ戻し手段が用いられる、
   フレームワークシステム。
2. クライアントと通信可能に接続されるフレームワークシステムであって、
   所定の異なる優先順位にそれぞれ対応した複数のエントリであって、各エントリは数値をもち、前記各エントリの数値には、前記各エントリに対応する優先順位が高いほど大きい初期値が設定されている、前記複数のエントリと、
   ソータブルスタックと、
   シンプルスタックと
   を有する前記フレームワークシステムの動作方法において：
   前記クライアントからリクエストのメッセージを受信するステップと；
   受信されたリクエストのメッセージをメッセージキューに入れるステップと；
   前記メッセージキューからリクエストのメッセージを取り出すステップと；
   取り出されたリクエストのメッセージを処理するステップと
   を備え；
   前記取り出すステップは、
   前記メッセージキューに複数のメッセージが蓄積されているとき、各メッセージの優先順位に応じて、前記複数のメッセージの前記メッセージキューからの出力順序を制御する優先モードと、
   前記メッセージキューに複数のメッセージが蓄積されているとき、前記メッセージキューから先に取り出されたメッセージの処理が完了するまで、前記メッセージキューに蓄積されている他のメッセージの取り出しを禁止するシーケンス保証モードと、
   各メッセージに応じて、又は各メッセージキューに応じて、前記優先モードを実行するか前記シーケンス保証モードを実行するかを選択するステップと、
   初期的に、前記複数のエントリのすべてを前記ソータブルスタックに入れる初期設定ステップと、
   前記ソータブルスタック内のエントリ中、最も大きい数値をもつ１つのエントリを、前記ソータブルスタックから取り出して前記シンプルスタックへ入れるエントリ移動ステップと、
   前記エントリ移動ステップの後に、前記シンプルスタックに最後に入れられたエントリに対応する優先順位と一致する優先順位をもつメッセージを、前記メッセージキュー内で探すサーチステップと、
   前記サーチステップにより前記一致する優先順位をもつメッセージが前記メッセージキュー内で見つからなければ、前記エントリ移動ステップを再び行う繰り返しステップと、
   前記サーチステップにより前記一致する優先順位をもつメッセージが前記メッセージキュー内で見つかれば、前記見つかったメッセージを前記メッセージキューから前記フレームワークサービスへ出力させるメッセージ出力ステップと、
   前記メッセージキューからメッセージが出力された場合、前記シンプルスタック内の前記出力されたメッセージの優先順位に対応するエントリの数値に対して、減らす、前記初期値へ戻す、または変更しない、のいずれかの動作を選択的に行い、その後、前記シンプルスタック内のすべてのエントリを、前記シンプルスタックから取り出して前記ソータブルスタックに入れ、その後、前記エントリ移動ステップを再び行うエントリ戻しステップと
   を有し；
   前記優先モードが選択された場合、前記初期設定ステップ、前記エントリ移動ステップ、前記サーチステップ、前記繰り返しステップ、前記メッセージ出力ステップ及び前記エントリ戻しステップを実行する方法。
   
   

Images