JPWO2002054263A1 - フレームワークシステム - Google Patents
フレームワークシステム Download PDFInfo
- Publication number
- JPWO2002054263A1 JPWO2002054263A1 JP2002555295A JP2002555295A JPWO2002054263A1 JP WO2002054263 A1 JPWO2002054263 A1 JP WO2002054263A1 JP 2002555295 A JP2002555295 A JP 2002555295A JP 2002555295 A JP2002555295 A JP 2002555295A JP WO2002054263 A1 JPWO2002054263 A1 JP WO2002054263A1
- Authority
- JP
- Japan
- Prior art keywords
- message
- framework
- service
- client
- messaging service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
- H04L51/18—Commands or executable codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/226—Delivery according to priorities
Abstract
メッセージングサービス１５は、クライアント１１，１３とフレームワークサービス１６の間で、サブジェクトＩＤを含むリクエストメッセージを中継する。フレームワークサービス１６は、複数のビジネスロジック２２とフロー定義ファイル２３を有する。フロー定義ファイル２３には、様々なサブジェクトＩＤに対応した複数の定義センテンスが含まれ、各定義センテンスには、ビジネスロジックの実行スケジュールが記述されている。フレームワークサービス１６は、受け取ったメッセージのサブジェクトＩＤに対応する実行スケジェールに従って、１又は複数のビジネスロジックを選び実行する。フロー定義ファイル２３は、稼動中であっても所望の時に更新できる。複数のビジネスロジックを連係させて実行する場合、フロー定義ファイルの記述次第で、先行するビジネスロジックに対して後続のビジネスロジックを同期的に実行することも非同期的に実行することもできる。
Description
技 術 分 野
本発明は、クライアントからのメッセージに応答して、選択された１又はそれ以上のビジネスロジックを実行するフレームワークシステムに関する。
技 術 背 景
この種のフレームワークシステムは、典型的には、１又はそれ以上のクライアントと通信可能に接続される１又はそれ以上のサーバによって構成される。この種のフレームワークシステムには、従来からメッセージングサービスと、フレームワークサービスという２つの基本機能が提供されている。メッセージングサービスは、クライアントとサーバ間及びサーバとサーバ間のメッセージ通信を処理するサービスである。フレームワークサービスは、通常複数のビジネスロジック（業務処理プロセス）を有しており、クライアントからのメッセージに応答して、選択された１又はそれ以上のビジネスロジックを同期方式で又は非同期方式で実行することによりトランザクションを遂行する。
しかしながら、上記従来例にあっては、フレームワークサービスにおけるビジネスロジックの処理スケジュールが固定的にプログラムされている。そのため、多種多様なメッセージに応じて複雑なビジネスロジックのフローを柔軟に定義することが困難である。
また、クライアントからのメッセージに応答して、複数のビジネスロジックを逐次に実行する場合がある。例えば、クライアントからの仕入登録リクエストに応答して、仕入登録や在庫更新や買掛金記帳などを行う場合である。このような場合、従来システムでは、例えば仕入登録のようなフロントデスクに関わるビジネスロジックはそのメッセージに同期して実行するが、在庫更新や買掛金記帳のようなバックオフィスに関わるビジネスロジックは夜間のバッチ処理により実行する。そのため、バックオフィスの処理の結果は、翌日まで待たないと参照できない。しかし、新たな取引のチャンスをいち早くキャッチするには、バックオフィスのビジネスロジックも可能な限り早期に実行してその結果が早期に参照できることが望ましい。
また、複数のフレームワークサーバを備えたシステムでは、フレームワークサーバ相互間でもメッセージを送受しながら協働して、一連のビジネスロジックを実行していく。各サーバのステータス（例えば、保有するビジネスロジックの種類、正常に稼動しているか否か、ビジーか否か、など）は、他のサーバとは違うのが普通であり、且つ、時間経過に伴って変化もする。このことは、ビジネスロジックの実行をどのサーバに依頼するかを決めるスケジューリングを複雑にする。
発 明 の 開 示
本発明は、ビジネスロジックフローを、プログラムすることなく、定義し変更することが容易なフレームワークシステムを提供することを目的とする。
本発明の別の目的は、一連のビジネスロジックを、完全にリアルタイムではなくても、できるだけリアルタイムに近い態様で、実行することができるフレームワークシステムを提供することにある。
本発明の更に別の目的は、複数のフレームワークサーバを備えたシステムにおいて、一連のビジネスロジックのスケジューリングを、それらサーバのステータスに応じて適切に行えるようにすることにある。
本発明の一つの観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、複数のビジネスロジックと関連付けられ、クライアントからのリクエストのメッセージに応答して、選択された１又はそれ以上のビジネスロジックを実行し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスと；フレームワークサービスに関連付けられたフロー定義ファイルとを備える。リクエストのメッセージは、そのメッセージのサブジェクトに関するサブジェクトＩＤを含んでいる。フロー定義ファイルは、複数の異なるサブジェクトＩＤにそれぞれ対応した複数の定義センテンスを含んでおり、各定義センテンスは所定の１又はそれ以上のビジネスロジックのための実行スケジュールを記述している。フレームワークサービスは、メッセージングサービスからリクエストのメッセージを受け取ると、定義ファイル内の受信されたメッセージのサブジェクトＩＤに対応した定義センテンスを参照し、参照された定義センテンスに記述された実行スケジュールに従って、実行するべき１又はそれ以上のビジネスロジックを選択する。
好適な実施形態では、フレームワークシステムは、フレームワークサービスが稼動している間に、フロー定義ファイルを更新するフロー定義更新コンポーネントを更に備える。
好適な実施形態では、また、フロー定義ファイルには、一つの先行のビジネスロジックと少なくとも一つの後続のビジネスロジックとを含む複数のビジネスロジックの連係された実行のための連係実行スケジュールを記述した定義センテンスを含むことができる（勿論、連係実行スケジュールを定義した定義センテンスを含まなくてもよい）。その連係実行スケジュールは、後続のビジネスロジックの実行に関して同期方式と非同期方式の選択に関する連係モードを含んでいる。そして、フレームワークサービスは、連係実行スケジュールに従って複数のビジネスロジックを実行する場合、連係実行スケジュール内の連係モードに従って、先行のビジネスロジックの実行と同期的に又は非同期的に、後続のビジネスロジックを実行する。
好適な実施形態では、連係実行スケジュールは、先行のビジネスロジックに関する情報と、後続のビジネスロジックのための第２のリクエストのメッセージに関する情報とを含む。そして、フレームワークシステムは、連係実行スケジュールに従って複数のビジネスロジックを実行する場合、先行のビジネスロジックを実行した後、先行のビジネスロジックの実行結果を用いて第２のリクエストのメッセージを生成して、その第２のリクエストのメッセージをメッセージングサービスに送る。その後、フレームワークシステムは、メッセージングサービスから上記第２のリクエストのメッセージを受けると、その第２のリクエストのメッセージに対応する定義センテンスの実行スケジュールに従って、後続のビジネスロジックを実行する。
好適な実施形態では、また、メッセージングサービスが、前記第２のリクエストのメッセージを保証する為の不揮発性のメッセージキューを備える。このメッセージキューは、第２のリクエストメッセージがフレームワークサービスへ送られた後も、その第２のリクエストメッセージを消さずに保存する。そして、メッセージグサービスは、その不揮発性のメッセージキューで保存されている第２のリクエストのメッセージを、必要に応じて、フレームワークシステムへ再送信することができる。
本発明の別の観点に従うクライアントと通信可能に接続されるフレームワークシステムは、クライアントからのリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスとを備える。そして、メッセージングサービスは、上記リクエストとリプライのメッセージのようなＰ ｔｏ Ｐ通信のメッセージだけでなく、クライアントとフレームワークサービスとの間のＰ ｔｏ Ｍ通信のメッセージをも中継する。
好適な実施形態では、メッセージングサービスが、Ｐ ｔｏ Ｍ通信のメッセージを一時的に待たせるためのリングバッファを有する。
好適な実施形態では、また、Ｐ ｔｏ Ｐ通信のメッセージの各々には、メッセージ保証の要否に関する保証モードが含まれている。そして、メッセージングサービスは、メッセージ保証が不要なＰ ｔｏ Ｐ通信のメッセージを一時的に待たせるための第１のメッセージキューと、メッセージ保証が必要なＰ ｔｏ Ｐ通信のメッセージを一時的に待たせるための不揮発性の第２のメッセージキューとを有する。
本発明のまた別の観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、クライアントと接続された少なくとも一つのメッセージングサービスを含んだ、相互にメッシュ接続されている複数のメッセージングサービスと；複数のメッセージングサービスにそれぞれ接続された複数のフレームワークサービスとを備える。そして、複数のフレームワークサービスの各々は、予め定められたサブジェクトＩＤをもったリクエストのメッセージを待ち受け、その予め定められたサブジェクトＩＤをもったリクエストのメッセージを受信すると、受信されたリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力することができる。そして、上記複数のメッセージングサービスは、クライアントと上記複数のフレームワークサービスの間でのメッセージの中継、及び、上記複数のフレームワークシステム相互間でのメッセージの中継を行う。
好適な実施形態では、各メッセージングサービスが、他の１又はそれ以上のメッセージングサービスの稼動を監視し、他の或るメッセージングサービスについて正常な稼動を検出できなかった場合は、その正常に稼動してないメッセージングサービスへメッセージを中継する代わりに、他の正常に稼動しているメッセージングサービスへメッセージを中継する。
好適な実施形態では、また、各メッセージングサービスが、各々に接続されたフレームワークサービスの状態を監視し、監視された状態に応じて、クライアントからのリクエストのメッセージを上記フレームワークサービスに中継するか、他の何れかのメッセージングサービスに中継するかを、選択する。
好適な実施形態では、また、各メッセージングサービスは独自の管理テーブルを有し、各管理テーブルには、各メッセージングサービスに接続されたフレームワークシステムが待ち受けるメッセージのサブジェクトＩＤ、及び、各メッセージングサービスに接続された他の１又はそれ以上のメッセージングサービスがそれぞれ待ち受けるメッセージのサブジェクトＩＤが登録されている。そして、各メッセージングサービスは、メッセージを受信したとき、それ独自の管理テーブルを参照して、受信されたメッセージのサブジェクトＩＤにマッチするサブジェクトＩＤを待ち受けるフレームワークサービス又は他のメッセージングサービスを探し、見つかったフレームワークサービス又は他のメッセージングサービスへ、受信されたメッセージを中継する。
好適な実施形態では、さらに、各メッセージングサービスは、それ独自の管理テーブルの内容に基づいて、そのメッセージングサービスが待ち受けるメッセージのサブジェクトＩＤを、他の１又はそれ以上のメッセージングサービスに通知する。その通知を受けた他のメッセージングサービスの各々は、通知された内容が、それ独自の管理テーブルに未だ登録されていなければ、その通知内容を、それ独自の管理テーブルに追加登録する。
本発明の更に別の観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、クライアントからのリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスとを備える。クライアントからのリクエストのメッセージは所与の優先順位を有している。そして、メッセージングサービスは、上記リクエストのメッセージを一時的に待たせるためのメッセージキューと、メッセージキューの入出力を管理するキュー管理コンポーネントとを備える。キュー管理コンポーネントは、メッセージキューに複数のメッセージが蓄積されているとき、各メッセージの優先順位に応じて、複数のメッセージのメッセージキューからの出力順序を制御する優先モードと；メッセージキューに複数のメッセージが蓄積されているとき、メッセージキューから先に取り出されたメッセージの処理が前記フレームワークサービスにおいて完了するまで、メッセージキューに蓄積されている他のメッセージの取り出しを禁止するシーケンス保証モードとを備える。
発明を実施するための最良の形態
以下、本発明の一実施形態を図面を参照して説明する。図１は、本実施形態の全体構成を示す。
本システムは、プレゼンテーション層１、ビジネスロジック層２、及びデータサービス層３から構成されている。
プレゼンテーション層１は、ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）クライアント１１、ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバ１２、又はＶＢ（Ｖｉｓｕａｌ Ｂａｓｉｃ）クライアント１３を含んでいる。
ビジネスロジック層２には、本発明の原理に従うフレームワークアークテクチャ（この明細書では「ＲｔＦＡ：Ｒｅａｌ Ｔｉｍｅ Ｆｒａｍｅｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ」という）が適用されたサーバコンピュータシステムであるＲｔＦＡサーバ１４が設けられている。ＲｔＦＡサーバ１４は、メッセージングサービスを行うサーバコンピュータシステム（以下、簡単に「メッセージングサービス」という）１５と、フレームワークサービスを行うサーバコンピュータシステム（以下、簡単に「フレームワークサービス」という）１６とを備えている。典型的には、メッセージングサービス１５とフレームワークサービス１６は、それぞれ、別のコンピュータマシン又は別のコンピュータマシンのセットを用いて具現化される。しかし、必ずしもそうでなければならないわけではなく、同一のコンピュータマシン又はコンピュータマシンのセットを用いて、メッセージングサービス１５とフレームワークサービス１６の双方がインプレメントされることも可能である。
メッセージングサービス１５は、クライアント１１，１３とＲｔＦＡサーバ１４間のメッセージのやり取りを制御する。すなわち、メッセージングサービス１５は、クライアント１１，１３から、或る処理のためのリクエストのメッセージを受信し、そのリクエストのメッセージを、リクエストされた処理を行なうことができるフレームワークサービス１６に渡す。また、メッセージングサービス１５は、フレームワークサービス１６から、実行された処理の結果を示すリプライのメッセージを受信し、更に、場合によっては、後続の追加の処理のための追加のリクエストのメッセージも受信する。そして、メッセージングサービス１５は、そのリプライのメッセージをクライアント１１，１３に送ったり、追加のリクエストのメッセージをフレームワークサービス１６に再び渡したりする。
メッセージングサービス１５によって取り扱われる全てのメッセージの各々には、そのメッセージのサブジェクト（例えば、仕入登録リクエスト、在庫更新リクエスト、買掛登録リクエストなど）を示す識別コードであるサブジェクトＩＤが含まれている。このサブジェクトＩＤは、後述するように、メッセージングサービス１５又はフレームワークサービス１６によって、そのメッセージの宛先を選択する目的に利用され、そのため、「宛先サブジェクトＩＤ」とも呼ばれる。
フレームワークサービス１６は、様々な種類のメッセージをそれぞれ処理するための複数のビジネスロジック（例えば、仕入処理ビジネスロジック、在庫処理ビジネスロジック、買掛処理ビジネスロジック、メッセージ変換ビジネスロジックなど）を有している。フレームワークサービス１６は、メッセージングサービス１５から或るメッセージを受け取ると、そのメッセージのサブジェクトＩＤからそのメッセージを処理するためのビジネスロジックを選び、その選んだビジネスロジックを呼び出しす。呼び出されたビジネスロジックは、そのメッセージの内容に応じた処理を行い、データサービス層９のデータを更新する。メッセージングサービス１５及びフレームワークサービス１６のためのコンピュータプログラムは、例えば、ＪＡＶＡ言語（商標）によって記述されている。
データサービス層３は、データベースサーバ（ＤＢサーバ）１７を備えている。
ウェブクライアント１１とウェブサーバ１２の間にはＨＴＴＰ又はソケットによる通信コネクションが確立され得る。ウェブクライアント１１とＲｔＦＡサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。ＶＢクライアント１３とＲｔＦＡサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。また、ウェブサーバ１２とＲｔＦＡサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。更に、ＲｔＦＡサーバ１４とＤＢサーバ１７との間にはＪＤＢＣによる通信コネクションが確立され得る。
図２は、ＲｔＦＡサーバ１４が取り扱うメッセージの構成を示す。
図２に示すように、メッセージ１０は、複数のサーバ制御項目と業務データとから構成される。サーバ制御項目は、ＲｔＦＡサーバ１４を制御するための各種のデータであり、例えば、メッセージ種別、保証モード、優先順位、サブジェクトＩＤ（宛先サブジェクトＩＤ）及び送信元情報などが含まれている。
「メッセージ種別」は、そのメッセージがＰ ｔｏ Ｐ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ）通信のメッセージであるか、Ｐ ｔｏ Ｍ（Ｐｏｉｎｔ ｔｏ Ｍａｎｙ）通信のメッセージであるかを区別する。ここで、Ｐ ｔｏ Ｐ通信とは、或る１つのコンピュータシステムから別の１つのコンピュータシステムへとメッセージが送られる通信、つまり、１対１通信のことをいう。Ｐ ｔｏ Ｐ通信の一例は、或るクライアントからの仕入登録リクエストのメッセージを、仕入処理を実行する或る一つのフレームワークサービスへ送る場合である。一方、Ｐ ｔｏ Ｍ通信とは、或る１つ又は複数のコンピュータシステムから別の複数のコンピュータシステムへとメッセージが送られる通信、つまり、１対複数又は複数対複数の通信のことをいう。Ｐ ｔｏ Ｍ通信の一例は、或る１つのフレームワークサービスからの在庫更新結果を示すメッセージを、フロントデスクの仕事を担う複数のクライアント端末へ送信する場合である。
「保証モード」は、メッセージ保証（すなわち、そのメッセージが確実に送信及び処理されることの保証）をする（“Ｇ”）か否か（“Ｎ”）を区別する。保証モードが“Ｎ”のメッセージを受信したとき、メッセージングサービス１５は、そのメッセージを、揮発性の半導体メモリを用いたメッセージキュー（以下、「メモリキュー」という）に入れる。一方、保証モードが“Ｇ”のメッセージを受信したとき、メッセージングサービス１５は、そのメッセージを、不揮発性のディスクストレージを用いたメッセージキュー（以下、「ＤＢ（データベース）キュー」という）に入れ、そのメッセージを送信した後も、そのメッセージをＤＢキューで保存しておく。従って、保証モードが“Ｇ”のメッセージについては、送信失敗やシステムダウンなどの問題が生じたとしても、後に再度、同じメッセージを送信することができる。
「優先順位」は、そのメッセージの処理の優先レベルを示す。例えば、ハイ（“Ｈ”）、ノーマル（“Ｎ”）及びロー（“Ｌ”）の３種類の優先順位がある。後述するように、メッセージングサービス１５は、メッセージキュー内で複数のメッセージが待っているとき、それらのメッセージをメッセージキューから取り出す順序を、それらのメッセージのそれぞれの優先順位に応じて制御することができる。
「サブジェクトＩＤ（宛先サブジェクトＩＤ）」は、既に述べたとおり、そのメッセージのサブジェクトの種別を示す識別コードである。後述するように、メッセージングサービス１５は、メッセージを受信すると、そのメッセージのサブジェクトＩＤに基づいて、そのメッセージの宛先となるべきコンピュータシステム（例えば、クライアント、フレームワークシステム、他のメッセージングサービスなど）を選択する。また、フレームワークサービス１６は、メッセージを受信すると、そのメッセージのサブジェクトＩＤに基づいて、そのメッセージを処理するために呼び出すべきビジネスロジックを選択する。
「送信元情報」は、そのメッセージの送信元のサブジェクトやＩＰアドレスやコンピュータ名などを表す。
図３は、ＲｔＦＡサーバ１４の構成図である。
既に参照した図１では、１つのＲｔＦＡサーバ１４しか示されていなかった。しかし、実際には、図３に示すように、複数のＲｔＦＡサーバ１４を設けることができる。図３に示す例では、２つのＲｔＦＡサーバ１４が設けられているが、もっと多くのＲｔＦＡサーバ１４を設けることができる。
図３に示すように、各ＲｔＦＡサーバ１４には、一つのメッセージングサービス１５と、１又は複数のフレームワークサービス１６が設けられ、メッセージングサービス１５とフレームワークサービス１６は相互に通信可能に接続されている。メッセージングサービス１５は、また、１又は複数のクライアント１１，１３とも通信可能に接続されている。メッセージングサービス１５は、クライアント１１，１３及びフレームワークサービス１６とそれぞれ通信する複数のスレッド１７１を並列に処理している。
複数のＲｔＦＡサーバ１４が存在するので、メッセージングサービス１５とフレームワークサービス１６の組は複数組存在している。そして、複数のＲｔＦＡサーバ１４のメッセージングサービス１５は、相互に通信可能に接続されている。各ＲｔＦＡサーバ−１４のメッセージングサービス１５は、他のＲｔＦＡサーバ１４のメッセージングサービス１５との通信を処理するスレッド１７１も備えている。各メッセー−ジングサービス１５が持つ複数の通信スレッド１７１は、それぞれキープアライブ機能を有し、この機能により、そのメッセ−ジングサービス１５にコネクションされたクライアント１１，１３、他のメッセージングサービス１５、及びフレームワークサービス１６と相互の正常な稼動を確認しあっている。
また、各メッセージングサービス１５には、図４に例示するような管理テーブル１８が関連付けられている。管理テーブル１８には、そのメッセージングサービス１５が伝達すべきメッセージの経路、換言すれば、そのメッセージングサービス１５が取り扱う様々なメッセージの送り先、が管理される。図４に示すように、管理テーブル１８には、そのメッセージングサービス１５に接続された全てのコンピュータシステム（クライアント１１，１３、他のメッセージングサービス１５、及びフレームワークサービス１６）の各々について、種別、コンピュータＩＤ、ＩＰアドレス、Ｐ ｔｏ ＰサブジェクトＩＤ、Ｐ ｔｏ ＭサブジェクトＩＤ及び処理中フラグなどが登録される。
「種別」は、そのコンピュータシステムの種別、例えば、フレームワークサービス（Ｆ）、メッセージングサービス（Ｍ）、クライアント端末ターミナル（Ｔ）の区別を示す。
「コンピュータＩＤ」及び「ＩＰアドレス」は、そのコンピュータシステムの固有の識別コードとＩＰアドレスを示す。
「Ｐ ｔｏ ＰサブジェクトＩＤ」は、そのコンピュータシステムが待ち受ける（つまり、そのコンピュータシステムが、そのメッセージの宛先になり得る）Ｐ ｔｏ Ｐ通信用のメッセージのサブジェクトＩＤ（宛先サブジェクトＩＤ）を示す。各コンピュータシステムごとに、複数のＰ ｔｏ ＰサブジェクトＩＤを登録することができる。
「Ｐ ｔｏ ＭサブジェクトＩＤ」は、そのコンピュータシステムが待ち受ける（つまり、そのコンピュータシステムが、そのメッセージの宛先になり得る）Ｐ ｔｏ Ｍ通信用のメッセージのサブジェクトＩＤ（宛先サブジェクトＩＤ）を示す。各コンピュータシステムごとに、複数のＰ ｔｏ ＭサブジェクトＩＤを登録することができる。
「処理中フラグ」は、そのコンピュータシステムとの通信のためのスレッド１７１が、Ｐ ｔｏ Ｐ通信の処理中である（「１」）か否（「０」）かを示す。
図４に示した管理テーブル１８の登録内容は、図３中の左側のメッセージングサービスＭｅｓ１の場合の例であり、そこには、左側のメッセージングサービスＭｅｓ１に接続された全てのコンピュータシステム、すなわち、２つのフレームワークサービスＦｒｍ１、Ｆｒｍ２、右側のメッセージングサービスＭｅｓ２及び３つのクライアント端末ＰＣ１、Ｐｃ２及びＰＣ３が登録されている。この例によれば、１番目のフレームワークサービスＦｒｍ１は、Ｐ ｔｏ Ｐ通信に関しては“Ａ”、“Ｂ”、“Ｃ”及び“Ｄ”というサブジェクトＩＤをそれぞれもった４種類のメッセージを待ち受けており、また、Ｐ ｔｏ Ｍ通信に関しては“０”、“Ｐ”、“Ｑ”及び“Ｒ”というサブジェクトＩＤをそれぞれもった４種類のメッセージを待ち受けている。また、図中右側のメッセージングサービスＭｅｓ２は、左側のメッセージングサービスＭｅｓ１からのＰ ｔｏ Ｐ通信のメッセージとして、“Ｄ”、“Ｅ”、“Ｆ”、“Ｈ”、“Ｉ”及び“Ｊ”というサブジェクトＩＤをそれぞれもった７種類のメッセージを待ち受けており、また、左側のメッセージングサービスＭｅｓ１からのＰ ｔｏ Ｍ通信のメッセージとして“Ｐ”、“Ｑ”、“Ｒ”、“Ｓ”、“Ｔ”及び“Ｕ”というサブジェクトＩＤをそれぞれもった６種類のメッセージを待ち受けている。
再び図３を参照して、各メッセージングサービス１５は、メッセージを受信すると、そのメッセージがＰ ｔｏ Ｐ通信のものかＰ ｔｏ Ｍ通信のものかを判断する。Ｐ ｔｏ Ｐ通信のメッセージを受信したときは、メッセージングサービス１５は、そのメッセージングサービス１５に関連付けられている図４に例示したような管理テーブル１８を参照して、その受信メッセージのサブジェクトＩＤとマッチするＰ ｔｏ ＰサブジェクトＩＤのメッセージを待ち受けているコンピュータシステムを探し、見つかった１以上のコンピュータシステムの中から処理中フラグが“０”である１つのコンピュータシステムを選び、そして、選ばれた１つのコンピュータシステムにその受信メッセージを送信する。また、Ｐ ｔｏ Ｍ通信のメッセージを受信したときは、メッセージングサービス１５は、そのメッセージングサービス１５に関連付けられている図４に示したような管理テーブル１８を参照して、その受信メッセージのサブジェクトＩＤとマッチするＰ ｔｏ ＭサブジェクトＩＤのメッセージを待ち受けてるコンピュータシステムを全て選び、そして、選ばれた全てのコンピュータシステムにそのメッセージを送信する。
図５は、複数のＲｔＦＡサーバ間の接続構成図である。図６は、複数のＲｔＦＡサーバ内のメッセージングサービスとフレームワークサービスの接続構成図である。
図５の上段又は下段に示すように、各ＲｔＦＡサーバ１４は他の全てのＲｔＦＡサーバ１４と相互に通信可能に接続されている。すなわち、図６に示すように、各ＲｔＦＡサーバ１４のメッセージングサービス１５が、他の全てのＲｔＦＡサーバ１４のメッセージングサービス１５と相互に通信可能に接続されている。このように複数のコンポーネントの各々が他の全てのコンポーネントと通信可能に接続されることを「メッシュ接続」という。また、図６に示すように、各メッセージングサービス１５に対しては複数のフレームワークサービス１６を直接連絡させることも可能である。
このように複数のメッセージングサービス１５のメッシュ接続の下で、各メッセージサービス１５は、所定の時期、例えばその起動時に、上述したキープアライブ機能を実行する。すなわち、各メッセージングサービス１５は、起動すると、自分の管理テーブル１８に既に登録されている他のメッセージングサービスの全てと逐次に接続して、自分と接続されているフレームワークシステム１６及びクライアント１１，１３が待ち受けるメッセージのサブジェクトＩＤを、接続された他のメッセージングサービスの全てに通知する。通知されたサブジェクトＩＤは、そのメッセージングサービス１５が他のメッセージングサービスから待ち受けるメッセージのサブジェクトＩＤとして、他のメッセージングサービスの管理テーブルに登録される。また、各メッセージングサービス１５は、他のメッセージングサービスと接続しようとしたときに接続できなかった場合には、その後に一定間隔で複数回接続をリトライする。また、各メッセージサービス１５は、自分の管理テーブル１８に未だ登録されていない他のメッセージングサービスから接続要求を受けたときには、その未登録のメッセージングサービスと接続して、未登録のメッセージングサービスとそれぞれが待ち受けるサブジェクトＩＤなどを交換し合い、そして、そのメッセージングサービスを自分の管理テーブル１８に登録する。このようなキープアライブ機能のおかげで、特定のメッセージングシステム１５が正常に稼動してない（例えば、システムダウンした）場合には、他の正常に稼動している各メッセージングサービス１５は、その正常に稼動してない特定のメッセージングシステム１５をメッセージの中継経路から除外し、自分の管理テーブル１８を参照して、自動的に別の中継経路を選択することができる。
次に、図７乃至図９に基づいて、メッセージングサービス１５が提供する通信サービスの種類を説明する。メッセージングサービス１５が提供するデータ配信サービスには、Ｐ ｔｏ Ｍ（１対多）通信処理と、Ｐ ｔｏ Ｐ（１対１）通信処理の２種類がある。
Ｐ ｔｏ Ｍ通信処理は、前述したように、図４に例示したような管理テーブル１８に登録されている各コンピュータシステムのＰ ｔｏ ＭサブジェクトＩＤに基づいて、メッセージングサービス１５が、受信したＰ ｔｏ Ｍメッセージを、それを待ち受ける全てのコンピュータシステムに配信する処理である。例えば、マーケット情報が更新される都度、更新されたマーケット情報のメッセージを、１乃至ｎ個のＲｔＦＡサーバからｎ個のクライアントに配信する場合に、Ｐ ｔｏ Ｍ通信処理が行われる。
一方、Ｐ ｔｏ Ｐ通信処理は、前述したように、図４に例示したような管理テーブル１８に登録されている各コンピュータシステムのＰ ｔｏ ＰサブジェクトＩＤに基づいて、メッセージングサービス１５が、受信したＰ ｔｏ Ｐメッセージを、それを待ち受けるコンピュータシステムの中の一つに送信する処理である。例えば、クライアントからの或る処理のためのリクエストのメッセージを、その処理を行うビジネスロジックを有した一つのフレームワークサービスに送る場合に、Ｐ ｔｏ Ｐ通信処理が行われる。
図７は、Ｐ ｔｏ Ｍ通信処理のメッセージ中継方法の一例を示している。パブリッシャーとしての或るフレームワークサービス１６から出力された或るＰ ｔｏ Ｍメッセージは、そのメッセージを待ち受ける全てのメッセージングサービス１５に配信され、そして、それらのメッセージングサービス１５から、そのメッセージを待ち受ける全てのクライアント１１、１３に配信される。
図８は、Ｐ ｔｏ Ｍ通信処理の一例を示すフローチャートである。まず、サブスクライバの一つであるクライアントＴ１は、所定のメッセージングサービスＭｅｓ１との間で、ソケットによるコネクションを確立する。また、クライアントＴ１から当該メッセージングサービスＭｅｓ１に対し自己が待ち受けるＰ ｔｏ ＭメッセージのサブジェクトＩＤ“Ｘ”を登録する。当該メッセージングサービスＭｅｓ１は、自己に関連付けられた管理テーブル１８に、クライアントＴ１のＰ ｔｏ ＭサブジェクトＩＤ“Ｘ”を追加する。一方、クライアントＴ１は、メッセージングサービスＭｅｓ１からのメッセージの配信を待つ。その後、メッセージングサービスＭｅｓ１に接続する他のメッセージングサービスＭｅｓ２，Ｍｅｓ３が起動したとき、メッセージングサービスＭｅｓ１の管理テーブル１８に既に登録されたクライアントＴ１のＰ ｔｏ ＭサブジェクトＩＤ“Ｘ”は、他のメッセージングサービスＭｅｓ２及びＭｅｓ３にも通知されて、それらの管理テーブル１８に、メッセージングサービスＭｅｓ１のＰ ｔｏ ＭサブジェクトＩＤとして“Ｘ”が追加される。
ここで、パブリッシャーとしてのフレームワークサービスＦｒｍ３からサブジェクトＩＤ“Ｘ”をもつＰ ｔｏ Ｍメッセージが配信されると、これを受けたメッセージングサービスＭｅｓ３は、自己に関連付けられた管理テーブル１８を参照し、サブジェクトＩＤ“Ｘ”を待ち受ける全てのメッセージングサービスＭｅｓ１及びＭｅｓ２をピックアップし、それらに当該メッセージを引き渡す。
クライアントＴ１とコネクトされたメッセージングサービスＭｅｓ１は、当該メッセージを受信すると、自己に関連付けられた管理テーブル１８からサブジェクトＩＤ“Ｘ”を待ち受けるクライアントＴ１をピックアップし、当該メッセージをそのクライアントＴ１に配信する。
図示してないが、各フレームワークサービスも、そのフレームワークサービスと直接連絡可能なメッセージングサービスへ、そのフレームワークサービスが待ち受けるＰ ｔｏ ＭメッセージのサブジェクトＩＤを通知する。それにより、そのフレームワークサービスが待ち受けるＰ ｔｏ ＭサブジェクトＩＤが、そのメッセージングサービスの管理テーブルに登録される。その後、そのメッセージングサービスは、その管理テーブルに登録されたフレームワークサービスのＰ ｔｏ ＭサブジェクトＩＤを、そのメッセージングサービスが待ち受けるＰ ｔｏ ＭサブジェクトＩＤとして、他の全てのメッセージングサービスに通知する。これにより、他の全てのメッセージングサービスの管理テーブルにも、そのフレームワークサービスが待ち受けるＰ ｔｏ ＭサブジェクトＩＤが登録されることになる。結果として、そのフレームワークサービスは、Ｐ ｔｏ ＭサブジェクトＩＤをもったメッセージを、いずれのメッセージングサービスからも受信できるようになる。
次に図９は、Ｐ ｔｏ Ｐ通信処理を示すフローチャートである。
上述したＰ ｔｏ Ｍ通信のサブジェクトＩＤの管理テーブルへの登録と同様に、各メッセージングサービスの管理テーブルには、そのメッセージングサービスが直接連絡可能なクライアント及びフレームワークサービスがそれぞれ待ち受けるＰ ｔｏ ＰサブジェクトＩＤ、並びに、他の全てのメッセージングサービスがそれぞれ待ち受けるＰ ｔｏ ＰサブジェクトＩＤが予め自動的に登録されている。
そのような状態において、図９に示すように、まず或るクライアントＰＣ１は、所定のメッセージングサービスＭｅｓ１とコネクションを確立する。
続いて、クライアントＰＣ１から或るサブジェクトＩＤ“Ａ”を持ったＰ ｔｏ Ｐのリクエストメッセージが送信されると、これを受信したメッセージングサービスＭｅｓ１は、自己の管理テーブル１８を参照して、そのサブジェクトＩＤ“Ａ”を待ち受けるコンピュータシステムの中の一つ、例えば、フレームワークサービスＦｒｍ１を選び、それに当該リクエストメッセージを引き渡す（矢印▲１▼）。フレームワークサービスＦｒｍ１は、引き受けたリクエストメッセージのサブジェクトＩＤ“Ａ”に対応したビジネスロジックを呼び出して、そのメッセージの処理を実行し、その実行結果を示すリプライメッセージをメッセージングサービスＭｅｓ１に戻す（矢印▲３▼）。そして、メッセージングサービスＭｅｓ１は、そのリプライメッセージをクライアントＰＣ１に返信する。そのリプライメッセージをを取得したクライアントＰＣ１は、メッセージングサービスＭｅｓ１とのコネクションを開放する。
或いは、メッセージングサービスＭｅｓ１は、クライアントＰＣ１から受信したサブジェクトＩＤ“Ａ”のリクエストメッセージを、上記の例のようにフレームワークサービスＦｒｍ１へ送る代わりに、サブジェクトＩＤ“Ａ”を待ち受ける他のメッセージングサービスＭｅｓ２へ送る（矢印▲２▼）こともできる。例えば、フレームワークサービスＦｒｍ１が処理中であるが、メッセージングサービスＭｅｓ２は処理中でないときには、そのようなことが行われる。その場合、メッセージングサービスＭｅｓ２は、そのリクエストメッセージを受けると、自己の管理テーブル１８を参照して、サブジェクトＩＤ“Ａ”を待ち受ける一つのコンピュータシステム、例えば、フレームワークシステムＦｒｍ２を選んで、それに当該リクエストメッセージを送って処理させる（矢印▲４▼）。フレームワークシステムＦｒｍ２から処理結果のリプライメッセージが返されると（矢印▲５▼）、メッセージングサービスＭｅｓ２は、そのリプライメッセージをメッセージングサービスＭｅｓ１に返し（矢印▲６▼）、そして、メッセージングサービスＭｅｓ１は、そのリプライメッセージをクライアントＰＣ１へ返す。
上述したように、メッセージングサービス１５は、自己と直接連絡可能なフレームワークサービス１６へメッセージを送るだけでなく、他のメッセージングサービスを経由して他のフレームワークサービスへメッセージを送ることも可能である。これにより、複数のＲｔＦＡサーバ１４間のロードバランシング（負荷平衡）が可能である。
図１０は、メッセージングサービスがもつロードバランシング機能の説明図である。
図１０に示すように、各ＲｔＦＡサーバ１４において、各フレームワークサービス１６は、メッセージングサービス１５と連絡する複数のスレッド１９を並列に処理している。また、各メッセージングサービス１５は、クライアントから受信したメッセージを一時的に保持するメッセージキュー１５ａを備えている。
各メッセージングサービス１５のキュー１５ａに蓄積された各メッセージは、そのメッセージングサービス１５に関連付けられた管理テーブルに従って、そのメッセージのサブジェクトＩＤに対応する何れかのフレームワークサービス１６に引き渡される。その場合、メッセージングサービス１５は、自己に直接連絡可能で且つそのサブジェクトＩＤを待ち受ける特定のフレームワークサービス１６に、そのメッセージを引き渡すことができる。しかし、その時、その特定のフレームワークサービス１６のスレッド１９に空きが無い（つまり、処理中である）場合、メッセージングサービス１５は、その処理中のフレームワークサービス１６ではなく、そのサブジェクトＩＤを待ち受ける他のメッセージングサービス１５に、そのメッセージを引渡す。そのメッセージを受け取った当該他のメッセージングサービス１５は、当該他のメッセージングサービス１６が直接に連絡可能であり且つそのサブジェクトＩＤを待ち受ける特定のフレームワークサービス１６に、そのメッセージを引き渡す。このようなメッセージ中継を可能にするために、各メッセージングサービス１５は、自分のメッセージキュー１５ａを常時監視し、そのメッセージキュー１５ａに処理待ちのメッセージが溜まっている場合は、直ちにそのキューからメッセージを取り出し、自分の管理テーブルを参照してそのメッセージの送り先をてきぱきと決定して、そのメッセージを送り出す。これにより、複数のＲｔＦＡサーバのロードバランスが適正化される。結果として、どのメッセージも可能な限り早期に処理され、よって、従来は夜間にバッチ処理で行われていたバックオフィスの仕事が、リアルタイムに近い態様で早期に実行できる。
続いて、フレームワークサービス１６の構成について説明する。
図１１は、フレームワークサービス１６の構成を示す。
フレームワークサービス１６の実体は、複数のフレームワークスレッド２５による並列処理で構成されている。各フレームワークスレッド２５は、予め準備された一群のビジネスロジック２０にアクセスし、そして、メッセージングサービス１５から引き渡されたメッセージのサブジェクトＩＤに対応する特定のビジネスロジック２２をロードして実行する。ここで、ビジネスロジックとは、例えばＪＡＶＡコードでプログラムされたプロセスであって、それぞれ固有のメッセージ処理を実行するものである。主要なビジネスロジックの多くは、データベースサーバ１７に管理されるデータベース２１に対し、メッセージの内容に応じた所定の操作を要求する。
図１２は、フレームワークサービス１６の動作説明図である。
フレームワークサービス１６のビジネスロジックの動作方式には、大きく分けて同期方式と、非同期方式の２種類がある。フレームワークサービス１６は、クライアントからの或るリクエストメッセージに応答して、ただ１つのビジネスロジックのみを実行する場合がある。また、フレームワークサービス１６は、リクエストメッセージに直接的に応答して１つのビジネスロジックを実行し、それに連係して、後続の１以上のビジネスロジックを実行する場合もある。図１２には、クライアント１１，１３からの仕入登録リクエストのメッセージに直接的に応答して仕入処理のビジネスロジックが実行され、これに連係して、在庫処理及び会計処理という２つの後続のビジネスロジックが実行される例が示されている。
クライアントからのリクエストメッセージに直接的に応答してただ一つのビジネスロジックのみを実行する場合、フレームワークサービス１６は、その唯一のビジネスロジックを通常は同期方式で実行し、そして、その実行結果を示すリプライメッセージをクライアントへ返す。
一方、クライアントからのリクエストメッセージに直接的に応答して１つのビジネスロジックを実行した後、これに連係して、後続の１以上のビジネスロジックを実行する場合、フレームワークサービス１６は、最初の一つのビジネスロジックは通常は同期方式で実行するが、２番目以降のビジネスロジックは同期方式で実行することもできるし、非同期方式で実行することもできる。図１２には、最初の仕入処理のビジネスロジックのみが同期方式で実行され、後続の在庫処理と会計処理のビジネスロジックは非同期方式で実行される例が示されている。図１２の例のように複数のビジネスロジックが実行される場合、フレームワークサービス１６は、同期方式で実行したビジネスロジックの全てが完了すると、その実行結果を示すリプライメッセージをクライアントへ返す。非同期方式で実行されるべきビジネスロジックは、クライアントからは切り離されたバックグラウンドで（つまり、クライアントからはオフラインで）実行される。
図１２に示すように、フレームワークサービス１６は、フロー定義ファイル２３を有しており、そこには、そのフレームワークサービス１６によるビジネスロジックの実行スケジュール（最初に実行すべき１つのビジネスロジック名、連係する後続の１又はそれ以上のビジネスロジックがある場合にはその後続のビジネスロジックへ渡すメッセージのサブジェクトＩＤ及び連係方式（同期か非同期か）、など）が、様々なメッセージのサブジェクトＩＤごとに定義されている。フレームワークサービス１６は、一つのメッセージを受け取ると、フロー定義ファイル２３を参照して、その受信されたメッセージのサブジェクトＩＤに対応するビジネスロジック実行スケジュールを選択し、選択されたスケジュールに従って１以上のビジネスロジックを実行する。その選択されたスケジュールには、少なくとも、そのメッセージに応答して直接的に実行されるべき１つのビジネスロジックが記述されているから、フレームワークサービスは、まず、その１つのビジネスロジックをロードして実行する。もし、その選択されたスケジュールに、更に、連係する後続の１以上のビジネスと連係方式とが記述されていたなら、フレームワークサービスは、最初のビジネスロジックの実行後に、その後続のビジネスロジックを、その連係方式で（つまり、同期的に又は非同期的に）実行することになる。なお、先行のビジネスロジックと後続のビジネスロジックは、同一のフレームワークサービスによって実行される場合もあるが、上述したロードバランシングにより別のフレームワークサービスによって実行される場合もある。
図１３は、フロー定義ファイル２３の簡単な例を示す。
図１３に示すように、フロー定義ファイル２３には、サブジェクトＩＤごとにビジネスロジック実行スケジュールをそれぞれ記述した複数のセンテンス２３１、２３２、２３３、２３４が存在する。フロー定義ファイル２３は、例えばテキストファイルであり、よって、定義センテンス２３１、２３２、２３３、２３４の追加、削除、変更などの編集は、テキストエディタなどを用いて簡単に行える。
図１３の一番上の定義センテンス２３１内に説明されているように、各定義センテンスは、セミコロン“；”で区切られた複数のサブセンテンスから構成される。最初のサブセンテンスには、入力サブジェクトＩＤ、ログキュー名、実行ビジネスロジック名などが含まれる。２番目以降の各サブセンテンスには、メッセージ変換ビジネスロジック名、出力サブジェクトＩＤ、連係モードなどが含まれる。最初のサブセンテンスは、メッセージに直接的に応答して実行されるべき１つのビジネスロジックに関するものであり、これは全ての定義センテンスに必ず記述される。２番目以降のサブセンテンスは、最初のビジネスロジックに連携して実行される後続の１以上のビジネスロジックに関するものであり、よって、後続のビジネスネスロジックがある場合にのみ記述される。
最初のサブセンテンスの項目の意味は次のとおりである。
ここで、「入力サブジェクトＩＤ」は、フレームワークシステムが受信したメッセージのサブジェクトＩＤである。
「ログキュー名」は、その受信したメッセージをログに書く場合に用いられるログキューの名称である。例えば、“＠ＤＥＦ”はデフォルトのログキューを用いることを意味し、“＠ＮＯＮＥ”はログに書かれないことを意味する。
「実行ビジネスロジック名」は、そのメッセージに直接応答して実行されるべきビジネスロジックの名称である。図示の定義センテンス２３２〜２３４の例では、入力サブジェクトＩＤと同じコードが用いられている。
２番目以降の各サブセンテンスの項目の意味は次のとおりである。
「メッセージ変換ビジネスロジック名」は、先行のビジネスロジックの処理結果データを後続のビジネスロジックに渡されるメッセージに変換するために実行されるメッセージ変換ビジネスロジックの名称である。メッセージ変換が不要な場合、ここには“＠ＮＯＮＥ”と書かれる。
「出力サブジェクトＩＤ」は、後続のビジネスロジックに渡されるメッセージのサブジェクトＩＤである。
「連係モード」は、後続のビジネスロジックを同期方式で実行するか非同期方式で実行するかを示す。例えば、“ＳＹＮＣ”は同期方式を意味し、“ＡＳＹＮＣ”は非同期方式を意味する。
図１３の２番目の定義センテンス２３２は次のスケジュール（１）を例示している。
（１）“ＢｕｙＳｅｌＢｕｙ”というサブジェクトＩＤのメッセージ（例えば、仕入検索リクエスト）に応答して、“ＢｕｙＳｅｌＢｕｙ”という名称のビジネスロジック（例えば、仕入検索処理）を実行する。
３番目の定義センテンス２３３は、次のスケジュール（１）〜（３）を例示している。
（１）“ＢｕｙＵｐｄＢｕｙ”というサブジェクトＩＤのメッセージ（例えば、仕入更新リクエスト）に応答して、まず、“ＢｕｙＵｐｄＢｕｙ”という名称のビジネスロジック（例えば、仕入更新処理）を実行する。
（２）次に、“ＣｎｖＢｕｙＵｐｄＢｕｙ”という名称の変換ビジネスロジックを用いて、先行する“ＢｕｙＵｐｄＢｕｙ”ビジネスロジックの出力データのフォーマットを変換して、“ＩｎｖＵｐｄＩｎｖ”というサブジェクトＩＤをもったメッセージ（例えば、在庫更新リクエスト）を作成してメッセージサービスへ出力する。
（３）出力された“ＩｎｖＵｐｄＩｎｖ”というメッセージを処理することになる後続のビジネスロジック（例えば、在庫更新処理）は、同期的に実行される。
さらに、４番目の定義センテンス２３４は、次のスケジュール（１）〜（５）を例示している。
（１）“ＢｕｙＩｎｓＢｕｙ”というサブジェクトＩＤのメッセージ（例えば、仕入検品更新リクエスト）に応答して、まず、“ＢｕｙＩｎｓＢｕｙ”という名称のビジネスロジック（例えば、仕入検品更新処理）を実行する。
（２）次に、“ＣｎｖＢｕｙＩｎｓＢｕｙ１”という名称の変換ビジネスロジックを用いて、先行する“ＢｕｙＩｎｓＢｕｙ”ビジネスロジックの出力データのフォーマットを変換して、“ＩｎｖＵｐｄＩｎｖ”というサブジェクトＩＤをもったメッセージ（例えば、在庫更新リクエスト）を作成してメッセージサービスへ出力する。
（３）出力された“ＩｎｖＵｐｄＩｎｖ”というメッセージを処理することになる後続のビジネスロジック（例えば、在庫更新処理）は、非同期的に実行される。
（４）また、“ＣｎｖＢｕｙＩｎｓＢｕｙ２”という名称の変換ビジネスロジックを用いて、先行する“ＢｕｙＩｎｓＢｕｙ”ビジネスロジックの出力データのフォーマットを変換して、“ＡｃｃＤｂｔＢｕｙ”というサブジェクトＩＤをもったメッセージ（例えば、買掛金登録リクエスト）を作成してメッセージサービスへ出力する。
（５）出力された“ＡｃｃＤｂｔＢｕｙ”というメッセージを受け取る後続のビジネスロジック（例えば、買掛金登録処理）は、非同期的に実行される。
再び図１２を参照する。各フレームワークサービス１６は、それに関連付けられたフロー定義ファイル２３を参照することにより、処理対象のメッセージに対応するビジネスロジック２２を選択し実行することができ、また、後続処理の必要性を判断し、必要であれば、後続処理のためのリクエストメッセージを作成してメッセージングサービス１５へ戻すことができる。
ここで、一のフレームワークスレッドによる処理の後続処理として、他のフレームワークスレッドによる処理を非同期的に行わせる場合、フレームワークサービス１６は、先行のフレームワークスレッドでのビジネスロジックによる処理のリザルト（後続処理のためのリクエストメッセージ）を一度メッセージングサービス１５のキュー１５ａにインプットし、その後、他のフレームワークスレッドがメッセージングサービス１５のキュー１５ａからそのリクエストメッセージをゲットすることによって、後続処理を行う。ここで、先行の処理を行うフレームワークシステム１６と、後続の処理を行なうフレームワークシステム１６は、同じ場合もあるし、異なる場合もある。各種の処理をどのフレームワークシステム１６に割り当てるかということは、既に説明したメッセージングサービスのロードバランシング機能によって制御される。
各フレームワークサービス１６は、メッセージドリブンの構成を採っている。即ち、メッセージングサービス１５からのメッセージの引渡しをトリガーとしてビジネスロジックのロード及びビジネスロジックによる処理を実行するようになっている。
以上説明した本実施形態によると、フレームワークサービスのビジネスロジックの連係方法に同期方式と非同期方式を用意し、随時に簡単に書き換え可能なフロー定義ファイルの記述によってビジネスロジックの実行スケジュールを制御できるので、複雑なビジネスロジックフローを定義し、また必要に応じて変更することが容易である。
また、上記実施形態では、メッセージングサービスをメッシュ接続すると共に、キープアライブ機能によって、メッセージングサービス相互間、メッセージングサービスとクライアントとの間、及びメッセージングサービスとフレームワークサービスとの間で、相互にステータス（待ち受けるメッセージのサブジェクトＩＤ、処理中か否か、など）を通知し合う。そして、各メッセージングサービスは、周囲のクライアント、フレームワークサービス及び他のメッセージングサービスの現在のステータスを、管理テーブルに記憶している。それにより、いずれのＲｔＦＡサーバがダウンした場合でも、各メッセージングサービスは、正常に使えるメッセージの中継経路を自動的に選択し、メッセージを正しいシステムへ伝えることができる。結果として、フォルトトレラント性が向上し、システムの稼動の信頼性が向上し、システムの拡張が容易になり、更に、システムメンテナンスも容易に行うことができる。
また、メッセージングサービスは、Ｐ ｔｏ Ｐ通信とＰ ｔｏ Ｍ通信のような複数種類のデータ配信方法を備え、管理テーブルに登録されているステータスに応じて、どのメッセージをどのコンピュータシステムにどのデータ配信方法で送るかというメッセージングスケジュールを自動的に選択することができる。その結果、柔軟なメッセージングサービスを提供することができる。
また、メッセージングサービスのロードバランシング機能により、複数のＲｔＦＡサーバの負荷バランスを自動的に調整することができ、高いパフォーマンスを提供することができる。
ここで、本発明の範囲は、本実施形態に限られない。例えば、ＪＡＶＡベース以外のプラットフォームを用いることによっても同等のシステムの実現は可能である。また、メッセージングサービスの上述した特徴と、フレームワークサービスの上述した特徴とは、上述した実施形態のように組み合わされている必要は、必ずしも無い。
以下、上記実施形態に具備される幾つかの詳細な機能を説明する。
図１４は、フロー定義ファイル２３の更新システムを示すブロック図である。
フレームワークサービス１６は、定義ファイル２３を更新するためのプログラムモジュールである定義ファイル更新モジュール１０１を備え、この更新モジュール１０１は、外部からリロードコマンド１１１を受付けると、フレームワークサービス１６のメインメモリ１０３内にロードされている現在使用中の定義ファイル２３を、そこに矢印１１３で示すように外部記憶装置（例えば、ディスクストレージ１０７に記憶されている新しい定義ファイル１０９を上書きすることで、更新する。ディスクストレージ１０７内の新しい定義ファイル１０９は、テキストエディタ１０５などを用いて容易に編集することができる。所望の時に、上述したリロードコマンド１１１を入力することで、メインメモリ１０３内の定義ファイル２３が、編集された新しい定義ファイル１０９と同じ内容に更新される。これにより、フレームワークサービス１６の稼動中であっても所望の時に、定義ファイル２３の内容を書き換えて、これをフレームワークサービス１６の以後の動作に反映させることができる。従って、実行するビジネスロジック２２の種類の変更や、後続の処理を行なうか否か、又は、複数のビジネスロジックの連係した動作を同期的に行うか、非同期的に行うか、といった処理スケジュール変更を、システムを稼動させたままの状態で行うことができる。
図１５は、フレームワークサービスのメッセージ変換処理機能を示す。
フレームワークサービス１６のためのコンピュータプログラムは例えばＪＡＶＡ言語で構築される。図１５に示すように、フレームワークサービス１６は、入力メッセージのフォーマット変換を行うための入力変換機能１０２と、出力メッセージのフォーマット変換を行うための出力変換機能１０３とを備えている。入力変換機能１０２は、メッセージングサービス１５からの例えばＸＭＬファイルの形式の入力メッセージを、ＪＡＶＡのオブジェクトの形式に変換する。出力変換機能１０３は、メッセージングサービス１５に出力するＪＡＶＡのオブジェクトの形式のメッセージを、ＸＭＬ形式に変換する。入力変換機能１０２は、ＸＭＬのＤＴＤ（文書型定義）の記述に基づいてＪＡＶＡクラスのメンバ変数を取得し、これをインスタンス化することによってＪＡＶＡオブジェクト化したメッセージを得る。また、出力変換機能１０３は、ＪＡＶＡクラスのメンバ変数に基づいてＸＭＬのＤＴＤを形成し、ＸＭＬ化したメッセージを得る。
図１６は、メッセージングサービスのメッセージキューの構成を示す。
上述の説明では、メッセージキュー１５ａを単一のキューであるかのごとくに説明した。しかし、実際には、図１６に示すように、メッセージキュー１５ａには３種類のキュー、すなわち、メモリキュー１５３とリングバッファ１５４とＤＢ（データベース）キュー１５５が含まれている。メモリキュー１５３とリングバッファ１５４は、ＲＡＭ１５１のような高速アクセスが可能な記憶装置に設けられる。ＤＢキュー１５５は、ハードディスク（ＨＤＤ）のよう不揮発性の大容量の記憶装置に設けられる。
メモリキュー１５３は、メッセージングサービスがクライアントから受信したＰ ｔｏ Ｐのリクエストメッセージのように、そのメッセージを処理した結果を受け取る相手が存在し、メッセージの保証が不要であるというメッセージを、一時的に待たせるために使用される。一方、ＤＢキュー１５５は、メッセージングサービスがフレームワークサービスから受信した非同期の後続処理のためのリクエストメッセージのように、メッセージの保証が必要なメッセージを、一時的に待たせるために使用される。メッセージの保証が必要か否かは、図２に示したメッセージ１０の構成中の「保証モード」で判断される。
リングバッファ１５４は、Ｐ ｔｏ Ｍ通信のメッセージを一時的に待たせるために使用される。各コンピュータシステムは、リンクバッファ１５４を巡回しながらリングバッファ１５４から自分の待ち受けるメッセージを見つけ出して取っていくことができる。図１６では、リングバッファ１５４は一つのバッファのごとくに示されているが、実際には、“Ｈ”、“Ｎ”及び“Ｌ”の３種類の優先順位にそれぞれ対応した３つのリングバッファのセットである。
ＤＢキュー１５５は、メッセージングサービスがフレームワークサービスから受信した後続処理のためのリクエストメッセージのように、メッセージの保証が必要なメッセージを、一時的に待たせるために使用される。
メッセージグサービスは、上述したキュー１５３、１５４、１５５に対するメッセージの書き込みと読み出しを制御するメッセージキュー管理機能１０４を有する。メッセージキュー管理機能１０４は、メモリキュー１５３をＤＢキュー１５５より優先して調べ、メモリキュー１５３にＰ ｔｏ Ｐメッセージが有れば、そのメッセージをメモリキュー１５３から取り出して、それを待ち受ける一つのコンピュータシステムへそのメッセージを送る。また、もしメモリキュー１５３にＰ ｔｏ Ｐメッセージが１つも無ければ、メッセージキュー管理機能１０４は、ＤＢキュー１５５を調べ、ＤＢキュー１５５内にＰ ｔｏ Ｐメッセージが有れば、そのメッセージをＤＢキュー１５５から読み、それを待ち受ける一つのコンピュータシステムへそのメッセージを送る。
メッセージキュー管理機能１０４は、図１６に示すように、ＤＢキュー１５５内のメッセージＭに対しては、そのメッセージの処理状態を示すステータス情報Ｓを付加し、そのメッセージが処理されればステータス情報Ｓを「未処理」から「処理済」へと書き換える。また、そのメッセージの処理に関してエラーが生じれば、ステータス情報Ｓを「エラー」とする。エラーの原因としては、データ不整合、プログラムロジックのミスなどがある。ＤＢキュー１５５に一旦入れられたメッセージは、システムダウンやエラーなどの問題が発生したとしても、消されずにＤＢキュー１５５内に保存される。
メッセージキュー管理機能１０４は、「エラー」のステータス情報Ｓを「未処理」に書き換える機能を有する。そして、システムダウンやエラーなどの問題が発生した場合、後に、メッセージキュー管理機能１０４は、、ステータス情報Ｓが「未処理」のメッセージを再度読み出して再送信する。それにより、メッセージの確実な処理が保証される。また、エラーになったメッセージのステータス情報Ｓを追うことにより、エラーの原因究明も可能である。
また、メッセージキューの管理機能１０４は、外部コマンドに応じて、「エラー」のステータス情報Ｓを「処理済」に書き換える機能も備えていている。例えば、システムの状況によっては、エラーステータスのメッセージを未処理ステータスに変更して再出力することが適切でない場合がある。また、メッセージに生じたエラーの程度によっては、フレームワークサービスに再出力して処理させるよりも、コマンド入力により当該メッセージに修正を加えた方が適切な場合もある。このような場合、「エラー」のステータス情報Ｓを「処理済」に書き換える機能が利用される。上述した「エラー」のステータス情報Ｓを「未処理」に書き換える機能と、「処理済」に書き換える機能とは、任意に選択することができる。
さらに、メッセージキュー管理機能１０４は、管理テーブル１８（図４）に登録されている全てのコンピュータシステムの各々ごとに、リングバッファ１５５の読みしアドレスポインタを有し、各コンピュータシステム用の読み出しアドレスポインタでリングバッファ１５５中を巡回しながら、そのコンピュータシステムが待ち受けるＰ ｔｏ Ｍメッセージをリングバッファ１５５から見つけ出し、その見つかったＰ ｔｏ Ｍメッセージを読んで、そのコンピュータシステムへ送る。
図１７及び図１８は、メッセージキュー管理機能１０４がメッセージキューにメッセージを格納する動作フローを示す。
図１７に示すように、メッセージキュー管理機能１０４は、クライアントからメッセージを受信すると（１６１）、まず、そのメッセージに関して、クライアントから非トランザクションモード（ＮＯＮ−ＴＲＡＮモード）とトランザクションモード（ＴＲＡＮモード）の何れが指定されているかを判断する（１６３）。ここで、ＮＯＮ−ＴＲＡＮモードが指定されている場合、メッセージキュー管理機能１０４は、メッセージを受信すれば直ちに、そのメッセージをメッセージキューに格納する（つまり、そのメッセージの処理を進める）。一方、ＴＲＡＮモードが指定されている場合、メッセージキュー管理機能１０４は、メッセージを受信しても、直ちにはそのメッセージをメッセージキューには格納せず、別の一時キューに溜めておき、クライアントからＣＯＭＭＩＴ（実行）コマンドが送られると、そのときにはじめて、そのメッセージをメッセージキューに格納する（つまり、そのメッセージの処理を進める）。クライアントは、ＴＲＡＮモードを指定してリクエストメッセージを発した場合、ＣＯＭＭＩＴコマンドを発しない限り、そのリクエストメッセージを後で撤回したり修正したりすることが可能である。
図１７のステップ１６３の判断の結果がＮＯＮ−ＴＲＡＮモードである場合、メッセージキュー管理機能１０４は、その受信したメッセージがＰ ｔｏ Ｐ通信のものかＰ ｔｏ Ｍ通信のものかを判断する（１６５）。その判断の結果がＰ ｔｏ Ｐ通信である場合、メッセージキュー管理機能１０４は、その受信したメッセージをキューに入れる（１６７）。キューに入れられたメッセージは、すぐに読み出されてフレームワークサービスへ送られてそこで処理される。その処理の結果として、フレームワークサービスから後続処理のリクエストメッセージが返された場合、メッセージキュー管理機能１０４は、その後続処理のリクエストメッセージをＤＢキューに入れる（１６９）。そして、メッセージキュー管理機能１０４は、その受信メッセージの処理結果を示す成功メッセージをクライアントへ返す（１７１）。
ステップ１６５の判断の結果がＰ ｔｏ Ｍ通信である場合、メッセージキュー管理機能１０４は、その受信したメッセージの優先順位（図２）が“Ｈ”、“Ｎ”又は“Ｌ”の何れであるか判別し（１７３）、そして、判別された優先順位に対応したリングバッファに、その受信メッセージを格納する（１７５、１７７又は１７９）。リングバッファに入れられたＰ ｔｏ Ｍメッセージは、それを待ち受ける全てコンピュータシステムに送信されることになる。そして、メッセージキュー管理機能１０４は、その受信メッセージについて成功メッセージをクライアントへ返す（１８１）。
ステップ１６３の判断結果がＮＯＮ−ＴＲＡＮモードであった場合、処理は図８に示すステップ１８１へ進む。ステップ１８１で、メッセージキュー管理機能１０４は、その受信メッセージを上述したメッセージキューとは別の一時キューに格納する．その後、クライアントから、その受信メッセージに関してＣＯＭＭＩＴコマンドを受信すると、メッセージキュー管理機能１０４は、一時キューからそのメッセージを取り出して、そのメッセージについてステップ１８５以降の処理を行う。ステップ１８５以降の処理は、既に説明した図７中のステップ１６５以降の処理と同じである。
図１９は、メッセージキュー管理機能１０４のメッセージ読出機能を示す。
図１９に示すように、メッセージングサービス１５のメッセージキュー管理機能１０４は、クライアント及びフレームワークサービス１６からそれぞれ受信したメッセージを、上述したような構成をもつメッセージキュー１５ａに蓄積する。メッセージキュー管理機能１０４は、メッセージキュー１５ａのうち特に図１６に示したメモリキュー１５３及びＤＢキュー１５５からメッセージを取り出す動作に関して、優先モード１０４ａとシーケンス保証モード１０４ｂの２種類の機能を有している。優先モード１０４ａは、メッセージの優先順位に基づいてメッセージキューからのメッセージの取り出し順序を制御する。一方、シーケンス保証モード１０４ｂは、メッセージキューから先に取り出されたメッセージの処理がフレームワークサービスにおいて完了するまで、当該メッセージキューに蓄積されている後続のメッセージの取り出しを禁止することにより、複数メッセージの一定の処理順序を保証する。各メッセージのサブジェクトＩＤ）に応じて、又は予め設定された各メッセージキューのモード設定に応じて、各メッセージキューについて優先モード１０４ａを実行するか、シーケンス保証モード１０４ｂを実行するか、が選択される。シーケンス保証モード１０４ｂは、例えば、複数のクライアントからそれぞれ売上処理のリクエストメッセージが来たとき、先にリクエストされた売上処理が完了した後に後から来た売上処理のリクエストを実行するというような一定の処理順序を保証したい場合に、適用される。
図２０は、優先モード１０４ａのための記憶域の構成を示す。図２１は、優先モード１０４ａの動作の流れを示す。
図２０に示すように、優先モード１０４ａは、ソータブルスタック２１１とシンプルタック２１３という２つのスタックメモリと、“Ｈ”、“Ｎ”及び“Ｌ”という３つの優先順位にそれぞれ対応した例えば３つのエントリ２１５Ｈ、２１５Ｎ及び２１５Ｌとを使用する。なお、エントリの数をもっと多くすることもできる。例えば、図示の３つのエントリの他に、“Ｈ”に対応したエントリをもう一つ追加するというようにである。
初期的に、各エントリ２１５Ｈ、２１５Ｎ及び２１５Ｌには、それぞれ、インデックスとして、例えば図示のような“５”、“３”及び“１”という数値が設定される。インデックスの初期値が大きいほど、優先的レベルが高いことを意味する。
そして、初期的に、全てのエントリ２１５Ｈ、２１５Ｎ及び２１５Ｌが、図示のようにソータブルスタック２１１に積まれ、一方、シンプルスタック２１３は空である。
ソータブルスタック２１１は、そこに積まれている複数のインデックスの配列を、インデックスの大きい順に、最も大きいインデックスをもったエントリが一番上に、最も小さいインデックスをもったエントリが一番下になるように、自動的に並べ替える。従って、ソータブルスタック２１１からは、インデックスのより大きいエントリほど、より先に取り出される。
シンプルスタック２１３は、単純に、後から入れられたエントリを先に入れられたエントリの上に積む。従って、シンプルスタック２１３からは、入れられた時がより後のエントリほど、より先に取り出される。
優先モード１０４ａは、図２１に示すフローに従って、ソータブルスタック２１１とシンプルスタック２１３との間でのエントリの移動と、エントリのインデックスの操作を行なうことにより、メッセージキュー（メモリキュー１５３又はＤＢキュー１５５）からメッセージを取り出す順序を制御する。
以下、図２１に示す流れを説明する。まず、優先モード１０４ａは、ソータブルスタック２１１から、一番上の（つまり、インデックスが最も大きい）１つのエントリを取り出し（２２１）、そのエントリをシンプルスタック２１３に積む（２２３）。次に、優先モード１０４ａは、シンプルスタック２１３の一番上のエントリの優先順位とマッチするメッセージがメッセージキューに有るか否かをチェックする（２２５）。その結果、マッチするメッセージが無ければ、処理はステップ２２１へ進む。また、上記チェックの結果、マッチするメッセージが有れば、優先モード１０４ａは、そのマッチしたメッセージをメッセージキューから取り出す（２２７）。取り出されたメッセージは、何れかのフレームワークシステムにて処理されることになる。その後、優先モード１０４ａは、シンプルスタック２１３内のエントリ数が１つか否かをチェックする（２２９）。その結果、シンプルスタック２１３内のエントリ数が２つ以上であれば、シンプルスタック２１３から全てのエントリを順に取り出してソータブルスタック２１１に積む（２３７）。そして、優先モード１０４ａは、ステップ２２７でメッセージキューから取り出したメッセージについて、フレームワークシステムからの処理結果を示すリプライメッセージをクライアントへ返す（２３９）。
ステップ２２９でのチェックの結果、シンプルスタック２１３内のエントリ数が１つである場合、優先モード１０４ａは、シンプルスタック２１３内のエントリのインデックスを１だけ減らす（２３１）。そして、優先モード１０４ａは、その減らされたインデックスが“−１”であるかどうかチェックし（２３３）、“−１”でなければ、処理をステップ２３７へ進め、一方、“−１”であれば、そのインデックスを初期値に戻して（２３５）から、処理をステップ２３７へ進める。
以上の操作により、メッセージキュー内のメッセージの並び順序をそれらのメッセージの優先順位を考慮して修正した順序で、メッセージキューからメッセージの取り出されることになる。すなわち、メッセージキューに入っているメッセージの順序が、優先順位において、例えば図２０に示すような“Ｈ”、“Ｈ”、“Ｌ”、“Ｈ”、“Ｈ”、“Ｈ”、“Ｎ”であった場合、そのメッセージキューから取り出されるメッセージの順序は、優先順位において、“Ｈ”、“Ｈ”、“Ｎ”、“Ｈ”、“Ｈ”、“Ｈ”、“Ｌ”となる。
図２２は、シーケンス保証モード１０４ｂの動作の流れを示す。
図２２に示すように、シーケンス保証モード１０４ｂは、メッセージの取り出し要求が生じると（２４１）、まず、メッセージキューをロックして（２４３、２４５、２５７）、メッセージキューからの他のメッセージ取り出しを禁止する。次に、シーケンス保証モード１０４ｂは、メッセージキューから１つのメッセージを読出す（２４７、２４９）。読み出されたメッセージは、何れかのフレームワークシステムで処理され（２５１）、その処理により然るべきデータベースの更新のコミット（又は処理失敗の場合にはロールバック）が行われる（２５３）。その後、シーケンス保証モード１０４ｂは、メッセージキューのロックを解除する（２５５）。
上記の操作により、先行するメッセージの処理が完了した後に、次のメッセージの処理が実行されるため、メッセージの一定の処理順序が保証される。
図２３は、フレームワークサービス１６のメッセージ判別機能を示す。
図２３に示すように、フレームワークサービス１６は、メッセージ判別ビジネスロジック１０６を有し、メッセージングサービス１５からメッセージを受け取ると、メッセージ判別ビジネスロジック１０６を実行する。メッセージ判別ビジネスロジック１０６は、その受信メッセージのサブジェクトＩＤにマッチするサブジェクトＩＤが書かれた定義センテンスを、そのフレームワークシステム１６に関連付けられたフロー定義ファイル２３から探す。マッチした定義センテンスが見つかれば、次に、その定義センテンスに記述されている実行ビジネスロジック２２が実行されることになる。しかし、マッチした定義センテンスが見つからなければ、メッセージ判別ビジネスロジック１０６は、処理できない旨のエラーのリプライメッセージをメッセージングサービス１５へ返信し、そのリプライメッセージはクライアントへ送られる。既に説明したように、メッセージングサービス１５は、管理テーブル１８（図４）に基づいて、各メッセージをそのメッセージを待ち受けるコンピュータシステムにのみ送信するから、原則的には、或るメッセージが誤ったフレームワークシステムに送られることはない。しかし、万が一、クライアントからの或るメッセージが誤ったフレームワークサービスに送られることが発生したとしても、クライアントは直ちに処理できない旨のエラーのリプライメッセージを受け取れるので、長々と待たされること無く、速やかに次の行動に移ることができる。また、フレームワークサービス１６は、予め登録された識別情報を有するメッセージに限ってフレームワークサービスでの処理を許可するサービス停止中モードを備え、当該モードが設定されている場合に予め登録されていない識別情報を有するメッセージをクライアントから受信した場合は、当該メッセージを受け付けない旨のメッセージをクライアントに返信する。
図２４は、フレームワークサービスがもつメッセージ変換ビジネスロジックを示す。
図２４に示すように、フレームワークサービス１６は、１又はそれ以上のメッセージ変換ビジネスロジック１０５を有している。それらのメッセージ変換ビジネスロジック１０５は、例えば、図１３に示したフロー定義ファイル２３の定義センテンス２３３及び２３４に記述された“ＣｎｖＢｕｙＵｐｄＢｕｙ”、“ＣｎｖＢｕｙＩｎｓＢｕｙ１”及び“ＣｎｖＢｕｙＩｎｓＢｕｙ２”などである。各メッセージ変換ビジネスロジック１０５は、予め定められた１つのビジネスロジックＢＬ１に対応していうる。或る定義センテンスに従って或るビジネスロジックＢＬ１が実行されると、引き続いて、これに対応したメッセージ変換ビジネスロジック１０５が実行される。メッセージ変換ビジネスロジック１０５は、先行のビジネスロジックＢＬ１から出力される処理結果のメッセージの形式を、後続のビジネスロジックＢＬ２への入力メッセージの形式に適合させるフォーマット変換機能と、先行のビジネスロジックＢＬ１から出力されたメッセージのパラメータに応じて、このメッセージを後続ビジネスロジックＢＬ２に入力するか否かを判定するメッセージフィルタリング機能とを備えている。例えば、先行のビジネスロジックＢＬ１が扱うメッセージのパラメータ配置と、後続ビジネスロジックＢＬ２が扱うメッセージのパラメータ配置が異なる場合、メッセージ変換ビジネスロジック１０５は、前者のパラメータ配置を後者のパラメータ配置に変換する。また、先行ビジネスロジックＢＬ１の出力メッセージの内容が特別のもの（例えば、リクエストの拒否、データベースの更新失敗、トランザクションのロールバックなど）であり、そのため、後続のビジネスロジックＢＬ２の実行が無意味であるという場合がある。そのような場合、メッセージ変換ビジネスロジック１０５は、メッセージフィルタリング機能により、後続ビジネスモデルＢＬ２への入力メッセージの生成をオミットする。ここで、先行ビジネスロジックＢＬ１とメッセージ変換ビジネスロジック１０５との間、又はメッセージ変換ビジネスロジック１０５と後続のビジネスロジックＢＬ２との間には、メッセージを一時保持するメッセージキューを介在させてもよい。
以上の説明は、本発明の説明のための例示にすぎない。本発明は、上述した実施形態のみに限らず、他の多くのシステム構成のバリエーションにおいても実施することができる。
【図面の簡単な説明】
図１は、本実施形態の全体構成図である。
図２は、ＲｔＦＡサーバ１４が取り扱うメッセージの構成を示すブロック図である。
図３は、ＲｔＦＡサーバ１４の構成図である。
図４は、メッセージングサービス１５に関係付けられる管理テーブル１８の例を示す。
図５は、複数のＲｔＦＡサーバ間の接続構成図である。
図６は、複数のメッセージングサービス間の接続構成図である。
図７は、Ｐ ｔｏ Ｍ（１対多）通信処理のメッセージ中継方法を示す説明図である。
図８は、Ｐ ｔｏ Ｍ通信処理の一例を示すフローチャートである。
図９は、Ｐ ｔｏ Ｐ（１対１）通信処理を示すフローチャートである。
図１０は、メッセージングサービスのロードバランシング機能の説明図である。
図１１は、フレームワークサービスの構成を示すブロック図である。
図１２は、フレームワークサービスの動作説明図である。
図１３は、フロー定義ファイルの簡単な例を示す。
図１４は、フロー定義ファイルの更新システムを示すブロック図である。
図１５は、フレームワークサービスのメッセージ変換処理機能を示すブロック図である。
図１６は、メッセージングサービスのメッセージキューの構成を示すブロック図である。
図１７は、メッセージキュー管理機能がメッセージキューにメッセージを格納する動作を示すフローチャートである。
図１８は、図１７のフローチャートの続きである。
図１９は、メッセージキュー管理機能のメッセージ読出機能を示すブロック図である。
図２０は、優先モードのための記憶域の構成を示す。
図２１は、優先モードの動作の流れを示す。
図２２は、シーケンス保証モードの動作の流れを示す。
図２３は、フレームワークサービスのメッセージ判別機能を示すブロック図である。
図２４は、フレームワークサービスのメッセージ変換ビジネスロジックを示すブロック図である。
本発明は、クライアントからのメッセージに応答して、選択された１又はそれ以上のビジネスロジックを実行するフレームワークシステムに関する。
技 術 背 景
この種のフレームワークシステムは、典型的には、１又はそれ以上のクライアントと通信可能に接続される１又はそれ以上のサーバによって構成される。この種のフレームワークシステムには、従来からメッセージングサービスと、フレームワークサービスという２つの基本機能が提供されている。メッセージングサービスは、クライアントとサーバ間及びサーバとサーバ間のメッセージ通信を処理するサービスである。フレームワークサービスは、通常複数のビジネスロジック（業務処理プロセス）を有しており、クライアントからのメッセージに応答して、選択された１又はそれ以上のビジネスロジックを同期方式で又は非同期方式で実行することによりトランザクションを遂行する。
しかしながら、上記従来例にあっては、フレームワークサービスにおけるビジネスロジックの処理スケジュールが固定的にプログラムされている。そのため、多種多様なメッセージに応じて複雑なビジネスロジックのフローを柔軟に定義することが困難である。
また、クライアントからのメッセージに応答して、複数のビジネスロジックを逐次に実行する場合がある。例えば、クライアントからの仕入登録リクエストに応答して、仕入登録や在庫更新や買掛金記帳などを行う場合である。このような場合、従来システムでは、例えば仕入登録のようなフロントデスクに関わるビジネスロジックはそのメッセージに同期して実行するが、在庫更新や買掛金記帳のようなバックオフィスに関わるビジネスロジックは夜間のバッチ処理により実行する。そのため、バックオフィスの処理の結果は、翌日まで待たないと参照できない。しかし、新たな取引のチャンスをいち早くキャッチするには、バックオフィスのビジネスロジックも可能な限り早期に実行してその結果が早期に参照できることが望ましい。
また、複数のフレームワークサーバを備えたシステムでは、フレームワークサーバ相互間でもメッセージを送受しながら協働して、一連のビジネスロジックを実行していく。各サーバのステータス（例えば、保有するビジネスロジックの種類、正常に稼動しているか否か、ビジーか否か、など）は、他のサーバとは違うのが普通であり、且つ、時間経過に伴って変化もする。このことは、ビジネスロジックの実行をどのサーバに依頼するかを決めるスケジューリングを複雑にする。
発 明 の 開 示
本発明は、ビジネスロジックフローを、プログラムすることなく、定義し変更することが容易なフレームワークシステムを提供することを目的とする。
本発明の別の目的は、一連のビジネスロジックを、完全にリアルタイムではなくても、できるだけリアルタイムに近い態様で、実行することができるフレームワークシステムを提供することにある。
本発明の更に別の目的は、複数のフレームワークサーバを備えたシステムにおいて、一連のビジネスロジックのスケジューリングを、それらサーバのステータスに応じて適切に行えるようにすることにある。
本発明の一つの観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、複数のビジネスロジックと関連付けられ、クライアントからのリクエストのメッセージに応答して、選択された１又はそれ以上のビジネスロジックを実行し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスと；フレームワークサービスに関連付けられたフロー定義ファイルとを備える。リクエストのメッセージは、そのメッセージのサブジェクトに関するサブジェクトＩＤを含んでいる。フロー定義ファイルは、複数の異なるサブジェクトＩＤにそれぞれ対応した複数の定義センテンスを含んでおり、各定義センテンスは所定の１又はそれ以上のビジネスロジックのための実行スケジュールを記述している。フレームワークサービスは、メッセージングサービスからリクエストのメッセージを受け取ると、定義ファイル内の受信されたメッセージのサブジェクトＩＤに対応した定義センテンスを参照し、参照された定義センテンスに記述された実行スケジュールに従って、実行するべき１又はそれ以上のビジネスロジックを選択する。
好適な実施形態では、フレームワークシステムは、フレームワークサービスが稼動している間に、フロー定義ファイルを更新するフロー定義更新コンポーネントを更に備える。
好適な実施形態では、また、フロー定義ファイルには、一つの先行のビジネスロジックと少なくとも一つの後続のビジネスロジックとを含む複数のビジネスロジックの連係された実行のための連係実行スケジュールを記述した定義センテンスを含むことができる（勿論、連係実行スケジュールを定義した定義センテンスを含まなくてもよい）。その連係実行スケジュールは、後続のビジネスロジックの実行に関して同期方式と非同期方式の選択に関する連係モードを含んでいる。そして、フレームワークサービスは、連係実行スケジュールに従って複数のビジネスロジックを実行する場合、連係実行スケジュール内の連係モードに従って、先行のビジネスロジックの実行と同期的に又は非同期的に、後続のビジネスロジックを実行する。
好適な実施形態では、連係実行スケジュールは、先行のビジネスロジックに関する情報と、後続のビジネスロジックのための第２のリクエストのメッセージに関する情報とを含む。そして、フレームワークシステムは、連係実行スケジュールに従って複数のビジネスロジックを実行する場合、先行のビジネスロジックを実行した後、先行のビジネスロジックの実行結果を用いて第２のリクエストのメッセージを生成して、その第２のリクエストのメッセージをメッセージングサービスに送る。その後、フレームワークシステムは、メッセージングサービスから上記第２のリクエストのメッセージを受けると、その第２のリクエストのメッセージに対応する定義センテンスの実行スケジュールに従って、後続のビジネスロジックを実行する。
好適な実施形態では、また、メッセージングサービスが、前記第２のリクエストのメッセージを保証する為の不揮発性のメッセージキューを備える。このメッセージキューは、第２のリクエストメッセージがフレームワークサービスへ送られた後も、その第２のリクエストメッセージを消さずに保存する。そして、メッセージグサービスは、その不揮発性のメッセージキューで保存されている第２のリクエストのメッセージを、必要に応じて、フレームワークシステムへ再送信することができる。
本発明の別の観点に従うクライアントと通信可能に接続されるフレームワークシステムは、クライアントからのリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスとを備える。そして、メッセージングサービスは、上記リクエストとリプライのメッセージのようなＰ ｔｏ Ｐ通信のメッセージだけでなく、クライアントとフレームワークサービスとの間のＰ ｔｏ Ｍ通信のメッセージをも中継する。
好適な実施形態では、メッセージングサービスが、Ｐ ｔｏ Ｍ通信のメッセージを一時的に待たせるためのリングバッファを有する。
好適な実施形態では、また、Ｐ ｔｏ Ｐ通信のメッセージの各々には、メッセージ保証の要否に関する保証モードが含まれている。そして、メッセージングサービスは、メッセージ保証が不要なＰ ｔｏ Ｐ通信のメッセージを一時的に待たせるための第１のメッセージキューと、メッセージ保証が必要なＰ ｔｏ Ｐ通信のメッセージを一時的に待たせるための不揮発性の第２のメッセージキューとを有する。
本発明のまた別の観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、クライアントと接続された少なくとも一つのメッセージングサービスを含んだ、相互にメッシュ接続されている複数のメッセージングサービスと；複数のメッセージングサービスにそれぞれ接続された複数のフレームワークサービスとを備える。そして、複数のフレームワークサービスの各々は、予め定められたサブジェクトＩＤをもったリクエストのメッセージを待ち受け、その予め定められたサブジェクトＩＤをもったリクエストのメッセージを受信すると、受信されたリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力することができる。そして、上記複数のメッセージングサービスは、クライアントと上記複数のフレームワークサービスの間でのメッセージの中継、及び、上記複数のフレームワークシステム相互間でのメッセージの中継を行う。
好適な実施形態では、各メッセージングサービスが、他の１又はそれ以上のメッセージングサービスの稼動を監視し、他の或るメッセージングサービスについて正常な稼動を検出できなかった場合は、その正常に稼動してないメッセージングサービスへメッセージを中継する代わりに、他の正常に稼動しているメッセージングサービスへメッセージを中継する。
好適な実施形態では、また、各メッセージングサービスが、各々に接続されたフレームワークサービスの状態を監視し、監視された状態に応じて、クライアントからのリクエストのメッセージを上記フレームワークサービスに中継するか、他の何れかのメッセージングサービスに中継するかを、選択する。
好適な実施形態では、また、各メッセージングサービスは独自の管理テーブルを有し、各管理テーブルには、各メッセージングサービスに接続されたフレームワークシステムが待ち受けるメッセージのサブジェクトＩＤ、及び、各メッセージングサービスに接続された他の１又はそれ以上のメッセージングサービスがそれぞれ待ち受けるメッセージのサブジェクトＩＤが登録されている。そして、各メッセージングサービスは、メッセージを受信したとき、それ独自の管理テーブルを参照して、受信されたメッセージのサブジェクトＩＤにマッチするサブジェクトＩＤを待ち受けるフレームワークサービス又は他のメッセージングサービスを探し、見つかったフレームワークサービス又は他のメッセージングサービスへ、受信されたメッセージを中継する。
好適な実施形態では、さらに、各メッセージングサービスは、それ独自の管理テーブルの内容に基づいて、そのメッセージングサービスが待ち受けるメッセージのサブジェクトＩＤを、他の１又はそれ以上のメッセージングサービスに通知する。その通知を受けた他のメッセージングサービスの各々は、通知された内容が、それ独自の管理テーブルに未だ登録されていなければ、その通知内容を、それ独自の管理テーブルに追加登録する。
本発明の更に別の観点に従う、クライアントと通信可能に接続されるフレームワークシステムは、クライアントからのリクエストのメッセージを処理し、そして、クライアントへのリプライのメッセージを出力するフレームワークサービスと；クライアントとフレームワークサービスとの間に介在し、クライアントとフレームワークサービスとの間でメッセージを中継するメッセージングサービスとを備える。クライアントからのリクエストのメッセージは所与の優先順位を有している。そして、メッセージングサービスは、上記リクエストのメッセージを一時的に待たせるためのメッセージキューと、メッセージキューの入出力を管理するキュー管理コンポーネントとを備える。キュー管理コンポーネントは、メッセージキューに複数のメッセージが蓄積されているとき、各メッセージの優先順位に応じて、複数のメッセージのメッセージキューからの出力順序を制御する優先モードと；メッセージキューに複数のメッセージが蓄積されているとき、メッセージキューから先に取り出されたメッセージの処理が前記フレームワークサービスにおいて完了するまで、メッセージキューに蓄積されている他のメッセージの取り出しを禁止するシーケンス保証モードとを備える。
発明を実施するための最良の形態
以下、本発明の一実施形態を図面を参照して説明する。図１は、本実施形態の全体構成を示す。
本システムは、プレゼンテーション層１、ビジネスロジック層２、及びデータサービス層３から構成されている。
プレゼンテーション層１は、ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）クライアント１１、ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバ１２、又はＶＢ（Ｖｉｓｕａｌ Ｂａｓｉｃ）クライアント１３を含んでいる。
ビジネスロジック層２には、本発明の原理に従うフレームワークアークテクチャ（この明細書では「ＲｔＦＡ：Ｒｅａｌ Ｔｉｍｅ Ｆｒａｍｅｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ」という）が適用されたサーバコンピュータシステムであるＲｔＦＡサーバ１４が設けられている。ＲｔＦＡサーバ１４は、メッセージングサービスを行うサーバコンピュータシステム（以下、簡単に「メッセージングサービス」という）１５と、フレームワークサービスを行うサーバコンピュータシステム（以下、簡単に「フレームワークサービス」という）１６とを備えている。典型的には、メッセージングサービス１５とフレームワークサービス１６は、それぞれ、別のコンピュータマシン又は別のコンピュータマシンのセットを用いて具現化される。しかし、必ずしもそうでなければならないわけではなく、同一のコンピュータマシン又はコンピュータマシンのセットを用いて、メッセージングサービス１５とフレームワークサービス１６の双方がインプレメントされることも可能である。
メッセージングサービス１５は、クライアント１１，１３とＲｔＦＡサーバ１４間のメッセージのやり取りを制御する。すなわち、メッセージングサービス１５は、クライアント１１，１３から、或る処理のためのリクエストのメッセージを受信し、そのリクエストのメッセージを、リクエストされた処理を行なうことができるフレームワークサービス１６に渡す。また、メッセージングサービス１５は、フレームワークサービス１６から、実行された処理の結果を示すリプライのメッセージを受信し、更に、場合によっては、後続の追加の処理のための追加のリクエストのメッセージも受信する。そして、メッセージングサービス１５は、そのリプライのメッセージをクライアント１１，１３に送ったり、追加のリクエストのメッセージをフレームワークサービス１６に再び渡したりする。
メッセージングサービス１５によって取り扱われる全てのメッセージの各々には、そのメッセージのサブジェクト（例えば、仕入登録リクエスト、在庫更新リクエスト、買掛登録リクエストなど）を示す識別コードであるサブジェクトＩＤが含まれている。このサブジェクトＩＤは、後述するように、メッセージングサービス１５又はフレームワークサービス１６によって、そのメッセージの宛先を選択する目的に利用され、そのため、「宛先サブジェクトＩＤ」とも呼ばれる。
フレームワークサービス１６は、様々な種類のメッセージをそれぞれ処理するための複数のビジネスロジック（例えば、仕入処理ビジネスロジック、在庫処理ビジネスロジック、買掛処理ビジネスロジック、メッセージ変換ビジネスロジックなど）を有している。フレームワークサービス１６は、メッセージングサービス１５から或るメッセージを受け取ると、そのメッセージのサブジェクトＩＤからそのメッセージを処理するためのビジネスロジックを選び、その選んだビジネスロジックを呼び出しす。呼び出されたビジネスロジックは、そのメッセージの内容に応じた処理を行い、データサービス層９のデータを更新する。メッセージングサービス１５及びフレームワークサービス１６のためのコンピュータプログラムは、例えば、ＪＡＶＡ言語（商標）によって記述されている。
データサービス層３は、データベースサーバ（ＤＢサーバ）１７を備えている。
ウェブクライアント１１とウェブサーバ１２の間にはＨＴＴＰ又はソケットによる通信コネクションが確立され得る。ウェブクライアント１１とＲｔＦＡサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。ＶＢクライアント１３とＲｔＦＡサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。また、ウェブサーバ１２とＲｔＦＡサーバ１４との間には、ソケットによる直接的な通信コネクションが確立され得る。更に、ＲｔＦＡサーバ１４とＤＢサーバ１７との間にはＪＤＢＣによる通信コネクションが確立され得る。
図２は、ＲｔＦＡサーバ１４が取り扱うメッセージの構成を示す。
図２に示すように、メッセージ１０は、複数のサーバ制御項目と業務データとから構成される。サーバ制御項目は、ＲｔＦＡサーバ１４を制御するための各種のデータであり、例えば、メッセージ種別、保証モード、優先順位、サブジェクトＩＤ（宛先サブジェクトＩＤ）及び送信元情報などが含まれている。
「メッセージ種別」は、そのメッセージがＰ ｔｏ Ｐ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ）通信のメッセージであるか、Ｐ ｔｏ Ｍ（Ｐｏｉｎｔ ｔｏ Ｍａｎｙ）通信のメッセージであるかを区別する。ここで、Ｐ ｔｏ Ｐ通信とは、或る１つのコンピュータシステムから別の１つのコンピュータシステムへとメッセージが送られる通信、つまり、１対１通信のことをいう。Ｐ ｔｏ Ｐ通信の一例は、或るクライアントからの仕入登録リクエストのメッセージを、仕入処理を実行する或る一つのフレームワークサービスへ送る場合である。一方、Ｐ ｔｏ Ｍ通信とは、或る１つ又は複数のコンピュータシステムから別の複数のコンピュータシステムへとメッセージが送られる通信、つまり、１対複数又は複数対複数の通信のことをいう。Ｐ ｔｏ Ｍ通信の一例は、或る１つのフレームワークサービスからの在庫更新結果を示すメッセージを、フロントデスクの仕事を担う複数のクライアント端末へ送信する場合である。
「保証モード」は、メッセージ保証（すなわち、そのメッセージが確実に送信及び処理されることの保証）をする（“Ｇ”）か否か（“Ｎ”）を区別する。保証モードが“Ｎ”のメッセージを受信したとき、メッセージングサービス１５は、そのメッセージを、揮発性の半導体メモリを用いたメッセージキュー（以下、「メモリキュー」という）に入れる。一方、保証モードが“Ｇ”のメッセージを受信したとき、メッセージングサービス１５は、そのメッセージを、不揮発性のディスクストレージを用いたメッセージキュー（以下、「ＤＢ（データベース）キュー」という）に入れ、そのメッセージを送信した後も、そのメッセージをＤＢキューで保存しておく。従って、保証モードが“Ｇ”のメッセージについては、送信失敗やシステムダウンなどの問題が生じたとしても、後に再度、同じメッセージを送信することができる。
「優先順位」は、そのメッセージの処理の優先レベルを示す。例えば、ハイ（“Ｈ”）、ノーマル（“Ｎ”）及びロー（“Ｌ”）の３種類の優先順位がある。後述するように、メッセージングサービス１５は、メッセージキュー内で複数のメッセージが待っているとき、それらのメッセージをメッセージキューから取り出す順序を、それらのメッセージのそれぞれの優先順位に応じて制御することができる。
「サブジェクトＩＤ（宛先サブジェクトＩＤ）」は、既に述べたとおり、そのメッセージのサブジェクトの種別を示す識別コードである。後述するように、メッセージングサービス１５は、メッセージを受信すると、そのメッセージのサブジェクトＩＤに基づいて、そのメッセージの宛先となるべきコンピュータシステム（例えば、クライアント、フレームワークシステム、他のメッセージングサービスなど）を選択する。また、フレームワークサービス１６は、メッセージを受信すると、そのメッセージのサブジェクトＩＤに基づいて、そのメッセージを処理するために呼び出すべきビジネスロジックを選択する。
「送信元情報」は、そのメッセージの送信元のサブジェクトやＩＰアドレスやコンピュータ名などを表す。
図３は、ＲｔＦＡサーバ１４の構成図である。
既に参照した図１では、１つのＲｔＦＡサーバ１４しか示されていなかった。しかし、実際には、図３に示すように、複数のＲｔＦＡサーバ１４を設けることができる。図３に示す例では、２つのＲｔＦＡサーバ１４が設けられているが、もっと多くのＲｔＦＡサーバ１４を設けることができる。
図３に示すように、各ＲｔＦＡサーバ１４には、一つのメッセージングサービス１５と、１又は複数のフレームワークサービス１６が設けられ、メッセージングサービス１５とフレームワークサービス１６は相互に通信可能に接続されている。メッセージングサービス１５は、また、１又は複数のクライアント１１，１３とも通信可能に接続されている。メッセージングサービス１５は、クライアント１１，１３及びフレームワークサービス１６とそれぞれ通信する複数のスレッド１７１を並列に処理している。
複数のＲｔＦＡサーバ１４が存在するので、メッセージングサービス１５とフレームワークサービス１６の組は複数組存在している。そして、複数のＲｔＦＡサーバ１４のメッセージングサービス１５は、相互に通信可能に接続されている。各ＲｔＦＡサーバ−１４のメッセージングサービス１５は、他のＲｔＦＡサーバ１４のメッセージングサービス１５との通信を処理するスレッド１７１も備えている。各メッセー−ジングサービス１５が持つ複数の通信スレッド１７１は、それぞれキープアライブ機能を有し、この機能により、そのメッセ−ジングサービス１５にコネクションされたクライアント１１，１３、他のメッセージングサービス１５、及びフレームワークサービス１６と相互の正常な稼動を確認しあっている。
また、各メッセージングサービス１５には、図４に例示するような管理テーブル１８が関連付けられている。管理テーブル１８には、そのメッセージングサービス１５が伝達すべきメッセージの経路、換言すれば、そのメッセージングサービス１５が取り扱う様々なメッセージの送り先、が管理される。図４に示すように、管理テーブル１８には、そのメッセージングサービス１５に接続された全てのコンピュータシステム（クライアント１１，１３、他のメッセージングサービス１５、及びフレームワークサービス１６）の各々について、種別、コンピュータＩＤ、ＩＰアドレス、Ｐ ｔｏ ＰサブジェクトＩＤ、Ｐ ｔｏ ＭサブジェクトＩＤ及び処理中フラグなどが登録される。
「種別」は、そのコンピュータシステムの種別、例えば、フレームワークサービス（Ｆ）、メッセージングサービス（Ｍ）、クライアント端末ターミナル（Ｔ）の区別を示す。
「コンピュータＩＤ」及び「ＩＰアドレス」は、そのコンピュータシステムの固有の識別コードとＩＰアドレスを示す。
「Ｐ ｔｏ ＰサブジェクトＩＤ」は、そのコンピュータシステムが待ち受ける（つまり、そのコンピュータシステムが、そのメッセージの宛先になり得る）Ｐ ｔｏ Ｐ通信用のメッセージのサブジェクトＩＤ（宛先サブジェクトＩＤ）を示す。各コンピュータシステムごとに、複数のＰ ｔｏ ＰサブジェクトＩＤを登録することができる。
「Ｐ ｔｏ ＭサブジェクトＩＤ」は、そのコンピュータシステムが待ち受ける（つまり、そのコンピュータシステムが、そのメッセージの宛先になり得る）Ｐ ｔｏ Ｍ通信用のメッセージのサブジェクトＩＤ（宛先サブジェクトＩＤ）を示す。各コンピュータシステムごとに、複数のＰ ｔｏ ＭサブジェクトＩＤを登録することができる。
「処理中フラグ」は、そのコンピュータシステムとの通信のためのスレッド１７１が、Ｐ ｔｏ Ｐ通信の処理中である（「１」）か否（「０」）かを示す。
図４に示した管理テーブル１８の登録内容は、図３中の左側のメッセージングサービスＭｅｓ１の場合の例であり、そこには、左側のメッセージングサービスＭｅｓ１に接続された全てのコンピュータシステム、すなわち、２つのフレームワークサービスＦｒｍ１、Ｆｒｍ２、右側のメッセージングサービスＭｅｓ２及び３つのクライアント端末ＰＣ１、Ｐｃ２及びＰＣ３が登録されている。この例によれば、１番目のフレームワークサービスＦｒｍ１は、Ｐ ｔｏ Ｐ通信に関しては“Ａ”、“Ｂ”、“Ｃ”及び“Ｄ”というサブジェクトＩＤをそれぞれもった４種類のメッセージを待ち受けており、また、Ｐ ｔｏ Ｍ通信に関しては“０”、“Ｐ”、“Ｑ”及び“Ｒ”というサブジェクトＩＤをそれぞれもった４種類のメッセージを待ち受けている。また、図中右側のメッセージングサービスＭｅｓ２は、左側のメッセージングサービスＭｅｓ１からのＰ ｔｏ Ｐ通信のメッセージとして、“Ｄ”、“Ｅ”、“Ｆ”、“Ｈ”、“Ｉ”及び“Ｊ”というサブジェクトＩＤをそれぞれもった７種類のメッセージを待ち受けており、また、左側のメッセージングサービスＭｅｓ１からのＰ ｔｏ Ｍ通信のメッセージとして“Ｐ”、“Ｑ”、“Ｒ”、“Ｓ”、“Ｔ”及び“Ｕ”というサブジェクトＩＤをそれぞれもった６種類のメッセージを待ち受けている。
再び図３を参照して、各メッセージングサービス１５は、メッセージを受信すると、そのメッセージがＰ ｔｏ Ｐ通信のものかＰ ｔｏ Ｍ通信のものかを判断する。Ｐ ｔｏ Ｐ通信のメッセージを受信したときは、メッセージングサービス１５は、そのメッセージングサービス１５に関連付けられている図４に例示したような管理テーブル１８を参照して、その受信メッセージのサブジェクトＩＤとマッチするＰ ｔｏ ＰサブジェクトＩＤのメッセージを待ち受けているコンピュータシステムを探し、見つかった１以上のコンピュータシステムの中から処理中フラグが“０”である１つのコンピュータシステムを選び、そして、選ばれた１つのコンピュータシステムにその受信メッセージを送信する。また、Ｐ ｔｏ Ｍ通信のメッセージを受信したときは、メッセージングサービス１５は、そのメッセージングサービス１５に関連付けられている図４に示したような管理テーブル１８を参照して、その受信メッセージのサブジェクトＩＤとマッチするＰ ｔｏ ＭサブジェクトＩＤのメッセージを待ち受けてるコンピュータシステムを全て選び、そして、選ばれた全てのコンピュータシステムにそのメッセージを送信する。
図５は、複数のＲｔＦＡサーバ間の接続構成図である。図６は、複数のＲｔＦＡサーバ内のメッセージングサービスとフレームワークサービスの接続構成図である。
図５の上段又は下段に示すように、各ＲｔＦＡサーバ１４は他の全てのＲｔＦＡサーバ１４と相互に通信可能に接続されている。すなわち、図６に示すように、各ＲｔＦＡサーバ１４のメッセージングサービス１５が、他の全てのＲｔＦＡサーバ１４のメッセージングサービス１５と相互に通信可能に接続されている。このように複数のコンポーネントの各々が他の全てのコンポーネントと通信可能に接続されることを「メッシュ接続」という。また、図６に示すように、各メッセージングサービス１５に対しては複数のフレームワークサービス１６を直接連絡させることも可能である。
このように複数のメッセージングサービス１５のメッシュ接続の下で、各メッセージサービス１５は、所定の時期、例えばその起動時に、上述したキープアライブ機能を実行する。すなわち、各メッセージングサービス１５は、起動すると、自分の管理テーブル１８に既に登録されている他のメッセージングサービスの全てと逐次に接続して、自分と接続されているフレームワークシステム１６及びクライアント１１，１３が待ち受けるメッセージのサブジェクトＩＤを、接続された他のメッセージングサービスの全てに通知する。通知されたサブジェクトＩＤは、そのメッセージングサービス１５が他のメッセージングサービスから待ち受けるメッセージのサブジェクトＩＤとして、他のメッセージングサービスの管理テーブルに登録される。また、各メッセージングサービス１５は、他のメッセージングサービスと接続しようとしたときに接続できなかった場合には、その後に一定間隔で複数回接続をリトライする。また、各メッセージサービス１５は、自分の管理テーブル１８に未だ登録されていない他のメッセージングサービスから接続要求を受けたときには、その未登録のメッセージングサービスと接続して、未登録のメッセージングサービスとそれぞれが待ち受けるサブジェクトＩＤなどを交換し合い、そして、そのメッセージングサービスを自分の管理テーブル１８に登録する。このようなキープアライブ機能のおかげで、特定のメッセージングシステム１５が正常に稼動してない（例えば、システムダウンした）場合には、他の正常に稼動している各メッセージングサービス１５は、その正常に稼動してない特定のメッセージングシステム１５をメッセージの中継経路から除外し、自分の管理テーブル１８を参照して、自動的に別の中継経路を選択することができる。
次に、図７乃至図９に基づいて、メッセージングサービス１５が提供する通信サービスの種類を説明する。メッセージングサービス１５が提供するデータ配信サービスには、Ｐ ｔｏ Ｍ（１対多）通信処理と、Ｐ ｔｏ Ｐ（１対１）通信処理の２種類がある。
Ｐ ｔｏ Ｍ通信処理は、前述したように、図４に例示したような管理テーブル１８に登録されている各コンピュータシステムのＰ ｔｏ ＭサブジェクトＩＤに基づいて、メッセージングサービス１５が、受信したＰ ｔｏ Ｍメッセージを、それを待ち受ける全てのコンピュータシステムに配信する処理である。例えば、マーケット情報が更新される都度、更新されたマーケット情報のメッセージを、１乃至ｎ個のＲｔＦＡサーバからｎ個のクライアントに配信する場合に、Ｐ ｔｏ Ｍ通信処理が行われる。
一方、Ｐ ｔｏ Ｐ通信処理は、前述したように、図４に例示したような管理テーブル１８に登録されている各コンピュータシステムのＰ ｔｏ ＰサブジェクトＩＤに基づいて、メッセージングサービス１５が、受信したＰ ｔｏ Ｐメッセージを、それを待ち受けるコンピュータシステムの中の一つに送信する処理である。例えば、クライアントからの或る処理のためのリクエストのメッセージを、その処理を行うビジネスロジックを有した一つのフレームワークサービスに送る場合に、Ｐ ｔｏ Ｐ通信処理が行われる。
図７は、Ｐ ｔｏ Ｍ通信処理のメッセージ中継方法の一例を示している。パブリッシャーとしての或るフレームワークサービス１６から出力された或るＰ ｔｏ Ｍメッセージは、そのメッセージを待ち受ける全てのメッセージングサービス１５に配信され、そして、それらのメッセージングサービス１５から、そのメッセージを待ち受ける全てのクライアント１１、１３に配信される。
図８は、Ｐ ｔｏ Ｍ通信処理の一例を示すフローチャートである。まず、サブスクライバの一つであるクライアントＴ１は、所定のメッセージングサービスＭｅｓ１との間で、ソケットによるコネクションを確立する。また、クライアントＴ１から当該メッセージングサービスＭｅｓ１に対し自己が待ち受けるＰ ｔｏ ＭメッセージのサブジェクトＩＤ“Ｘ”を登録する。当該メッセージングサービスＭｅｓ１は、自己に関連付けられた管理テーブル１８に、クライアントＴ１のＰ ｔｏ ＭサブジェクトＩＤ“Ｘ”を追加する。一方、クライアントＴ１は、メッセージングサービスＭｅｓ１からのメッセージの配信を待つ。その後、メッセージングサービスＭｅｓ１に接続する他のメッセージングサービスＭｅｓ２，Ｍｅｓ３が起動したとき、メッセージングサービスＭｅｓ１の管理テーブル１８に既に登録されたクライアントＴ１のＰ ｔｏ ＭサブジェクトＩＤ“Ｘ”は、他のメッセージングサービスＭｅｓ２及びＭｅｓ３にも通知されて、それらの管理テーブル１８に、メッセージングサービスＭｅｓ１のＰ ｔｏ ＭサブジェクトＩＤとして“Ｘ”が追加される。
ここで、パブリッシャーとしてのフレームワークサービスＦｒｍ３からサブジェクトＩＤ“Ｘ”をもつＰ ｔｏ Ｍメッセージが配信されると、これを受けたメッセージングサービスＭｅｓ３は、自己に関連付けられた管理テーブル１８を参照し、サブジェクトＩＤ“Ｘ”を待ち受ける全てのメッセージングサービスＭｅｓ１及びＭｅｓ２をピックアップし、それらに当該メッセージを引き渡す。
クライアントＴ１とコネクトされたメッセージングサービスＭｅｓ１は、当該メッセージを受信すると、自己に関連付けられた管理テーブル１８からサブジェクトＩＤ“Ｘ”を待ち受けるクライアントＴ１をピックアップし、当該メッセージをそのクライアントＴ１に配信する。
図示してないが、各フレームワークサービスも、そのフレームワークサービスと直接連絡可能なメッセージングサービスへ、そのフレームワークサービスが待ち受けるＰ ｔｏ ＭメッセージのサブジェクトＩＤを通知する。それにより、そのフレームワークサービスが待ち受けるＰ ｔｏ ＭサブジェクトＩＤが、そのメッセージングサービスの管理テーブルに登録される。その後、そのメッセージングサービスは、その管理テーブルに登録されたフレームワークサービスのＰ ｔｏ ＭサブジェクトＩＤを、そのメッセージングサービスが待ち受けるＰ ｔｏ ＭサブジェクトＩＤとして、他の全てのメッセージングサービスに通知する。これにより、他の全てのメッセージングサービスの管理テーブルにも、そのフレームワークサービスが待ち受けるＰ ｔｏ ＭサブジェクトＩＤが登録されることになる。結果として、そのフレームワークサービスは、Ｐ ｔｏ ＭサブジェクトＩＤをもったメッセージを、いずれのメッセージングサービスからも受信できるようになる。
次に図９は、Ｐ ｔｏ Ｐ通信処理を示すフローチャートである。
上述したＰ ｔｏ Ｍ通信のサブジェクトＩＤの管理テーブルへの登録と同様に、各メッセージングサービスの管理テーブルには、そのメッセージングサービスが直接連絡可能なクライアント及びフレームワークサービスがそれぞれ待ち受けるＰ ｔｏ ＰサブジェクトＩＤ、並びに、他の全てのメッセージングサービスがそれぞれ待ち受けるＰ ｔｏ ＰサブジェクトＩＤが予め自動的に登録されている。
そのような状態において、図９に示すように、まず或るクライアントＰＣ１は、所定のメッセージングサービスＭｅｓ１とコネクションを確立する。
続いて、クライアントＰＣ１から或るサブジェクトＩＤ“Ａ”を持ったＰ ｔｏ Ｐのリクエストメッセージが送信されると、これを受信したメッセージングサービスＭｅｓ１は、自己の管理テーブル１８を参照して、そのサブジェクトＩＤ“Ａ”を待ち受けるコンピュータシステムの中の一つ、例えば、フレームワークサービスＦｒｍ１を選び、それに当該リクエストメッセージを引き渡す（矢印▲１▼）。フレームワークサービスＦｒｍ１は、引き受けたリクエストメッセージのサブジェクトＩＤ“Ａ”に対応したビジネスロジックを呼び出して、そのメッセージの処理を実行し、その実行結果を示すリプライメッセージをメッセージングサービスＭｅｓ１に戻す（矢印▲３▼）。そして、メッセージングサービスＭｅｓ１は、そのリプライメッセージをクライアントＰＣ１に返信する。そのリプライメッセージをを取得したクライアントＰＣ１は、メッセージングサービスＭｅｓ１とのコネクションを開放する。
或いは、メッセージングサービスＭｅｓ１は、クライアントＰＣ１から受信したサブジェクトＩＤ“Ａ”のリクエストメッセージを、上記の例のようにフレームワークサービスＦｒｍ１へ送る代わりに、サブジェクトＩＤ“Ａ”を待ち受ける他のメッセージングサービスＭｅｓ２へ送る（矢印▲２▼）こともできる。例えば、フレームワークサービスＦｒｍ１が処理中であるが、メッセージングサービスＭｅｓ２は処理中でないときには、そのようなことが行われる。その場合、メッセージングサービスＭｅｓ２は、そのリクエストメッセージを受けると、自己の管理テーブル１８を参照して、サブジェクトＩＤ“Ａ”を待ち受ける一つのコンピュータシステム、例えば、フレームワークシステムＦｒｍ２を選んで、それに当該リクエストメッセージを送って処理させる（矢印▲４▼）。フレームワークシステムＦｒｍ２から処理結果のリプライメッセージが返されると（矢印▲５▼）、メッセージングサービスＭｅｓ２は、そのリプライメッセージをメッセージングサービスＭｅｓ１に返し（矢印▲６▼）、そして、メッセージングサービスＭｅｓ１は、そのリプライメッセージをクライアントＰＣ１へ返す。
上述したように、メッセージングサービス１５は、自己と直接連絡可能なフレームワークサービス１６へメッセージを送るだけでなく、他のメッセージングサービスを経由して他のフレームワークサービスへメッセージを送ることも可能である。これにより、複数のＲｔＦＡサーバ１４間のロードバランシング（負荷平衡）が可能である。
図１０は、メッセージングサービスがもつロードバランシング機能の説明図である。
図１０に示すように、各ＲｔＦＡサーバ１４において、各フレームワークサービス１６は、メッセージングサービス１５と連絡する複数のスレッド１９を並列に処理している。また、各メッセージングサービス１５は、クライアントから受信したメッセージを一時的に保持するメッセージキュー１５ａを備えている。
各メッセージングサービス１５のキュー１５ａに蓄積された各メッセージは、そのメッセージングサービス１５に関連付けられた管理テーブルに従って、そのメッセージのサブジェクトＩＤに対応する何れかのフレームワークサービス１６に引き渡される。その場合、メッセージングサービス１５は、自己に直接連絡可能で且つそのサブジェクトＩＤを待ち受ける特定のフレームワークサービス１６に、そのメッセージを引き渡すことができる。しかし、その時、その特定のフレームワークサービス１６のスレッド１９に空きが無い（つまり、処理中である）場合、メッセージングサービス１５は、その処理中のフレームワークサービス１６ではなく、そのサブジェクトＩＤを待ち受ける他のメッセージングサービス１５に、そのメッセージを引渡す。そのメッセージを受け取った当該他のメッセージングサービス１５は、当該他のメッセージングサービス１６が直接に連絡可能であり且つそのサブジェクトＩＤを待ち受ける特定のフレームワークサービス１６に、そのメッセージを引き渡す。このようなメッセージ中継を可能にするために、各メッセージングサービス１５は、自分のメッセージキュー１５ａを常時監視し、そのメッセージキュー１５ａに処理待ちのメッセージが溜まっている場合は、直ちにそのキューからメッセージを取り出し、自分の管理テーブルを参照してそのメッセージの送り先をてきぱきと決定して、そのメッセージを送り出す。これにより、複数のＲｔＦＡサーバのロードバランスが適正化される。結果として、どのメッセージも可能な限り早期に処理され、よって、従来は夜間にバッチ処理で行われていたバックオフィスの仕事が、リアルタイムに近い態様で早期に実行できる。
続いて、フレームワークサービス１６の構成について説明する。
図１１は、フレームワークサービス１６の構成を示す。
フレームワークサービス１６の実体は、複数のフレームワークスレッド２５による並列処理で構成されている。各フレームワークスレッド２５は、予め準備された一群のビジネスロジック２０にアクセスし、そして、メッセージングサービス１５から引き渡されたメッセージのサブジェクトＩＤに対応する特定のビジネスロジック２２をロードして実行する。ここで、ビジネスロジックとは、例えばＪＡＶＡコードでプログラムされたプロセスであって、それぞれ固有のメッセージ処理を実行するものである。主要なビジネスロジックの多くは、データベースサーバ１７に管理されるデータベース２１に対し、メッセージの内容に応じた所定の操作を要求する。
図１２は、フレームワークサービス１６の動作説明図である。
フレームワークサービス１６のビジネスロジックの動作方式には、大きく分けて同期方式と、非同期方式の２種類がある。フレームワークサービス１６は、クライアントからの或るリクエストメッセージに応答して、ただ１つのビジネスロジックのみを実行する場合がある。また、フレームワークサービス１６は、リクエストメッセージに直接的に応答して１つのビジネスロジックを実行し、それに連係して、後続の１以上のビジネスロジックを実行する場合もある。図１２には、クライアント１１，１３からの仕入登録リクエストのメッセージに直接的に応答して仕入処理のビジネスロジックが実行され、これに連係して、在庫処理及び会計処理という２つの後続のビジネスロジックが実行される例が示されている。
クライアントからのリクエストメッセージに直接的に応答してただ一つのビジネスロジックのみを実行する場合、フレームワークサービス１６は、その唯一のビジネスロジックを通常は同期方式で実行し、そして、その実行結果を示すリプライメッセージをクライアントへ返す。
一方、クライアントからのリクエストメッセージに直接的に応答して１つのビジネスロジックを実行した後、これに連係して、後続の１以上のビジネスロジックを実行する場合、フレームワークサービス１６は、最初の一つのビジネスロジックは通常は同期方式で実行するが、２番目以降のビジネスロジックは同期方式で実行することもできるし、非同期方式で実行することもできる。図１２には、最初の仕入処理のビジネスロジックのみが同期方式で実行され、後続の在庫処理と会計処理のビジネスロジックは非同期方式で実行される例が示されている。図１２の例のように複数のビジネスロジックが実行される場合、フレームワークサービス１６は、同期方式で実行したビジネスロジックの全てが完了すると、その実行結果を示すリプライメッセージをクライアントへ返す。非同期方式で実行されるべきビジネスロジックは、クライアントからは切り離されたバックグラウンドで（つまり、クライアントからはオフラインで）実行される。
図１２に示すように、フレームワークサービス１６は、フロー定義ファイル２３を有しており、そこには、そのフレームワークサービス１６によるビジネスロジックの実行スケジュール（最初に実行すべき１つのビジネスロジック名、連係する後続の１又はそれ以上のビジネスロジックがある場合にはその後続のビジネスロジックへ渡すメッセージのサブジェクトＩＤ及び連係方式（同期か非同期か）、など）が、様々なメッセージのサブジェクトＩＤごとに定義されている。フレームワークサービス１６は、一つのメッセージを受け取ると、フロー定義ファイル２３を参照して、その受信されたメッセージのサブジェクトＩＤに対応するビジネスロジック実行スケジュールを選択し、選択されたスケジュールに従って１以上のビジネスロジックを実行する。その選択されたスケジュールには、少なくとも、そのメッセージに応答して直接的に実行されるべき１つのビジネスロジックが記述されているから、フレームワークサービスは、まず、その１つのビジネスロジックをロードして実行する。もし、その選択されたスケジュールに、更に、連係する後続の１以上のビジネスと連係方式とが記述されていたなら、フレームワークサービスは、最初のビジネスロジックの実行後に、その後続のビジネスロジックを、その連係方式で（つまり、同期的に又は非同期的に）実行することになる。なお、先行のビジネスロジックと後続のビジネスロジックは、同一のフレームワークサービスによって実行される場合もあるが、上述したロードバランシングにより別のフレームワークサービスによって実行される場合もある。
図１３は、フロー定義ファイル２３の簡単な例を示す。
図１３に示すように、フロー定義ファイル２３には、サブジェクトＩＤごとにビジネスロジック実行スケジュールをそれぞれ記述した複数のセンテンス２３１、２３２、２３３、２３４が存在する。フロー定義ファイル２３は、例えばテキストファイルであり、よって、定義センテンス２３１、２３２、２３３、２３４の追加、削除、変更などの編集は、テキストエディタなどを用いて簡単に行える。
図１３の一番上の定義センテンス２３１内に説明されているように、各定義センテンスは、セミコロン“；”で区切られた複数のサブセンテンスから構成される。最初のサブセンテンスには、入力サブジェクトＩＤ、ログキュー名、実行ビジネスロジック名などが含まれる。２番目以降の各サブセンテンスには、メッセージ変換ビジネスロジック名、出力サブジェクトＩＤ、連係モードなどが含まれる。最初のサブセンテンスは、メッセージに直接的に応答して実行されるべき１つのビジネスロジックに関するものであり、これは全ての定義センテンスに必ず記述される。２番目以降のサブセンテンスは、最初のビジネスロジックに連携して実行される後続の１以上のビジネスロジックに関するものであり、よって、後続のビジネスネスロジックがある場合にのみ記述される。
最初のサブセンテンスの項目の意味は次のとおりである。
ここで、「入力サブジェクトＩＤ」は、フレームワークシステムが受信したメッセージのサブジェクトＩＤである。
「ログキュー名」は、その受信したメッセージをログに書く場合に用いられるログキューの名称である。例えば、“＠ＤＥＦ”はデフォルトのログキューを用いることを意味し、“＠ＮＯＮＥ”はログに書かれないことを意味する。
「実行ビジネスロジック名」は、そのメッセージに直接応答して実行されるべきビジネスロジックの名称である。図示の定義センテンス２３２〜２３４の例では、入力サブジェクトＩＤと同じコードが用いられている。
２番目以降の各サブセンテンスの項目の意味は次のとおりである。
「メッセージ変換ビジネスロジック名」は、先行のビジネスロジックの処理結果データを後続のビジネスロジックに渡されるメッセージに変換するために実行されるメッセージ変換ビジネスロジックの名称である。メッセージ変換が不要な場合、ここには“＠ＮＯＮＥ”と書かれる。
「出力サブジェクトＩＤ」は、後続のビジネスロジックに渡されるメッセージのサブジェクトＩＤである。
「連係モード」は、後続のビジネスロジックを同期方式で実行するか非同期方式で実行するかを示す。例えば、“ＳＹＮＣ”は同期方式を意味し、“ＡＳＹＮＣ”は非同期方式を意味する。
図１３の２番目の定義センテンス２３２は次のスケジュール（１）を例示している。
（１）“ＢｕｙＳｅｌＢｕｙ”というサブジェクトＩＤのメッセージ（例えば、仕入検索リクエスト）に応答して、“ＢｕｙＳｅｌＢｕｙ”という名称のビジネスロジック（例えば、仕入検索処理）を実行する。
３番目の定義センテンス２３３は、次のスケジュール（１）〜（３）を例示している。
（１）“ＢｕｙＵｐｄＢｕｙ”というサブジェクトＩＤのメッセージ（例えば、仕入更新リクエスト）に応答して、まず、“ＢｕｙＵｐｄＢｕｙ”という名称のビジネスロジック（例えば、仕入更新処理）を実行する。
（２）次に、“ＣｎｖＢｕｙＵｐｄＢｕｙ”という名称の変換ビジネスロジックを用いて、先行する“ＢｕｙＵｐｄＢｕｙ”ビジネスロジックの出力データのフォーマットを変換して、“ＩｎｖＵｐｄＩｎｖ”というサブジェクトＩＤをもったメッセージ（例えば、在庫更新リクエスト）を作成してメッセージサービスへ出力する。
（３）出力された“ＩｎｖＵｐｄＩｎｖ”というメッセージを処理することになる後続のビジネスロジック（例えば、在庫更新処理）は、同期的に実行される。
さらに、４番目の定義センテンス２３４は、次のスケジュール（１）〜（５）を例示している。
（１）“ＢｕｙＩｎｓＢｕｙ”というサブジェクトＩＤのメッセージ（例えば、仕入検品更新リクエスト）に応答して、まず、“ＢｕｙＩｎｓＢｕｙ”という名称のビジネスロジック（例えば、仕入検品更新処理）を実行する。
（２）次に、“ＣｎｖＢｕｙＩｎｓＢｕｙ１”という名称の変換ビジネスロジックを用いて、先行する“ＢｕｙＩｎｓＢｕｙ”ビジネスロジックの出力データのフォーマットを変換して、“ＩｎｖＵｐｄＩｎｖ”というサブジェクトＩＤをもったメッセージ（例えば、在庫更新リクエスト）を作成してメッセージサービスへ出力する。
（３）出力された“ＩｎｖＵｐｄＩｎｖ”というメッセージを処理することになる後続のビジネスロジック（例えば、在庫更新処理）は、非同期的に実行される。
（４）また、“ＣｎｖＢｕｙＩｎｓＢｕｙ２”という名称の変換ビジネスロジックを用いて、先行する“ＢｕｙＩｎｓＢｕｙ”ビジネスロジックの出力データのフォーマットを変換して、“ＡｃｃＤｂｔＢｕｙ”というサブジェクトＩＤをもったメッセージ（例えば、買掛金登録リクエスト）を作成してメッセージサービスへ出力する。
（５）出力された“ＡｃｃＤｂｔＢｕｙ”というメッセージを受け取る後続のビジネスロジック（例えば、買掛金登録処理）は、非同期的に実行される。
再び図１２を参照する。各フレームワークサービス１６は、それに関連付けられたフロー定義ファイル２３を参照することにより、処理対象のメッセージに対応するビジネスロジック２２を選択し実行することができ、また、後続処理の必要性を判断し、必要であれば、後続処理のためのリクエストメッセージを作成してメッセージングサービス１５へ戻すことができる。
ここで、一のフレームワークスレッドによる処理の後続処理として、他のフレームワークスレッドによる処理を非同期的に行わせる場合、フレームワークサービス１６は、先行のフレームワークスレッドでのビジネスロジックによる処理のリザルト（後続処理のためのリクエストメッセージ）を一度メッセージングサービス１５のキュー１５ａにインプットし、その後、他のフレームワークスレッドがメッセージングサービス１５のキュー１５ａからそのリクエストメッセージをゲットすることによって、後続処理を行う。ここで、先行の処理を行うフレームワークシステム１６と、後続の処理を行なうフレームワークシステム１６は、同じ場合もあるし、異なる場合もある。各種の処理をどのフレームワークシステム１６に割り当てるかということは、既に説明したメッセージングサービスのロードバランシング機能によって制御される。
各フレームワークサービス１６は、メッセージドリブンの構成を採っている。即ち、メッセージングサービス１５からのメッセージの引渡しをトリガーとしてビジネスロジックのロード及びビジネスロジックによる処理を実行するようになっている。
以上説明した本実施形態によると、フレームワークサービスのビジネスロジックの連係方法に同期方式と非同期方式を用意し、随時に簡単に書き換え可能なフロー定義ファイルの記述によってビジネスロジックの実行スケジュールを制御できるので、複雑なビジネスロジックフローを定義し、また必要に応じて変更することが容易である。
また、上記実施形態では、メッセージングサービスをメッシュ接続すると共に、キープアライブ機能によって、メッセージングサービス相互間、メッセージングサービスとクライアントとの間、及びメッセージングサービスとフレームワークサービスとの間で、相互にステータス（待ち受けるメッセージのサブジェクトＩＤ、処理中か否か、など）を通知し合う。そして、各メッセージングサービスは、周囲のクライアント、フレームワークサービス及び他のメッセージングサービスの現在のステータスを、管理テーブルに記憶している。それにより、いずれのＲｔＦＡサーバがダウンした場合でも、各メッセージングサービスは、正常に使えるメッセージの中継経路を自動的に選択し、メッセージを正しいシステムへ伝えることができる。結果として、フォルトトレラント性が向上し、システムの稼動の信頼性が向上し、システムの拡張が容易になり、更に、システムメンテナンスも容易に行うことができる。
また、メッセージングサービスは、Ｐ ｔｏ Ｐ通信とＰ ｔｏ Ｍ通信のような複数種類のデータ配信方法を備え、管理テーブルに登録されているステータスに応じて、どのメッセージをどのコンピュータシステムにどのデータ配信方法で送るかというメッセージングスケジュールを自動的に選択することができる。その結果、柔軟なメッセージングサービスを提供することができる。
また、メッセージングサービスのロードバランシング機能により、複数のＲｔＦＡサーバの負荷バランスを自動的に調整することができ、高いパフォーマンスを提供することができる。
ここで、本発明の範囲は、本実施形態に限られない。例えば、ＪＡＶＡベース以外のプラットフォームを用いることによっても同等のシステムの実現は可能である。また、メッセージングサービスの上述した特徴と、フレームワークサービスの上述した特徴とは、上述した実施形態のように組み合わされている必要は、必ずしも無い。
以下、上記実施形態に具備される幾つかの詳細な機能を説明する。
図１４は、フロー定義ファイル２３の更新システムを示すブロック図である。
フレームワークサービス１６は、定義ファイル２３を更新するためのプログラムモジュールである定義ファイル更新モジュール１０１を備え、この更新モジュール１０１は、外部からリロードコマンド１１１を受付けると、フレームワークサービス１６のメインメモリ１０３内にロードされている現在使用中の定義ファイル２３を、そこに矢印１１３で示すように外部記憶装置（例えば、ディスクストレージ１０７に記憶されている新しい定義ファイル１０９を上書きすることで、更新する。ディスクストレージ１０７内の新しい定義ファイル１０９は、テキストエディタ１０５などを用いて容易に編集することができる。所望の時に、上述したリロードコマンド１１１を入力することで、メインメモリ１０３内の定義ファイル２３が、編集された新しい定義ファイル１０９と同じ内容に更新される。これにより、フレームワークサービス１６の稼動中であっても所望の時に、定義ファイル２３の内容を書き換えて、これをフレームワークサービス１６の以後の動作に反映させることができる。従って、実行するビジネスロジック２２の種類の変更や、後続の処理を行なうか否か、又は、複数のビジネスロジックの連係した動作を同期的に行うか、非同期的に行うか、といった処理スケジュール変更を、システムを稼動させたままの状態で行うことができる。
図１５は、フレームワークサービスのメッセージ変換処理機能を示す。
フレームワークサービス１６のためのコンピュータプログラムは例えばＪＡＶＡ言語で構築される。図１５に示すように、フレームワークサービス１６は、入力メッセージのフォーマット変換を行うための入力変換機能１０２と、出力メッセージのフォーマット変換を行うための出力変換機能１０３とを備えている。入力変換機能１０２は、メッセージングサービス１５からの例えばＸＭＬファイルの形式の入力メッセージを、ＪＡＶＡのオブジェクトの形式に変換する。出力変換機能１０３は、メッセージングサービス１５に出力するＪＡＶＡのオブジェクトの形式のメッセージを、ＸＭＬ形式に変換する。入力変換機能１０２は、ＸＭＬのＤＴＤ（文書型定義）の記述に基づいてＪＡＶＡクラスのメンバ変数を取得し、これをインスタンス化することによってＪＡＶＡオブジェクト化したメッセージを得る。また、出力変換機能１０３は、ＪＡＶＡクラスのメンバ変数に基づいてＸＭＬのＤＴＤを形成し、ＸＭＬ化したメッセージを得る。
図１６は、メッセージングサービスのメッセージキューの構成を示す。
上述の説明では、メッセージキュー１５ａを単一のキューであるかのごとくに説明した。しかし、実際には、図１６に示すように、メッセージキュー１５ａには３種類のキュー、すなわち、メモリキュー１５３とリングバッファ１５４とＤＢ（データベース）キュー１５５が含まれている。メモリキュー１５３とリングバッファ１５４は、ＲＡＭ１５１のような高速アクセスが可能な記憶装置に設けられる。ＤＢキュー１５５は、ハードディスク（ＨＤＤ）のよう不揮発性の大容量の記憶装置に設けられる。
メモリキュー１５３は、メッセージングサービスがクライアントから受信したＰ ｔｏ Ｐのリクエストメッセージのように、そのメッセージを処理した結果を受け取る相手が存在し、メッセージの保証が不要であるというメッセージを、一時的に待たせるために使用される。一方、ＤＢキュー１５５は、メッセージングサービスがフレームワークサービスから受信した非同期の後続処理のためのリクエストメッセージのように、メッセージの保証が必要なメッセージを、一時的に待たせるために使用される。メッセージの保証が必要か否かは、図２に示したメッセージ１０の構成中の「保証モード」で判断される。
リングバッファ１５４は、Ｐ ｔｏ Ｍ通信のメッセージを一時的に待たせるために使用される。各コンピュータシステムは、リンクバッファ１５４を巡回しながらリングバッファ１５４から自分の待ち受けるメッセージを見つけ出して取っていくことができる。図１６では、リングバッファ１５４は一つのバッファのごとくに示されているが、実際には、“Ｈ”、“Ｎ”及び“Ｌ”の３種類の優先順位にそれぞれ対応した３つのリングバッファのセットである。
ＤＢキュー１５５は、メッセージングサービスがフレームワークサービスから受信した後続処理のためのリクエストメッセージのように、メッセージの保証が必要なメッセージを、一時的に待たせるために使用される。
メッセージグサービスは、上述したキュー１５３、１５４、１５５に対するメッセージの書き込みと読み出しを制御するメッセージキュー管理機能１０４を有する。メッセージキュー管理機能１０４は、メモリキュー１５３をＤＢキュー１５５より優先して調べ、メモリキュー１５３にＰ ｔｏ Ｐメッセージが有れば、そのメッセージをメモリキュー１５３から取り出して、それを待ち受ける一つのコンピュータシステムへそのメッセージを送る。また、もしメモリキュー１５３にＰ ｔｏ Ｐメッセージが１つも無ければ、メッセージキュー管理機能１０４は、ＤＢキュー１５５を調べ、ＤＢキュー１５５内にＰ ｔｏ Ｐメッセージが有れば、そのメッセージをＤＢキュー１５５から読み、それを待ち受ける一つのコンピュータシステムへそのメッセージを送る。
メッセージキュー管理機能１０４は、図１６に示すように、ＤＢキュー１５５内のメッセージＭに対しては、そのメッセージの処理状態を示すステータス情報Ｓを付加し、そのメッセージが処理されればステータス情報Ｓを「未処理」から「処理済」へと書き換える。また、そのメッセージの処理に関してエラーが生じれば、ステータス情報Ｓを「エラー」とする。エラーの原因としては、データ不整合、プログラムロジックのミスなどがある。ＤＢキュー１５５に一旦入れられたメッセージは、システムダウンやエラーなどの問題が発生したとしても、消されずにＤＢキュー１５５内に保存される。
メッセージキュー管理機能１０４は、「エラー」のステータス情報Ｓを「未処理」に書き換える機能を有する。そして、システムダウンやエラーなどの問題が発生した場合、後に、メッセージキュー管理機能１０４は、、ステータス情報Ｓが「未処理」のメッセージを再度読み出して再送信する。それにより、メッセージの確実な処理が保証される。また、エラーになったメッセージのステータス情報Ｓを追うことにより、エラーの原因究明も可能である。
また、メッセージキューの管理機能１０４は、外部コマンドに応じて、「エラー」のステータス情報Ｓを「処理済」に書き換える機能も備えていている。例えば、システムの状況によっては、エラーステータスのメッセージを未処理ステータスに変更して再出力することが適切でない場合がある。また、メッセージに生じたエラーの程度によっては、フレームワークサービスに再出力して処理させるよりも、コマンド入力により当該メッセージに修正を加えた方が適切な場合もある。このような場合、「エラー」のステータス情報Ｓを「処理済」に書き換える機能が利用される。上述した「エラー」のステータス情報Ｓを「未処理」に書き換える機能と、「処理済」に書き換える機能とは、任意に選択することができる。
さらに、メッセージキュー管理機能１０４は、管理テーブル１８（図４）に登録されている全てのコンピュータシステムの各々ごとに、リングバッファ１５５の読みしアドレスポインタを有し、各コンピュータシステム用の読み出しアドレスポインタでリングバッファ１５５中を巡回しながら、そのコンピュータシステムが待ち受けるＰ ｔｏ Ｍメッセージをリングバッファ１５５から見つけ出し、その見つかったＰ ｔｏ Ｍメッセージを読んで、そのコンピュータシステムへ送る。
図１７及び図１８は、メッセージキュー管理機能１０４がメッセージキューにメッセージを格納する動作フローを示す。
図１７に示すように、メッセージキュー管理機能１０４は、クライアントからメッセージを受信すると（１６１）、まず、そのメッセージに関して、クライアントから非トランザクションモード（ＮＯＮ−ＴＲＡＮモード）とトランザクションモード（ＴＲＡＮモード）の何れが指定されているかを判断する（１６３）。ここで、ＮＯＮ−ＴＲＡＮモードが指定されている場合、メッセージキュー管理機能１０４は、メッセージを受信すれば直ちに、そのメッセージをメッセージキューに格納する（つまり、そのメッセージの処理を進める）。一方、ＴＲＡＮモードが指定されている場合、メッセージキュー管理機能１０４は、メッセージを受信しても、直ちにはそのメッセージをメッセージキューには格納せず、別の一時キューに溜めておき、クライアントからＣＯＭＭＩＴ（実行）コマンドが送られると、そのときにはじめて、そのメッセージをメッセージキューに格納する（つまり、そのメッセージの処理を進める）。クライアントは、ＴＲＡＮモードを指定してリクエストメッセージを発した場合、ＣＯＭＭＩＴコマンドを発しない限り、そのリクエストメッセージを後で撤回したり修正したりすることが可能である。
図１７のステップ１６３の判断の結果がＮＯＮ−ＴＲＡＮモードである場合、メッセージキュー管理機能１０４は、その受信したメッセージがＰ ｔｏ Ｐ通信のものかＰ ｔｏ Ｍ通信のものかを判断する（１６５）。その判断の結果がＰ ｔｏ Ｐ通信である場合、メッセージキュー管理機能１０４は、その受信したメッセージをキューに入れる（１６７）。キューに入れられたメッセージは、すぐに読み出されてフレームワークサービスへ送られてそこで処理される。その処理の結果として、フレームワークサービスから後続処理のリクエストメッセージが返された場合、メッセージキュー管理機能１０４は、その後続処理のリクエストメッセージをＤＢキューに入れる（１６９）。そして、メッセージキュー管理機能１０４は、その受信メッセージの処理結果を示す成功メッセージをクライアントへ返す（１７１）。
ステップ１６５の判断の結果がＰ ｔｏ Ｍ通信である場合、メッセージキュー管理機能１０４は、その受信したメッセージの優先順位（図２）が“Ｈ”、“Ｎ”又は“Ｌ”の何れであるか判別し（１７３）、そして、判別された優先順位に対応したリングバッファに、その受信メッセージを格納する（１７５、１７７又は１７９）。リングバッファに入れられたＰ ｔｏ Ｍメッセージは、それを待ち受ける全てコンピュータシステムに送信されることになる。そして、メッセージキュー管理機能１０４は、その受信メッセージについて成功メッセージをクライアントへ返す（１８１）。
ステップ１６３の判断結果がＮＯＮ−ＴＲＡＮモードであった場合、処理は図８に示すステップ１８１へ進む。ステップ１８１で、メッセージキュー管理機能１０４は、その受信メッセージを上述したメッセージキューとは別の一時キューに格納する．その後、クライアントから、その受信メッセージに関してＣＯＭＭＩＴコマンドを受信すると、メッセージキュー管理機能１０４は、一時キューからそのメッセージを取り出して、そのメッセージについてステップ１８５以降の処理を行う。ステップ１８５以降の処理は、既に説明した図７中のステップ１６５以降の処理と同じである。
図１９は、メッセージキュー管理機能１０４のメッセージ読出機能を示す。
図１９に示すように、メッセージングサービス１５のメッセージキュー管理機能１０４は、クライアント及びフレームワークサービス１６からそれぞれ受信したメッセージを、上述したような構成をもつメッセージキュー１５ａに蓄積する。メッセージキュー管理機能１０４は、メッセージキュー１５ａのうち特に図１６に示したメモリキュー１５３及びＤＢキュー１５５からメッセージを取り出す動作に関して、優先モード１０４ａとシーケンス保証モード１０４ｂの２種類の機能を有している。優先モード１０４ａは、メッセージの優先順位に基づいてメッセージキューからのメッセージの取り出し順序を制御する。一方、シーケンス保証モード１０４ｂは、メッセージキューから先に取り出されたメッセージの処理がフレームワークサービスにおいて完了するまで、当該メッセージキューに蓄積されている後続のメッセージの取り出しを禁止することにより、複数メッセージの一定の処理順序を保証する。各メッセージのサブジェクトＩＤ）に応じて、又は予め設定された各メッセージキューのモード設定に応じて、各メッセージキューについて優先モード１０４ａを実行するか、シーケンス保証モード１０４ｂを実行するか、が選択される。シーケンス保証モード１０４ｂは、例えば、複数のクライアントからそれぞれ売上処理のリクエストメッセージが来たとき、先にリクエストされた売上処理が完了した後に後から来た売上処理のリクエストを実行するというような一定の処理順序を保証したい場合に、適用される。
図２０は、優先モード１０４ａのための記憶域の構成を示す。図２１は、優先モード１０４ａの動作の流れを示す。
図２０に示すように、優先モード１０４ａは、ソータブルスタック２１１とシンプルタック２１３という２つのスタックメモリと、“Ｈ”、“Ｎ”及び“Ｌ”という３つの優先順位にそれぞれ対応した例えば３つのエントリ２１５Ｈ、２１５Ｎ及び２１５Ｌとを使用する。なお、エントリの数をもっと多くすることもできる。例えば、図示の３つのエントリの他に、“Ｈ”に対応したエントリをもう一つ追加するというようにである。
初期的に、各エントリ２１５Ｈ、２１５Ｎ及び２１５Ｌには、それぞれ、インデックスとして、例えば図示のような“５”、“３”及び“１”という数値が設定される。インデックスの初期値が大きいほど、優先的レベルが高いことを意味する。
そして、初期的に、全てのエントリ２１５Ｈ、２１５Ｎ及び２１５Ｌが、図示のようにソータブルスタック２１１に積まれ、一方、シンプルスタック２１３は空である。
ソータブルスタック２１１は、そこに積まれている複数のインデックスの配列を、インデックスの大きい順に、最も大きいインデックスをもったエントリが一番上に、最も小さいインデックスをもったエントリが一番下になるように、自動的に並べ替える。従って、ソータブルスタック２１１からは、インデックスのより大きいエントリほど、より先に取り出される。
シンプルスタック２１３は、単純に、後から入れられたエントリを先に入れられたエントリの上に積む。従って、シンプルスタック２１３からは、入れられた時がより後のエントリほど、より先に取り出される。
優先モード１０４ａは、図２１に示すフローに従って、ソータブルスタック２１１とシンプルスタック２１３との間でのエントリの移動と、エントリのインデックスの操作を行なうことにより、メッセージキュー（メモリキュー１５３又はＤＢキュー１５５）からメッセージを取り出す順序を制御する。
以下、図２１に示す流れを説明する。まず、優先モード１０４ａは、ソータブルスタック２１１から、一番上の（つまり、インデックスが最も大きい）１つのエントリを取り出し（２２１）、そのエントリをシンプルスタック２１３に積む（２２３）。次に、優先モード１０４ａは、シンプルスタック２１３の一番上のエントリの優先順位とマッチするメッセージがメッセージキューに有るか否かをチェックする（２２５）。その結果、マッチするメッセージが無ければ、処理はステップ２２１へ進む。また、上記チェックの結果、マッチするメッセージが有れば、優先モード１０４ａは、そのマッチしたメッセージをメッセージキューから取り出す（２２７）。取り出されたメッセージは、何れかのフレームワークシステムにて処理されることになる。その後、優先モード１０４ａは、シンプルスタック２１３内のエントリ数が１つか否かをチェックする（２２９）。その結果、シンプルスタック２１３内のエントリ数が２つ以上であれば、シンプルスタック２１３から全てのエントリを順に取り出してソータブルスタック２１１に積む（２３７）。そして、優先モード１０４ａは、ステップ２２７でメッセージキューから取り出したメッセージについて、フレームワークシステムからの処理結果を示すリプライメッセージをクライアントへ返す（２３９）。
ステップ２２９でのチェックの結果、シンプルスタック２１３内のエントリ数が１つである場合、優先モード１０４ａは、シンプルスタック２１３内のエントリのインデックスを１だけ減らす（２３１）。そして、優先モード１０４ａは、その減らされたインデックスが“−１”であるかどうかチェックし（２３３）、“−１”でなければ、処理をステップ２３７へ進め、一方、“−１”であれば、そのインデックスを初期値に戻して（２３５）から、処理をステップ２３７へ進める。
以上の操作により、メッセージキュー内のメッセージの並び順序をそれらのメッセージの優先順位を考慮して修正した順序で、メッセージキューからメッセージの取り出されることになる。すなわち、メッセージキューに入っているメッセージの順序が、優先順位において、例えば図２０に示すような“Ｈ”、“Ｈ”、“Ｌ”、“Ｈ”、“Ｈ”、“Ｈ”、“Ｎ”であった場合、そのメッセージキューから取り出されるメッセージの順序は、優先順位において、“Ｈ”、“Ｈ”、“Ｎ”、“Ｈ”、“Ｈ”、“Ｈ”、“Ｌ”となる。
図２２は、シーケンス保証モード１０４ｂの動作の流れを示す。
図２２に示すように、シーケンス保証モード１０４ｂは、メッセージの取り出し要求が生じると（２４１）、まず、メッセージキューをロックして（２４３、２４５、２５７）、メッセージキューからの他のメッセージ取り出しを禁止する。次に、シーケンス保証モード１０４ｂは、メッセージキューから１つのメッセージを読出す（２４７、２４９）。読み出されたメッセージは、何れかのフレームワークシステムで処理され（２５１）、その処理により然るべきデータベースの更新のコミット（又は処理失敗の場合にはロールバック）が行われる（２５３）。その後、シーケンス保証モード１０４ｂは、メッセージキューのロックを解除する（２５５）。
上記の操作により、先行するメッセージの処理が完了した後に、次のメッセージの処理が実行されるため、メッセージの一定の処理順序が保証される。
図２３は、フレームワークサービス１６のメッセージ判別機能を示す。
図２３に示すように、フレームワークサービス１６は、メッセージ判別ビジネスロジック１０６を有し、メッセージングサービス１５からメッセージを受け取ると、メッセージ判別ビジネスロジック１０６を実行する。メッセージ判別ビジネスロジック１０６は、その受信メッセージのサブジェクトＩＤにマッチするサブジェクトＩＤが書かれた定義センテンスを、そのフレームワークシステム１６に関連付けられたフロー定義ファイル２３から探す。マッチした定義センテンスが見つかれば、次に、その定義センテンスに記述されている実行ビジネスロジック２２が実行されることになる。しかし、マッチした定義センテンスが見つからなければ、メッセージ判別ビジネスロジック１０６は、処理できない旨のエラーのリプライメッセージをメッセージングサービス１５へ返信し、そのリプライメッセージはクライアントへ送られる。既に説明したように、メッセージングサービス１５は、管理テーブル１８（図４）に基づいて、各メッセージをそのメッセージを待ち受けるコンピュータシステムにのみ送信するから、原則的には、或るメッセージが誤ったフレームワークシステムに送られることはない。しかし、万が一、クライアントからの或るメッセージが誤ったフレームワークサービスに送られることが発生したとしても、クライアントは直ちに処理できない旨のエラーのリプライメッセージを受け取れるので、長々と待たされること無く、速やかに次の行動に移ることができる。また、フレームワークサービス１６は、予め登録された識別情報を有するメッセージに限ってフレームワークサービスでの処理を許可するサービス停止中モードを備え、当該モードが設定されている場合に予め登録されていない識別情報を有するメッセージをクライアントから受信した場合は、当該メッセージを受け付けない旨のメッセージをクライアントに返信する。
図２４は、フレームワークサービスがもつメッセージ変換ビジネスロジックを示す。
図２４に示すように、フレームワークサービス１６は、１又はそれ以上のメッセージ変換ビジネスロジック１０５を有している。それらのメッセージ変換ビジネスロジック１０５は、例えば、図１３に示したフロー定義ファイル２３の定義センテンス２３３及び２３４に記述された“ＣｎｖＢｕｙＵｐｄＢｕｙ”、“ＣｎｖＢｕｙＩｎｓＢｕｙ１”及び“ＣｎｖＢｕｙＩｎｓＢｕｙ２”などである。各メッセージ変換ビジネスロジック１０５は、予め定められた１つのビジネスロジックＢＬ１に対応していうる。或る定義センテンスに従って或るビジネスロジックＢＬ１が実行されると、引き続いて、これに対応したメッセージ変換ビジネスロジック１０５が実行される。メッセージ変換ビジネスロジック１０５は、先行のビジネスロジックＢＬ１から出力される処理結果のメッセージの形式を、後続のビジネスロジックＢＬ２への入力メッセージの形式に適合させるフォーマット変換機能と、先行のビジネスロジックＢＬ１から出力されたメッセージのパラメータに応じて、このメッセージを後続ビジネスロジックＢＬ２に入力するか否かを判定するメッセージフィルタリング機能とを備えている。例えば、先行のビジネスロジックＢＬ１が扱うメッセージのパラメータ配置と、後続ビジネスロジックＢＬ２が扱うメッセージのパラメータ配置が異なる場合、メッセージ変換ビジネスロジック１０５は、前者のパラメータ配置を後者のパラメータ配置に変換する。また、先行ビジネスロジックＢＬ１の出力メッセージの内容が特別のもの（例えば、リクエストの拒否、データベースの更新失敗、トランザクションのロールバックなど）であり、そのため、後続のビジネスロジックＢＬ２の実行が無意味であるという場合がある。そのような場合、メッセージ変換ビジネスロジック１０５は、メッセージフィルタリング機能により、後続ビジネスモデルＢＬ２への入力メッセージの生成をオミットする。ここで、先行ビジネスロジックＢＬ１とメッセージ変換ビジネスロジック１０５との間、又はメッセージ変換ビジネスロジック１０５と後続のビジネスロジックＢＬ２との間には、メッセージを一時保持するメッセージキューを介在させてもよい。
以上の説明は、本発明の説明のための例示にすぎない。本発明は、上述した実施形態のみに限らず、他の多くのシステム構成のバリエーションにおいても実施することができる。
【図面の簡単な説明】
図１は、本実施形態の全体構成図である。
図２は、ＲｔＦＡサーバ１４が取り扱うメッセージの構成を示すブロック図である。
図３は、ＲｔＦＡサーバ１４の構成図である。
図４は、メッセージングサービス１５に関係付けられる管理テーブル１８の例を示す。
図５は、複数のＲｔＦＡサーバ間の接続構成図である。
図６は、複数のメッセージングサービス間の接続構成図である。
図７は、Ｐ ｔｏ Ｍ（１対多）通信処理のメッセージ中継方法を示す説明図である。
図８は、Ｐ ｔｏ Ｍ通信処理の一例を示すフローチャートである。
図９は、Ｐ ｔｏ Ｐ（１対１）通信処理を示すフローチャートである。
図１０は、メッセージングサービスのロードバランシング機能の説明図である。
図１１は、フレームワークサービスの構成を示すブロック図である。
図１２は、フレームワークサービスの動作説明図である。
図１３は、フロー定義ファイルの簡単な例を示す。
図１４は、フロー定義ファイルの更新システムを示すブロック図である。
図１５は、フレームワークサービスのメッセージ変換処理機能を示すブロック図である。
図１６は、メッセージングサービスのメッセージキューの構成を示すブロック図である。
図１７は、メッセージキュー管理機能がメッセージキューにメッセージを格納する動作を示すフローチャートである。
図１８は、図１７のフローチャートの続きである。
図１９は、メッセージキュー管理機能のメッセージ読出機能を示すブロック図である。
図２０は、優先モードのための記憶域の構成を示す。
図２１は、優先モードの動作の流れを示す。
図２２は、シーケンス保証モードの動作の流れを示す。
図２３は、フレームワークサービスのメッセージ判別機能を示すブロック図である。
図２４は、フレームワークサービスのメッセージ変換ビジネスロジックを示すブロック図である。
Claims (20)
- クライアントと通信可能に接続されるフレームワークシステムにおいて：
複数のビジネスロジックと；
前記複数のビジネスロジックと関連付けられ、前記クライアントからのリクエストのメッセージに応答して、選択された１又はそれ以上のビジネスロジックを実行し、そして、前記クライアントへのリプライのメッセージを出力するフレームワークサービスと；
前記クライアントと前記フレームワークサービスとの間に介在し、前記クライアントと前記フレームワークサービスとの間でメッセージを中継するメッセージングサービスと；
前記フレームワークサービスに関連付けられたフロー定義ファイルと
を備え；
前記リクエストのメッセージは、前記リクエストのメッセージのサブジェクトに関するサブジェクトＩＤを含んでおり；
前記フロー定義ファイルは、複数の異なるサブジェクトＩＤにそれぞれ対応した複数の定義センテンスを含んでおり、各定義センテンスは所定の１又はそれ以上のビジネスロジックのための実行スケジュールを記述しており；
前記フレームワークサービスは、前記メッセージングサービスから前記リクエストのメッセージを受け取ると、前記定義ファイル内の前記リクエストのメッセージのサブジェクトＩＤに対応した定義センテンスを参照し、参照された定義センテンスに記述された実行スケジュールに従って、実行するべき１又はそれ以上のビジネスロジックを選択する；
フレームワークシステム。 - 請求項１記載のフレームワークシステムにおいて、前記フレームワークサービスが稼動している間に、前記フロー定義ファイルを更新するフロー定義更新コンポーネントを更に備えたフレームワークシステム。
- 請求項１記載のフレームワークシステムにおいて、
前記フロー定義ファイル内の少なくとも一つの定義センテンスは、一つの先行のビジネスロジックと少なくとも一つの後続のビジネスロジックとを含む複数のビジネスロジックの連係された実行のための連係実行スケジュールを記述しており、前記連係実行スケジュールは、前記後続のビジネスロジックの実行に関して同期方式と非同期方式の選択に関する連係モードを含んでおり；
前記フレームワークサービスは、前記連係実行スケジュールに従って前記複数のビジネスロジックを実行する場合、前記連係実行スケジュール内の前記連係モードに従って、前記先行のビジネスロジックの実行と同期的に又は非同期的に、前記後続のビジネスロジックを実行する；
フレームワークシステム。 - 請求項３記載のフレームワークシステムにおいて、
前記連係実行スケジュールは、前記先行のビジネスロジックに関する情報と、前記後続のビジネスロジックのための第２のリクエストのメッセージに関する情報とを含み；
前記フレームワークシステムは、前記連係実行スケジュールに従って前記複数のビジネスロジックを実行する場合、前記先行のビジネスロジックを実行した後、前記先行のビジネスロジックの実行結果を用いて前記第２のリクエストのメッセージを生成して、前記第２のリクエストのメッセージを前記メッセージングサービスに送り、その後、前記メッセージングサービスから前記第２のリクエストのメッセージを受けると、前記第２のリクエストのメッセージに対応する定義センテンスの実行スケジュールに従って、前記後続のビジネスロジックを実行する；
フレームワークシステム。 - 請求項４記載のフレームワークシステムにおいて、
前記メッセージングサービスが、前記第２のリクエストのメッセージを保証するための不揮発性のメッセージキューを備え；
前記メッセージキューは、前記第２のリクエストメッセージが前記フレームワークサービスへ送られた後も、前記第２のリクエストメッセージを消さずに保存する；
フレームワークシステム。 - 請求項５記載のフレームワークシステムにおいて、
前記メッセージグサービスが、前記メッセージキューで保存されている前記第２のリクエストのメッセージを、必要に応じて、前記フレームワークシステムへ再送信する；
フレームワークシステム。 - クライアントと通信可能に接続されるフレームワークシステムにおいて：
前記クライアントからのリクエストのメッセージを処理し、そして、前記クライアントへのリプライのメッセージを出力するフレームワークサービスと；
前記クライアントと前記フレームワークサービスとの間に介在し、前記クライアントと前記フレームワークサービスとの間でメッセージを中継するメッセージングサービスと
を備え；
前記メッセージングサービスは、前記リクエストのメッセージと前記リプライのメッセージを含むＰ ｔｏ Ｐ通信のメッセージだけでなく、前記クライアントと前記フレームワークサービスとの間のＰ ｔｏ Ｍ通信のメッセージをも中継する；
フレームワークシステム。 - 請求項７記載のフレームワークシステムにおいて、
前記メッセージングサービスが、前記Ｐ ｔｏ Ｍ通信のメッセージを一時的に待たせるためのリングバッファを有する；
フレームワークシステム。 - 請求項７記載のフレームワークシステムにおいて、
前記Ｐ ｔｏ Ｐ通信のメッセージの各々には、メッセージ保証の要否に関する保証モードが含まれており；
前記メッセージングサービスが、メッセージ保証が不要なＰ ｔｏ Ｐ通信のメッセージを一時的に待たせるための第１のメッセージキューと、メッセージ保証が必要なＰ ｔｏ Ｐ通信のメッセージを一時的に待たせるための不揮発性の第２のメッセージキューとを有する；
フレームワークシステム。 - クライアントと通信可能に接続されるフレームワークシステムにおいて、
前記クライアントと接続された少なくとも一つのメッセージングサービスを含んだ、相互にメッシュ接続されている複数のメッセージングサービスと；
前記複数のメッセージングサービスにそれぞれ接続された複数のフレームワークサービスと
を備え；
前記複数のフレームワークサービスの各々は、予め定めれたサブジェクトＩＤをもったリクエストのメッセージを待ち受け、前記予め定めれたサブジェクトＩＤをもったリクエストのメッセージを受信すると、受信されたリクエストのメッセージを処理し、そして、前記クライアントへのリプライのメッセージを出力することができ；
前記複数のメッセージンサービスは、前記クライアントと前記複数のフレームワークサービスの間でのメッセージの中継、及び、前記複数のフレームワークシステム相互間でのメッセージの中継を行う；
フレームワークシステム。 - 請求項１０記載のフレームワークシステムにおいて、
各メッセージングサービスが、他の１又はそれ以上のメッセージングサービスの稼動を監視し、他の或るメッセージングサービスについて正常な稼動を検出できなかった場合は、前記他の或るメッセージングサービスへメッセージを中継する代わりに、他の正常に稼動しているメッセージングサービスへメッセージを中継する；
フレームワークシステム。 - 請求項１０記載のフレームワークシステムにおいて、
各メッセージングサービスが、前記各メッセージングサービスに接続されたフレームワークサービスの状態を監視し、監視された前記状態に応じて、前記クライアントからの前記リクエストのメッセージを前記各メッセージングサービスに接続されたフレームワークサービスに中継するか、他の何れかのメッセージングサービスに中継するかを選択する；
フレームワークシステム。 - 請求項１０記載のフレームワークシステムにおいて、
各メッセージングサービスは独自の管理テーブルを有し；
前記各メッセージングサービスの独自の管理テーブルには、前記各メッセージングサービスに接続されたフレームワークシステムが待ち受けるメッセージのサブジェクトＩＤ、及び、前記各メッセージングサービスに接続された他の１又はそれ以上のメッセージングサービスがそれぞれ待ち受けるメッセージのサブジェクトＩＤが登録されており；
前記各メッセージングサービスは、メッセージを受信したとき、前記各メッセージングサービスの独自の管理テーブルを参照して、受信されたメッセージのサブジェクトＩＤにマッチするサブジェクトＩＤを待ち受けるフレームワークサービス又は他のメッセージングサービスを探し、見つかったフレームワークサービス又は他のメッセージングサービスへ前記受信されたメッセージを中継する；
フレームワークシステム。 - 請求項１３に記載のフレームワークシステムにおいて、
各メッセージングサービスは、前記各メッセージングサービスの独自の管理テーブルの内容に基づいて、前記各メッセージングサービスが待ち受けるメッセージのサブジェクトＩＤを、前記各メッセージングサービスに接続されている他の１又はそれ以上のメッセージングサービスに対して通知する；
フレームワークシステム。 - 請求項１４記載のフレームワークシステムにおいて、
各メッセージングサービスは、前記各メッセージングサービスに接続されている他の各メッセージングサービスの各々から、前記他の各メッセージングサービスが待ち受けるメッセージのサブジェクトＩＤを通知されたとき、通知された内容が前記各メッセージングサービスの独自の管理テーブルに未だ登録されていなければ、前記通知された内容を前記独自の管理テーブルに追加登録する；
フレームワークシステム。 - クライアントと通信可能に接続されるフレームワークシステムにおいて：
前記クライアントからのリクエストのメッセージを処理し、そして、前記クライアントへのリプライのメッセージを出力するフレームワークサービスと；
前記クライアントと前記フレームワークサービスとの間に介在し、前記クライアントと前記フレームワークサービスとの間でメッセージを中継するメッセージングサービスと
を備え；
前記リクエストのメッセージは所与の優先順位を有しており；
前記メッセージングサービスが、前記リクエストのメッセージを一時的に待たせるためのメッセージキューと、前記メッセージキューの入出力を管理するキュー管理コンポーネントとを備え；
前記キュー管理コンポーネントは、
前記メッセージキューに複数のメッセージが蓄積されているとき、各メッセージの優先順位に応じて、前記複数のメッセージの前記メッセージキューからの出力順序を制御する優先モードと、
前記メッセージキューに複数のメッセージが蓄積されているとき、前記メッセージキューから先に取り出されたメッセージの処理が前記フレームワークサービスにおいて完了するまで、前記メッセージキューに蓄積されている他のメッセージの取り出しを禁止するシーケンス保証モードと
を備える；
フレームワークシステム。 - クライアントと通信可能に接続されるフレームワークシステムの動作方法において：
複数の異なるサブジェクトＩＤにそれぞれ対応したビジネスロジック実行スケジュールが記述されたフロー定義ファイルを用意するステップと；
前記クライアントから、所与のサブジェクトＩＤをもつリクエストのメッセージを受信するステップと；
前記フロー定義ファイル内の、受信されたリクエストのメッセージのサブジェクトＩＤに対応したビジネスロジック実行スケジュールを参照するステップと；
参照されたビジネスロジック実行スケジュールに従って、予め用意された複数のビジネスロジックの中から、１又はそれ以上のビジネスロジックを選択するステップと；
選択された１又はそれ以上のビジネスロジックを実行するステップと；
前記クライアントへリプライのメッセージを返すステップと；
を備えた方法。 - クライアントと通信可能に接続されるフレームワークシステムの動作方法において：
一つのクライアントと一つのフレームワークサービスとの間で、リクエストとリプライのメッセージをやりとりするＰ ｔｏ Ｐ通信のステップと；
同じメッセージを複数のクライアント又は複数のフレームワークサービスへ送るＰ ｔｏ Ｍ通信のステップと；
を備えた方法。 - クライアントと通信可能に接続されるフレームワークシステムの動作方法において：
相互にメッシュ接続されている複数のメッセージングサービスの中の一つが、前記クライアントからリクエストのメッセージを受信するステップと；
前記一つのメッセージングサービスが、受信されリクエストのメッセージを、前記一つのメッセージングサービスに接続されたフレームワークサービス、及び前記一つのメッセージングサービスに接続された他の何れか一つのメッセージングサービスの内の選択された一方へ、中継するステップと；
前記受信されたリクエストのメッセージが前記他の一つのメッセジングサービスへ中継されたとき、前記他の一つのメッセジングサービスが、前記受信されリクエストのメッセージを、前記他の一つのメッセージングサービスに接続されたフレームワークサービス、及び前記他の一つのメッセージングサービスに接続された更に他の何れか一つのメッセージングサービスの内の選択された一方へ、中継するステップと；
を備えた方法。 - クライアントと通信可能に接続されるフレームワークシステムの動作方法において：
前記クライアントからリクエストのメッセージを受信するステップと；
受信されたリクエストのメッセージをメッセージキューに入れるステップと；
前記メッセージキューからリクエストのメッセージを取り出すステップと；
取り出されたリクエストのメッセージを処理するステップと
を備え；
前記取り出すステップは、
前記メッセージキューに複数のメッセージが蓄積されているとき、各メッセージの優先順位に応じて、前記複数のメッセージの前記メッセージキューからの出力順序を制御する優先モードと、
前記メッセージキューに複数のメッセージが蓄積されているとき、前記メッセージキューから先に取り出されたメッセージの処理が完了するまで、前記メッセージキューに蓄積されている他のメッセージの取り出しを禁止するシーケンス保証モードと
を有した方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000401794 | 2000-12-28 | ||
| JP2000401794 | 2000-12-28 | ||
| PCT/JP2001/011532 WO2002054263A1 (fr) | 2000-12-28 | 2001-12-27 | Systeme de structure |
Related Child Applications (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006041465A Division JP3944230B2 (ja) | 2000-12-28 | 2006-02-17 | フレームワークシステム |
| JP2006041454A Division JP3944229B2 (ja) | 2000-12-28 | 2006-02-17 | フレームワークシステム |
| JP2006041472A Division JP3944231B2 (ja) | 2000-12-28 | 2006-02-17 | フレームワークシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2002054263A1 true JPWO2002054263A1 (ja) | 2004-05-13 |
| JP3803707B2 JP3803707B2 (ja) | 2006-08-02 |
Family
ID=18866181
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002555295A Expired - Lifetime JP3803707B2 (ja) | 2000-12-28 | 2001-12-27 | フレームワークシステム |
Country Status (4)
| Country | Link |
|---|---|
| US (2) | US7177899B2 (ja) |
| EP (1) | EP1347390A4 (ja) |
| JP (1) | JP3803707B2 (ja) |
| WO (1) | WO2002054263A1 (ja) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1639458A4 (en) * | 2003-06-12 | 2010-05-05 | Reuters America | BUSINESS PROCESS AUTOMATION |
| US20050071848A1 (en) * | 2003-09-29 | 2005-03-31 | Ellen Kempin | Automatic registration and deregistration of message queues |
| US7676791B2 (en) * | 2004-07-09 | 2010-03-09 | Microsoft Corporation | Implementation of concurrent programs in object-oriented languages |
| US7836449B2 (en) * | 2005-04-29 | 2010-11-16 | Microsoft Corporation | Extensible infrastructure for task display and launch |
| DE102005043041A1 (de) * | 2005-09-09 | 2007-03-22 | Siemens Ag | Verfahren und Vorrichtung zum Aufbau einer themenbezogenen Kommunikationsverbindung |
| JP2007114902A (ja) * | 2005-10-18 | 2007-05-10 | Just Syst Corp | 情報処理装置、情報処理方法および情報処理プログラム |
| GB0524021D0 (en) | 2005-11-25 | 2006-01-04 | Ibm | A system for preserving message order |
| JP2007226385A (ja) * | 2006-02-22 | 2007-09-06 | Fujitsu Ltd | メッセージキュー制御プログラム及びメッセージキューイングシステム |
| US20080228715A1 (en) * | 2007-03-12 | 2008-09-18 | Terabyte Media, Llc | Apparatus and method for distributed information retrieval and processing |
| US8370839B2 (en) * | 2007-07-20 | 2013-02-05 | International Business Machines Corporation | Monitoring message queues in message queuing information systems and initiating batch jobs to perform functions on the message queues |
| US8843938B2 (en) * | 2008-07-02 | 2014-09-23 | International Business Machines Corporation | Methods, systems, and computer program products for asynchronous resumption of a dataflow |
| US9141446B2 (en) * | 2008-10-24 | 2015-09-22 | Sap Se | Maintenance of message serialization in multi-queue messaging environments |
| US8296411B2 (en) * | 2010-03-01 | 2012-10-23 | International Business Machines Corporation | Programmatically determining an execution mode for a request dispatch utilizing historic metrics |
| US8468172B2 (en) * | 2010-05-14 | 2013-06-18 | Sap Ag | Integrated application server and data server processes with matching data formats |
| JP2010211826A (ja) * | 2010-05-27 | 2010-09-24 | Fujitsu Ltd | メッセージキュー制御プログラム、メッセージキューイングシステム及びメッセージキューイングシステムの制御方法 |
| US9372902B2 (en) | 2011-09-23 | 2016-06-21 | International Business Machines Corporation | Accessing and editing virtually-indexed message flows using structured query langauge (SQL) |
| US10002033B2 (en) | 2012-02-07 | 2018-06-19 | Microsoft Technology Licensing, Llc | Efficiently receiving messages across a large number of messaging entities |
| US9201938B2 (en) * | 2012-05-21 | 2015-12-01 | Sap Se | Parameter driven data format conversion in client/server architectures |
| JP6459654B2 (ja) * | 2014-11-07 | 2019-01-30 | 富士通株式会社 | イベントドリブンシステム、情報処理装置、イベントドリブンプログラムおよびイベントドリブン方法 |
| CN105939365B (zh) * | 2015-06-29 | 2019-03-15 | 杭州迪普科技股份有限公司 | 主控板用户态从业务板内核态获取数据的方法及装置 |
| CN108255620B (zh) * | 2018-01-08 | 2021-11-05 | 北京奇艺世纪科技有限公司 | 一种业务逻辑处理方法、装置、业务服务器及系统 |
| US11277369B1 (en) * | 2021-03-02 | 2022-03-15 | Servicenow, Inc. | Message queue architecture and interface for a multi-application platform |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS5856171A (ja) * | 1981-09-30 | 1983-04-02 | Fujitsu Ltd | マルチ・システムにおける資源情報管理方法 |
| JPS59220866A (ja) * | 1983-05-30 | 1984-12-12 | Hitachi Ltd | 分散処理方式 |
| JPS62126457A (ja) * | 1985-11-27 | 1987-06-08 | Fujitsu Ltd | 分散デ−タ処理方式 |
| JPS62212763A (ja) * | 1986-03-13 | 1987-09-18 | Fujitsu Ltd | 計算機ネツトワ−クにおけるジヨブ実行方式 |
| JPH0765526B2 (ja) | 1987-08-25 | 1995-07-19 | 株式会社日立製作所 | 内燃機関の空燃比制御装置 |
| JPH01129345A (ja) * | 1987-11-13 | 1989-05-22 | Toshiba Corp | マルチプロセッサ・システム |
| JPH01253036A (ja) * | 1988-03-31 | 1989-10-09 | Nippon Telegr & Teleph Corp <Ntt> | メッセージ・パッシング管理方式 |
| JPH02109154A (ja) * | 1988-10-18 | 1990-04-20 | Nippon Telegr & Teleph Corp <Ntt> | ジョブ制御方法 |
| JPH02113362A (ja) * | 1988-10-24 | 1990-04-25 | Nippon Telegr & Teleph Corp <Ntt> | 分散処理システム |
| JPH02275563A (ja) | 1989-04-17 | 1990-11-09 | Nippon Telegr & Teleph Corp <Ntt> | 情報処理システムにおけるサーバ利用方式 |
| JP2972232B2 (ja) * | 1989-08-30 | 1999-11-08 | 株式会社日立製作所 | 計算機ネツトワーク・システムの制御方式 |
| CA2148459C (en) * | 1993-10-08 | 2000-01-11 | Paul Clarke | Message transmission across a network |
| US5577211A (en) * | 1994-05-11 | 1996-11-19 | Ibm Corporation | System and method using chained structure queues for ordering of message delivery between connected nodes wherein unsuccessful message portion is skipped and retried |
| US5768506A (en) * | 1994-09-30 | 1998-06-16 | Hewlett-Packard Co. | Method and apparatus for distributed workflow building blocks of process definition, initialization and execution |
| US5634127A (en) * | 1994-11-30 | 1997-05-27 | International Business Machines Corporation | Methods and apparatus for implementing a message driven processor in a client-server environment |
| GB2313524A (en) * | 1996-05-24 | 1997-11-26 | Ibm | Providing communications links in a computer network |
| US5867495A (en) * | 1996-11-18 | 1999-02-02 | Mci Communications Corporations | System, method and article of manufacture for communications utilizing calling, plans in a hybrid network |
| US5999525A (en) * | 1996-11-18 | 1999-12-07 | Mci Communications Corporation | Method for video telephony over a hybrid network |
| US6405239B1 (en) * | 1996-12-09 | 2002-06-11 | Scientific-Atlanta, Inc. | Using a hierarchical file system for indexing data broadcast to a client from a network of servers |
| JP3954689B2 (ja) * | 1997-06-12 | 2007-08-08 | インターナショナル・ビジネス・マシーンズ・コーポレーション | メッセージ処理方法、メッセージ処理装置及びメッセージ処理を制御するプログラムを格納する記憶媒体 |
| US6012084A (en) * | 1997-08-01 | 2000-01-04 | International Business Machines Corporation | Virtual network communication services utilizing internode message delivery task mechanisms |
| US6131385A (en) | 1997-08-18 | 2000-10-17 | Trw Inc. | Integrated pulsed propulsion system for microsatellite |
| US5960404A (en) * | 1997-08-28 | 1999-09-28 | International Business Machines Corp. | Mechanism for heterogeneous, peer-to-peer, and disconnected workflow operation |
| JPH11120009A (ja) | 1997-10-14 | 1999-04-30 | Toshiba Tec Corp | プロセス間通信制御装置 |
| US6047324A (en) * | 1998-02-05 | 2000-04-04 | Merrill Lynch & Co. Inc. | Scalable distributed network controller |
| JP3514421B2 (ja) | 1998-03-31 | 2004-03-31 | 株式会社日立ハイテクインスツルメンツ | 刻印認識装置及びその認識方法 |
| US6490611B1 (en) | 1999-01-28 | 2002-12-03 | Mitsubishi Electric Research Laboratories, Inc. | User level scheduling of inter-communicating real-time tasks |
| JP2000242697A (ja) * | 1999-02-19 | 2000-09-08 | Kokusai Electric Co Ltd | 情報配信システム |
| JP4146983B2 (ja) * | 1999-02-26 | 2008-09-10 | インターナショナル・ビジネス・マシーンズ・コーポレーション | サーバ・オブジェクトのメソッドを呼び出すプロセス方法及びデータ処理システム |
| US6986018B2 (en) * | 2001-06-26 | 2006-01-10 | Microsoft Corporation | Method and apparatus for selecting cache and proxy policy |
-
2001
- 2001-12-27 JP JP2002555295A patent/JP3803707B2/ja not_active Expired - Lifetime
- 2001-12-27 US US10/204,740 patent/US7177899B2/en active Active
- 2001-12-27 EP EP01995024A patent/EP1347390A4/en not_active Withdrawn
- 2001-12-27 WO PCT/JP2001/011532 patent/WO2002054263A1/ja active Application Filing
-
2007
- 2007-01-03 US US11/649,016 patent/US7366751B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP1347390A1 (en) | 2003-09-24 |
| US7177899B2 (en) | 2007-02-13 |
| EP1347390A4 (en) | 2009-04-08 |
| US7366751B2 (en) | 2008-04-29 |
| US20070130247A1 (en) | 2007-06-07 |
| WO2002054263A1 (fr) | 2002-07-11 |
| JP3803707B2 (ja) | 2006-08-02 |
| US20030014551A1 (en) | 2003-01-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3803707B2 (ja) | フレームワークシステム | |
| JP3944231B2 (ja) | フレームワークシステム | |
| US5826269A (en) | Electronic mail interface for a network server | |
| US7421546B2 (en) | Intelligent state engine system | |
| JP4397385B2 (ja) | コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体 | |
| US7580970B2 (en) | Systems and methods for database synchronization | |
| US7577687B2 (en) | Systems and methods for synchronizing databases | |
| JP3892987B2 (ja) | メッセージ・ブローカ・データ処理装置、方法、及び記録媒体 | |
| US5978836A (en) | Workflow systems and methods | |
| US7526576B2 (en) | Computer network system using encapsulation to decompose work units for synchronizing and operating a second database from a first database | |
| US7707177B2 (en) | Computer network system for building, synchronising and/or operating a second database from/with a first database, and procedures for it | |
| US7614057B2 (en) | Entity linking system | |
| US20090271466A1 (en) | Data logging with network interfacing feature | |
| JP3944229B2 (ja) | フレームワークシステム | |
| JP3944230B2 (ja) | フレームワークシステム | |
| JP7083850B2 (ja) | 多規格メッセージ処理 | |
| JPH06290098A (ja) | 分散データベース処理方法 | |
| RU2744566C1 (ru) | Способ и система интеграции информационных ресурсов предприятия | |
| GB2330497A (en) | Destination inconsistency in store and forward conferencing system | |
| JP2002092331A (ja) | 証券決済管理システム、証券決済管理方法 | |
| GB2384329A (en) | Workflow system employing mobile agents | |
| WO2006119790A1 (en) | Methods and systems for electronic records management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051220 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060217 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060313 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060329 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3803707 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090519 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100519 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100519 Year of fee payment: 4 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100519 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110519 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110519 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120519 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120519 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130519 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20220519 Year of fee payment: 16 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |