JP3622467B2 - メッセージ配信管理システムおよび方法並びに情報記録媒体 - Google Patents

メッセージ配信管理システムおよび方法並びに情報記録媒体 Download PDF

Info

Publication number
JP3622467B2
JP3622467B2 JP36443997A JP36443997A JP3622467B2 JP 3622467 B2 JP3622467 B2 JP 3622467B2 JP 36443997 A JP36443997 A JP 36443997A JP 36443997 A JP36443997 A JP 36443997A JP 3622467 B2 JP3622467 B2 JP 3622467B2
Authority
JP
Japan
Prior art keywords
message
data
request
response
processing device
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.)
Expired - Fee Related
Application number
JP36443997A
Other languages
English (en)
Other versions
JPH11187018A (ja
Inventor
彰 佐藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Seiko Epson Corp
Original Assignee
Seiko Epson Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Seiko Epson Corp filed Critical Seiko Epson Corp
Priority to JP36443997A priority Critical patent/JP3622467B2/ja
Publication of JPH11187018A publication Critical patent/JPH11187018A/ja
Application granted granted Critical
Publication of JP3622467B2 publication Critical patent/JP3622467B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

【0001】
【発明の属する技術分野】
本発明は、本発明は、ネットワークにおけるメッセージ配信管理システムおよび方法並びに情報記録媒体に関する。
【0002】
【背景技術および発明が解決しようとする課題】
通信技術の発展により、ネットワークの大規模化、分散処理化が進んでいる。これらのネットワークでは、各処理装置間で様々なメッセージがやりとりされるため、効率的かつ汎用的なメッセージ配信管理を行うことが重要である。
【0003】
しかし、メッセージ配信管理を行う場合、各処理装置は通信相手の所在や状況を意識した通信を行っている。例えば、DB(データベース)管理システムをバージョンアップする際、DBサーバを停止する必要が生じる場合がある。通信元の処理装置は、通信先のDBサーバが停止しているか、どこにあるのか自ら判断して通信する必要がある。このような状況では、効率的なメッセージ配信管理を行うことは困難である。
【0004】
また、バージョンアップ等が行われた場合、メッセージの構造がバージョンアップしたものとしないものとで異なる場合がある。このような場合、一部の処理装置ではバージョンアップが行われ、他の処理装置では行われていないと各処理装置間でメッセージの構造を意識する必要があり、各バージョンに対応したアプリケーションを作成する必要がある。このような状況では、汎用的なメッセージ配信管理を行うことは困難である。特に、24時間稼働する必要があるネットワークシステムにおいては、常にネットワークシステム全体を稼働し続けるための汎用性が必要とされる。
【0005】
本発明の目的は、効率的かつ汎用的なメッセージ配信管理システムおよび方法並びに情報記録媒体提供することにある。
【0006】
【課題を解決するための手段】
前記目的を達成するため、本発明に係るメッセージ配信管理システムは、通信路に接続されたメッセージ配信管理手段を介して、複数の処理装置間で通知型メッセージ、要求応答型メッセージおよび確認許可型メッセージの送受信を行うネットワークにおけるメッセージ配信管理システムであって、
前記メッセージ配信管理手段は、
メッセージの配信管理を行うための通知管理データ、要求応答管理データおよび確認許可管理データを含む管理データが記憶される管理データ記憶手段と、
受信メッセージに基づき、前記管理データの作成を行う管理データ制御手段と、
前記管理データに基づき、受信メッセージを所定の処理装置へ向け配信する配信制御手段と、
を含んで構成され、
前記通知型メッセージは、
状態変化の通知を示す通知メッセージと、
この通知メッセージの受信希望を示す通知希望メッセージの少なくとも2種類のメッセージから構成され、
前記通知メッセージの受信を希望する処理装置は、
前記通知希望メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
前記通知メッセージを前記メッセージ配信管理手段から受信する手段と、
を含んで構成され、
前記状態変化の通知を行う処理装置は、
状態変化時にその旨を、通知メッセージとして前記メッセージ配信管理手段へ向け送信する手段を含んで構成され、
前記管理データ制御手段は、
前記通知希望メッセージを受信した場合に、通知希望元の処理装置へ向け前記状態変化の通知を行うための前記通知管理データを作成し、
前記配信制御手段は、
前記通知メッセージを受信した場合に、前記通知管理データに基づき前記通知希望処理装置へ向け前記通知メッセージを配信するように構成され、
前記要求応答型メッセージは、
情報の問い合わせを示す要求メッセージと、
この要求メッセージに対する応答希望を示す応答希望メッセージと、
前記要求メッセージに対する応答を示す応答メッセージの少なくとも3種類のメッセージから構成され、
前記応答を希望する処理装置は、
前記応答希望メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
前記要求メッセージを前記メッセージ配信管理手段から受信し、要求に対応した応答内容を含む応答メッセージを作成して前記メッセージ配信管理手段へ向け送信する手段と、
を含んで構成され、
前記要求メッセージ送信元の処理装置は、
前記要求メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
要求に対応した前記応答メッセージを前記メッセージ配信管理手段から受信する手段と、
を含んで構成され、
前記管理データ制御手段は、
前記応答希望メッセージを受信した場合に、前記応答希望メッセージ送信元の処理装置へ向け前記要求メッセージの配信を行い、前記要求メッセージを受信した場合に、前記要求メッセージ送信元の処理装置へ向け前記応答メッセージの配信を行うための前記要求応答管理データを作成し、
前記配信制御手段は、
前記要求メッセージを受信した場合に、前記要求応答管理データに基づき前記応答希望メッセージ送信元の処理装置へ向け前記要求メッセージを配信し、前記応答希望メッセージ送信元の処理装置から前記応答メッセージを受信した場合に、前記要求応答管理データに基づき前記要求メッセージ送信元の処理装置へ向け前記応答メッセージを配信するように構成され、
前記確認許可型メッセージは、
イベントの実行に対する許可を得るための確認を示す確認メッセージと、
この確認メッセージに対する許可付与の希望を示す許可希望メッセージと、
前記確認メッセージに対する許可、不許可を示す許可メッセージの少なくとも3種類のメッセージから構成され、
前記許可付与を希望する処理装置は、
前記許可希望メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
前記確認メッセージを前記メッセージ配信管理手段から受信し、前記許可メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
を含んで構成され、
前記確認を行う処理装置は、
前記確認メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
確認に対応した前記許可メッセージを前記メッセージ配信管理手段から受信する手段と、
を含んで構成され、
前記管理データ制御手段は、
前記確認メッセージを受信した場合に、前記許可希望メッセージ送信元の処理装置へ向け前記確認メッセージの配信を行い、前記許可メッセージを受信した場合に、前記確認メッセージ送信元の処理装置へ向け前記許可メッセージの配信を行うための前記確認許可管理データを作成し、
前記配信制御手段は、
前記確認メッセージを受信した場合に、前記確認許可管理データに基づき前記許可希望メッセージ送信元の処理装置へ向け前記確認メッセージを配信し、前記許可希望メッセージ送信元の処理装置から前記許可メッセージを受信した場合に、前記確認許可管理データに基づき前記確認メッセージ送信元の処理装置へ向け前記許可メッセージを配信するように構成されていることを特徴とする。
【0007】
本発明によれば、メッセージの型を通知、要求応答、確認許可という3つに単純化かつ共通化し、これらのメッセージを用いて複数の処理装置間で情報のやりとりを行えるようメッセージを配信管理することにより、ネットワークでの複雑な処理も容易に行うことができる。
【0008】
また、メッセージを共通化しているため、各処理装置やメッセージ配信管理手段でデータの扱い方を共通化でき、各処理装置で個別に対応させる処理を低減し、各処理装置の増減による影響を受けにくいメッセージ配信管理システムを実現できる。
【0009】
したがって、本発明を、特に分散処理ネットワークにおいて用いることが好ましい。
【0010】
また、各メッセージは、
その通信の目的を示す目的データを有するメッセージパターンデータを含んで構成され、
前記目的データは、
少なくとも前記通知、前記通知希望、前記要求、前記応答希望、前記応答、前記確認、前記許可希望、前記許可のいずれかの目的を示すデータであり、
前記管理データ制御手段は、
受信メッセージに含まれる前記メッセージパターンデータを、前記処理装置の所在データと関連づけることにより、前記受信メッセージを配信管理するための配信管理データを作成し、この配信管理データを前記管理データとして、前記管理データ記憶手段に記憶するように構成され、
前記配信制御手段は、
前記受信メッセージに含まれる前記メッセージパターンデータと、前記管理データとに基づき、前記受信メッセージの配信制御を行ってもよい
【0011】
本発明によれば、メッセージパターンデータに含まれる目的データから通信の目的が判断でき、通知、要求といった各メッセージ毎に管理データを作成することができ、メッセージ毎の処理が行いやすい。
【0012】
また、メッセージパターンデータを、処理装置の所在データと関連づけて管理データを作成している。これにより、どのメッセージパターンのときにはどこの処理装置に送るかを各処理装置は意識することなく情報のやりとりが行える。すなわち、通信相手の所在は、メッセージ配信管理手段により管理されているため、通信相手の増減を意識することなく通信が行えるメッセージ配信管理システムを実現できる。
【0013】
また、前記管理データは、
前記処理装置の前記所在データおよび識別データとを有する装置データと、
前記処理装置からの受信メッセージの配信管理を行うためのメッセージデータと、
を含んで構成され、
前記管理データ制御手段は、
前記処理装置が前記通信路との接続を開始した場合に、この処理装置に対する前記識別データを作成し、この識別データと、対応する所在データとを前記装置データとして前記管理データ記憶手段に記憶するとともに、前記受信メッセージに含まれる前記メッセージパターンデータを有する前記メッセージデータを、前記装置データと関連づけることにより、前記メッセージパターンデータに基づき、前記受信メッセージを配信管理するための前記配信管理データを作成し、この配信管理データを前記管理データとして、前記管理データ記憶手段に記憶するように構成され、
前記配信制御手段は、
前記受信メッセージに含まれる前記メッセージパターンデータと、前記管理データとに基づき、前記受信メッセージの配信制御を行ってもよい
【0014】
本発明によれば、通信相手がネットワークに参加した場合でも、この通信相手の情報は、メッセージ配信管理手段に管理されている情報に追加されているため、通信元の処理装置は、通信相手の増加を意識することなく通信が行えるメッセージ配信管理システムを実現できる。
【0015】
また、前記管理データ制御手段は、
前記処理装置が前記通信路との接続を終了した場合に、前記接続時に作成した前記装置データおよび前記装置データと関連づけられた前記メッセージデータを削除してもよい
【0016】
本発明によれば、通信相手がネットワークからいなくなった場合でも、この通信相手の情報は、メッセージ配信管理手段に管理されている情報から削除されているため、通信元の処理装置は、通信相手の減少を意識することなく通信が行えるメッセージ配信管理システムを実現できる。
【0017】
また、前記通知型メッセージは、
前記目的データとして、前記通知または前記通知希望のいずれかのデータを含んで構成され、
前記通知管理データは、
前記通知希望メッセージが配信管理される通知希望装置データを含んで構成され、
前記管理データ制御手段は、
前記通知希望メッセージを受信した場合、前記通知希望装置データを作成して前記管理データ記憶手段に記憶するように構成され、
前記配信制御手段は、
前記通知メッセージを受信した場合、前記通知メッセージに含まれる前記メッセージパターンデータと、前記管理データ記憶手段に記憶された前記通知希望装置データとに基づき、前記通知希望処理装置へ向け前記通知メッセージを配信してもよい
【0018】
本発明によれば、通知型メッセージをやりとりする場合、通知希望メッセージと通知メッセージとが対応するものかどうかを、メッセージパターンデータ同士の比較により判断できるため、効率的に通知処理が行える。特に、不特定多数の通信相手に対してほぼ同時に通知する処理に対して効果的である。
【0019】
また、前記要求応答型メッセージは、
前記目的データとして、前記要求、前記応答または前記応答希望のいずれかのデータを含んで構成され、
前記要求応答管理データは、
前記応答希望メッセージが配信管理される応答希望装置データを含んで構成され、
前記管理データ制御手段は、
前記応答希望メッセージを受信した場合、前記応答希望装置データを作成して前記管理データ記憶手段に記憶するように構成され、
前記配信制御手段は、
前記応答希望メッセージを受信した場合、この応答希望メッセージが前記応答希望装置データに記憶されていないメッセージパターンデータを有するメッセージならば、前記応答希望メッセージ送信元の処理装置へ向け、応答権の付与を示す応答権付与メッセージを配信し、
前記要求メッセージを受信した場合、前記要求メッセージに含まれるメッセージパターンデータと、前記管理データ記憶手段に記憶された前記応答希望装置データとに基づき、前記応答権付与メッセージ配信先の応答希望処理装置へ向け、前記要求メッセージ送信元の処理装置の前記識別データを前記要求メッセージに含ませた要求メッセージを配信し、
前記応答権付与メッセージ配信先の応答希望処理装置は、
前記要求メッセージを受信した場合、この要求メッセージに対する応答メッセージに、前記要求メッセージに含まれる前記識別データを含ませて前記配信制御手段へ向け送信し、
前記配信制御手段は、
前記要求メッセージ配信先の処理装置から前記要求メッセージに対する前記応答メッセージを受信した場合、この応答メッセージ中の識別データに基づき、前記要求メッセージ送信元の処理装置へ向け前記応答メッセージを配信してもよい
【0020】
本発明によれば、要求応答型メッセージをやりとりする場合、応答希望メッセージと要求メッセージとが対応するものかどうかを、メッセージパターンデータ同士の比較により判断できるため、効率的に要求応答処理が行える。
【0021】
また、応答権の付与により応答する処理装置を、一つに限定することができるため、同時に複数の応答を受信しなくて済み、通信量を抑えるとともに確実な要求応答処理が行える。また、一つに限定可能であるため、要求応答型メッセージを排他制御に用いることもできる。
【0022】
さらに、要求メッセージ送信元の識別データをメッセージに含ませることにより、応答メッセージをどこに配送すべきか意識しなくて済む。
【0023】
また、前目的データとしての応答データは、前記要求メッセージに対する回答の継続を示す応答継続データ、この回答の終了を示す応答終了データのいずれかのデータを含んで構成され、
前記配信制御手段は、
前記要求メッセージ配信先の処理装置から、前記応答メッセージを受信した場合、所定の条件に基づき、前記応答メッセージを分割し、
この分割したメッセージに前記応答継続データを含ませて応答継続メッセージとして作成し、前記応答メッセージ中の識別データに基づき、前記要求メッセージ送信元の処理装置へ向け前記応答継続メッセージを配信し、
割した最終の応答メッセージに、前記応答終了データを含ませて応答終了メッセージとして作成し、前記応答メッセージに含まれる前記識別データに基づき、前記要求メッセージ送信元の処理装置へ向け前記応答終了メッセージを配信してもよい
【0024】
ここで、「所定の条件に基づき、前記応答メッセージを分割」とは、応答メッセージが、所定長以上の場合、例えば応答メッセージ配信先の処理装置が処理困難な長さ以上の場合、所定の単位で前記応答メッセージを分割することを意味する。
【0025】
また、「所定の単位」としては、応答メッセージ配信先の処理装置が処理可能な最大長、データ部中の組データ単位または連想配列単位等が考えられるが、連想配列単位が好ましい。
【0026】
本発明によれば、応答内容が多く、メッセージが長くなり、メッセージを分割せざるを得ない場合も、応答継続、応答終了というデータを用いることにより、長い応答内容を含むメッセージも配送することができる。
【0027】
さらに、連想配列単位等の論理的な一単位で分割することにより、データの格納および取り出しが容易となる。
【0028】
また、前記確認許可型メッセージは、
前記目的データとして、前記確認、前記許可または前記許可希望のいずれかのデータを含んで構成され、
前記確認許可管理データは、
前記許可希望メッセージを配信管理する許可希望装置データを含んで構成され、
前記管理データ制御手段は、
前記許可希望メッセージを受信した場合、前記許可希望装置データを作成して前記管理データ記憶手段に記憶するように構成され、
前記配信制御手段は、
前記確認メッセージを受信した場合、この確認メッセージに含まれる前記メッセージパターンデータと、前記管理データ記憶手段に記憶された前記許可希望装置データとに基づき、前記確認メッセージ送信元の確認処理装置の前記識別データを前記確認メッセージに含ませ、前記許可希望処理装置へ向けこの確認メッセージを配信し、
前記確認メッセージの配信先の処理装置から前記確認メッセージに対する前記確認処理装置の識別データを有する許可メッセージを受信した場合、この許可メッセージ中の識別データに基づき、前記確認メッセージ送信元の処理装置へ向け前記許可メッセージを配信してもよい
【0029】
本発明によれば、確認許可型メッセージをやりとりする場合、許可希望メッセージと確認メッセージとが対応するものかどうかを、メッセージパターンデータ同士の比較により判断できるため、効率的に確認許可処理が行える。
【0030】
さらに、確認メッセージ送信元の識別データをメッセージに含ませることにより、許可メッセージをどこに配送すべきか意識しなくて済む。
【0031】
また、前記確認許可型メッセージは、
前記目的データとして、前記確認、前記許可、前記許可希望または前記確認に対する回答の終了を示す許可終了のいずれかのデータを含んで構成され、
前記許可希望メッセージを送信する許可希望処理装置は複数存在し、
前記配信制御手段は、
前記確認メッセージを受信した場合、この確認メッセージに含まれる前記メッセージパターンデータと、前記管理データ記憶手段に記憶された前記許可希望装置データとに基づき、前記確認メッセージ送信元の確認処理装置の前記識別データを前記確認メッセージに含ませ、複数の許可希望処理装置へ向けこの確認メッセージを配信し、
前記複数の許可希望処理装置は、
前記確認メッセージを受信した場合、この確認メッセージに含まれる前記識別データを送信する許可メッセージに含ませ、この許可メッセージを前記メッセージ配信管理手段へ向け送信し、
前記配信制御手段は、
前記確認メッセージ配信先の複数の処理装置から前記確認メッセージに対する前記許可メッセージを受信した場合、この許可メッセージ中の識別データに基づき、前記確認メッセージ送信元の処理装置へ向け前記許可メッセージを配信し、
受信した許可メッセージが最終のものである場合、この許可メッセージ中の識別データに基づき、前記確認メッセージ送信元の処理装置へ向け、前記許可メッセージを配信するとともに、前記目的データに前記許可終了を含ませた許可終了メッセージを配信してもよい
【0032】
本発明によれば、複数の処理装置から許可をもらう必要がある場合も、許可終了データを用いることにより、確認メッセージを送信した処理装置は、有効な全許可処理装置から許可が返送されたことを判断できる。
【0033】
また、前記メッセージパターンデータは、
前記目的データに基づき選択された前記管理データにおいて、所定のメッセージを受信する処理装置のグループを示すグループデータを含んで構成され、
前記管理データ制御手段は、
前記目的データおよび前記グループデータが指定されたメッセージを受信した場合、この受信メッセージに含まれる前記目的データに基づき前記管理データを選択し、前記受信メッセージに含まれる前記グループデータに基づき、前記受信メッセージに基づき作成した配信管理データを、前記管理データ記憶手段中の選択した管理データ中に分類して記憶し、
前記配信制御手段は、
前記目的データおよび前記グループデータが指定されたメッセージを受信した場合、この受信メッセージの前記メッセージパターンデータと、前記メッセージパターンデータと対応する前記管理データ中の前記配信管理データとに基づき、前記受信メッセージの配信制御を行ってもよい
【0034】
本発明によれば、目的データにより当該メッセージの目的を区別し、グループデータにより送受信対象を区別することができる。これにより、送受信対象を限定したメッセージ配信処理が行える。
【0035】
また、各メッセージは、
前記メッセージパターンデータを有する固定長のヘッダ部と、
前記メッセージパターンデータに応じた詳細データを有する可変長のデータ部と、
を含んで構成され、
前記データ部は、
データ名とそのデータ名に対応するデータとからなる組データを含んで構成され、
前記処理装置および前記メッセージ配信管理手段は、
前記データ名を指定することにより、そのデータ名に対応するデータを取得できるように構成されていてもよい
【0036】
本発明によれば、ヘッダ部を固定長とし、ヘッダ部に各メッセージ共通で必要なデータを含ませることにより、各メッセージ共通で必要なデータを取得しやすくし、データ部を可変長とすることにより詳細なデータであってもメッセージに含ませることができる。これにより、メッセージ処理効率を上げるとともに柔軟なデータ表現が可能なメッセージを実現できる。
【0037】
また、メッセージから詳細なデータを取り出す場合、データ名を指定することにより対応するデータを取得できる。例えば、配列構造でデータ表現した場合、当該配列の要素を取り出すには、要素番号を指定するため、どういう順番でデータが格納されているか意識する必要があるが、本発明によれば、データの格納順序を意識することなくデータを取得できる。
【0038】
したがって、バージョンアップ等でメッセージに格納されるデータ要素が異なっている場合でも、メッセージにより適切に情報をやりとりすることができる。
【0039】
なお、データ名のデータ型としては、文字列型、数型、日付型等の各種のデータ型を適用できる。
【0040】
また、前記組データは、
連想配列形式で構成され、
前記処理装置および前記メッセージ配信管理手段は、
前記連想配列形式のデータから必要な組データを取り出して前記データ名を指定することにより、そのデータ名に対応するデータを取得できるように構成されていてもよい
【0041】
本発明によれば、連想配列形式のデータから必要な組データを取り出すことができ、単独の組データで表現されたデータ構造と同様にデータを格納および取得することができる。
【0042】
すなわち、複雑なデータをメッセージに格納する場合でも、連想配列形式で表現することにより、単独の組データとしてデータを単純化して扱うことができ、柔軟性の高いメッセージ配信管理システムを実現できる。
【0043】
ここで、連想配列とは、UNIXのPerl等で用いられている通常の連想配列のことである。
【0044】
また、前記メッセージ配信管理手段は、
メッセージ変換手段を有し、
前記ヘッダ部は、
そのメッセージにおいて使用されている文字種別を示す文字種別データを含んで構成され、
前記メッセージ変換手段は、
前記文字種別データに基づきそのメッセージにおいて使用されている文字を変換できるように構成されていてもよい
【0045】
例えば、通信元の処理装置では文字種別としてEUC(Extended UNIX Code)を用いてメッセージを作成して送信した場合、通信先の処理装置では文字種別としてSJIS(ShiftJIS)しか認識しない場合、通信先でメッセージの文字種別を判断して変換しなければならないが、本発明によれば、メッセージ配信管理手段内のメッセージ変換手段がメッセージ中の文字種別データから文字種別を判断して変換するため、通信元や通信先の処理装置はメッセージの文字種別を意識せずに通信できる。これにより、汎用的なメッセージ配信管理システムを実現できる。
【0046】
また、前記メッセージパターンデータは、
前記目的データに基づき選択された前記管理データにおいて、前記グループデータに基づき選択された所定の処理装置から当該メッセージの処理を行う処理装置が選択されるための処理内容を示すカテゴリデータを含んで構成され、
前記管理データ制御手段は、
前記目的データ、前記グループデータおよび前記カテゴリデータが指定されたメッセージを受信した場合、この受信メッセージに含まれる前記目的データに基づき前記管理データを選択し、前記受信メッセージに含まれる前記グループデータおよび前記カテゴリデータに基づき、前記受信メッセージに基づき作成した配信管理データを、前記管理データ記憶手段中の選択した管理データ中に分類して記憶し、
前記配信制御手段は、
前記目的データ、前記グループデータおよび前記カテゴリデータが指定されたメッセージを受信した場合、この受信メッセージの前記メッセージパターンデータと、前記メッセージパターンデータと対応する前記管理データ中の前記配信管理データとに基づき、前記受信メッセージの配信制御を行ってもよい。本発明によれば、処理内容によってメッセージを配信すべき処理装置を選択することができる。これにより、通信元は、そのメッセージによる処理に適した処理装置を意識することなく、処理を行うことができる。したがって、本発明を、分散処理ネットワークのような各処理装置が種々の処理を分担して行うようなネットワークにおいて用いることが好ましい。
【0047】
また、前記グループデータまたは前記カテゴリデータの少なくとも一方は、
前記グループデータにおける前記グループまたは前記カテゴリデータにおける前記処理内容が段階的に分類された複数の分類データを含んで構成され、
前記配信制御手段は、
前記複数の分類データが指定されたメッセージを受信した場合、この受信メッセージの前記メッセージパターンデータと、前記管理データと、前記複数の分類データとに基づきメッセージ共有グループを段階的に絞り込み、前記受信メッセージの配信制御を行ってもよい
【0048】
本発明によれば、上述したように、グループデータまたはカテゴリデータによって選択された処理装置をさらに細かいレベルで区別することができる。したがって、本発明を、特に処理装置が多数存在する大規模ネットワークにおいて用いることが好ましい。
【0049】
また、前記分類データには、
当該分類に属する全処理装置を示す全指定データを指定可能であり、
前記配信制御手段は、
前記分類に前記全指定データが指定されたメッセージを受信した場合、この受信メッセージの前記メッセージパターンデータと、前記管理データと、前記全指定データが指定された前記分類データとに基づき、前記受信メッセージの配信管理を行ってもよい
【0050】
本発明によれば、処理装置を細かくレベル分けした場合でも、全指定データにより細かくレベル分けしない場合と同様のメッセージ配信管理が可能となる。例えばカテゴリデータにおいて、上位の分類としてあるデータベースを指定し下位の分類を全指定とした場合、あるデータベースを検索するメッセージや、あるデータベースを更新するメッセージも、同一の処理装置に配信することができる。すなわち、カテゴリデータをレベル分けせずに、カテゴリデータに、あるデータベースとだけ指定した場合と同様の処理が行える。したがって、本発明を、特に処理装置が多数存在する大規模ネットワークにおいて用いることが好ましい。
【0051】
また、前記通知型、前記要求応答型、前記確認許可型メッセージのうち少なくとも1つのメッセージは、
前記目的データとして、所定の処理装置が前記通信路との接続を開始した場合にその通知が行われるための開始通知希望データを含んで構成され、
前記管理データのうち少なくとも1つの管理データは、
前記開始通知希望データが指定された開始通知希望メッセージが配信管理される開始通知希望装置データを含んで構成され、
前記管理データ制御手段は、
前記開始通知希望メッセージを受信した場合、前記開始通知希望装置データを作成して前記管理データ記憶手段に記憶し、
前記配信制御手段は、
前記カテゴリデータに前記通信路との接続の開始を通知する接続開始データが指定されたメッセージを、前記所定の処理装置から受信した場合、この受信メッセージに含まれる前記メッセージパターンデータと、前記開始通知希望装置データとに基づき、前記開始通知希望メッセージを送信した処理装置へ向け、前記接続開始データが指定されたメッセージを配信してもよい
【0052】
本発明によれば、通信元の処理装置が、メッセージ送信対象となるべき処理装置が存在するかどうか確認した上でメッセージを送信することが可能となる。
【0053】
また、前記要求メッセージを送信する処理装置は、
この要求メッセージに対応する応答が可能な応答装置が前記通信路との接続を開始し、この応答装置から前記応答希望メッセージを前記メッセージ配信管理手段が受信した場合にその通知が行われるための応答通知希望メッセージを送信するよう構成され、
前記要求応答管理データは、
前記応答通知希望メッセージが配信管理される応答装置待ちデータを含んで構成され、
前記管理データ制御手段は、
前記応答通知希望メッセージを受信した場合、このメッセージに基づき応答装置待ちデータを作成して前記管理データ記憶手段に記憶し、
前記配信制御手段は、
前記応答希望メッセージを前記応答装置から受信した場合、この受信メッセージの前記メッセージパターンデータと、前記応答装置待ちデータとに基づき、前記応答通知希望メッセージを送信した処理装置へ向け、前記応答装置の出現を通知する応答装置出現メッセージを配信してもよい
【0054】
本発明によれば、通信元の処理装置が、メッセージ送信対象となるべき処理装置が存在するかどうか確認した上でメッセージの送信を開始することが可能となる。
【0055】
また、前記通知型、前記要求応答型、前記確認許可型メッセージのうち少なくとも1つのメッセージは、
前記目的データとして、所定の処理装置が前記通信路との接続を終了した場合にその通知が行われるための終了通知希望データを含んで構成され、
前記管理データのうち少なくとも1つの管理データは、
前記終了通知希望データが指定された終了通知希望メッセージが配信管理される終了通知希望装置データを含んで構成され、
前記管理データ制御手段は、
前記終了通知希望メッセージを受信した場合、前記終了通知希望装置データを作成して前記管理データ記憶手段に記憶し、
前記配信制御手段は、
前記所定の処理装置が前記通信路との接続を終了した場合、前記終了通知希望装置データに基づき、前記終了通知希望メッセージを送信した処理装置へ向け接続終了を示すメッセージを配信してもよい
【0056】
本発明によれば、通信元の処理装置が、メッセージ送信対象となるべき処理装置が存在するかどうか確認した上でメッセージを送信することが可能となる。なお、所定の処理装置が通信路との接続を終了したかどうかの判断は、所定の処理装置からカテゴリデータに終了通知を示すデータが指定されたメッセージを受信することで判断してもよいし、所定の処理装置の通信ポートを常に監視しておき、当該通信ポートの接続が切れたことで判断してもよい。
【0057】
また、前記要求応答型メッセージは、
前記目的データとして、前記応答権を有する処理装置が前記通信路との接続を終了した場合にその通知が行われるための終了通知希望データを含んで構成され、
前記要求応答管理データは、
前記終了通知希望データが指定された終了通知希望メッセージが配信管理される終了通知希望装置データを含んで構成され、
前記管理データ制御手段は、
前記終了通知希望メッセージを受信した場合、前記終了通知希望装置データを作成して前記管理データ記憶手段に記憶し、
前記配信制御手段は、
前記応答権を有する処理装置が前記通信路との接続を終了した場合、
応答権付与待ちの処理装置がないならば、前記終了通知希望装置データに基づき、前記終了通知希望メッセージを送信した処理装置へ向け接続終了を示すメッセージを配信してもよい
【0058】
本発明によれば、要求元の処理装置が、接続終了を示すメッセージを受信することにより、当該要求を行うことが可能かどうか判断できる。
【0059】
また、前記メッセージ配信管理手段は、
時間測定手段を有し、
前記処理装置からメッセージ受信後、前記時間測定手段により測定された測定時間に基づき、当該メッセージに対して行われる処理をタイムアウト処理してもよい
【0060】
ここで、測定時間とは、例えば、メッセージ受信時や、当該メッセージに対してメッセージを配信した時点を測定開始時点とし、当該メッセージに対してメッセージを配信した処理装置から回答メッセージを受信した時点や、当該メッセージに対応したメッセージを配信する時点を測定終了時点として測定した時間のことである。
【0061】
また、当該メッセージに対して行う処理とは、例えば、上記当該メッセージに対してメッセージを配信した処理装置から回答メッセージを受信する処理や、上記当該メッセージに対応したメッセージを配信する処理のことである。
【0062】
また、タイムアウト処理とは、前記測定時間が所定の時間を超えていることを判断し、上記当該メッセージに対して行われる処理をそれ以上待つことを止めることである。
【0063】
本発明によれば、待ち時間が少なくなり、メッセージ配信処理を短時間に行うことができる。また、メッセージを送信したが、それに対する回答メッセージがいつまで経っても戻ってこないといった事態を回避することができ、効率的なメッセージ配信管理システムを実現できる。
【0064】
また、前記管理データは、
処理装置から送られたメッセージの配信状態が、各処理装置毎に管理される状態管理データを含んで構成され、
前記管理データ制御手段は、
前記処理装置からメッセージを受信した場合、前記受信メッセージを送信した処理装置用の前記状態管理データを作成して前記管理データ記憶手段に記憶し、
前記処理装置から前記処理装置または他の処理装置のメッセージ配信状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記状態管理データを取得するよう構成され、
前記配信制御手段は、
前記問い合わせがあった場合、前記問い合わせ元の処理装置へ向け、前記取得した状態管理データの情報を含ませたメッセージを配信してもよい
【0065】
本発明によれば、各処理装置が、自己のメッセージ配信状態や、他の処理装置のメッセージ配信状態を確認することができる。これにより、メッセージ配信状態のモニタリングを実現できる。
【0066】
また、前記通知管理データは、
前記通知希望メッセージの配信状態が、各処理装置毎に管理される通知希望状態データを含んで構成され、
前記管理データ制御手段は、
前記通知希望メッセージを受信した場合、前記通知希望状態データを作成して前記管理データ記憶手段に記憶し、
前記処理装置から前記処理装置または他の処理装置の通知希望メッセージ配信状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記通知希望状態データを取得するよう構成され、
前記配信制御手段は、
前記通知希望メッセージ配信状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記通知希望状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した通知希望状態データの情報を含ませたメッセージを配信してもよい
【0067】
本発明によれば、各処理装置が、自己の通知型メッセージ配信状態や、他の処理装置の通知型メッセージ配信状態を確認することができる。これにより、通知型メッセージ配信状態のモニタリングを実現できる。
【0068】
また、前記要求応答管理データは、
前記要求メッセージの配信状態が、各処理装置毎に管理される要求状態データと、
前記応答希望メッセージの配信状態が、各処理装置毎に管理される応答希望状態データと、
を含んで構成され、
前記管理データ制御手段は、
前記応答希望メッセージを受信した場合、前記応答希望状態データを作成して前記管理データ記憶手段に記憶し、
前記要求メッセージを受信した場合、前記要求状態データを作成して前記管理データ記憶手段に記憶し、
前記処理装置から前記処理装置または他の処理装置の応答希望メッセージ配信状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記応答希望状態データを取得し、
前記処理装置から前記処理装置または他の処理装置の要求メッセージ配信状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記要求状態データを取得するよう構成され、
前記配信制御手段は、
前記応答希望メッセージ配信状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記応答希望状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した応答希望状態データの情報を含ませたメッセージを配信し、
前記要求メッセージ配信状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記要求状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した要求状態データの情報を含ませたメッセージを配信してもよい。
【0069】
本発明によれば、各処理装置が、自己の要求応答型メッセージ配信状態や、他の処理装置の要求応答型メッセージ配信状態を確認することができる。これにより、要求応答型メッセージ配信状態のモニタリングを実現できる。
【0070】
また、前記確認許可管理データは、
前記確認メッセージの配信状態が管理される確認状態データと、
前記許可希望メッセージの配信状態が管理される許可希望状態データと、
を含んで構成され、
前記管理データ制御手段は、
前記許可希望メッセージを受信した場合、前記許可希望状態データを作成して前記管理データ記憶手段に記憶し、
前記確認メッセージを受信した場合、前記確認状態データを作成して前記管理データ記憶手段に記憶し、
前記処理装置から前記処理装置または他の処理装置の許可希望メッセージ配信管理状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記許可希望状態データを取得し、
前記処理装置から前記処理装置または他の処理装置の確認メッセージ配信管理状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記確認状態データを取得するよう構成され、
前記配信制御手段は、
前記許可希望メッセージ配信管理状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記許可希望状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した許可希望状態データの情報を含ませたメッセージを配信し、
前記確認メッセージ配信管理状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記確認状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した確認状態データの情報を含ませたメッセージを配信してもよい
【0071】
本発明によれば、各処理装置が、自己の確認許可型メッセージ配信状態や、他の処理装置の確認許可型メッセージ配信状態を確認することができる。これにより、確認許可型メッセージ配信状態のモニタリングを実現できる。
【0072】
また、本発明に係るメッセージ配信管理方法は、メッセージの配信管理を行うための通知管理データ、要求応答管理データおよび確認許可管理データを用い、通信路に接続されたメッセージ配信管理手段を介して複数の処理装置間において、
状態変化の通知を示す通知メッセージおよびこの通知メッセージの受信希望を示す通知希望メッセージを含む通知型メッセージと、
情報の問い合わせを示す要求メッセージ、この要求メッセージに対する応答希望を示す応答希望メッセージおよび前記要求メッセージに対する応答を示す応答メッセージを含む要求応答型メッセージと、
イベントの実行に対する許可を得るための確認を示す確認メッセージ、この確認メッセージに対する許可付与の希望を示す許可希望メッセージおよび前記確認メッセージに対する許可、不許可を示す許可メッセージを含む確認許可型メッセージの送受信を行うネットワークにおけるメッセージ配信管理方法であって、
状態変化の通知を行う通知工程と、
情報の問い合わせと回答を行う要求応答工程と、
イベントの実行に対する確認と許可を行う確認許可工程と、
を含み、
前記通知工程は、
前記複数の処理装置から送信される状態変化の通知を希望する通知希望メッセージを受信する通知希望受信工程と、
前記通知希望メッセージを管理データ記憶手段に記憶する通知希望記憶工程と、
前記複数の処理装置から送信される前記通知メッセージを受信する通知受信工程と、
前記通知メッセージを前記管理データ記憶手段に記憶する通知記憶工程と、
前記配信制御手段により、前記管理データ記憶手段に記憶された通知メッセージと、前記管理データ記憶手段に記憶された通知希望メッセージとを比較する通知比較工程と、
前記通知メッセージと、前記通知希望メッセージとが対応するものである場合、前記通知希望メッセージを送信した処理装置へ向け前記通知メッセージを配信する通知メッセージ配信工程と、
を含み、
前記要求応答工程は、
前記複数の処理装置から送信される情報の問い合わせの応答を希望する応答希望メッセージを受信する応答希望受信工程と、
前記応答希望メッセージを送信した処理装置に対して所定の条件で応答権を付与する応答権付与工程と、
前記応答希望メッセージを前記管理データ記憶手段に記憶する応答希望記憶工程と、
前記複数の処理装置から送信される情報の問い合わせの応答を要求する要求メッセージを受信する要求受信工程と、
前記要求メッセージを前記管理データ記憶手段に記憶する要求記憶工程と、
前記配信制御手段により、前記管理データ記憶手段に記憶された要求メッセージパターンデータと、前記管理データ記憶手段に記憶された応答希望メッセージパターンデータとを比較する要求応答比較工程と、
前記要求メッセージパターンデータと、前記応答希望メッセージパターンデータとが対応するものである場合、前記応答希望メッセージを送信し、前記応答権を付与された処理装置へ向け前記要求メッセージを配信する要求メッセージ配信工程と、
前記要求メッセージを配信した処理装置から応答メッセージを受信し、前記要求メッセージを送信した処理装置へ向け配信する応答メッセージ配信工程と、
を含み、
前記確認許可工程は、
前記処理装置から送信される前記許可希望メッセージを受信する許可希望受信工程と、
この許可希望メッセージを前記管理データ記憶手段に記憶する許可希望記憶工程と、
前記処理装置から送信される確認メッセージを受信する確認受信工程と、
この確認メッセージを前記管理データ記憶手段に記憶する確認記憶工程と、
前記配信制御手段により、前記管理データ記憶手段に記憶された確認メッセージと、前記管理データ記憶手段に記憶された許可希望メッセージとを比較する確認許可比較工程と、
前記確認メッセージと、前記許可希望メッセージとが対応するものである場合、前記許可希望メッセージを送信した処理装置へ向け前記確認メッセージを配信する確認メッセージ配信工程と、
前記確認メッセージを配信した処理装置から前記許可メッセージを受信する工程と、
前記確認メッセージを送信した処理装置へ向け前記受信した許可メッセージを配信する許可メッセージ配信工程と、
を含むことを特徴とする。
【0073】
本発明によれば、メッセージの型を通知、要求応答、確認許可という3つに単純化かつ共通化し、これらのメッセージを用いて複数の処理装置間で情報のやりとりを行えるようメッセージを配信管理することにより、ネットワークでの複雑な処理も容易に行うことができる。
【0074】
また、メッセージを共通化しているため、各処理装置やメッセージ配信管理手段でデータの扱い方を共通化でき、各処理装置で個別に対応させる処理を低減し、各処理装置の増減による影響を受けにくいメッセージ配信管理方法を実現できる。
【0075】
したがって、本発明を、特に分散処理ネットワークにおいて用いることが好ましい。なお、応答権付与工程における所定の条件としては、未記憶のメッセージパターンデータを有する応答希望メッセージを送信した処理装置に応答権を付与してもよいし、優先度に応じて応答権を付与してもよい。また、応答権付与の方法としては、要求応答管理データで応答権を付与した処理装置を管理すればよく、これに加えてメッセージ配信管理手段により応答権付与メッセージを当該応答希望メッセージを送信した処理装置へ向け配信してもよい。
【0076】
また、本発明に係る情報記録媒体は、複数の処理装置が存在するネットワーク上において、
状態変化の通知を示す通知メッセージおよびこの通知メッセージの受信希望を示す通知希望メッセージを含む通知型メッセージと、
情報の問い合わせを示す要求メッセージ、この要求メッセージに対する応答希望を示す応答希望メッセージおよび前記要求メッセージに対する応答を示す応答メッセージを含む要求応答型メッセージと、
イベントの実行に対する許可を得るための確認を示す確認メッセージ、この確認メッセージに対する許可付与の希望を示す許可希望メッセージおよび前記確認メッセージに対する許可、不許可を示す許可メッセージを含む確認許可型メッセージの送受信を行うメッセージ配信管理手段として、前記ネットワークに接続されたコンピュータを機能させるためのプログラムが記録された情報記録媒体であって、
前記メッセージ配信管理手段は、
各メッセージの配信管理を行うための通知管理データ、要求応答管理データおよび確認許可管理データを含む管理データが記憶される管理データ記憶手段と、
受信メッセージに基づき、前記管理データの作成を行う管理データ制御手段と、
前記管理データに基づき、受信メッセージを所定の処理装置へ向け配信する配信制御手段と、
を含んで構成され、
前記管理データ制御手段は、
前記通知希望メッセージを受信した場合に、通知希望元の処理装置へ向け前記状態変化の通知を行うための前記通知管理データを作成し、
前記応答希望メッセージを受信した場合に、前記応答希望メッセージ送信元の処理装置へ向け前記要求メッセージの配信を行い、前記要求メッセージを受信した場合に、前記要求メッセージ送信元の処理装置へ向け前記応答メッセージの配信を行うための前記要求応答管理データを作成し、
前記確認メッセージを受信した場合に、前記許可希望メッセージ送信元の処理装置へ向け前記確認メッセージの配信を行い、前記許可メッセージを受信した場合に、前記確認メッセージ送信元の処理装置へ向け前記許可メッセージの配信を行うための前記確認許可管理データを作成し、
前記配信制御手段は、
前記通知メッセージを受信した場合に、前記通知管理データに基づき前記通知希望処理装置へ向け前記通知メッセージを配信し、
前記要求メッセージを受信した場合に、前記要求応答管理データに基づき前記応答希望メッセージ送信元の処理装置へ向け前記要求メッセージを配信し、前記応答希望メッセージ送信元の処理装置から前記応答メッセージを受信した場合に、前記要求応答管理データに基づき前記要求メッセージ送信元の処理装置へ向け前記応答メッセージを配信し、
前記確認メッセージを受信した場合に、前記確認許可管理データに基づき前記許可希望メッセージ送信元の処理装置へ向け前記確認メッセージを配信し、前記許可希望メッセージ送信元の処理装置から前記許可メッセージを受信した場合に、前記確認許可管理データに基づき前記確認メッセージ送信元の処理装置へ向け前記許可メッセージを配信することを特徴とする。
【0077】
本発明によれば、メッセージの型を通知、要求応答、確認許可という3つに単純化かつ共通化し、これらのメッセージを用いて複数の処理装置間で情報のやりとりを行えるようメッセージを配信管理することにより、ネットワークでの複雑な処理も容易に行うことができる。また、メッセージを共通化しているため、各処理装置やメッセージ配信管理手段でデータの扱い方を共通化でき、各処理装置で個別に対応させる処理を低減し、各処理装置の増減による影響を受けにくいメッセージ配信管理可能な情報記録媒体を実現できる。
【0078】
したがって、本発明を、特に分散処理ネットワークにおいて用いることが好ましい。
【0079】
【発明の実施の形態】
本発明は、各種のネットワークシステムに適用することが可能であるが、種々のメッセージや処理装置が存在する大規模ネットワークシステムや分散処理ネットワークシステムに適用すれば、特に効果的である。
【0080】
以下、本発明を分散処理ネットワークに適用した実施例について、図面を用いながら説明する。
【0081】
図1は、分散処理ネットワークシステムの一例を示す。この分散処理ネットワークシステムは、メッセージ配信管理手段であるメッセージ配信管理サーバ310と、メッセージ送受信を行う複数の処理装置320〜334と、これら各処理装置が接続された通信路300とを含んで構成されている。
【0082】
このような種々の処理装置が存在し、各処理装置がメッセージをやりとりして処理を分散して行っている状況において、効率的かつ汎用的な分散処理ネットワークシステムを実現するためには、各処理装置間でやりとりされるメッセージのデータ構造、取り扱い方法、種別を標準化し、これらを適切に扱えるメッセージ配信管理システムを実現することが効果的である。以下、メッセージのデータ構造の標準化、メッセージの取り扱い方法の標準化、メッセージの種別の標準化について説明する。
【0083】
(メッセージのデータ構造の標準化)
図2は、メッセージのデータ構造の概略図である。メッセージのデータ構造の標準化として、固定長のヘッダ部100と可変長のデータ部200とから構成されるメッセージを規定した。必須の情報は、固定長のヘッダ部100に入力し、メッセージの詳細な内容については可変長のデータ部200に入力することにより、データの取り扱いが容易となる。
【0084】
前記必須の情報として、メッセージの種別を示すメッセージパターンデータ102を規定した。
【0085】
メッセージパターンデータ102は、少なくとも通信の目的を示す目的データ140を含んで構成される。目的データ140を用いることにより、通信の目的を判断でき、メッセージの取り扱いが容易となる。
【0086】
メッセージの目的データ140に加えて、通信対象グループを示すグループデータ150、さらにはメッセージの意味内容を示すカテゴリデータ160を含んで構成すれば、さらにメッセージの種別を細かく区分した、複雑なメッセージ配信も行える。
【0087】
グループデータ150とは、具体的には、ある地域、ある工場、ある職場等の一定の通信対象となるグループを示すデータのことである。また、カテゴリデータ160とは、具体的には、製品の加工、残高照会、データベース(以下「DB」という。)の検索等のメッセージによる処理の内容を示すデータのことである。
【0088】
すなわち、グループデータ150を用いることにより、送受信対象を区別することができ、送受信対象を限定したメッセージ配信が行える。また、カテゴリデータ160を用いることにより、処理内容に応じた処理装置を選択でき、これにより通信元の処理装置は、そのメッセージによる処理に適した処理装置を意識することなく通信が行える。
【0089】
図3は、ヘッダ部100の概略図を示す。図3に示すように、これらグループデータ150、カテゴリデータ160を、多段階に分類するための分類データ152を設けることにより、さらに詳細に区分したメッセージ配信も可能となる。したがって、分類データ152を大規模なネットワークシステムに用いれば、特に効果的である。
【0090】
また、分類データ152等には当該分類に属する処理装置を全て指定することが可能な全指定データを指定することができる。ネットワークが大規模であれば、分類も多段階となり、1つの分類に属する処理装置も増大するが、例えばグループデータ150において、上位分類152−1、2だけ指定し、下位分類152−3に全指定データを指定することにより、1回の通信で下位分類152−3に属する処理装置を全て指定することができ、効率的なメッセージ配信処理が行える。なお、全指定データとは、具体的には、ALL等の文字列や、*等の記号等が適用できる。
【0091】
また、カテゴリデータ160において、例えば、上位の分類152−4として従業員DBを指定し、下位の分類152−5に全指定データを指定した場合、従業員DBを検索するメッセージや、更新するメッセージも同一の処理装置に配信することができる。したがって、カテゴリデータ160の上位分類152−4に従業員DBとだけ指定した場合と同様のメッセージ配信処理が行える。すなわち、通信相手を意識せずに処理内容に適した処理装置を選択することができるメッセージ配信処理が行える。
【0092】
以上説明してきたヘッダ部100に格納されるデータに応じてデータ部200には当該メッセージの詳細な情報が格納される。本実施の形態では、メッセージを取り扱いやすくするため、図2に示すように、データ名202とそのデータ名202に対応するデータ204とからなる組データを、連想配列形式で格納している。組データとすることにより、バージョンアップによらない汎用的なメッセージ配信管理システムを実現できる。
【0093】
図4は、データ部200の一例を示す。例えば、作業者名のデータを取り出す場合、配列構造では要素番号を指定するため、どういう順番でデータが格納されているか意識する必要があるが、本実施の形態によれば、作業者名と指定すれば鈴木というデータが取り出せるため、データの格納順序を意識することなくデータを取り扱える。
【0094】
また、連想配列形式とすることにより、単独の組データで表現されたデータ構造と同様にデータを取り扱うことができる。すなわち、複雑なデータをメッセージに格納する場合でも、連想配列形式で表現することにより単独の組データとしてデータを単純化して扱うことができ、汎用性の高いメッセージ配信管理システムを実現することができる。
【0095】
なお、ここで連想配列とは、インデクスの値を配列の要素に対応づけたものであり、UNIXのPerl等で用いられる連想配列と同様のものである。例えば、C++等の配列は整数を配列の要素に対応づけたものであるが、連想配列では上記インデクスの値として、整数型以外に、実数型、日付型、文字列型等の各種のデータ型を適用できる。
【0096】
(メッセージの取り扱い方法の標準化)
上述したように、メッセージのデータ構造を規定することにより、メッセージの取り扱い方法も標準化できる。ここでメッセージ処理の流れについて概説する。メッセージ処理は、概略的には、配信用に記憶し、次に記憶したメッセージと受信したメッセージを比較し、受信したメッセージを配信するという流れとなる。図5は、概略的なメッセージ処理の流れを示すフローチャートである。ネットワークの構成は図6に示すものとする。例えば、通信元の処理装置8ではメッセージ20を作成し、メッセージ配信管理手段4へ向け送信する(ステップ2)。
【0097】
メッセージ配信管理手段4は、メッセージの配信管理を行うための管理データを記憶する管理データ記憶手段52と、受信メッセージに基づき、管理データの作成を行う管理データ制御手段54と、管理データに基づき、受信メッセージを所定の処理装置へ向け配信する配信制御手段56とを含んで構成されている。
【0098】
メッセージ配信管理手段4では、メッセージ20を受信(ステップ4)後、管理データ制御手段54により、受信メッセージ20に含まれるヘッダ部100中のメッセージパターンデータ102からメッセージ20の種別を判断し(ステップ6)、適切な配信管理データ60を作成して(ステップ8)管理データ記憶手段52に記憶する(ステップ10)。
【0099】
メッセージ配信管理手段4は、処理装置10からメッセージ22を受信し、配信管理データ60と比較することにより、受信メッセージ22を配信すべきかどうか判断する。
【0100】
受信メッセージを配信すべきと判断した場合(ステップ12)、配信制御手段56により、受信メッセージを所定の処理装置8(8−1、8−2)へ向け配信する(ステップ14)。
【0101】
所定の処理装置8では、配信されたメッセージ中のメッセージパターンデータ102に基づき、当該メッセージ22の種別を判断し、当該メッセージ中のデータ部200から必要な組データを取り出し、必要な処理を行う(ステップ16)。回答が必要かどうか判断し(ステップ18)、回答が必要な場合は、回答メッセージを作成してメッセージ配信管理手段4へ向け送信する(ステップ20)。
【0102】
以上のように、メッセージパターンデータ102という少量の情報からメッセージの種別を効率的に判断でき、メッセージのデータ構造も規定されているため、データの取り扱いは容易かつ汎用的である。
【0103】
また、以上、説明してきたように、メッセージのデータ構造を規定し、データの取り扱い方を標準化することにより、バージョンアップが行われてデータ構造が異なるメッセージがやりとりされるようになった場合でも、各処理装置間でメッセージの構造を意識する必要はなく、汎用的なメッセージ配信管理を行うことができる。
【0104】
(メッセージの種別の標準化)
本実施の形態では、さらにメッセージ種別も標準化している。効率的かつ汎用的なメッセージ配信を行うため、通知型、要求応答型、確認許可型という3つのメッセージを規定した。通知型とは、通知希望のあった処理装置に対して状態変化の通知を行う一連の処理であり、要求応答型とは、処理装置間で情報の問い合わせと問い合わせに対する応答を行う一連の処理であり、確認許可型とは、イベントの実行に対する確認とそれに対する許可を行う一連の処理である。なお、通知、要求等のメッセージの違いはメッセージに含まれる目的データ140により判断することができる。
【0105】
以下、これら3つのメッセージ配信処理に共通する全体の構成および処理を説明した後、個別の事項について説明する。
【0106】
(3つのメッセージに共通する全体の構成および処理)
上述したように、ネットワークに接続している各処理装置間でやりとりされる3つのメッセージは、メッセージ配信管理手段4において配信管理される。
【0107】
配信管理されるために用いられる管理データは、ネットワークに接続している処理装置の所在データと識別データとを有する装置データと、処理装置からの受信メッセージが配信管理されるためのメッセージデータとを含んで構成される。
【0108】
管理データ制御手段54は、処理装置が通信路300との接続を開始した場合に、この処理装置に対する識別データを作成し、この識別データと、対応する所在データとを装置データとして管理データ記憶手段52に記憶する。
【0109】
これによれば、通信相手がネットワークに参加した場合でも、この通信相手の情報は、メッセージ配信管理手段4に管理されている情報に追加されているため、通信元の処理装置は、通信相手の増加を意識することなく通信が行えるメッセージ配信管理システムを実現できる。
【0110】
また、管理データ制御手段4は、受信メッセージに含まれるメッセージパターンデータ102を有するメッセージデータを、装置データと関連づけることにより、メッセージパターンデータ102に基づき、受信メッセージを配信管理するための配信管理データ60を作成し、この配信管理データ60を管理データとして管理データ記憶手段52に記憶するよう構成されている。
【0111】
ここで、所在データとしては、処理装置のアドレスや、ポート番号等が用いられる。メッセージパターンデータ102が処理装置の所在データと関連づけられることにより、どのメッセージパターンのときにはどこの処理装置に送るかを各処理装置は意識することなく情報のやりとりが行える。したがって、汎用的なメッセージ配信管理システムを実現できる。
【0112】
また、識別データとしては、重複のない連続番号が用いられる。所在データで処理装置を管理した場合、処理装置の増減等で同じアドレスが複数の処理装置に割り当てられることもあり、適切な配信が行えない場合も生じうるが、本実施の形態では、識別データで管理することにより、通信相手を一意に識別することができ、相手の増減によらない汎用的なメッセージ配信管理システムを実現できる。
【0113】
また、配信制御手段56は、受信メッセージに含まれるメッセージパターンデータ102と、管理データとに基づき、受信メッセージの配信制御を行う。メッセージパターンデータ102という少ない情報に基づき配信制御できるため、効率的なメッセージ配信管理システムを実現できる。
【0114】
また、管理データ制御手段54は、処理装置8−1が通信路300との接続を終了した場合に、接続時に作成した装置データおよび装置データと関連づけられたメッセージデータを削除する。
【0115】
これによれば、通信相手がネットワークからいなくなった場合でも、この通信相手の情報は、メッセージ配信管理手段4に管理されている情報から削除されているため、通信元の処理装置10は、通信相手の減少を意識することなく通信が行えるメッセージ配信管理システムを実現できる。
【0116】
(通知型メッセージ)
通知型メッセージとしては、状態の変化を通知する通知メッセージと、通知を希望する通知希望メッセージとがある。目的データ140として、それぞれ通知データまたは通知希望データが指定されることにより、当該メッセージの通信目的を判断できる。
【0117】
ここで、状態の変化としては、例えば、製品をラインに投入した、Aさんの口座からBさんの口座へ振り込みがあった等が該当する。
【0118】
また、通知型では不特定の通知希望者に通知するものであり、通知者は通知メッセージがどこに配信されたか、どのように処理されたか意識しなくてよい。特に、不特定多数の相手にほぼ同時にメッセージを送信する場合に効果的である。
【0119】
図6は、通知型におけるネットワークシステムの概略を示し、図7は、通知型メッセージ処理の一例を示すフローチャートである。また、図8は、配信管理データ60の概略図を示す。
【0120】
通知型メッセージをやりとりする場合、まず、通知を希望する処理装置8(8−1、8−2)から通知希望メッセージ20(20−1、20−2)がメッセージ送受信手段40(40−1、40−2)によりメッセージ配信管理手段4に送信され、メッセージ配信管理手段4は、この通知希望メッセージ20を受信する(ステップ32)。
【0121】
メッセージ配信管理手段4は、通知を希望する処理装置8へ向け、通知希望メッセージ20のメッセージパターンデータ102と対応する通知メッセージ22を配信するため、通知希望装置リスト62を作成する。
【0122】
通知希望装置リスト62としては、図9に示すような形式を採用できる。通知希望装置リスト62の場合、目的データ140は通知希望であり、グループデータ150、カテゴリデータ160の違いに応じて分類して作成する。例えば、グループデータ150がグループAでカテゴリデータ160がカテゴリAである場合、当該メッセージを送信した装置Cの装置情報を、既に同じメッセージパターンデータ102を有するメッセージを送信した装置Aの装置情報の後ろに作成する。なお、図中の矢印はポインタであり、メッセージ情報と装置情報とが関連づけられていることを示す。
【0123】
すなわち、メッセージ配信管理手段4は、受信した通知希望メッセージ20に基づき、通知希望メッセージ20を送信した処理装置8の装置データを、通知希望メッセージ20のメッセージパターンデータ102毎に分類して通知希望装置リスト62を作成する(ステップ34)。作成した通知希望装置リスト62を配信管理データ60の一部として管理データ記憶手段52に記憶して管理する(ステップ36)。
【0124】
以上のようにして通知メッセージ配信用の情報が管理され、通知メッセージ22を受信して配信する準備が整った状態となる。
【0125】
通知メッセージ22は、処理装置10からメッセージ配信管理手段4に送信される。メッセージ配信管理手段4は、通知メッセージ22を受信した場合(ステップ38)、配信制御手段56を用い、通知メッセージ22に含まれるメッセージパターンデータ102と、管理データ記憶手段52中の通知希望装置リスト62に記憶されたメッセージパターンデータ102の一部とが対応するものか判断する(ステップ40)。
【0126】
具体的には、通知メッセージ22のグループデータ150がグループAで、カテゴリデータ160がカテゴリAである場合、図9に示すように、同じグループデータ150、カテゴリデータ160を有する通知希望メッセージ20を送信した装置Aと装置Cが対応するものとなる。
【0127】
対応するものがあれば、対応する通知希望メッセージ20を送信した通知希望処理装置へ向け通知メッセージ22を配信する(ステップ42)。なお、対応するものがない場合は何も処理を行わない。
【0128】
本実施の形態によれば、通知型メッセージをやりとりする場合、通知希望メッセージ20と通知メッセージ22とが対応するものかどうかを、メッセージパターンデータ102同士の比較により判断できるため、効率的に通知処理が行える。特に、多数の処理装置に同時に通知する必要があるような大規模ネットワークシステムに適用すれば効果的である。
【0129】
(要求応答型メッセージ)
要求応答型メッセージとしては、情報の問い合わせを行う要求メッセージ、要求メッセージに対する応答を希望する応答希望メッセージ、要求メッセージに対する応答を行う応答メッセージとがある。目的データ140として、要求、応答または応答希望のいずれかのデータが指定されることにより、当該メッセージの通信目的を判断できる。
【0130】
ここで、情報の問い合わせとは、具体的には、製品加工条件の問い合わせや、残高の問い合わせ等が該当する。
【0131】
図10は、要求応答型におけるネットワークシステムの概略を示し、図11は、要求応答型メッセージ処理の一例を示すフローチャートである。
【0132】
要求応答型メッセージをやりとりする場合、まず、応答を希望する応答希望処理装置12(12−1、12−2)から応答希望メッセージ24(24−1、24−2)がメッセージ送受信手段42(42−1、42−2)によりメッセージ配信管理手段4に送信される。
【0133】
メッセージ配信管理手段4は、この応答希望メッセージ24を受信する(ステップ52)。メッセージ配信管理手段4は、受信した応答希望メッセージ24に基づき、応答希望メッセージ24を送信した処理装置8の装置データを、応答希望メッセージ24のメッセージパターンデータ102毎に分類して配信管理するための応答希望装置リスト66を作成する(ステップ54)。
【0134】
応答希望装置リスト66としては、通知型で説明したように図9に示すような形式を採用できる。
【0135】
次に、作成した応答希望装置リスト66を、配信管理データ60の一部として管理データ記憶手段52に記憶して管理する(ステップ56)。
【0136】
この場合のように、応答希望処理装置が複数ある場合、メッセージ配信管理手段4は、最初に登録された応答希望処理装置に応答権を付与する。図9の例では最初に登録された装置A、装置B、装置C、装置Cにそれぞれの応答希望に対して応答権が付与される。図10の例では、応答希望処理装置12−1に応答権を付与するメッセージを作成して配信する(ステップ58)。
【0137】
これによれば、応答権の付与により応答する処理装置を、一つに限定することができるため、同時に複数の応答を受信しなくて済み、通信量を抑えるとともに確実な要求応答処理が行える。この際、メッセージパターン102毎に最初に応答希望装置リスト66に登録された応答希望処理装置に応答権を付与することが好ましい。これにより、大規模なネットワークへの適用も容易となる。
【0138】
なお、応答権の付与は処理の優先度に応じて変更するよう構成してもよく、全ての応答希望処理装置に対して応答権を付与してもよい。
【0139】
一方、応答権付与中のメッセージパターンデータ102と同一のメッセージパターンデータ102を有するメッセージを受信した場合、すなわち、例えば図9に示す装置Aの次に装置CからグループAおよびカテゴリAが指定された応答希望メッセージを受信した場合、応答希望装置リスト66に当該装置情報およびメッセージ情報を作成し、当該メッセージを送信した処理装置Cへ向け応答許可待ちを示すメッセージを配信する。
【0140】
もちろん、すべての応答希望処理装置である装置Aおよび装置Cに要求メッセージ28を配信する構成とすることも可能である。
【0141】
以上のようにして要求メッセージ配信用の情報が管理され、要求メッセージ28を受信して配信する準備が整った状態となる。
【0142】
要求メッセージ28は、要求処理装置14からメッセージ送受信手段44によりメッセージ配信管理手段4に送信される。メッセージ配信管理手段4は、この要求メッセージ28を受信する(ステップ60)。
【0143】
要求処理装置14からメッセージ送受信手段44により要求メッセージ28がメッセージ配信管理手段4に送信され、メッセージ配信管理手段4は、この確認メッセージ28を受信する(ステップ60)。メッセージ配信管理手段4は、受信した要求メッセージ28に基づき、要求メッセージ28を送信した処理装置14の装置データを、要求メッセージ28のメッセージパターンデータ102毎に分類して配信管理するための要求装置リスト64を作成する(ステップ62)。
【0144】
要求装置リスト64には、応答希望装置リスト62と異なり、図12に示すように、メッセージパターンデータ102だけでなく、メッセージに含まれるその他のデータ、好ましくは要求メッセージ28全体を記憶することが好ましい。要求メッセージ28全体を記憶することにより、要求メッセージ28を再送する必要が生じたときも再送することができる。また、要求メッセージ28を送信した処理装置の所在を確認する場合に用いることもできる。
【0145】
次に、作成した要求装置リスト64を配信管理データ60の一部として管理データ記憶手段52に記憶して管理する(ステップ64)。
【0146】
次に、管理データ制御手段54は、応答希望装置リスト66を用い、受信した要求メッセージ28のメッセージパターンデータ102と対応する応答希望メッセージ24のメッセージパターンデータ102とが対応するかどうか判断する(ステップ66)。この場合の判断手法は上述した通知型のものと同様である。
【0147】
対応するメッセージパターンデータ102があった場合、伝送制御手段56は、応答希望装置リスト66に基づき、対応する応答希望メッセージ送信元であって、応答権を有する応答希望処理装置12−1へ向け要求処理装置14の識別データを含ませた要求メッセージ28を配信する(ステップ68)。
【0148】
応答権付与メッセージ配信先の応答希望処理装置12−1は、メッセージ送受信手段42−1により要求メッセージ28を受信した場合、この要求メッセージ28に対する応答メッセージ26に、要求メッセージ28に含まれる識別データを含ませて配信制御手段4へ向け送信する。
【0149】
次に、配信制御手段56は、要求メッセージ28配信先の処理装置から要求メッセージ28に対する応答メッセージ26を受信し(ステップ70)、要求処理装置14へ向け応答メッセージ26を配信する(ステップ72)。
【0150】
本実施の形態によれば、要求応答型メッセージをやりとりする場合、応答希望メッセージ24と要求メッセージ28とが対応するものかどうかを、メッセージパターンデータ同士の比較により判断できるため、効率的に要求応答処理が行える。
【0151】
また、要求メッセージ送信元の識別データをメッセージに含ませることにより、応答メッセージ26をどこに配送すべきか意識しなくて済むため、汎用的なメッセージ配信管理システムを実現できる。
【0152】
すなわち、応答メッセージ26中には要求処理装置の識別データが含まれており、識別データは要求処理装置のポート番号と対応づけられていることにより、応答メッセージ26を参照することによりどこに応答メッセージ26を配信するか判断できる。
【0153】
また、応答データを、前記要求メッセージに対する回答の継続を示す応答継続データ、この回答の終了を示す応答終了データのいずれかのデータを含めて構成してもよい。
【0154】
これによれば、応答内容が多く、メッセージが長くなり、メッセージを分割せざるを得ない場合も、応答継続、応答終了というデータを用いることにより、長い応答内容を含むメッセージも配送することができる。
【0155】
図13は、この場合の具体的な処理の流れを示すフローチャートである。配信制御手段56は、応答希望処理装置12−1から応答メッセージ26を受信した場合(ステップ80)、応答メッセージ26の長さを判断し(ステップ82)、所定の長さを超えている場合は応答メッセージ26を分割する(ステップ84)。
【0156】
なお、所定の長さとしては、応答メッセージ配信先の処理装置が処理困難な長さ、伝送効率が低下するような長さ等が考えられる。
【0157】
分割した最終の応答メッセージ26でない場合(ステップ86)、この分割したメッセージに応答継続データを含ませて応答継続メッセージ26−1として作成する(ステップ88)。次に、応答メッセージ26中の識別データに基づき、要求処理装置14へ向け応答継続メッセージ26−1を配信する(ステップ90)。
【0158】
分割した最終の応答メッセージ26である場合(ステップ86)、この分割したメッセージに応答終了データを含ませて応答終了メッセージ26−2として作成する(ステップ92)。次に、応答メッセージに含まれる識別データに基づき、要求処理装置14へ向け応答終了メッセージ26−2を配信する(ステップ94)。
【0159】
なお、上記の応答メッセージ26の分割等の処理を応答希望処理装置12が行うように構成することも可能である。これによれば、分割等の複雑な処理を行わなくて済み、要求応答型では要求メッセージ28、応答メッセージ26、応答継続メッセージ26−1、応答終了メッセージ26−2という4つのメッセージを配信するだけなので、メッセージ配信制御手段4をより汎用的なものとすることができる。
【0160】
また、メッセージを分割する単位としては、データ部200中の組データ単位や、メッセージをやりとりできる最大長の単位、伝送に適した長さの単位等でも可能であるが、データ部200中の連想配列の一単位毎とすることが好ましい。
【0161】
例えば、図41に示すデータ部200の例では、作業名、作業者名および仕上数の一単位毎に分割する。ヘッダ部100に分割した一単位のデータを連結して応答継続メッセージ26−1等を作成すればよい。これによれば、各処理装置でのデータの取り扱いを容易とし、データの格納および取り出し等に関して効率を向上させることができる。
【0162】
なお、上記の実施例では、要求メッセージ28に識別データを含ませて配信する構成としているが、受信した要求メッセージ28をそのまま配信し、要求装置リスト64に記憶された識別データに基づき要求処理装置14の所在を判断するよう構成してもよい。
【0163】
(確認許可型メッセージ)
確認許可型メッセージとしては、イベントの実行に対する許可を求める確認メッセージ、確認メッセージに対する許可を希望する許可希望メッセージ、確認メッセージに対する許可を行う許可メッセージとがある。目的データ140として、確認、許可または許可希望のいずれかのデータが指定されることにより、当該メッセージの通信目的を判断できる。
【0164】
ここで、イベントの実行としては、具体的には、製品のラインへの投入、残高照会のためにDBを参照する等がある。すなわち、製品をラインに投入してよいか確認し、投入してよい場合は許可がされる。
【0165】
図14は、確認許可型におけるネットワークシステムの概略を示し、図15は、確認許可型メッセージ処理の一例を示すフローチャートである。
【0166】
確認許可型メッセージをやりとりする場合、まず、許可を行うことを希望する許可希望処理装置16(16−1、16−2)から許可希望メッセージ30(30−1、30−2)がメッセージ送受信手段46(46−1、46−2)によりメッセージ配信管理手段4に送信される。
【0167】
メッセージ配信管理手段4は、この許可希望メッセージ30を受信する(ステップ102)。メッセージ配信管理手段4は、受信した許可希望メッセージ30に基づき、許可希望メッセージ30を送信した処理装置16の装置データを、許可希望メッセージ30のメッセージパターンデータ102毎に分類して許可希望装置リスト70を作成する(ステップ104)。
【0168】
許可希望装置リスト70は、上述した通知希望装置リスト62と同様の形式である。次に、メッセージ配信管理手段4は、作成した許可希望装置リスト70を配信管理データ60の一部として管理データ記憶手段52に記憶して管理する(ステップ106)。
【0169】
以上のようにして確認メッセージ34を配信管理するための準備が整えられる。
【0170】
確認メッセージ34は、確認処理装置18からメッセージ送受信手段48によりメッセージ配信管理手段4に送信される。メッセージ配信管理手段4は、この確認メッセージ34を受信する(ステップ110)。
【0171】
メッセージ配信管理手段4は、受信した確認メッセージ34に基づき、確認メッセージ34を送信した処理装置18の装置データを、確認メッセージ34のメッセージパターンデータ102毎に分類して配信管理するための確認装置リスト68を作成する(ステップ112)。
【0172】
確認装置リスト68の形式は上述した要求装置リスト64と同様のものである。確認装置リスト68は、確認メッセージ34を再送する場合や、確認メッセージ34の送信元を管理するために用いられる。
【0173】
次に、メッセージ配信管理手段4は、作成した確認装置リスト68を配信管理データ60として管理データ記憶手段52に記憶して管理する(ステップ114)。
【0174】
次に、管理データ制御手段54は、許可希望装置リスト70を用い、記憶した確認メッセージ34のメッセージパターンデータ102と許可希望メッセージ30のメッセージパターンデータ102とが対応するかどうか判断する(ステップ116)。判断手法は上述した通知型のものと同様である。
【0175】
対応するメッセージパターンデータ102があった場合、配信制御手段56は、対応する許可希望メッセージ30を送信した全ての処理装置16−1、16−2へ向け確認処理装置18の識別データを含ませた確認メッセージ34を配信する(ステップ118)。
【0176】
複数の許可希望処理装置16は、メッセージ送受信手段46により確認メッセージ34を受信した場合、この確認メッセージ34に含まれる識別データを送信する許可メッセージ32(32−1、32−2)に含ませ、この許可メッセージ32をメッセージ配信管理手段4へ向け送信する。
【0177】
配信制御手段56は、確認メッセージ配信先の複数の許可希望処理装置16から確認メッセージ34に対する許可メッセージ32を受信した場合(ステップ120)、この許可メッセージ32中の識別データに基づき、確認処理装置18へ向け許可メッセージ32を配信する(ステップ122)。
【0178】
受信した許可メッセージ32が最終のものである場合(ステップ124)、この許可メッセージ中の識別データに基づき、確認処理装置18へ向け、許可メッセージ32を配信するとともに、目的データ140に許可終了を含ませた許可終了メッセージ36を配信する(ステップ126)。
【0179】
これによれば、確認許可型メッセージをやりとりする場合、許可希望メッセージ30と確認メッセージ34とが対応するものかどうかを、メッセージパターンデータ同士の比較により判断できるため、効率的に確認許可処理を行える。
【0180】
また、確認メッセージ送信元の識別データをメッセージに含ませることにより、許可メッセージ32をどこに配信すべきか意識しなくて済むため、汎用的なメッセージ配信管理システムを実現できる。
【0181】
さらに、許可終了メッセージ36を用いることにより、複数の許可希望処理装置から許可をもらう必要がある場合も、確認処理装置は、有効な全許可処理装置から許可が返送されたことを判断できる。
【0182】
なお、上記の実施例では、確認メッセージ34に識別データを含ませて配信する構成としているが、受信した確認メッセージ34をそのまま配信し、確認装置リスト68に記憶された識別データに基づき確認処理装置18の所在を判断するよう構成してもよい。
【0183】
(モニタリング)
また、自処理装置と他の処理装置のメッセージ配信状態を確認できれば汎用性が増し、必要な処理を行ってくれる通信相手がいるかどうか確認した上で、処理を依頼すると効率的である。
【0184】
メッセージ配信状態の確認等のモニタリング等を行えるようにするには、状態管理データを設ければよい。具体的な実現手段は以下のようになる。
【0185】
管理データとして、各処理装置から送られたメッセージの配信状態を、各処理装置毎に管理する状態管理データを含んで構成する。図16は、状態管理データ80を含んで構成したメッセージ配信制御手段4の機能ブロック図の一例を示す。
【0186】
図16に示すように、メッセージを受信した処理装置分の状態管理データ80−1〜80−3が管理データ記憶手段52に記憶され、各状態管理データ80−1〜80−3は、配信管理データ60中の状態管理データ管理リスト78から辿れるようにポイントづけされている。
【0187】
図17は、メッセージ配信管理手段4を用いたモニタリング処理の流れを示すフローチャートである。メッセージ配信管理手段4は、処理装置からメッセージを受信した場合(ステップ152)、管理データ制御手段54を用いて、受信メッセージを送信した処理装置用の状態管理データ80を作成して管理データ記憶手段52に記憶する(ステップ154)。
【0188】
処理装置から該処理装置または他の処理装置のメッセージ配信状態の問い合わせがあった場合(ステップ156)、管理データ制御手段54を用いて、配信管理データ60中の状態管理データ管理リスト78から問い合わせがあった処理装置用の状態管理データ80のアドレスを取得し、当該状態管理データ80に記憶されているメッセージ配信情報を取得する(ステップ158)。
【0189】
次に、配信制御手段56を用いて、問い合わせ元の処理装置へ向け、取得した状態管理データ80の情報を含ませたメッセージを配信する(ステップ160)。
【0190】
ここで、状態管理データ80の情報を含ませたメッセージとは、例えば、他の処理装置のメッセージ配信状態の問い合わせの場合、他の処理装置が要求メッセージ28を送信してその応答を待っているといった状態を示すメッセージのことである。
【0191】
これによれば、各処理装置が、自己のメッセージ配信状態や、他の処理装置のメッセージ配信状態を確認することができる。これにより、メッセージ配信状態のモニタリングを実現できる。
【0192】
このモニタリングを通知型、要求応答型、確認許可型メッセージに対して実現する場合は以下のようになる。なお、処理の流れは図17に示すものとほぼ同様であるため、図面については省略する。
【0193】
通知型の場合は以下のようになる。図18は、状態管理データ80の具体例を示す。通知型における状態管理データ80には、通知希望メッセージ20の配信状態がメッセージパターンデータ102毎に管理されるための通知希望パターンリスト82が含まれている。
【0194】
通知希望パターンリスト82は、図19に示すように、メッセージパターンデータ102毎にグループデータ150、カテゴリデータ160を含むメッセージ情報を含んで構成されており、どのような通知希望メッセージ20を送信しているか確認するためのものである。
【0195】
通知型では、メッセージ配信管理手段4を用いて以下の処理を行う。通知希望メッセージ20を受信した場合、管理データ制御手段54を用いて、通知希望パターンリスト82を作成して管理データ記憶手段52に記憶する。
【0196】
次に、処理装置から該処理装置または他の処理装置のメッセージ配信状態の問い合わせがあった場合、管理データ制御手段54を用いて、問い合わせがあった処理装置用の通知希望パターンリスト82を取得する。
【0197】
次に、配信制御手段56を用いて、問い合わせ元の処理装置へ向け、取得した通知希望パターンデータの情報を含ませたメッセージを配信する。
【0198】
これによれば、各処理装置が、自己の通知型メッセージ配信状態や、他の処理装置の通知型メッセージ配信状態を確認することができる。これにより、通知型メッセージ配信状態のモニタリングを実現できる。
【0199】
要求応答型の場合は以下のようになる。要求応答型における状態管理データ80には、要求メッセージ28の配信状態がメッセージパターンデータ102毎に管理されるための要求メッセージリスト84と、応答希望メッセージ24の配信状態がメッセージパターンデータ102毎に管理される応答希望パターンリスト86とが含まれている。
【0200】
要求メッセージリスト84は、図20に示すように、メッセージパターンデータ102毎に要求メッセージ全体を含んで構成されており、どのような要求メッセージ28を送信しているか確認するためのものである。
【0201】
応答希望パターンリスト86は、図19に示すように、メッセージパターンデータ102毎にグループデータ150、カテゴリデータ160を含むメッセージ情報を含んで構成されており、どのような応答希望メッセージ24を送信しているか確認するためのものである。
【0202】
メッセージ配信管理手段4は以下の処理を行う。応答希望メッセージ24を受信した場合、管理データ制御手段54を用いて、応答希望パターンリスト86を作成して管理データ記憶手段52に記憶する。
【0203】
要求メッセージ28を受信した場合、要求メッセージリスト84を作成して管理データ記憶手段52に記憶する。なお、ここで要求メッセージリスト84には、図20に示すように、要求メッセージ28そのものを記憶することが好ましい。これによれば、応答が終わらないうちに応答権を他の処理装置に渡す必要が生じた場合、要求メッセージ28を当該他の処理装置に効率的に配信することができる。
【0204】
処理装置から該処理装置または他の処理装置の応答希望メッセージ配信状態の問い合わせがあった場合、管理データ制御手段54を用いて、問い合わせがあった処理装置用の応答希望パターンリスト86を取得する。次に、配信制御手段56を用いて、この問い合わせメッセージのメッセージパターンデータ102と、応答希望パターンリスト86とに基づき、問い合わせ元の処理装置へ向け、取得した応答希望パターンリスト86の情報を含ませたメッセージを配信する。
【0205】
処理装置から該処理装置または他の処理装置の要求メッセージ配信状態の問い合わせがあった場合、管理データ制御手段54を用いて、問い合わせがあった処理装置用の前記要求状態データを取得する。次に、配信制御手段56を用いて、この問い合わせメッセージのメッセージパターンデータ102と、要求メッセージリスト84とに基づき、問い合わせ元の処理装置へ向け、取得した要求メッセージリスト84の情報を含ませたメッセージを配信する。
【0206】
これによれば、各処理装置が、自己の要求応答型メッセージ配信状態や、他の処理装置の要求応答型メッセージ配信状態を確認することができる。これにより、要求応答型メッセージ配信状態のモニタリングを実現できる。
【0207】
確認許可型の場合は以下のようになる。確認許可型における状態管理データ80は、確認メッセージ34の配信状態がメッセージパターンデータ102毎に管理される確認メッセージリスト88と、許可希望メッセージ30の配信状態がメッセージパターンデータ102毎に管理される許可希望パターンリスト90とを含んで構成されている。
【0208】
確認メッセージリスト88は、図20に示すように、メッセージパターンデータ102毎に確認メッセージ34全体を含んで構成されており、どのような確認メッセージ34を送信しているか確認するためのものである。
【0209】
許可希望パターンリスト90は、図19に示すように、メッセージパターンデータ102毎にグループデータ150、カテゴリデータ160を含むメッセージ情報を含んで構成されており、どのような許可希望メッセージ30を送信しているか確認するためのものである。
【0210】
メッセージ配信管理手段4は以下の処理を行う。許可希望メッセージ30を受信した場合、管理データ制御手段54を用いて、許可希望パターンリスト90を作成して管理データ記憶手段52に記憶する。
【0211】
確認メッセージ34を受信した場合、確認メッセージリスト88を作成して管理データ記憶手段52に記憶する。
【0212】
処理装置から該処理装置または他の処理装置の許可希望メッセージ配信管理状態の問い合わせがあった場合、管理データ制御手段54を用いて、問い合わせがあった処理装置用の許可希望パターンリスト90を取得する。次に、配信制御手段56を用いて、この問い合わせメッセージのメッセージパターンデータ102と、許可希望パターンリスト90とに基づき、問い合わせ元の処理装置へ向け、取得した許可希望パターンリスト90の情報を含ませたメッセージを配信する。
【0213】
また、処理装置から該処理装置または他の処理装置の確認メッセージ配信管理状態の問い合わせがあった場合、管理データ制御手段54を用いて、問い合わせがあった処理装置用の確認メッセージリスト88を取得する。次に、配信制御手段56を用いて、この問い合わせメッセージのメッセージパターンデータ102と、確認メッセージリスト88とに基づき、問い合わせ元の処理装置へ向け、取得した確認メッセージリスト88の情報を含ませたメッセージを配信する。
【0214】
これによれば、各処理装置が、自己の確認許可型メッセージ配信状態や、他の処理装置の確認許可型メッセージ配信状態を確認することができる。これにより、確認許可型メッセージ配信状態のモニタリングを実現できる。
【0215】
以上説明してきたように、通信路に接続している全処理装置に対する全メッセージの配信状態をモニタリングすることができ、汎用的かつ効率的なメッセージ配信制御システムを実現できる。
【0216】
次に、効率性を高めるため、必要な処理を行ってくれる通信相手がいるかどうか確認するためには、メッセージ配信管理手段4が各処理装置の通信路300との接続状況を把握していれば、各処理装置は他の処理装置の存在を意識することなく、汎用的かつ効率的な通信処理が行える。この機能を実現するためには以下のような構成および処理とすればよい。
【0217】
通知型、要求応答型、確認許可型メッセージのうち少なくとも1つのメッセージについて、目的データ140として、所定の処理装置が通信路300との接続を開始した場合にその通知が行われるための開始通知希望データを含んで構成する。また、図8に示すように、管理データのうち少なくとも1つの配信管理データ60を、開始通知希望データが指定された開始通知希望メッセージが配信管理される開始通知希望装置リスト72を含んで構成する。メッセージ配信管理手段4での処理は以下のようになる。
【0218】
図21は、メッセージ配信管理手段4での開始通知希望メッセージ配信管理処理の流れを示すフローチャートである。
【0219】
メッセージ配信管理手段4は、開始通知希望メッセージを受信した場合(ステップ172)、管理データ制御手段54を用いて、図8に示すように、開始通知希望装置リスト72を作成して配信管理データ60の一部として管理データ記憶手段52に記憶する(ステップ174)。
【0220】
開始通知希望装置リスト72とは、メッセージ配信管理手段4が開始通知希望メッセージに含まれるメッセージパターンデータ102と対応する通知メッセージを受信した場合に、通知が行われるためのメッセージであり、開始通知希望メッセージに含まれるメッセージパターンデータ102毎に分類して管理され、図9に示すようなデータ構造である。
【0221】
メッセージ配信管理手段4は、カテゴリデータ160に通信路300との接続の開始を通知する接続開始データが指定されたメッセージを、所定の処理装置から受信した場合(ステップ176)、配信制御手段56を用いて、この受信メッセージに含まれるメッセージパターンデータ102に対応するメッセージパターンデータ102を有するメッセージを送信した処理装置の装置情報を、開始通知希望装置リスト72から上述したような方法で取得する(ステップ178)。この取得した装置情報に基づき、開始通知希望メッセージを送信した処理装置へ向け、開始データが指定されたメッセージを配信する(ステップ180)。
【0222】
これによれば、通信元の処理装置が、メッセージ送信対象となるべき処理装置が存在するかどうか確認した上でメッセージを送信することが可能となる。
【0223】
例えば、本実施の形態を、通知型に適用すれば通知希望を行っている処理装置の存在を確認でき、確認許可型に適用すれば許可希望を行っている処理装置の存在を確認できた上で通信できるため、効率的である。
【0224】
特に、本実施の形態を、要求応答型メッセージ配信制御に用いれば効果的である。これによれば、要求メッセージ送信元の処理装置が、応答を行ってくれる処理装置が存在するかどうか確認した上で要求メッセージ28の送信を開始することが可能となる。したがって、応答が必須である処理を行う場合等において、確実に応答を受けることができるようになる。また、同様に要求に対応する応答を行ってくれる処理装置の出現を待つという考え方もある。
【0225】
この場合のメッセージ配信管理手段4の構成および処理は以下のようになる。
【0226】
図8に示すように、配信管理データ60の一部として、要求に対する応答を行う処理装置が通信路300との接続を開始したかどうか判断するための応答待ち要求メッセージが配信管理される応答装置待ちリスト76を含んで構成する。
【0227】
応答装置待ちリスト76とは、メッセージ配信管理手段4が応答待ち要求メッセージに含まれるメッセージパターンデータ102と対応するメッセージを受信した場合に、応答が行われるためのメッセージであり、応答待ち要求メッセージに含まれるメッセージパターンデータ102毎に分類して管理され、図9に示すようなデータ構造である。
【0228】
メッセージ配信制御手段4は、要求処理装置14から送信された応答待ち要求メッセージを受信した場合、管理データ制御手段54を用いて、応答待ち要求メッセージのメッセージパターンデータ102毎に分類して応答装置待ちリスト76を作成して管理データ記憶手段52に記憶する。
【0229】
図22は、この場合のメッセージ配信処理の流れを示すフローチャートである。メッセージ配信制御手段4は、応答希望処理装置から応答希望メッセージ24を受信した場合(ステップ392)、当該メッセージ中のメッセージパターンデータ102が応答希望装置リスト66にないものであって(ステップ394)、応答装置待ちリスト76に登録されたメッセージパターンデータ102と対応するものであるかどうか確認する(ステップ396)。
【0230】
対応するものである場合、配信制御手段56を用いて、要求装置リスト64に登録されている応答待ち要求メッセージを送信した要求処理装置14へ向け応答希望処理装置の登場を示すメッセージを配信し(ステップ398)、当該要求を応答装置待ちリスト76から削除する(ステップ400)。
【0231】
これによっても、応答が必須である処理を行う場合等において、確実に応答を受けることができるようになる。
【0232】
また、逆に所定の処理装置が通信路300との接続を終了したことも確認できれば、さらに汎用性および効率性が高まる。
【0233】
この機能を実現するため、メッセージ配信管理制御手段4の構成および処理は以下のようになる。
【0234】
通知型、要求応答型、確認許可型メッセージのうち少なくとも1つのメッセージを、目的データ140として、所定の処理装置が通信路300との接続を終了した場合にその通知が行われるための終了通知希望データを含んで構成し、管理データのうち少なくとも1つの管理データを、終了通知希望データが指定された終了通知希望メッセージが配信管理される終了通知希望装置リスト74を含んで構成する。
【0235】
終了通知希望装置リスト74とは、メッセージ配信管理手段4が終了通知希望メッセージに含まれるメッセージパターンデータ102と対応する通知メッセージ22を受信した場合に、通知が行われるためのメッセージであり、終了通知希望メッセージに含まれるメッセージパターンデータ102毎に分類して管理され、図9に示すようなデータ構造である。
【0236】
メッセージ配信管理手段4は、以下の処理を行う。終了通知希望メッセージを受信した場合、管理データ制御手段54を用いて、終了通知希望装置リスト74を作成して管理データ記憶手段52に記憶する。
【0237】
カテゴリデータ160に通信路300との接続の終了を通知する接続終了データが指定されたメッセージを、前記所定の処理装置から受信した場合、配信制御手段56を用いて、この受信メッセージに含まれるメッセージパターンデータ102と、終了通知希望装置リスト74とに基づき、終了通知希望メッセージを送信した処理装置へ向け、接続終了データが指定されたメッセージを配信する。
【0238】
これによれば、通信元の処理装置が、メッセージ送信対象となるべき処理装置が存在するかどうか確認した上でメッセージを送信することが可能となる。なお、所定の処理装置が通信路との接続を終了したかどうかの判断は、メッセージ配信管理手段4が、所定の処理装置の通信ポートを常に監視しておき、当該通信ポートの接続が切れたことで判断してもよい。この場合、上述した装置データの所在データとして通信ポートを用いればよい。
【0239】
また、図18に示すように、モニタリングを行えるよう、終了通知希望リスト92を設けて終了通知希望メッセージをメッセージパターンデータ102毎に管理することにより、終了通知希望メッセージの配信状態をモニタリングすることもできる。
【0240】
また、本実施の形態を、通知型に適用すれば通知希望を行っている処理装置の存在を確認でき、確認許可型に適用すれば許可希望を行っている処理装置の存在を確認できた上で通信できるため、効率的である。
【0241】
特に、本実施の形態を、要求応答型メッセージ配信制御に用いれば効果的である。これによれば、要求メッセージ送信元の処理装置が、応答を行ってくれる処理装置が存在するかどうか確認した上で要求メッセージ28の送信を開始することが可能となる。
【0242】
また、要求メッセージ28には要求メッセージ送信元の識別データが含まれている。このため、応答を行う処理装置が、要求メッセージ受信後、当該要求メッセージ送信元の識別データを含ませた終了通知希望メッセージをメッセージ配信管理手段4へ向け送信しておくことにより、応答メッセージ26を送信する前に終了通知希望元である要求メッセージ送信元の処理装置が接続を終了した場合でもメッセージ配信管理手段4から通知を受けることにより、当該処理装置が終了したことを判断できる。終了したと判断した処理装置は、現在実行中の処理を中断または中止することができる。
【0243】
したがって、応答が必須である処理を行う場合等において、確実に応答を受けることができるようになる。また、同様に要求に対応する応答を行ってくれる処理装置を予め登録しておくという考え方もある。この場合のメッセージ配信管理手段の構成および処理は上述した応答装置待ちリスト76とほぼ同様の方法で実現できる。
【0244】
これによれば、要求処理装置14が、メッセージ配信管理手段4から配信された終了通知を示すメッセージを受信することにより、当該要求を行うことができなくなったことを判断できる。
【0245】
(タイムアウト処理)
また、メッセージを受信して配信する必要がある場合、タイムアウト処理ができれば待ち時間が少なくなり、効率性が向上する。
【0246】
図23は、メッセージ配信管理手段4に時間測定手段58を設けた一例を示す機能ブロック図である。図23に示すように、タイムアウト処理機能を実現するため、メッセージ配信管理手段4に時間測定手段58を設け、処理装置からメッセージ受信後、時間測定手段58により測定した測定時間に基づき、当該メッセージに対して行われる処理をタイムアウト処理する。
【0247】
ここで、測定時間とは、例えば、メッセージ受信時や、当該メッセージに対してメッセージを配信した時点を測定開始時点とし、当該メッセージに対してメッセージを配信した処理装置から回答メッセージを受信した時点や、当該メッセージに対応したメッセージを配信する時点を測定終了時点として測定した時間のことである。
【0248】
また、当該メッセージに対して行う処理とは、例えば、上記当該メッセージに対してメッセージを配信した処理装置から回答メッセージを受信する処理や、上記当該メッセージに対応したメッセージを配信する処理のことである。また、タイムアウト処理とは、測定時間が所定の時間を超えていることを判断し、上記当該メッセージに対して行われる処理をそれ以上待つことを止めることである。
【0249】
これによれば、待ち時間が少なくなり、メッセージ配信処理を短時間に行うことができる。また、メッセージを送信したが、それに対する回答メッセージがいつまで経っても戻ってこないといった事態を回避することができ、効率的なメッセージ配信管理システムを実現できる。
【0250】
特に、タイムアウト処理を要求応答型で用いる場合、要求メッセージ配信時点から配信先の処理装置から前記応答メッセージのいずれかの受信時点までの時間を時間測定手段58により測定し、この測定時間が所定時間を超えている場合、この測定時間に基づき、応答メッセージ26に対して行われる処理をタイムアウト処理する。
【0251】
これによれば、要求メッセージ28を送信したが、それに対する応答メッセージ26がいつまで経っても戻ってこない場合、応答権を別の処理装置に付与し、再度その処理装置に要求メッセージ28を配信して応答を得ることができ、効率的なメッセージ配信管理システムを実現できる。
【0252】
また、タイムアウト処理を確認許可型で用いる場合、確認メッセージ配信時点から配信先の処理装置から許可メッセージ32のいずれかの受信時点までの時間を時間測定手段58により測定し、この測定時間が所定時間を超えている場合、この測定時間に基づき、許可メッセージ32に対して行われる処理をタイムアウト処理する。
【0253】
これによれば、待ち時間が少なくなり、メッセージ配信処理を短時間に行うことができる。すなわち、確認メッセージ34を送信したが、それに対する許可メッセージ32がいつまで経っても戻ってこない場合、許可と判断して許可終了メッセージ36を配信することにより、効率的なメッセージ配信管理システムを実現できる。
【0254】
なお、上記のタイムアウト処理を、各処理装置が行うよう構成してもよい。各処理装置に時間測定手段を設けることにより、要求、応答、確認、許可等のメッセージをタイムアウト処理することにより、効率的なメッセージ配信管理システムを実現できる。
【0255】
(3つのメッセージを用いた具体例)
以上説明してきた通知型、要求応答型、確認許可型という3つのメッセージを実際のネットワークシステムに適用した具体例について説明する。
【0256】
(生産現場への適用)
図1は、多種多様な製品を製造している生産現場のネットワーク構成の一例を示す。図1に示す生産現場のネットワーク構成は、作業者端末324と、メッセージ配信管理手段であるメッセージサーバ310と、ロット管理DB350と接続されたロット管理サーバ330〜334と、その他複数のサーバ320、322、326、328と、これらの各装置が接続される通信路であるイーサネットケーブル300とを含んで構成されている。
【0257】
また、図24〜図34は、製品製造の際のメッセージ配信管理の処理の流れを示すフローチャートである。ここで、製品の管理単位をロットといい、ロットには個々を識別するためのロット番号が付けられている。あるロットを作業工程に投入する際の一連の流れを以下に示す。
【0258】
図24は、メッセージ配信管理のメイン処理を示すフローチャートである。ロットを受け取った作業者は、製品に付いているロット番号を端末324から入力する。このイベントにより、そのロットを当該作業工程に投入してよいか確認メッセージ34がメッセージサーバ310に送信される。
【0259】
メッセージサーバ310は、図24に示すように、受信データはあるか常に監視している(ステップ202)。確認メッセージ34を受信した場合、受信データがある場合となり、応答メッセージ26かどうか確認し(ステップ204)、応答メッセージ26ではないため、許可メッセージ32かどうか確認する(ステップ206)。許可メッセージ32でもないため、図25に示すメッセージ処理を行う(ステップ212)。
【0260】
図25はメッセージ処理の流れを示すフローチャートである。ここで、通常メッセージとは、通知、要求、応答(応答継続、応答終了含む)、確認、許可のいずれかを示すメッセージである。また、管理メッセージとは、通知希望、応答希望、許可希望のいずれかの登録または削除を示すメッセージである。特殊メッセージについては後述する。
【0261】
メッセージ処理では、まず、通常メッセージかどうか確認する(ステップ220)。確認メッセージ34は通常メッセージであるため、図22に示す通常メッセージ処理を行う(ステップ226)。
【0262】
図26は通常メッセージ処理の流れを示すフローチャートである。通常メッセージ処理では、通知か?(ステップ240)、要求か?(ステップ242)、応答または応答継続か?(ステップ244)、確認か?(ステップ246)の順にメッセージの種別が判断される。確認メッセージ34であるため、確認元を識別データとして確認メッセージ中のヘッダ部100に書き込む(ステップ264)。書き込み後、図19に示す確認処理を行う(ステップ266)。
【0263】
図27は確認メッセージ処理の流れを示すフローチャートである。確認メッセージ処理では、確認メッセージ34のメッセージパターンデータ102と対応するメッセージパターンデータ102を有する許可希望メッセージ30を登録した許可希望処理装置16のデータを取得する(ステップ300)。
【0264】
なお、許可希望処理装置16のデータは、許可希望装置リスト70に登録されているものである。メッセージサーバ310は、図1で一点鎖線で示す許可希望グループ420に該当するサーバ330〜334から許可希望メッセージ30を受信し、その情報をサーバ310のメモリに記憶して管理している。
【0265】
ここで、許可希望メッセージ30受信時のメッセージ配信管理処理の流れについて説明する。許可希望メッセージ30は、許可希望の登録として扱い、管理メッセージの一種である。したがって、図25に示す管理メッセージに該当するかどうか確認し(ステップ222)、該当するため管理メッセージ処理(ステップ228)を行う。
【0266】
図28は管理メッセージ処理(ステップ228)の流れを示すフローチャートである。管理メッセージ処理では、通知希望登録か?(ステップ340)、通知希望削除か?(ステップ342)、応答希望登録か?(ステップ344)、応答希望削除か?(ステップ346)、許可希望登録か?(ステップ348)の順に判断を行い、許可希望登録に該当するため、許可希望パターン登録処理(ステップ358)を行う。
【0267】
図29は、許可希望パターン登録処理(ステップ358)の流れを示すフローチャートである。許可希望パターン登録処理では、受信した許可希望メッセージ30のメッセージパターンデータ102が、配信管理中の許可希望装置リスト70に存在するかどうか確認し(ステップ380)、存在しない場合、受信したメッセージパターンデータ102を、許可希望装置リスト70に追加する(ステップ381)とともに、許可希望パターンリスト90にも追加する(ステップ382)。
【0268】
なお、図28に示す許可希望パターン削除処理(ステップ360)では、許可希望パターン登録処理と逆に許可希望装置リスト70および許可希望パターンリスト90から当該許可希望メッセージ30のメッセージパターンデータ102を削除する。
【0269】
また、許可希望パターン削除メッセージは、目的データ150に許可希望削除と指定されていることで判断できる。
【0270】
許可希望メッセージ受信時のメッセージ配信管理の流れは以上の通りであり、再び図27に示す許可希望処理装置16のデータ取得(ステップ300)以降の処理について説明する。
【0271】
図27に示すように、このようにして取得した許可装置のメッセージパターンデータ102と受信した確認メッセージ34のメッセージパターンデータ102とが対応するものであるかどうか判断し(ステップ302)、対応する許可希望処理装置があると判断した場合、全許可希望装置である許可希望サーバ330〜334へ向け、確認メッセージ34を配信する(ステップ306)。そして、確認装置である端末324と確認メッセージ34を配信した許可希望装置であるサーバ330〜334の装置情報を確認装置リスト68に追加する(ステップ308)。
【0272】
確認メッセージ34を配信された許可希望グループ420であるロット管理サーバ330〜334は、プログラムにより、そのロットを投入してよいかロット管理DB350を検索し、投入できると判断した場合はメッセージサーバ310へ向け許可を示す許可メッセージ32を送信する。
【0273】
メッセージサーバ310は、図26に示すように、許可メッセージ32を受信した場合は許可処理(ステップ270)を行う。
【0274】
図30は、許可処理(ステップ270)の流れを示すフローチャートである。メッセージサーバ310は、許可メッセージ受信毎に、受信した許可メッセージ32を確認メッセージ送信元の端末324へ向け配信する(ステップ320)。
【0275】
次に、確認装置リスト68から許可メッセージ送信元の処理装置の装置情報を削除する(ステップ322)。この段階で、確認装置リスト68の装置情報により、受信した許可メッセージ32が最終のものかどうか判断できる(ステップ324)。
【0276】
最終の許可メッセージ32である場合、許可終了メッセージ36を端末324へ向け配信する(ステップ326)。
【0277】
なお、こういった生産現場では、製品の品質管理も重要である。通常は一つでも許可メッセージ32が不許可なら不許可とみなすが、確認処理装置18である端末324が所定の割合の不許可を示す許可メッセージ32を受信した場合、不許可と判断するよう構成してもよい。これにより、効率的に製品の品質管理が行える。
【0278】
端末324では、許可終了メッセージ36を受信することにより、ロットを投入してよいかどうかを判断できる。許可を示すものであれば、そのロットを投入する。
【0279】
ロットを投入すると、ロットの投入という状態の変化があったことを示す通知メッセージ22がメッセージサーバ310に送信され、図1の点線部で示す通知希望グループ400であるサーバ320、322へ向け配信される。この際、端末324ではどのような相手に通知するかは意識する必要がない。
【0280】
すなわち、通知型には限られないが、動的にサーバが増減する場合でも汎用的に対応できる。
【0281】
例えば、ロット投入確認に対するチェックを工程管理サーバのみで許可を行っている状況で、在庫も同時にチェックできるよう在庫管理サーバでも許可を行うように許可サーバを増加させる場合でも、確認を行う者は許可サーバの増加を意識せずに確認を行うことができる。
【0282】
メッセージサーバ310は、図26に示すように、通知メッセージ22を受信した場合、通知元を識別情報に書き込み(ステップ258)、後処理(ステップ268)を行う。
【0283】
図31は、後処理(ステップ268)の流れを示すフローチャートである。メッセージサーバ310は、通知メッセージ22を受信した場合、配信管理している全処理装置に対して以下の確認を行う(ステップ280)。
【0284】
応答処理装置12に該当するか?(ステップ282)、通知希望処理装置18に該当するか?(ステップ284)を確認し、確認している処理装置が通知希望処理装置18である場合、通知処理(ステップ288)を行う。
【0285】
なお、通知希望処理装置18かどうかの確認は、通知希望装置リスト62に登録されているかどうかで確認する。メッセージサーバ310は、図1で点線で示す通知希望グループ400に該当するサーバ320、322から通知希望メッセージ20を受信し、その情報をメッセージサーバ310のメモリに記憶して管理している。
【0286】
ここで、通知希望メッセージ受信時のメッセージ配信管理処理の流れについて説明する。通知希望メッセージ20は、通知希望の登録として扱い、管理メッセージの一種である。したがって、図25に示す管理メッセージに該当するかどうか確認し(ステップ222)、該当するため管理メッセージ処理(ステップ228)を行う。
【0287】
通知希望メッセージの登録および削除は、上述した図29に示す許可希望パターン登録処理(ステップ358)およびその削除とほぼ同様であり、許可希望装置リスト70、許可希望パターンリスト90が通知希望装置リスト62、通知希望パターンリスト82に代わるだけである。
【0288】
なお、通知希望パターン削除メッセージは、目的データ150に通知希望削除と指定されていることで判断できる。
【0289】
このようにしてメッセージサーバ310に管理されている通知希望処理装置18を判断できるようにし、図31に示すように、通知希望処理装置18に該当する場合(ステップ284)、通知処理(ステップ288)を行う。通知処理(ステップ288)とは、具体的には、受信した通知メッセージ22に対応する通知希望メッセージ20を送信したサーバ320、322へ向け通知メッセージ22を配信することである。
【0290】
通知メッセージ22を配信されたサーバ320、322では、当該通知メッセージ中の情報に基づき、ロット管理情報を更新する。
【0291】
現在の技術進歩が著しい状況では製品仕様の変更も頻繁に行われる。このような場合、製品加工プログラムのバージョンアップを行う必要があるが、一部のサーバだけバージョンアップを行うと新旧両バージョンが併存し、製品加工が適切に行えない場合もある。また、関連する全てのサーバを止めてバージョンアップしたのでは、その間は生産ラインが止まり、効率的ではない。
【0292】
そこで、このような場合は要求応答型メッセージを用いれば効率的に作業が行える。端末324からは製品加工条件の取得を要求する要求メッセージ28をメッセージサーバ310へ向け送信する。メッセージサーバ310では、図1に示す破線で囲まれた応答希望グループ410のうち、応答権が付与された応答希望サーバ334へ向け要求メッセージ28を配信する。
【0293】
メッセージサーバ310は、応答希望サーバ334から応答メッセージ26を受信後、応答メッセージ26を端末324へ向け配信する。
【0294】
要求応答型メッセージの具体的な配信管理は以下のようになる。図26に示すように、メッセージサーバ310は、要求メッセージ28を受信したことを判断すると(ステップ242)、要求メッセージ送信元の識別情報を要求メッセージ28に書き込むとともに、応答者を取得する(ステップ260)。
【0295】
ここで、応答者を取得する(ステップ260)処理とは、具体的には応答希望装置リスト66を検索し、受信した要求メッセージ28のメッセージパターンデータ102に対応するメッセージパターンデータ102を有する応答希望メッセージ24を送信した応答権付与済みのサーバ334の装置情報を取得することである。
【0296】
次に、上述した後処理(ステップ268)を行う。図31に示すように、応答権付与済みの応答装置であるかどうかは、応答者取得処理(ステップ260)で取得した情報により判断できる。応答装置であると判断した場合、要求処理(ステップ286)を行う。
【0297】
ここで、応答希望メッセージ24の配信管理について説明する。応答希望メッセージ24は、応答希望登録であって管理メッセージに該当する。図28に示すように、メッセージサーバ310は、応答希望登録と判断した場合(ステップ344)、応答希望パターン登録処理(ステップ354)を行う。
【0298】
図32は応答希望パターン登録処理(ステップ354)の流れを示すフローチャートである。メッセージサーバ310は、応答希望装置リスト66および応答希望パターンリスト86に応答希望メッセージ24のメッセージパターンデータ102を追加する(ステップ390)。
【0299】
次に、当該応答希望メッセージ24のメッセージパターンデータ102が、応答希望装置リスト66に未登録のものである場合(ステップ392)、応答許可を示す応答権付与メッセージをサーバ334へ向け配信する(ステップ394)。
【0300】
次に、当該応答希望メッセージ24のメッセージパターンデータ102が、上述した応答装置待ちリスト76に登録されたメッセージパターンデータ102と対応するものであるかどうか確認する(ステップ396)。
【0301】
対応するものである場合、要求装置リスト64に登録されている応答待ち要求メッセージを送信した要求処理装置14へ向け応答希望処理装置の登場を示すメッセージを配信し(ステップ398)、当該要求を応答装置待ちリスト76から削除する(ステップ400)。
【0302】
一方、サーバ334の次に同一のメッセージパターンデータ102を有する応答希望メッセージ24を送信したサーバ326、332に対しては応答許可待ちメッセージを配信する(ステップ402)。
【0303】
以上説明した応答希望パターン登録処理とは逆に、図28に示すように、応答希望パターン削除メッセージを受信した場合(ステップ346)、応答希望パターン削除処理(ステップ356)を行う。
【0304】
図33は応答希望パターン削除処理(ステップ356)の流れを示すフローチャートである。メッセージサーバ310は、応答希望装置リスト66および応答希望パターンリスト86に応答希望メッセージ24のメッセージパターンデータ102を削除する(ステップ410)。
【0305】
次に、当該応答希望メッセージ送信元のサーバ334が応答権を保持していたかどうか応答希望装置リスト66に基づき確認し(ステップ412)、応答権を保持していた場合、次の応答希望処理装置12が存在するかどうか確認し(ステップ414)、存在する場合、応答許可待ちメッセージを配信済みで次に登録されたサーバ326へ向け応答許可を示す応答権付与メッセージを配信する(ステップ416)。
【0306】
一方、次の応答希望装置が存在しない場合、当該要求メッセージ28に応答する処理装置が存在しない状態となったため、当該要求メッセージ28に対応するメッセージパターンデータ102が終了通知希望装置リスト74に登録されている終了通知希望サーバがある場合(ステップ418)、このサーバへ向け終了通知メッセージを配信する(ステップ420)。
【0307】
次に、当該要求メッセージ送信元のサーバの装置情報およびメッセージ情報を終了通知希望装置リスト74から削除する(ステップ422)。
【0308】
応答希望メッセージ24の配信管理および応答権の付与についての説明は以上の通りである。
【0309】
ここで再び、上述した後処理(ステップ268)以降の処理について説明する。図31に示すように、応答権付与済みの応答装置であるかどうかは、応答者取得処理(ステップ260)で取得した情報により判断できる。応答装置であると判断した場合、要求処理(ステップ286)を行う。
【0310】
要求処理(ステップ286)とは、具体的には、要求装置リスト64に端末324の装置情報を追加するとともに、受信した要求メッセージ28を要求メッセージリスト84に追加し、応答権付与済みのサーバ334へ向け要求メッセージ28を配信することである。
【0311】
応答権付与済みのサーバ334では、要求メッセージ28を受信後、要求メッセージ28から製品加工条件の取得であることを判断し、ロット管理DB350を検索し、要求メッセージ28に含まれるロット番号に対応する製品加工条件等を取り出す。
【0312】
次に、要求メッセージ28を、その識別データは残したまま、取得した製品加工条件等を含ませて応答メッセージ26に作り変える。
【0313】
次に、作成した応答メッセージ26をメッセージサーバ310へ向け送信する。
【0314】
図26に示すように、メッセージサーバ310は、応答メッセージ受信後(ステップ244)、応答メッセージ26に含まれる識別情報から応答メッセージ送信先が端末324であることを確認する(ステップ262)。
【0315】
次に、後処理(ステップ268)として、図31に示すように、応答メッセージ26を端末324へ向け配信する応答処理を行う(ステップ290)。なお、応答継続メッセージ26−1や応答終了メッセージ26−2である場合も同様である。
【0316】
応答メッセージ26を受信した端末324は、当該メッセージに含まれる製品加工条件等の情報を取得し、製品加工を行うことが可能となる。
【0317】
また、特殊メッセージとは、上述した応答装置待ちや終了通知等を行うために使用されるメッセージのことであり、図34は、これら特殊メッセージを扱う際の処理の流れを示すフローチャートである。
【0318】
まず、図25に示すように、メッセージサーバ310は、受信メッセージが特殊メッセージである場合(ステップ224)、図34に示す特殊メッセージ処理(ステップ230)を行う。
【0319】
特殊メッセージ処理(ステップ230)では、応答可能時に通知を希望する応答装置待ち要求メッセージか判断し(ステップ452)、応答装置待ち要求メッセージである場合、応答装置待ちリスト76に受信メッセージに含まれるメッセージパターンデータ102を登録する(ステップ458)。
【0320】
また、応答装置待ち要求メッセージでない場合、応答不能時に通知を希望する終了通知希望メッセージか判断し(ステップ454)。終了通知希望メッセージである場合、終了通知希望装置リスト74に受信メッセージに含まれるメッセージパターンデータ102を登録する(ステップ460)。
【0321】
以上のように、通知型、要求応答型、確認許可型という3種類のメッセージを配信管理することにより、多種多様な製品を製造している生産現場のネットワークに適用した場合も、効率的かつ汎用的なメッセージ配信管理を行うことができる。
【0322】
(電子商取引への適用例)
以上の生産現場での例は、一地点で有線の通信路を介しての分散処理システムの例であるが、次に、通信衛星を用いるので通信路が無線であり、遠隔地を結んで分散処理を行う例として電子商取引への適用例を以下に示す。
【0323】
図35は、電子商取引で用いられるネットワークシステムの一例を示す概略図である。また、図36、37は、このシステムでのメッセージ配信管理の流れを示すフローチャートである。なお、全体のメッセージ配信管理の流れは生産現場の例で示したものと同様であるので省略し、電子商取引に特有のメッセージ配信管理の流れについて示している。
【0324】
例えば、図35に示す衛星通信による電子商取引ネットワークシステムは、金融機関500と、金融機関502と、商店504と、携帯型端末506と、通信衛星508とから構成されている。
【0325】
金融機関500は、メッセージ配信管理サーバ520、利用者DB管理サーバ530とを有し、金融機関502では利用者DBのバックアップDB管理サーバ540を有している。
【0326】
利用者が残高照会する場合は以下の流れとなる。図36は残高照会のメッセージ配信管理の流れを示すフローチャートである。まず、利用者が携帯型端末506から残高照会というイベントを発生させることにより、残高照会可能かどうか確認するため、確認メッセージ34がメッセージ配信管理サーバ520へ向け通信衛星508を介して送信される。
【0327】
メッセージ配信管理サーバ520は、確認メッセージ34を受信した場合(ステップ502)、残高照会可能かどうか確認するため、利用者DB550を有する金融機関500および金融機関502に対して利用者DB550およびバックアップDB560を更新中でないか確認メッセージ34を配信する(ステップ504)。
【0328】
メッセージ配信管理サーバ520は、金融機関500および金融機関502から許可メッセージ32を受信し、配信した時点で(ステップ506、508)、許可終了メッセージ36を携帯型端末506へ向け配信する(ステップ510)。
【0329】
携帯型端末506は、許可終了メッセージ36が配信されることにより、利用者DB550を参照可能であることを判断できる。
【0330】
次に、携帯型端末506により、残高照会の要求メッセージ28が通信衛星508を介してメッセージ配信管理サーバ520へ向け送信される。
【0331】
メッセージ配信管理サーバ520は、要求メッセージ28を受信した場合(ステップ520)、残高照会の応答権を有する金融機関500の利用者DB管理サーバ530へ向け要求メッセージ28を配信する(ステップ522)。
【0332】
利用者DB管理サーバ530は、利用者DB550を用いて利用者の残高データを取得し、この残高データを含ませた応答メッセージ26を作成してメッセージ配信管理サーバ520へ向け送信する。
【0333】
メッセージ配信管理サーバ520は、応答メッセージ受信後(ステップ524)、受信した応答メッセージ26を携帯型端末506へ向け配信する(ステップ526)。
【0334】
携帯型端末506は、応答メッセージ26を受信し、このメッセージに含まれる残高データから残高が確認できる。
【0335】
また、利用者が商品を購入する場合は以下の流れとなる。図37は商品購入時のメッセージ配信管理の流れを示すフローチャートである。まず、利用者が携帯型端末506から商品購入というイベントを発生させることにより、商品購入可能かどうか確認するため、残高の照会を行う確認メッセージ34がメッセージ配信管理サーバ520へ向け通信衛星508を介して送信された後、商品購入という要求メッセージ28が配信される。
【0336】
残高の照会を行う確認メッセージ34の流れ(ステップ550)は上述したものと同様なので省略する。携帯型端末506のプログラムは、許可終了メッセージ36が配信されることにより、利用者DB550を参照可能であり、商品を購入できる条件を満たしていることを判断できる。
【0337】
次に、商品購入のため、携帯型端末506から要求メッセージ28が通信衛星508を介してメッセージ配信管理サーバ520へ向け送信される。
【0338】
メッセージ配信管理サーバ520は、この要求メッセージ受信後(ステップ558)、応答権を有する利用者DB管理サーバ530へ向け要求メッセージ28を配信する(ステップ560)。
【0339】
利用者DB管理サーバ530は、端末506の利用者の管理情報に対して商品金額分を減額して利用者DB550を更新し、商店504の管理情報に対して商品金額分を増額するよう商店の情報が格納された利用者DB550を更新する。利用者DB管理サーバ530は、利用者DB550を更新後、バックアップDB560を更新する要求メッセージ28をメッセージ配信管理サーバ520へ向け送信する。
【0340】
メッセージ配信管理サーバ520は、バックアップDB560を更新する要求メッセージ受信後(ステップ564)、バックアップDB560を更新する要求メッセージ28に対する応答権を有するバックアップDB管理サーバ540へ向け、要求メッセージ28を配信する(ステップ566)。
【0341】
バックアップDB管理サーバ540は、利用者DB管理サーバ530と同様の更新を行った後、応答メッセージ26をメッセージ配信管理サーバ520へ向け送信する。
【0342】
メッセージ配信管理サーバ520は、この応答メッセージ受信後(ステップ568)、受信した応答メッセージ26を利用者DB管理サーバ530へ向け配信する(ステップ570)。
【0343】
利用者DB管理サーバ530は、応答メッセージ26を受信して、更新を正常に行えたことを判断した後、携帯型端末506の識別情報を含む応答メッセージ26を、メッセージ配信管理サーバ520へ向け送信する。
【0344】
メッセージ配信管理サーバ520は、利用者DB管理サーバ530から応答メッセージ26を受信した場合(ステップ578)、メッセージ中に含まれる識別情報に基づき携帯型端末506へ向け応答メッセージ26を配信する(ステップ580)。
【0345】
利用者は、応答メッセージ26を受信することにより、携帯型端末506の画面表示等を通じて商品購入処理が正常に行われたことを確認できる。
【0346】
また、メッセージ配信管理サーバ520は、商店504へ向け、利用者から商品の申し込みと入金があった旨の通知メッセージ22を配信する(ステップ590)。
【0347】
商店504は、通知メッセージ22を受信することにより、入金があったことを確認し、利用者に指定された届け先に商品を配送する。
【0348】
以上のように、本システムによる処理対象は、部品のような有体物であっても電子マネーのような無体物であってもよい。また、通信路は、ケーブル等の有線であってもよいし、通信衛星を用いた通信路等の無線の通信路であってもよい。
【0349】
また、メッセージを送受信する処理装置は、コンピュータのようにほぼ固定されたものでもよいし、携帯型端末のように移動可能なものであってもよい。さらに、メッセージ配信管理手段や処理装置は、工場のように比較的狭い場所に小規模かつ集中的に配置されるものであっても、携帯型端末と金融機関のように広域に大規模かつ分散的に配置されるものであってもよい。
【0350】
また、以上の2例で示したように、要求応答メッセージを排他制御に用いることもできる。すなわち、応答権を一つに限定することにより、ある要求に対して応答処理を行うことを、一つの処理装置に限定できる。また、電子商取引の例で示したように、特に分散処理で必要とされる複数DBの同時更新処理も実現できる。
【0351】
(変形例)
(メッセージヘッダ部の変形例)
以上説明してきた実施例では、メッセージヘッダ部100にメッセージパターンデータ102があり、このメッセージパターンデータ102を用いてメッセージの種別を判断できるものであったが、ヘッダ部100にその他のデータ領域を設けて実現することも可能である。
【0352】
図38は、ヘッダ部100にメッセージの文字種別を示す文字種別データ130、メッセージのモードを示すモードデータ190を設けた一例を示す。
【0353】
例えば、文字種別データ130がない場合、通信元の処理装置では文字種別としてEUC(Extended UNIX Code)を用いてメッセージを作成して送信した場合、通信先の処理装置では文字種別としてSJIS(ShiftJIS)しか認識しない場合、通信先でメッセージの文字種別を判断して変換しなければならない。
【0354】
文字種別データ130を用いて、メッセージ配信管理手段4で文字変換を行うことにより、EUCやSJISといった文字コードの別だけでなく、日本語や英語といったメッセージの言語を、通信先の処理装置で意識せずに取り扱うことができるようになる。
【0355】
具体的な実現手段は以下のようになる。図39は、メッセージ変換を行う際のメッセージ配信管理システム4の機能ブロック図の一例である。図39に示すように、メッセージ配信管理手段4に、メッセージ変換手段50を設け、メッセージのヘッダ部100に、そのメッセージにおいて使用されている文字種別を示す文字種別データ130を含んで構成する。
【0356】
メッセージ配信管理手段4がメッセージを受信した場合、メッセージ変換手段50を用いて、受信したメッセージに含まれる文字種別データ130に基づきそのメッセージにおいて使用されている文字を変換する。
【0357】
これによれば、メッセージ配信管理手段内のメッセージ変換手段50がメッセージ中の文字種別データ130から文字種別を判断して変換するため、通信元や通信先の処理装置はメッセージの文字種別を意識せずに通信できる。これにより、汎用的なメッセージ配信管理システムを実現できる。
【0358】
また、上述した実施例では、メッセージパターンデータ102が、目的データ140、グループデータ150、カテゴリデータ160を含んで構成される例について示したが、さらにメッセージパターンデータ102にモードデータ190も含めてメッセージの種別を判断するようにしてもよい。
【0359】
モードデータ190には管理、通常、特殊といったメッセージの大きな区分を指定することも可能であるし、通常メッセージ以外のメッセージの区別に用いてもよい。例えば、応答許可待ち、応答権付与、通知希望登録、通知希望削除、応答希望登録、応答希望削除、許可希望登録、許可希望削除等の指定を可能にするよう構成してもよい。
【0360】
さらに、図38に示すように、ヘッダ部100に、メッセージ長データ110、バージョン番号120、メッセージ識別番号170、メッセージ送信元識別番号180を設ければ、さらに汎用性が高まる。
【0361】
なお、上述したメッセージ長の判断をメッセージ長データ110を用いて行い、処理装置の識別データとしてメッセージ送信元識別番号180を用いて行ってもよい。
【0362】
また、メッセージ識別番号170およびメッセージ送信元識別番号180はそれぞれ重複のない番号を用いることが好ましい。重複がないため、メッセージを一意に識別することができるようになる。
【0363】
(情報記録媒体)
以上説明してきたメッセージ配信管理手段4が行う処理を情報記録媒体に記録して構成してもよい。情報記録媒体としては、一般に用いられている磁気やレーザー光を用いた記憶媒体を適用できる。
【0364】
図40は、本実施の形態によるメッセージ配信管理をコンピュータ3に行わせるための情報記録媒体600の使用例を示す概略図である。
【0365】
情報記録媒体600に記憶されている通知管理情報610、要求応答管理情報620、確認許可管理情報630の少なくとも一つをコンピュータ3に読み込ませることにより、上述した通知型、要求応答型、確認許可型の各処理をコンピュータ3に行わせることができる。
【0366】
すなわち、コンピュータ3において、CPU55が管理データ制御手段54、配信制御手段56、メッセージ変換手段50および時間測定手段58として機能し、メモリ51が配信管理データ60および状態管理データ80が記憶される管理データ記憶手段52として機能することにより、コンピュータ3を上述したメッセージ配信管理手段4として機能させることができるようになる。
【0367】
また、情報記録媒体600を用いないでコンピュータ3を上述したメッセージ配信管理手段4として機能させる場合、例えば、メッセージ変換手段50、管理データ制御手段54、配信制御手段56としてCPUを用い、管理データ記憶手段52としてメモリを用い、時間測定手段58としてシステムタイマを用いればよい。
【0368】
なお、本発明は上述した実施例に限られるものではない。例えば、管理データ記憶手段52に記憶するものはメッセージそのものであっても、メッセージパターンデータ102だけであっても、メッセージパターンデータ102にその他の装置情報やメッセージ情報を付加したものであってもよい。
【0369】
また、本発明は、分散処理ネットワークだけでなく、クライアントサーバ型、集中処理型等の各種のネットワークに適用することが可能である。
【0370】
【図面の簡単な説明】
【図1】本発明の実施の形態の一例に係る分散処理ネットワークシステムの一例を示す図である。
【図2】メッセージのデータ構造の概略図である。
【図3】ヘッダ部の概略図である。
【図4】データ部の概略図である。
【図5】概略的なメッセージ処理の流れを示すフローチャートである。
【図6】通知型ネットワークシステムの一例を示す概略図である。
【図7】通知型メッセージ処理の一例を示すフローチャートである。
【図8】配信管理データの概略図である。
【図9】通知希望装置リスト等のデータ構造の一例を示す概略図である。
【図10】要求応答型ネットワークシステムの一例を示す概略図である。
【図11】要求応答型メッセージ処理の一例を示すフローチャートである。
【図12】要求装置リスト等のデータ構造の一例を示す概略図である。
【図13】応答継続および応答終了処理の一例を示すフローチャートである。
【図14】確認許可型ネットワークシステムの一例を示す概略図である。
【図15】確認許可型メッセージ処理の一例を示すフローチャートである。
【図16】状態管理データを含んで構成したメッセージ配信制御手段の一例を示す機能ブロック図である。
【図17】メッセージ配信管理手段を用いたモニタリング処理の一例を示すフローチャートである。
【図18】状態管理データの概略図である。
【図19】通知希望パターンリスト等のデータ構造の一例を示す概略図である。
【図20】要求メッセージリスト等のデータ構造の一例を示す概略図である。
【図21】開始通知希望メッセージ配信管理処理の一例を示すフローチャートである。
【図22】応答装置待ちデータを用いた処理の一例を示すフローチャートである。
【図23】メッセージ配信管理手段に時間測定手段を設けた一例を示す機能ブロック図である。
【図24】メッセージ配信管理のメイン処理の流れを示すフローチャートである。
【図25】メッセージ処理の流れを示すフローチャートである。
【図26】通常メッセージ処理の流れを示すフローチャートである。
【図27】確認メッセージ処理の流れを示すフローチャートである。
【図28】管理メッセージ処理の流れを示すフローチャートである。
【図29】許可希望パターン登録処理の流れを示すフローチャートである。
【図30】許可処理の流れを示すフローチャートである。
【図31】後処理の流れを示すフローチャートである。
【図32】応答希望パターン登録処理の流れを示すフローチャートである。
【図33】応答希望パターン削除処理の流れを示すフローチャートである。
【図34】特殊メッセージを扱う際の処理の流れを示すフローチャートである。
【図35】電子商取引で用いられるネットワークシステムの一例を示す概略図である。
【図36】残高照会のメッセージ配信管理の流れを示すフローチャートである。
【図37】商品購入時のメッセージ配信管理の流れを示すフローチャートである。
【図38】ヘッダ部にメッセージの文字種別を示す文字種別データ、メッセージのモードを示すモードデータ等を設けた一例を示す概略図である。
【図39】メッセージ変換を行う際のメッセージ配信管理システムの一例を示す機能ブロック図である。
【図40】本実施の形態によるメッセージ配信管理をコンピュータに行わせるための情報記録媒体の使用例を示す概略図である。
【図41】データ部の概略図の他の一例である。
【符号の説明】
4 メッセージ配信管理手段
8 通知希望処理装置
10 通知処理装置
12 応答希望処理装置
14 要求処理装置
16 許可希望処理装置
18 確認処理装置
52 管理データ記憶手段
54 管理データ制御手段
56 配信制御手段
100 ヘッダ部
102 メッセージパターンデータ
200 データ部
300 通信路
310 メッセージ配信管理サーバ
600 情報記録媒体

Claims (27)

  1. 通信路に接続されたメッセージ配信管理手段を介して、複数の処理装置間で通知型メッセージ、要求応答型メッセージおよび確認許可型メッセージの送受信を行うネットワークにおけるメッセージ配信管理システムであって、
    前記メッセージ配信管理手段は、
    メッセージの配信管理を行うための通知管理データ、要求応答管理データおよび確認許可管理データを含む管理データが記憶される管理データ記憶手段と、
    受信メッセージに基づき、前記管理データの作成を行う管理データ制御手段と、
    前記管理データに基づき、受信メッセージを所定の処理装置へ向け配信する配信制御手段と、
    を含んで構成され、
    前記通知型メッセージは、
    状態変化の通知を示す通知メッセージと、
    この通知メッセージの受信希望を示す通知希望メッセージの少なくとも2種類のメッセージから構成され、
    前記通知メッセージの受信を希望する処理装置は、
    前記通知希望メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
    前記通知メッセージを前記メッセージ配信管理手段から受信する手段と、
    を含んで構成され、
    前記状態変化の通知を行う処理装置は、
    状態変化時にその旨を、通知メッセージとして前記メッセージ配信管理手段へ向け送信する手段を含んで構成され、
    前記管理データ制御手段は、
    前記通知希望メッセージを受信した場合に、通知希望元の処理装置へ向け前記状態変化の通知を行うための前記通知管理データを作成し、
    前記配信制御手段は、
    前記通知メッセージを受信した場合に、前記通知管理データに基づき前記通知希望処理装置へ向け前記通知メッセージを配信するように構成され、
    前記要求応答型メッセージは、
    情報の問い合わせを示す要求メッセージと、
    この要求メッセージに対する応答希望を示す応答希望メッセージと、
    前記要求メッセージに対する応答を示す応答メッセージの少なくとも3種類のメッセージから構成され、
    前記応答を希望する処理装置は、
    前記応答希望メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
    前記要求メッセージを前記メッセージ配信管理手段から受信し、要求に対応した応答内容を含む応答メッセージを作成して前記メッセージ配信管理手段へ向け送信する手段と、
    を含んで構成され、
    前記要求メッセージ送信元の処理装置は、
    前記要求メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
    要求に対応した前記応答メッセージを前記メッセージ配信管理手段から受信する手段と、
    を含んで構成され、
    前記管理データ制御手段は、
    前記応答希望メッセージを受信した場合に、前記応答希望メッセージ送信元の処理装置へ向け前記要求メッセージの配信を行い、前記要求メッセージを受信した場合に、前記要求メッセージ送信元の処理装置へ向け前記応答メッセージの配信を行うための前記要求応答管理データを作成し、
    前記配信制御手段は、
    前記要求メッセージを受信した場合に、前記要求応答管理データに基づき前記応答希望メッセージ送信元の処理装置へ向け前記要求メッセージを配信し、前記応答希望メッセージ送信元の処理装置から前記応答メッセージを受信した場合に、前記要求応答管理データに基づき前記要求メッセージ送信元の処理装置へ向け前記応答メッセージを配信するように構成され、
    前記確認許可型メッセージは、
    イベントの実行に対する許可を得るための確認を示す確認メッセージと、
    この確認メッセージに対する許可付与の希望を示す許可希望メッセージと、
    前記確認メッセージに対する許可、不許可を示す許可メッセージの少なくとも3種類のメッセージから構成され、
    前記許可付与を希望する処理装置は、
    前記許可希望メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
    前記確認メッセージを前記メッセージ配信管理手段から受信し、前記許可メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
    を含んで構成され、
    前記確認を行う処理装置は、
    前記確認メッセージを前記メッセージ配信管理手段へ向け送信する手段と、
    確認に対応した前記許可メッセージを前記メッセージ配信管理手段から受信する手段と、
    を含んで構成され、
    前記管理データ制御手段は、
    前記確認メッセージを受信した場合に、前記許可希望メッセージ送信元の処理装置へ向け前記確認メッセージの配信を行い、前記許可メッセージを受信した場合に、前記確認メッセージ送信元の処理装置へ向け前記許可メッセージの配信を行うための前記確認許可管理データを作成し、
    前記配信制御手段は、
    前記確認メッセージを受信した場合に、前記確認許可管理データに基づき前記許可希望メッセージ送信元の処理装置へ向け前記確認メッセージを配信し、前記許可希望メッセージ送信元の処理装置から前記許可メッセージを受信した場合に、前記確認許可管理データに基づき前記確認メッセージ送信元の処理装置へ向け前記許可メッセージを配信するように構成されていることを特徴とするメッセージ配信管理システム。
  2. 請求項1において、
    メッセージは、
    その通信の目的を示す目的データを有するメッセージパターンデータを含んで構成され、
    前記目的データは、
    少なくとも前記通知、前記通知希望、前記要求、前記応答希望、前記応答、前記確認、前記許可希望、前記許可のいずれかの目的を示すデータであり、
    前記管理データ制御手段は、
    受信メッセージに含まれる前記メッセージパターンデータを、前記処理装置の所在データと関連づけることにより、前記受信メッセージを配信管理するための配信管理データを作成し、この配信管理データを前記管理データとして、前記管理データ記憶手段に記憶するように構成され、
    前記配信制御手段は、
    前記受信メッセージに含まれる前記メッセージパターンデータと、前記管理データとに基づき、前記受信メッセージの配信制御を行うことを特徴とするメッセージ配信管理システム。
  3. 請求項2において、
    前記管理データは、
    前記処理装置の前記所在データおよび識別データとを有する装置データと、
    前記処理装置からの受信メッセージの配信管理を行うためのメッセージデータと、
    を含んで構成され、
    前記管理データ制御手段は、
    前記処理装置が前記通信路との接続を開始した場合に、この処理装置に対する前記識別データを作成し、この識別データと、対応する所在データとを前記装置データとして前記管理データ記憶手段に記憶するとともに、前記受信メッセージに含まれる前記メッセージパターンデータを有する前記メッセージデータを、前記装置データと関連づけることにより、前記メッセージパターンデータに基づき、前記受信メッセージを配信管理するための前記配信管理データを作成し、この配信管理データを前記管理データとして、前記管理データ記憶手段に記憶するように構成され、
    前記配信制御手段は、
    前記受信メッセージに含まれる前記メッセージパターンデータと、前記管理データとに基づき、前記受信メッセージの配信制御を行うことを特徴とするメッセージ配信管理システム。
  4. 請求項3において、
    前記管理データ制御手段は、
    前記処理装置が前記通信路との接続を終了した場合に、前記接続時に作成した前記装置データおよび前記装置データと関連づけられた前記メッセージデータを削除することを特徴とするメッセージ配信管理システム。
  5. 請求項2〜4のいずれかにおいて、
    前記通知型メッセージは、
    前記目的データとして、前記通知または前記通知希望のいずれかのデータを含んで構成され、
    前記通知管理データは、
    前記通知希望メッセージが配信管理される通知希望装置データを含んで構成され、
    前記管理データ制御手段は、
    前記通知希望メッセージを受信した場合、前記通知希望装置データを作成して前記管理データ記憶手段に記憶するように構成され、
    前記配信制御手段は、
    前記通知メッセージを受信した場合、前記通知メッセージに含まれる前記メッセージパターンデータと、前記管理データ記憶手段に記憶された前記通知希望装置データとに基づき、前記通知希望処理装置へ向け前記通知メッセージを配信することを特徴とするメッセージ配信管理システム。
  6. 請求項2〜5のいずれかにおいて、
    前記要求応答型メッセージは、
    前記目的データとして、前記要求、前記応答または前記応答希望のいずれかのデータを含んで構成され、
    前記要求応答管理データは、
    前記応答希望メッセージが配信管理される応答希望装置データを含んで構成され、
    前記管理データ制御手段は、
    前記応答希望メッセージを受信した場合、前記応答希望装置データを作成して前記管理データ記憶手段に記憶するように構成され、
    前記配信制御手段は、
    前記応答希望メッセージを受信した場合、この応答希望メッセージが前記応答希望装置データに記憶されていないメッセージパターンデータを有するメッセージならば、前記応答希望メッセージ送信元の処理装置へ向け、応答権の付与を示す応答権付与メッセージを配信し、
    前記要求メッセージを受信した場合、前記要求メッセージに含まれるメッセージパターンデータと、前記管理データ記憶手段に記憶された前記応答希望装置データとに基づき、前記応答権付与メッセージ配信先の応答希望処理装置へ向け、前記要求メッセージ送信元の処理装置の前記識別データを前記要求メッセージに含ませた要求メッセージを配信し、
    前記応答権付与メッセージ配信先の応答希望処理装置は、
    前記要求メッセージを受信した場合、この要求メッセージに対する応答メッセージに、前記要求メッセージに含まれる前記識別データを含ませて前記配信制御手段へ向け送信し、
    前記配信制御手段は、
    前記要求メッセージ配信先の処理装置から前記要求メッセージに対する前記応答メッセージを受信した場合、この応答メッセージ中の識別データに基づき、前記要求メッセージ送信元の処理装置へ向け前記応答メッセージを配信することを特徴とするメッセージ配信管理システム。
  7. 請求項6において、
    前記目的データとしての応答データは、前記要求メッセージに対する回答の継続を示す応答継続データ、この回答の終了を示す応答終了データのいずれかのデータを含んで構成され、
    前記配信制御手段は、
    前記要求メッセージ配信先の処理装置から、前記応答メッセージを受信した場合、所定の条件に基づき、前記応答メッセージを分割し、
    この分割したメッセージに前記応答継続データを含ませて応答継続メッセージとして作成し、前記応答メッセージ中の識別データに基づき、前記要求メッセージ送信元の処理装置へ向け前記応答継続メッセージを配信し、
    割した最終の応答メッセージに、前記応答終了データを含ませて応答終了メッセージとして作成し、前記応答メッセージに含まれる前記識別データに基づき、前記要求メッセージ送信元の処理装置へ向け前記応答終了メッセージを配信することを特徴とするメッセージ配信管理システム。
  8. 請求項2〜7のいずれかにおいて、
    前記確認許可型メッセージは、
    前記目的データとして、前記確認、前記許可または前記許可希望のいずれかのデータを含んで構成され、
    前記確認許可管理データは、
    前記許可希望メッセージを配信管理する許可希望装置データを含んで構成され、
    前記管理データ制御手段は、
    前記許可希望メッセージを受信した場合、前記許可希望装置データを作成して前記管理データ記憶手段に記憶するように構成され、
    前記配信制御手段は、
    前記確認メッセージを受信した場合、この確認メッセージに含まれる前記メッセージパターンデータと、前記管理データ記憶手段に記憶された前記許可希望装置データとに基づき、前記確認メッセージ送信元の確認処理装置の前記識別データを前記確認メッセージに含ませ、前記許可希望処理装置へ向けこの確認メッセージを配信し、
    前記確認メッセージの配信先の処理装置から前記確認メッセージに対する前記確認処理装置の識別データを有する許可メッセージを受信した場合、この許可メッセージ中の識別データに基づき、前記確認メッセージ送信元の処理装置へ向け前記許可メッセージを配信することを特徴とするメッセージ配信管理システム。
  9. 請求項8において、
    前記確認許可型メッセージは、
    前記目的データとして、前記確認、前記許可、前記許可希望または前記確認に対する回答の終了を示す許可終了のいずれかのデータを含んで構成され、
    前記許可希望メッセージを送信する許可希望処理装置は複数存在し、
    前記配信制御手段は、
    前記確認メッセージを受信した場合、この確認メッセージに含まれる前記メッセージパターンデータと、前記管理データ記憶手段に記憶された前記許可希望装置データとに基づき、前記確認メッセージ送信元の確認処理装置の前記識別データを前記確認メッセージに含ませ、複数の許可希望処理装置へ向けこの確認メッセージを配信し、
    前記複数の許可希望処理装置は、
    前記確認メッセージを受信した場合、この確認メッセージに含まれる前記識別データを送信する許可メッセージに含ませ、この許可メッセージを前記メッセージ配信管理手段へ向け送信し、
    前記配信制御手段は、
    前記確認メッセージ配信先の複数の処理装置から前記確認メッセージに対する前記許可メッセージを受信した場合、この許可メッセージ中の識別データに基づき、前記確認メッセージ送信元の処理装置へ向け前記許可メッセージを配信し、
    受信した許可メッセージが最終のものである場合、この許可メッセージ中の識別データに基づき、前記確認メッセージ送信元の処理装置へ向け、前記許可メッセージを配信するとともに、前記目的データに前記許可終了を含ませた許可終了メッセージを配信することを特徴とするメッセージ配信管理システム。
  10. 請求項2〜9のいずれかにおいて、
    前記メッセージパターンデータは、
    前記目的データに基づき選択された前記管理データにおいて、所定のメッセージを受信する処理装置のグループを示すグループデータを含んで構成され、
    前記管理データ制御手段は、
    前記目的データおよび前記グループデータが指定されたメッセージを受信した場合、この受信メッセージに含まれる前記目的データに基づき前記管理データを選択し、前記受信メッセージに含まれる前記グループデータに基づき、前記受信メッセージに基づき作成した配信管理データを、前記管理データ記憶手段中の選択した管理データ中に分類して記憶し、
    前記配信制御手段は、
    前記目的データおよび前記グループデータが指定されたメッセージを受信した場合、この受信メッセージの前記メッセージパターンデータと、前記メッセージパターンデータと対応する前記管理データ中の前記配信管理データとに基づき、前記受信メッセージの配信制御を行うことを特徴とするメッセージ配信管理システム。
  11. 請求項2〜10のいずれかにおいて、
    メッセージは、
    前記メッセージパターンデータを有する固定長のヘッダ部と、
    前記メッセージパターンデータに応じた詳細データを有する可変長のデータ部と、
    を含んで構成され、
    前記データ部は、
    データ名とそのデータ名に対応するデータとからなる組データを含んで構成され、
    前記処理装置および前記メッセージ配信管理手段は、
    前記データ名を指定することにより、そのデータ名に対応するデータを取得できるように構成されていることを特徴とするメッセージ配信管理システム。
  12. 請求項11において、
    前記組データは、
    連想配列形式で構成され、
    前記処理装置および前記メッセージ配信管理手段は、
    前記連想配列形式のデータから必要な組データを取り出して前記データ名を指定することにより、そのデータ名に対応するデータを取得できるように構成されていることを特徴とするメッセージ配信管理システム。
  13. 請求項11、12のいずれかにおいて、
    前記メッセージ配信管理手段は、
    メッセージ変換手段を有し、
    前記ヘッダ部は、
    そのメッセージにおいて使用されている文字種別を示す文字種別データを含んで構成され、
    前記メッセージ変換手段は、
    前記文字種別データに基づきそのメッセージにおいて使用されている文字を変換できるように構成されていることを特徴とするメッセージ配信管理システム。
  14. 請求項10〜13のいずれかにおいて、
    前記メッセージパターンデータは、
    前記目的データに基づき選択された前記管理データにおいて、前記グループデータに基づき選択された所定の処理装置から当該メッセージの処理を行う処理装置が選択されるための処理内容を示すカテゴリデータを含んで構成され、
    前記管理データ制御手段は、
    前記目的データ、前記グループデータおよび前記カテゴリデータが指定されたメッセージを受信した場合、この受信メッセージに含まれる前記目的データに基づき前記管理データを選択し、前記受信メッセージに含まれる前記グループデータおよび前記カテゴリデータに基づき、前記受信メッセージに基づき作成した配信管理データを、前記管理データ記憶手段中の選択した管理データ中に分類して記憶し、
    前記配信制御手段は、
    前記目的データ、前記グループデータおよび前記カテゴリデータが指定されたメッセージを受信した場合、この受信メッセージの前記メッセージパターンデータと、前記メッセージパターンデータと対応する前記管理データ中の前記配信管理データとに基づき、前記受信メッセージの配信制御を行うことを特徴とするメッセージ配信管理システム。
  15. 請求項14において、
    前記グループデータまたは前記カテゴリデータの少なくとも一方は、
    前記グループデータにおける前記グループまたは前記カテゴリデータにおける前記処理内容が段階的に分類された複数の分類データを含んで構成され、
    前記配信制御手段は、
    前記複数の分類データが指定されたメッセージを受信した場合、この受信メッセージの前記メッセージパターンデータと、前記管理データと、前記複数の分類データとに基づきメッセージ共有グループを段階的に絞り込み、前記受信メッセージの配信制御を行うことを特徴とするメッセージ配信管理システム。
  16. 請求項15において、
    前記分類データには、
    当該分類に属する全処理装置を示す全指定データを指定可能であり、
    前記配信制御手段は、
    前記分類に前記全指定データが指定されたメッセージを受信した場合、この受信メッセージの前記メッセージパターンデータと、前記管理データと、前記全指定データが指定された前記分類データとに基づき、前記受信メッセージの配信管理を行うことを特徴とするメッセージ配信管理システム。
  17. 請求項14〜16のいずれかにおいて、
    前記通知型、前記要求応答型、前記確認許可型メッセージのうち少なくとも1つのメッセージは、
    前記目的データとして、所定の処理装置が前記通信路との接続を開始した場合にその通知が行われるための開始通知希望データを含んで構成され、
    前記管理データのうち少なくとも1つの管理データは、
    前記開始通知希望データが指定された開始通知希望メッセージが配信管理される開始通知希望装置データを含んで構成され、
    前記管理データ制御手段は、
    前記開始通知希望メッセージを受信した場合、前記開始通知希望装置データを作成して前記管理データ記憶手段に記憶し、
    前記配信制御手段は、
    前記カテゴリデータに前記通信路との接続の開始を通知する接続開始データが指定されたメッセージを、前記所定の処理装置から受信した場合、この受信メッセージに含まれる前記メッセージパターンデータと、前記開始通知希望装置データとに基づき、前記開始通知希望メッセージを送信した処理装置へ向け、前記接続開始データが指定されたメッセージを配信することを特徴とするメッセージ配信管理システム。
  18. 請求項2〜16のいずれかにおいて、
    前記要求メッセージを送信する処理装置は、
    この要求メッセージに対応する応答が可能な応答装置が前記通信路との接続を開始し、この応答装置から前記応答希望メッセージを前記メッセージ配信管理手段が受信した場合にその通知が行われるための応答通知希望メッセージを送信するよう構成され、
    前記要求応答管理データは、
    前記応答通知希望メッセージが配信管理される応答装置待ちデータを含んで構成され、
    前記管理データ制御手段は、
    前記応答通知希望メッセージを受信した場合、このメッセージに基づき応答装置待ちデータを作成して前記管理データ記憶手段に記憶し、
    前記配信制御手段は、
    前記応答希望メッセージを前記応答装置から受信した場合、この受信メッセージの前記メッセージパターンデータと、前記応答装置待ちデータとに基づき、前記応答通知希望メッセージを送信した処理装置へ向け、前記応答装置の出現を通知する応答装置出現メッセージを配信することを特徴とするメッセージ配信管理システム。
  19. 請求項14〜18のいずれかにおいて、
    前記通知型、前記要求応答型、前記確認許可型メッセージのうち少なくとも1つのメッセージは、
    前記目的データとして、所定の処理装置が前記通信路との接続を終了した場合にその通知が行われるための終了通知希望データを含んで構成され、
    前記管理データのうち少なくとも1つの管理データは、
    前記終了通知希望データが指定された終了通知希望メッセージが配信管理される終了通知希望装置データを含んで構成され、
    前記管理データ制御手段は、
    前記終了通知希望メッセージを受信した場合、前記終了通知希望装置データを作成して前記管理データ記憶手段に記憶し、
    前記配信制御手段は、
    前記所定の処理装置が前記通信路との接続を終了した場合、前記終了通知希望装置データに基づき、前記終了通知希望メッセージを送信した処理装置へ向け接続終了を示すメッセージを配信することを特徴とするメッセージ配信管理システム。
  20. 請求項14〜18のいずれかにおいて、
    前記要求応答型メッセージは、
    前記目的データとして、前記応答権を有する処理装置が前記通信路との接続を終了した場合にその通知が行われるための終了通知希望データを含んで構成され、
    前記要求応答管理データは、
    前記終了通知希望データが指定された終了通知希望メッセージが配信管理される終了通知希望装置データを含んで構成され、
    前記管理データ制御手段は、
    前記終了通知希望メッセージを受信した場合、前記終了通知希望装置データを作成して前記管理データ記憶手段に記憶し、
    前記配信制御手段は、
    前記応答権を有する処理装置が前記通信路との接続を終了した場合、
    応答権付与待ちの処理装置がないならば、前記終了通知希望装置データに基づき、前記終了通知希望メッセージを送信した処理装置へ向け接続終了を示すメッセージを配信することを特徴とするメッセージ配信管理システム。
  21. 請求項2〜20のいずれかにおいて、
    前記メッセージ配信管理手段は、
    時間測定手段を有し、
    前記処理装置からメッセージ受信後、前記時間測定手段により測定された測定時間に基づき、当該メッセージに対して行われる処理をタイムアウト処理することを特徴とするメッセージ配信管理システム。
  22. 請求項1〜21のいずれかにおいて、
    前記管理データは、
    処理装置から送られたメッセージの配信状態が、各処理装置毎に管理される状態管理データを含んで構成され、
    前記管理データ制御手段は、
    前記処理装置からメッセージを受信した場合、前記受信メッセージを送信した処理装置用の前記状態管理データを作成して前記管理データ記憶手段に記憶し、
    前記処理装置から前記処理装置または他の処理装置のメッセージ配信状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記状態管理データを取得するよう構成され、
    前記配信制御手段は、
    前記問い合わせがあった場合、前記問い合わせ元の処理装置へ向け、前記取得した状態管理データの情報を含ませたメッセージを配信することを特徴とするメッセージ配信管理システム。
  23. 請求項1〜22のいずれかにおいて、
    前記通知管理データは、
    前記通知希望メッセージの配信状態が、各処理装置毎に管理される通知希望状態データを含んで構成され、
    前記管理データ制御手段は、
    前記通知希望メッセージを受信した場合、前記通知希望状態データを作成して前記管理データ記憶手段に記憶し、
    前記処理装置から前記処理装置または他の処理装置の通知希望メッセージ配信状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記通知希望状態データを取得するよう構成され、
    前記配信制御手段は、
    前記通知希望メッセージ配信状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記通知希望状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した通知希望状態データの情報を含ませたメッセージを配信することを特徴とするメッセージ配信管理システム。
  24. 請求項1〜23のいずれかにおいて、
    前記要求応答管理データは、
    前記要求メッセージの配信状態が、各処理装置毎に管理される要求状態データと、
    前記応答希望メッセージの配信状態が、各処理装置毎に管理される応答希望状態データと、
    を含んで構成され、
    前記管理データ制御手段は、
    前記応答希望メッセージを受信した場合、前記応答希望状態データを作成して前記管理データ記憶手段に記憶し、
    前記要求メッセージを受信した場合、前記要求状態データを作成して前記管理データ記憶手段に記憶し、
    前記処理装置から前記処理装置または他の処理装置の応答希望メッセージ配信状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記応答希望状態データを取得し、
    前記処理装置から前記処理装置または他の処理装置の要求メッセージ配信状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記要求状態データを取得するよう構成され、
    前記配信制御手段は、
    前記応答希望メッセージ配信状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記応答希望状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した応答希望状態データの情報を含ませたメッセージを配信し、
    前記要求メッセージ配信状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記要求状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した要求状態データの情報を含ませたメッセージを配信することを特徴とするメッセージ配信管理システム。
  25. 請求項1〜24のいずれかにおいて、
    前記確認許可管理データは、
    前記確認メッセージの配信状態が管理される確認状態データと、
    前記許可希望メッセージの配信状態が管理される許可希望状態データと、
    を含んで構成され、
    前記管理データ制御手段は、
    前記許可希望メッセージを受信した場合、前記許可希望状態データを作成して前記管理データ記憶手段に記憶し、
    前記確認メッセージを受信した場合、前記確認状態データを作成して前記管理データ記憶手段に記憶し、
    前記処理装置から前記処理装置または他の処理装置の許可希望メッセージ配信管理状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記許可希望状態データを取得し、
    前記処理装置から前記処理装置または他の処理装置の確認メッセージ配信管理状態の問い合わせがあった場合、問い合わせがあった処理装置用の前記確認状態データを取得するよう構成され、
    前記配信制御手段は、
    前記許可希望メッセージ配信管理状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記許可希望状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した許可希望状態データの情報を含ませたメッセージを配信し、
    前記確認メッセージ配信管理状態の問い合わせがあった場合、この問い合わせメッセージの前記メッセージパターンデータと、前記確認状態データとに基づき、前記問い合わせ元の処理装置へ向け、前記取得した確認状態データの情報を含ませたメッセージを配信することを特徴とするメッセージ配信管理システム。
  26. メッセージの配信管理を行うための通知管理データ、要求応答管理データおよび確認許可管理データを用い、通信路に接続されたメッセージ配信管理手段を介して複数の処理装置間において、
    状態変化の通知を示す通知メッセージおよびこの通知メッセージの受信希望を示す通知希望メッセージを含む通知型メッセージと、
    情報の問い合わせを示す要求メッセージ、この要求メッセージに対する応答希望を示す応答希望メッセージおよび前記要求メッセージに対する応答を示す応答メッセージを含む要求応答型メッセージと、
    イベントの実行に対する許可を得るための確認を示す確認メッセージ、この確認メッセージに対する許可付与の希望を示す許可希望メッセージおよび前記確認メッセージに対する許可、不許可を示す許可メッセージを含む確認許可型メッセージの送受信を行うネットワークにおけるメッセージ配信管理方法であって、
    状態変化の通知を行う通知工程と、
    情報の問い合わせと回答を行う要求応答工程と、
    イベントの実行に対する確認と許可を行う確認許可工程と、
    を含み、
    前記通知工程は、
    前記複数の処理装置から送信される状態変化の通知を希望する通知希望メッセージを受信する通知希望受信工程と、
    前記通知希望メッセージを管理データ記憶手段に記憶する通知希望記憶工程と、
    前記複数の処理装置から送信される前記通知メッセージを受信する通知受信工程と、
    前記通知メッセージを前記管理データ記憶手段に記憶する通知記憶工程と、
    前記配信制御手段により、前記管理データ記憶手段に記憶された通知メッセージと、前記管理データ記憶手段に記憶された通知希望メッセージとを比較する通知比較工程と、
    前記通知メッセージと、前記通知希望メッセージとが対応するものである場合、前記通知希望メッセージを送信した処理装置へ向け前記通知メッセージを配信する通知メッセージ配信工程と、
    を含み、
    前記要求応答工程は、
    前記複数の処理装置から送信される情報の問い合わせの応答を希望する応答希望メッセージを受信する応答希望受信工程と、
    前記応答希望メッセージを送信した処理装置に対して所定の条件で応答権を付与する応答権付与工程と、
    前記応答希望メッセージを前記管理データ記憶手段に記憶する応答希望記憶工程と、
    前記複数の処理装置から送信される情報の問い合わせの応答を要求する要求メッセージを受信する要求受信工程と、
    前記要求メッセージを前記管理データ記憶手段に記憶する要求記憶工程と、
    前記配信制御手段により、前記管理データ記憶手段に記憶された要求メッセージパターンデータと、前記管理データ記憶手段に記憶された応答希望メッセージパターンデータとを比較する要求応答比較工程と、
    前記要求メッセージパターンデータと、前記応答希望メッセージパターンデータとが対応するものである場合、前記応答希望メッセージを送信し、前記応答権を付与された処理装置へ向け前記要求メッセージを配信する要求メッセージ配信工程と、
    前記要求メッセージを配信した処理装置から応答メッセージを受信し、前記要求メッセージを送信した処理装置へ向け配信する応答メッセージ配信工程と、
    を含み、
    前記確認許可工程は、
    前記処理装置から送信される前記許可希望メッセージを受信する許可希望受信工程と、
    この許可希望メッセージを前記管理データ記憶手段に記憶する許可希望記憶工程と、
    前記処理装置から送信される確認メッセージを受信する確認受信工程と、
    この確認メッセージを前記管理データ記憶手段に記憶する確認記憶工程と、
    前記配信制御手段により、前記管理データ記憶手段に記憶された確認メッセージと、前記管理データ記憶手段に記憶された許可希望メッセージとを比較する確認許可比較工程と、
    前記確認メッセージと、前記許可希望メッセージとが対応するものである場合、前記許可希望メッセージを送信した処理装置へ向け前記確認メッセージを配信する確認メッセージ配信工程と、
    前記確認メッセージを配信した処理装置から前記許可メッセージを受信する工程と、
    前記確認メッセージを送信した処理装置へ向け前記受信した許可メッセージを配信する許可メッセージ配信工程と、
    を含むことを特徴とするメッセージ配信管理方法。
  27. 複数の処理装置が存在するネットワーク上において、
    状態変化の通知を示す通知メッセージおよびこの通知メッセージの受信希望を示す通知希望メッセージを含む通知型メッセージと、
    情報の問い合わせを示す要求メッセージ、この要求メッセージに対する応答希望を示す応答希望メッセージおよび前記要求メッセージに対する応答を示す応答メッセージを含む要求応答型メッセージと、
    イベントの実行に対する許可を得るための確認を示す確認メッセージ、この確認メッセージに対する許可付与の希望を示す許可希望メッセージおよび前記確認メッセージに対する許可、不許可を示す許可メッセージを含む確認許可型メッセージの送受信を行うメッセージ配信管理手段として、前記ネットワークに接続されたコンピュータを機能させるためのプログラムが記録された情報記録媒体であって、
    前記メッセージ配信管理手段は、
    各メッセージの配信管理を行うための通知管理データ、要求応答管理データおよび確認許可管理データを含む管理データが記憶される管理データ記憶手段と、
    受信メッセージに基づき、前記管理データの作成を行う管理データ制御手段と、
    前記管理データに基づき、受信メッセージを所定の処理装置へ向け配信する配信制御手段と、
    を含んで構成され、
    前記管理データ制御手段は、
    前記通知希望メッセージを受信した場合に、通知希望元の処理装置へ向け前記状態変化の通知を行うための前記通知管理データを作成し、
    前記応答希望メッセージを受信した場合に、前記応答希望メッセージ送信元の処理装置へ向け前記要求メッセージの配信を行い、前記要求メッセージを受信した場合に、前記要求メッセージ送信元の処理装置へ向け前記応答メッセージの配信を行うための前記要求応答管理データを作成し、
    前記確認メッセージを受信した場合に、前記許可希望メッセージ送信元の処理装置へ向け前記確認メッセージの配信を行い、前記許可メッセージを受信した場合に、前記確認メッセージ送信元の処理装置へ向け前記許可メッセージの配信を行うための前記確認許可管理データを作成し、
    前記配信制御手段は、
    前記通知メッセージを受信した場合に、前記通知管理データに基づき前記通知希望処理装置へ向け前記通知メッセージを配信し、
    前記要求メッセージを受信した場合に、前記要求応答管理データに基づき前記応答希望メッセージ送信元の処理装置へ向け前記要求メッセージを配信し、前記応答希望メッセージ送信元の処理装置から前記応答メッセージを受信した場合に、前記要求応答管理データに基づき前記要求メッセージ送信元の処理装置へ向け前記応答メッセージを配信し、
    前記確認メッセージを受信した場合に、前記確認許可管理データに基づき前記許可希望メッセージ送信元の処理装置へ向け前記確認メッセージを配信し、前記許可希望メッセージ送信元の処理装置から前記許可メッセージを受信した場合に、前記確認許可管理データに基づき前記確認メッセージ送信元の処理装置へ向け前記許可メッセージを配信することを特徴とする情報記録媒体。
JP36443997A 1997-12-18 1997-12-18 メッセージ配信管理システムおよび方法並びに情報記録媒体 Expired - Fee Related JP3622467B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP36443997A JP3622467B2 (ja) 1997-12-18 1997-12-18 メッセージ配信管理システムおよび方法並びに情報記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP36443997A JP3622467B2 (ja) 1997-12-18 1997-12-18 メッセージ配信管理システムおよび方法並びに情報記録媒体

Publications (2)

Publication Number Publication Date
JPH11187018A JPH11187018A (ja) 1999-07-09
JP3622467B2 true JP3622467B2 (ja) 2005-02-23

Family

ID=18481814

Family Applications (1)

Application Number Title Priority Date Filing Date
JP36443997A Expired - Fee Related JP3622467B2 (ja) 1997-12-18 1997-12-18 メッセージ配信管理システムおよび方法並びに情報記録媒体

Country Status (1)

Country Link
JP (1) JP3622467B2 (ja)

Also Published As

Publication number Publication date
JPH11187018A (ja) 1999-07-09

Similar Documents

Publication Publication Date Title
US5890139A (en) Answering method and system in online shopping
US20030055668A1 (en) Workflow engine for automating business processes in scalable multiprocessor computer platforms
US7844659B2 (en) Process integration persistency
KR100248525B1 (ko) 에이전트 기능을 가진 그룹웨어 시스템
US7590597B2 (en) Electronic business transaction system
JP2721672B2 (ja) データ処理を複数の制御位置にわたって分散させるための装置
CN101471896B (zh) 中继服务器和中继通信系统
US20150046275A1 (en) System and method for programming point of sale devices
JP2005521974A (ja) コンピュータシステムにて、承認の要求を呈示する方法、コンピュータメモリ、およびコンピュータシステム
JP2861176B2 (ja) オンライン業務監視装置
US20020069121A1 (en) Supply assurance
JPH09505918A (ja) 一群のデータからデータを抽出する方法および装置
JPH10222409A (ja) 分散データ管理システム
US7133913B2 (en) Information routing
JP5984355B2 (ja) 分散型データベースシステムおよび分散型データ処理システム
CN114416769A (zh) 待办任务查询方法、装置及电子设备
JP3622467B2 (ja) メッセージ配信管理システムおよび方法並びに情報記録媒体
JP3666221B2 (ja) メッセージ配信管理システムおよび方法並びに情報記録媒体
US20020091590A1 (en) Fundraising system with creation, coordination, and order tracking tools
JP3695110B2 (ja) メッセージ配信管理システムおよび方法並びに情報記録媒体
CN103403743A (zh) 便携终端管理服务器和便携终端管理程序
JP4121344B2 (ja) ライセンス管理装置、方法及びプログラム
KR20090090047A (ko) Rfid 비즈니스 인식 프레임워크
JP2002203096A (ja) 販売支援システムおよび方法
JP3801680B2 (ja) 分散処理システムにおけるデータベースの情報収集システム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20041018

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: 20041102

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20041115

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081203

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091203

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101203

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101203

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111203

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111203

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121203

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121203

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131203

Year of fee payment: 9

LAPS Cancellation because of no payment of annual fees