JP2005284962A - 管理サーバ、管理方法及び管理プログラム - Google Patents

Abstract

【課題】 分散型システムのウェブサービスに対応する管理サーバ、管理方法及び管理プログラムを提供する。
【解決手段】
管理システム１００は、機能排他管理部１１、バッチ処理管理部１２、機能情報管理部１３、情報排他管理部１４及び排他記憶部１５等を備える管理サーバ１と、クライアント端末２ａ〜２ｅ等から構成され、機能排他管理部１１は、機能排他処理部１１ａ及び機能排他解除処理部１１ｂを備え、バッチ処理管理部１２は、バッチ即時起動要求部１２ａ、バッチ起動要求部１２ｂ、バッチ再起動要求部１２ｃ等を備え、機能情報管理部１３は機能及び情報を管理し、情報排他管理部１４は、情報排他部１４ａ等を備え、排他記憶部１５は、起動管理パラメータ情報記憶部１５ａ、起動機能管理情報記憶部１５ｂ、バッチ要求管理情報記憶部１５ｃ及び情報排他管理情報記憶部１５ｄを備える。
【選択図】 図１

Description

本発明は、分散型システムのウェブサービスにおける排他制御処理を行う管理サーバ、管理方法及び管理プログラムに関する。

近年、システムを運用していく上でデータ操作時の排他制御は不可欠な要素となっている。データ操作時の排他制御を行なう場合、操作するデータに対して排他を行なう制御（以下「情報排他」と記載）とデータを操作するアプリケーション機能に対して排他を行なう制御（以下「機能排他」と記載）があり、従来は情報排他と機能排他はそれぞれ別々の制御機能として開発され、利用側でも別々のインタフェースを設定して利用してきた。

例えば、複数のアプリケーションによる複数の共通プロセスの排他的使用方法（特許文献１参照。）や、共有リソースの排他制御装置等がある（特許文献２参照。）。
特開２０００−２０３２２号公報 特開２０００−３２８７号公報

しかしながら、従来の通信ネットワークにより結合された分散したサーバ間での排他については相手側の動作環境に合わせたインタフェースを使用せねばならず、サーバ間で排他利用の効率を下げていた。

又、通信ネットワークを介した計算機間での通信プロトコルの性能では満足のいく通信性能と情報の信頼性を得ることに限界があった。

本発明は、上記問題点を解決する為になされたものであり、分散型システムにおいて、データ排他、機能排他をウェブサービスを介して集中型の排他制御を行い、通信性能及び情報信頼性を向上することができる、管理サーバ、管理方法及び管理プログラムを提供することを目的とする。

上記問題点を解決する為、本発明の第１の特徴は、(イ)クライアント端末からの機能若しくは情報の要求を受けた際に機能若しくは情報の排他制御を行なう管理サーバであって、機能の管理に必要なデータを格納する起動機能管理情報記憶部及び情報の管理に必要なデータを格納する情報排他管理情報記憶部を有する排他記憶部と、（ロ）複数のクライアント端末より機能の使用要求を依頼された時の排他制御として機能のバッチ処理を行なうバッチ処理管理部と、（ハ）クライアント端末より機能の使用要求を受信すると起動機能管理情報記憶部のデータを基に機能が使用可能か否かを判断し、使用可能な場合には使用要求毎に管理番号を発番して実行する機能の起動情報を起動機能管理情報記憶部に登録し、使用不可能な場合にはバッチ処理管理部にバッチ処理の依頼を行なう機能排他処理部及び機能の処理終了の検知若しくはクライアント端末からの機能の排他解除の要求を受信すると管理番号を基に起動機能管理情報記憶部を検索し管理番号に該当する情報の削除を行なう機能排他管理部と、（ニ）クライアント端末より情報の使用状態の調査を受信すると情報管理情報記憶部を検索して情報が使用可能であるかを判定し、使用可能と判定された場合には情報排他管理情報記憶部内の情報を情報排他に更新して更新毎に管理番号の発番を行なう情報排他処理部及びクライアント端末より情報排他の解除の要求を受信すると情報排他管理情報記憶部内の管理番号に該当する情報の削除を行なう情報排他解除部を有する情報排他管理部とを備える管理サーバであることを要旨とする。

本発明の第２の特徴は、（イ）機能及び情報を管理し、クライアント端末からの使用要求により機能若しくは情報を送信する機能情報管理部と、（ロ）機能の管理に必要なデータを格納する起動機能管理情報記憶部及び情報の管理に必要なデータを格納する情報排他管理情報記憶部を有する排他記憶部、複数のクライアント端末より機能の使用要求を依頼された時の排他制御として機能のバッチ処理を行なうバッチ処理管理部と、（ハ）クライアント端末より機能の使用要求を受信すると起動機能管理情報記憶部のデータを基に機能が使用可能か否かを判断し、使用可能な場合には使用要求毎に管理番号を発番して実行する機能の起動情報を起動機能管理情報記憶部に登録し、クライアント端末に機能情報管理部が管理する機能の使用を許可し、使用不可能な場合にはバッチ処理管理部にバッチ処理の依頼を行なう機能排他処理部及び機能の処理終了の検知もしくはクライアント端末からの機能の排他解除の要求を受信すると管理番号を基に起動機能管理情報記憶部を検索し管理番号に該当する情報の削除を行なう機能排他管理部と、（ニ）クライアント端末より情報の使用状態の調査を受信すると情報管理情報記憶部を検索して情報が使用可能であるかを判定し、使用可能と判定された場合には情報排他管理情報記憶部内の情報を情報排他に更新して更新毎に管理番号の発番を行ない、クライアント端末に機能情報管理部が管理する情報の使用を許可する情報排他処理部と、（ホ）クライアント端末より情報排他の解除の要求を受信すると情報排他管理情報記憶部内の管理番号に該当する情報の削除を行なう情報排他解除部を有する情報排他管理部とを備える管理サーバであることを要旨とする。

本発明の第３の特徴は、（イ）クライアント端末から機能若しくは情報の使用要求を受けた際に排他制御を行なう管理方法であって、複数のクライアント端末より機能の使用要求を依頼された時の排他制御としてバッチ処理管理部が機能のバッチ処理を行なうステップと、（ロ）クライアント端末より機能の使用要求を受信すると起動機能管理情報記憶部のデータを基に機能が使用可能か否かを判断し、使用可能な場合には使用要求毎に管理番号を発番して実行する機能の起動情報を起動機能管理情報記憶部に登録してクライアント端末に機能情報管理部が管理する機能の使用を許可し、使用不可能な場合にはバッチ処理管理部にバッチ処理の依頼を行なうステップと、（ハ）クライアント端末より機能の排他解除の要求を受信すると管理番号を基に起動機能管理情報記憶部を検索し管理番号に該当する情報の削除を行なうステップと、（ニ）クライアント端末より情報の使用状態の調査を受信すると情報管理情報記憶部を検索して情報が使用可能であるかを判定し、使用可能と判定された場合には情報排他管理情報記憶部内の情報を情報排他に更新して更新毎に管理番号の発番を行ない、クライアント端末に機能情報管理部が管理する情報の使用を許可するステップと、（ニ）機能の処理終了の検知もしくはクライアント端末からの情報排他の解除の要求を受信すると情報排他管理情報記憶部内の管理番号に該当する情報の削除を行なうステップとを有する管理方法であることを要旨とする。

本発明の第４の特徴は、（イ）機能及び情報を管理する機能情報管理部に、クライアント端末から機能若しくは情報の使用要求を受けた際に排他制御を行なうコンピュータに、複数のクライアント端末より機能の使用要求を依頼された時の排他制御としてバッチ処理管理部が機能のバッチ処理を行なう命令と、（ロ）クライアント端末より機能の使用要求を受信すると起動機能管理情報記憶部のデータを基に機能が使用可能か否かを判断し、使用可能な場合には使用要求毎に管理番号を発番して実行する機能の起動情報を起動機能管理情報記憶部に登録してクライアント端末に機能情報管理部が管理する機能の使用を許可し、使用不可能な場合にはバッチ処理管理部にバッチ処理の依頼を行なう命令と、（ハ）クライアント端末より機能の排他解除の要求を受信すると管理番号を基に起動機能管理情報記憶部を検索し管理番号に該当する情報の削除を行なう命令と、（ニ）クライアント端末より情報の使用状態の調査を受信すると情報管理情報記憶部を検索して情報が使用可能であるかを判定し、使用可能と判定された場合には情報排他管理情報記憶部内の情報を情報排他に更新して更新毎に管理番号の発番を行ない、クライアント端末に機能情報管理部が管理する情報の使用を許可する命令と、（ホ）機能の処理終了の検知もしくはクライアント端末からの情報排他の解除の要求を受信すると情報排他管理情報記憶部内の管理番号に該当する情報の削除を行なう命令とを実行させる管理プログラムであることを要旨とする。

本発明の管理サーバ、管理方法及び管理プログラムによると、クライアント側において排他制御の為のインタフェースの使い分けを意識することなく、情報排他及び機能排他を行なうことができる。情報排他及び機能排他が同サーバ内で高速に行なわれる為、通信網を介したクライアント端末及び管理サーバ間の排他制御のネットワーク通信効率を向上させることができる。

管理システムにおいては、ウェブサービスには全てＸＭＬ（エクステンシブル・マークアップ・ラングエッジ）言語を使用する為データ解析、エラー解析が容易で、通信網を介したクライアント端末及び管理サーバ間での排他制御性能を向上させることができる。

次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。ただし、図面は模式的なものであることに留意すべきである。

（実施の形態）
（管理システム）
本発明の実施の形態における管理システム１００は、図１に示すように、管理しているアプリケーション機能及び情報を、クライアント側の複数のクライアント端末２ａ，２ｂ，２ｃ，２ｄ，２ｅにおいて使用する際に発生するデッドロック等を防ぐ為の排他処理を行なうシステムである。このシステムは、管理サーバ１、クライアント端末２ａ〜２ｅ等から構成される。管理サーバ１は、通信網５によって他の管理サーバ等の通信装置と接続されている。尚、管理サーバ１及びクライアント端末２ａ〜２ｅは複数存在し、通信網５に接続されていて構わない。

クライアント端末２ａ〜２ｅは、管理サーバ１のクライアント端末であり、管理サーバ１に排他チェック、排他管理の依頼を行なったり、クライアント端末として運用管理に使用したりする。尚、管理サーバ１とクライアント端末２ａ〜２ｅ間は、通信網５を介して接続されても良い。

通信網５は、管理サーバ１が他の通信装置に対して情報を送受信する為のネットワークであり、具体的に、ＬＡＮ、ＷＡＮ、インターネット回線、公衆回線等を指す。

管理サーバ１は、クライアント端末２ａ〜２ｅへ対し情報若しくは機能に関する依頼を行なう際の排他処理をウェブサービスとして行なう。管理サーバ１は、図１に示すように、機能排他管理部１１、バッチ処理管理部１２、機能情報管理部１３、情報排他管理部１４及び排他記憶部１５等を備えている。

排他記憶部１５は、起動管理パラメータ情報記憶部１５ａ、起動機能管理情報記憶部１５ｂ、バッチ要求管理情報記憶部１５ｃ及び情報排他管理情報記憶部１５ｄ等より構成される。

機能情報管理部１３は、複数存在するクライアント端末２ａ〜２ｅが必要とする情報及び機能を集中管理する装置であり、機能を記憶する機能記憶装置４ａ、情報を記憶する機能記憶装置４ａ、機能記憶装置４ａ及び機能記憶装置４ａへのデータアクセスを管理するデータ管理部３等を備えている。

起動管理パラメータ情報記憶部１５ａは、起動処理に必要なパラメータを保持し、図３に示すように、クラス名、排他クラス名、同時起動数、動作種別、排他種別、起動場所、更新日付等の項目より構成される。

起動機能管理情報記憶部１５ｂは、機能を起動及び管理するのに必要なデータを保持し、図４に示すように、管理番号、所属コード、起動元端末番号、クラス名、プロセスＩＤ、処理状態フラグ、処理開始日時、更新日付等の項目より構成される。

バッチ要求管理情報記憶部１５ｃは、バッチ処理を管理する為のデータを保持し、図５に示すように、管理番号、所属コード、起動元端末番号、クラス名、起動条件、処理状態フラグ、バッチ処理ステータス、起動要求日時、即時起動ステータス、要求取消ステータス、排他所属コード、排他端末番号、排他クラス名、更新日時等の項目より構成される。

情報排他管理情報記憶部１５ｄは、情報排他を管理するのに必要なデータを保持し、図６に示すように、所属コード、排他区分、排他キー情報、管理番号、起動元端末番号、クラス名、プロセスＩＤ、更新日時等の項目より構成される。

機能排他管理部１１は、機能排他に関する処理を行なう機能排他処理部１１ａ及び機能排他の解除に関する処理を行なう機能排他解除処理部１１ｂ等を備えている。

機能排他処理部１１ａは、管理サーバ１で動作するバッチ機能のプロセスや画面機能のプロセスが共に動作する環境の中で、排他関係にあるプロセス同士の同時実行を抑制するため、プロセス開始する前段階で動作可能か判定を行い、プロセスが使用するデータ破壊または不整合等を事前に防ぐための処理をウェブサービスとして行なう。例えば、クライアント端末２ａ〜２ｅより起動される画面機能やバッチ機能、管理サーバ１側で動作するバッチ機能に対して、それぞれのプロセスが実行可能か判定を行い、実行可能な状態の場合には、管理番号の発番をバッチ起動管理部１２ｆに依頼して実行するプロセスの実行情報を起動機能管理情報記憶部１５ｂに登録し、受付番号は要求元のクライアント端末２ａに返却する。又、実行不可能な状態の場合にはクライアント端末２ａに排他原因である情報の通知を行なう。

機能排他解除処理部１１ｂは、画面機能またはバッチ機能が終了する際、起動機能管理情報記憶部１５ｂ内で管理される自身のプロセス情報の解除をウェブサービスとして行なう。また、解除することによって動作可能となるプロセス情報の検索を起動機能管理情報記憶部１５ｂ内にて行い、存在する場合には該当するプロセス情報の処理状態を更新し、バッチ再起動要求部１２ｃへ開始要求の通知を行なう。

バッチ処理管理部１２は、機能排他処理部１１ａにてプロセスが実行可能と判定されると、画面機能やサーバ機能におけるデータ更新処理など直ちに実行を必要とする起動要求（以下「即時起動要求」と記載）と、サーバ機能でも帳票出力などの要求のみ受け付けて実行可能な際に処理を動作する要求（以下「起動要求」と記載）とを判別し、これら２つの要求をウェブサービスとして管理する。バッチ処理管理部１２は、バッチ即時起動要求部１２ａ、バッチ起動要求部１２ｂ、バッチ再起動要求部１２ｃ、バッチ監視部１２ｄ、バッチ要求取消部１２ｅ及びバッチ起動管理部１２ｆ等を備えている。

バッチ即時起動要求部１２ａは、起動受付要求のあったプロセスが機能排他チェックの結果により実行可能と判定された場合に、即時起動要求を行なう。実行不可と判定された場合には、即時起動要求の情報を受付順にバッチ要求管理情報記憶部１５ｃへ登録し、再起動のタイミングを計る。この処理は、クライアント側の要求順や複数プロセスを時系列に動作させるなどの順序性を持たせた起動制御に有効となる。バッチ起動要求部１２ｂは、通常の起動要求を行い、実行可能な際に所定の機能を動作させるよう要求する。

バッチ再起動要求部１２ｃは、同時起動数の制限または機能排他により処理待ちとなっているバッチ処理の再起動を行なう。

バッチ監視部１２ｄは、バッチ処理の起動要求又は即時起動要求のあったバッチ処理の状態を監視し、要求の都度、その状態の通知を行なう。

バッチ要求取消部１２ｅは、起動要求のあったバッチ処理が、排他待ち、要求受付等の処理待ち状態である場合、バッチ起動要求の取消を行なう。

バッチ起動管理部１２ｆは、起動要求が行なわれるとバッチ要求管理情報記憶部１５ｃより、処理状態フラグが要求受付となっている起動情報を検索し、該当するレコードが存在した場合、機能排他チェックを行い実行可能状態か判定する。処理結果が実行可能になった場合、バッチ処理管理部１２に該当するプロセスの起動制御を依頼する。

情報排他管理部１４は、情報データの排他処理を管理するための部で、情報排他部１４ａ、情報排他解除部１４ｂ及び情報排他一括解除部１４ｃ等を備えている。

情報排他部１４ａは、画面処理やバッチ処理として動作するプロセスにおいて、各プロセスが使用する情報データに対しての排他処理を行なう。例えば、人事管理情報等の場合、人の情報データは固有のものである為、その情報データを使用して動作するプロセスにおいて、必ず情報データに対して排他をかけ、他のプロセスで更新出来ないように管理する。

情報排他部１４ａは、情報排他管理情報記憶部１５ｄの情報を基に、情報データに対しての排他処理を行なう。情報排他解除部１４ｂは、情報データ排他の解除を行なう。情報排他一括解除部１４ｃは、情報データ排他の一括解除を行なう。

尚、管理サーバ１は、図２のハードウェア構成を有しており、セントラルプロセッシングユニット（以下「ＣＰＵ」と記載）５５、入力装置５１、出力装置５２、通信インタフェース５６、通信制御装置５７、主記憶装置５３及び補助記憶装置５４等から構成される。ＣＰＵ５５は、通常のサーバ処理に加え、図１の機能排他管理部１１、バッチ処理管理部１２及び情報排他管理部１４等を備えている。ＣＰＵ５５がこれらのモジュールを適宜演算処理することにより、排他管理の動作は実行される。

入力装置５１は、キーボード、マウス等から入力信号を受信するインタフェースである。フロッピー（登録商標）ディスク、ハードディスク等の外部記憶装置を介して入力されても良い。出力装置５２は、処理結果等を出力するための装置であり、具体的には液晶ディスプレイ、ＣＲＴディスプレイ、プリンタ等を指す。通信インタフェース５６は、他装置間においてデータを送受信するための装置である。通信制御装置５７は、他装置に対しデータを送受信する為の制御信号を生成する。主記憶装置５３は、主メモリとして、処理の手順を記述したプログラムや処理されるべきデータを一時的に記憶し、ＣＰＵ５５の要請に従ってプログラムの機械命令やデータを引き渡す。又、ＣＰＵ５５で処理されたデータは主記憶装置５３に書き込まれる。主記憶装置５３とＣＰＵ５５はアドレスバス、データバス、制御信号等で結ばれている。

（管理サーバの動作）
以下、管理サーバ１の全体動作について図７のフローチャートを参照して説明する。

（ａ）先ず、ステップＳ１０１において、図１の機能排他処理部１１ａが、クライアント端末２ａより画面処理排他チェック等の機能を使用する要求を受信すると、ステップＳ１０２において機能排他処理部１１ａは、起動管理パラメータ情報記憶部１５ａより起動処理に必要なパラメータを取得する。更に、ステップＳ１０３において、起動機能管理情報記憶部１５ｂより使用する要求の有った機能が使用中か否かを判断する情報を取得する。

（ｂ）ステップＳ１０４では、機能排他処理部１１ａは、バッチ処理管理部１２に対しバッチ起動の依頼をする。バッチ処理管理部１２は、使用する機能には即時起動要求と起動要求のいずれが適用されるか判断し、即時起動要求の場合はバッチ即時起動要求部１２ａに対してバッチの即時起動要求を送信し、起動要求の場合はバッチ起動要求部１２ｂに対してバッチの起動要求を送信する。バッチ即時起動要求部１２ａ又はバッチ起動要求部１２ｂは、各々バッチ処理の起動を行い、必要に応じてバッチ監視部１２ｄによるバッチ処理の監視や、バッチ要求取消部１２ｅによるバッチ要求の取消等を行なう。詳細については後述する。又、機能排他処理部１１ａは、バッチ起動管理部１２ｆにバッチ起動の為の排他命令を送信し、起動機能管理情報記憶部１５ｂに機能起動情報を書き込む。

（ｃ）ステップＳ１０５において、機能排他解除処理部１１ｂが、クライアント端末２ｂ若しくは管理サーバ１の内部プログラムより、ある機能の排他解除要求を受信すると、機能排他解除処理部１１ｂは、バッチ起動管理部１２ｆに排他解除の命令を出し、バッチ要求管理情報記憶部１５ｃに排他解除を登録し、更に、起動機能管理情報記憶部１５ｂの機能起動情報を使用可に更新する。

（ｄ）ステップＳ１０６において、情報排他管理部１４が情報排他のチェック要求をクライアント端末２ｃより受信すると、情報排他部１４ａが、情報排他管理情報記憶部１５ｄの情報を基に、情報排他処理の使用状態の検索処理を行なう。検索の結果、該当する情報が使用可能であれば、管理サーバ１はクライアント端末２ｃの機能情報管理部１３への接続を許可し、クライアント端末２ｃはこの情報を使用する。この間、情報排他管理部１４による情報排他処理が行なわれる。

（ｅ）ステップＳ１０７において、情報排他解除若しくは情報排他一括解除の要求をクライアント端末２ｄ若しくは管理サーバ１の内部プログラムより受信すると、情報排他解除部１４ｂが情報排他の解除処理を行い、若しくは、情報排他一括解除部１４ｃが情報排他の一括解除処理を行なう。詳細は後述する。尚、情報排他の解除処理及び一括解除処理の情報は情報排他管理情報記憶部１５ｄ内に登録される。

尚、ステップＳ１０１〜Ｓ１０５では機能排他処理、ステップＳ１０６〜Ｓ１０７では情報排他処理について述べているが、実際の処理はこの順序に規定されることはなく、例えば機能排他処理と情報排他処理が同時に実行されても構わない。

説明上、管理サーバ１に対し所定の要求を行なうクライアント端末２ａ〜２ｅを複数存在させているが、要求はどのクライアント端末からでも送信することが出来、更にクライアント端末は１つ以上存在すればよい。

上記のように、管理システム１００においては、管理サーバ１に対して複数の排他要求が一斉に発生した場合に、排他制御機能内で処理の直列化を行い、排他要求が複数同時かけられてしまう状況を回避する。

機能排他では、同一プロセスの同時起動最大数を設けることにより複数発生した同一プロセスの起動要求に対して、受け付けた起動要求を全て登録し同時起動最大数を超えない制御と、プロセスの終了毎に終了した数分、登録された未起動プロセスを起動する。

情報排他では、排他対象データ項目の複数指定及び一括での排他解除を行なう。

（機能排他処理部の動作）
次に、ステップＳ１０１の機能排他処理部１１ａの動作について図８のフローチャートを用いて詳細に説明する。

（ａ）ステップＳ２０１において、図１の機能排他処理部１１ａが、クライアント端末２ａより画面処理排他チェック等の機能を使用する要求を受信すると、機能要求の受付処理が行われる。機能排他処理部１１ａと排他要求を行なうプロセス間のインタフェースとしては、「端末番号」、「クラス名」、「管理番号」、「プロセスＩＤ」、「所属コード」等を使用する。尚、これらのインタフェースは全てＸＭＬ言語にて記述される。

「端末番号」には、要求元のクライアント端末２ａの番号を設定する。この番号は要求情報として、排他情報をクライアントに公開する場合にどのクライアント端末から要求されたプロセスかを特定する場合に使用する。「クラス名」は、排他判定の対象となる機能のＩＤである。「管理番号」は、機能排他処理部１１ａがバッチ起動管理部１２ｆへ管理番号発番を依頼することにより作成され、管理サーバ１の立ち上げ時より終了する間、静的領域として確保された主記憶装置５３の一部において記憶される。

管理番号の構成は、年（４桁）＋月（２桁）＋日（２桁）＋時（２４時間表記、２桁）＋連番（５桁）＋ウェブサーバの端末名（１５桁）とする。連番の発番は、要求時刻の時に対し初期値を１から９９９９９までを範囲とし、時が変わった場合に再度１から発番を行なう。この管理番号構成により、機能排他を管理システム１００内で一元管理する。

「プロセスＩＤ」は、端末番号に該当するプロセスの内部番号（オペレーティングシステムにより個々に付与される番号）である。

「所属コード」は、プロセスの実行環境に属する所属コード、例えば支社や支店等グループ内の一意のコードである。所属コードが設定された場合には、同一の所属コードが設定されている実行プロセスが対象、所属コードが設定されていない場合は、全ての実行プロセスを対象となる。

（ｂ）ステップＳ２０２においては、排他判定処理が行なわれる。機能排他処理部１１ａは、クラス名より図３の起動管理パラメータ情報記憶部１５ａから排他対象となる排他クラス名を取得し、取得したクラス名が起動機能管理情報記憶部１５ｂ内に存在するか判定を行なう。排他対象となるクラス名が存在する場合には実行不能として要求元のクライアント端末２ａにその情報を返却する。

実行可能と判定した場合、機能排他処理部１１ａはクラス名に対する同時起動数判定を行なう。同時起動数は図４の起動管理パラメータ情報記憶部１５ａ内に持ち、クラス名に対し起動数制約（例えば１つのみ実行可能，３つまで実行可能等）を付与する。

更に、同じクラス名を持つプロセスの実行数を図４の起動機能管理情報記憶部１５ｂより求め、実行数が同時起動数に達していない場合は、実行可能と判定し、管理サーバ１は、機能情報管理部１３に情報の送信を依頼し、要求元クライアント端末２ａにその情報を返却する。その際、起動機能管理情報記憶部１５ｂ内にクラス名に対するプロセス情報の登録を行なう。

尚、同時起動数に達している場合、実行待ちとして判定し要求元クライアント端末２ａにその情報を返却する。その際、図５のバッチ要求管理情報記憶部１５ｃに実行待ちとなった情報を登録する。

（ｃ）ステップＳ２０３においては、機能排他処理部１１ａは、排他判定処理の結果より要求元クライアント端末２ａに結果通知を行なう。結果通知では、図９に示すように、各々の処理結果を戻り値として返す。

（機能排他解除処理部の動作）
ステップＳ１０５の機能排他解除処理部１１ｂの動作について図１０のフローチャートを用いて詳細に説明する。

（ａ）先ずステップＳ３０１において、クライアント端末２ｂより機能排他解除の要求を受信すると、機能排他解除処理部１１ｂは、機能排他解除要求の受付処理を行なう。尚、機能排他解除の受付においてにて使用するインタフェースは、「端末番号」、「クラス名」、「管理番号」、「プロセスＩＤ」等とする。尚、これらはステップＳ２０１において機能排他処理部１１ａが設定したものと同一である。

（ｂ）ステップＳ３０２においては、排他解除処理として、クライアント端末２ｂより機能排他解除処理部１１ｂに渡された引数情報より、管理番号を使用して図４の起動機能管理情報記憶部１５ｂで設定されている対象レコードを検索する。更に検索結果により対象レコードの処理状態フラグの更新を行なう。また、同じ管理番号で図５のバッチ要求管理情報記憶部１５ｃを検索し、該当する情報が有る場合はその情報の削除を行なう。

（ｃ）ステップＳ３０３においては、機能排他解除処理部１１ｂは、図５のバッチ要求管理情報記憶部１５ｃより処理状態フラグが「排他待ち」になっている情報を検索し、該当する情報が有る場合には、該当する情報が持つ管理番号にてバッチ再起動要求部１２ｃへ開始要求を行なう。

（ｄ）ステップＳ３０４においては、機能排他解除処理部１１ｂは、バッチ要求管理情報記憶部１５ｃより、処理状態フラグが処理待ち若しくは排他待ちになっている情報を検索する。排他待ち状態をこの時点で再チェックするのは、排他待ち情報検索・要求処理の結果により再度排他待ちとなるプロセス情報の発生を考慮している為である。該当する情報が有る場合には、該当する情報が持つ管理番号にてバッチ再起動要求部１２ｃへ開始要求を行なう。

（ｅ）ステップＳ３０５においては、機能排他解除処理部１１ｂは、排他解除処理の結果より、要求元クライアント端末２ｂに結果通知を行なう。結果通知は、図１１に示すように、処理結果が正常であれば「０」、以上であれば「−１」を戻り値として返す。

（バッチ処理管理部の動作）
ステップＳ１０４のバッチ処理管理部１２の動作について図１２のフローチャートを用いて詳細に説明する。

（ａ）ステップＳ４０１においては、バッチ処理管理部１２は、バッチ起動受付要求のあったプロセスが機能排他チェックの結果により実行可能と判定された場合、プロセスの起動処理を行なう。実行不可と判定された場合には、要求情報を受付順にバッチ要求管理情報記憶部１５ｃへ登録し、再起動のタイミングを計る。

この処理は、クライアント側の要求順や複数プロセスを時系列に動作させるなどの順序性を持たせた起動制御に有効となる。例えば、画面機能にて単一データを対象とした帳票出力要求（バッチ要求）が発生したとする。この時クライアント端末２ａが帳票出力を、対象となるデータの範囲を順に要求した等の規則で要求してきた場合、要求順に沿ったかたちで帳票出力を動作させて結果を得る。

バッチ要求受付にて使用するインタフェースは、「端末番号」、「クラス名」、「起動条件」、「所属コード」等から成る。「端末番号」は、要求元のクライアント端末２ａの番号を設定する。この情報は、排他情報をクライアントに公開する場合に、どの端末から要求されたプロセスかを特定する場合に使用する。「クラス名」は、起動要求するクラス名を指す。「起動条件」は、起動要求するクラス名に対する引数情報を指す。「所属コード」は、プロセスの実行環境に属する所属コードを指す。

（ｂ）ステップＳ４０２において、バッチ処理管理部１２は、バッチ起動への管理を起動させるリモート処理として、インターバルタイマーによる時間間隔を例えば１ｍｓ置きながら、バッチ起動管理部１２ｆを呼び出す。

（ｃ）ステップＳ４０３において、バッチ起動管理部１２ｆは、起動要求後、バッチ要求管理情報記憶部１５ｃより、処理状態フラグが要求受付となっている起動情報を検索する。該当するレコードが存在した場合、機能排他チェック処理を呼び出し実行可能状態か判定を行なう。処理結果が実行可能になった場合、バッチ処理起動を呼び出し該当するプロセスの起動制御を行なう。

（ｄ）ステップＳ４０４においては、バッチ要求管理情報記憶部１５ｃの情報より機能排他処理部１１ａを呼び出し、起動要求のプロセスの実行状態を判定する。判定結果は、要求元クライアント端末２ａに戻り値として通知する。

（ｅ）ステップＳ４０５においては、バッチ起動管理部１２ｆは、起動要求のあったプロセスを機能情報管理部１３より取得し、実際に実行させる。この実行制御としては、プロセスの実行から終了までを管理し、プロセスの終了状態をバッチ要求管理情報記憶部１５ｃに更新する。また、終了したプロセスが持つ管理情報を基に、機能排他解除処理部１１ｂを呼び出す。

（ｆ）ステップＳ４０６においては、機能排他解除処理部１１ｂは、バッチ処理実行後にバッチ起動管理部１２ｆより渡された管理番号より、排他情報の削除要求を行なう。この削除要求を基に起動機能管理情報記憶部１５ｂ及びバッチ要求管理情報記憶部１５ｃの排他情報は更新される。

（ｇ）ステップＳ４０７において、バッチ起動管理部１２ｆは、要求元のクライアント端末２ａに排他情報削除の通知を行なう。削除結果の通知としては、図１３のように、処理結果が正常であれば「４」、異常であれば「−１」の戻り値を返す。

（バッチ監視部の動作）
以下、ステップＳ１０４のバッチ監視部１２ｄの動作について詳細に説明する。バッチ監視部１２ｄは、起動要求又は即時起動要求のあったバッチ処理の状態を監視し、その要求の都度、その状態を通知する。バッチ監視部１２ｄにおいては、バッチ起動管理部１２ｆより通知された「管理番号」がインタフェースとして使用される。バッチ監視部１２ｄは、要求元のクライアント端末２ａより取得した管理番号により、バッチ要求管理情報記憶部１５ｃ及び起動機能管理情報記憶部１５ｂを検索し、バッチ処理の状態を要求元クライアント端末２ａに通知する。結果通知の内容は、図１４に示すように設定される。

（バッチ要求取消部の動作）
以下、ステップＳ１０４のバッチ要求取消部１２ｅの動作について詳細に説明する。バッチ要求取消部１２ｅは、起動要求のあったバッチ処理の状態が、排他待ち、要求受付を含む処理待ち状態である場合、バッチ起動要求の取り消しを行なう。バッチ要求取消部１２ｅにおいては、バッチ処理管理部１２より通知された「管理番号」がインタフェースとして使用される。バッチ要求取消部１２ｅは、要求元のクライアント端末２ａより取得した管理番号を基にバッチ要求管理情報記憶部１５ｃを検索し、排他待ち、要求受付等の処理待ち状態のバッチ処理に対して、要求取り消し命令を送り、要求取消しの変更及び更新を行なう。尚、更新操作が終わるまでレコードをロック状態に設定するため、他の処理で更新されないようになる。この更新後、その状態を返り値として要求元に通知する。結果通知の内容は、図１５に示すように設定される。

（バッチ再起動要求部の動作）
以下、ステップＳ１０４のバッチ再起動要求部１２ｃの動作について詳細に説明する。バッチ再起動要求部１２ｃは、同時起動数の制限または機能排他による処理待ちとなっているバッチ処理を再起動させる。バッチ再起動要求部１２ｃは、バッチ起動管理部１２ｆより通知された「管理番号」をインタフェースとして設定する。バッチ再起動要求部１２ｃは、機能排他解除処理部１１ｂの要求により、取得した管理番号により図５のバッチ要求管理情報記憶部１５ｃを検索し、排他待ちを含む処理待ち状態のバッチ処理の処理状態フラグを、要求受付に更新する。なお、更新操作が終わるまでレコードをロック状態に設定するため、他の処理で更新されないようになる。バッチ再起動要求部１２ｃの結果より、要求元クライアント端末２ａに結果通知を行なう。結果通知の内容は、図１６に示すように設定される。

（情報排他管理部の動作）
以下、情報排他管理部１４の情報排他部１４ａ、情報排他解除部１４ｂ及び情報排他一括解除部１４ｃの動作について詳細に説明する。

（情報排他部の動作）
以下、情報排他部１４ａの動作について図１７のフローチャートを参照して詳細に説明する。

（ａ）先ずステップＳ５０１において、クライアント端末２ｃより機能情報管理部１３へ対する情報要求を受けると、情報排他部１４ａは情報排他要求の受け付けを行なう。情報排他部１４ａにおいては、インタフェースとして、「端末番号」、「クラス名」、「プロセスＩＤ」、「排他区分」、「排他キー情報」、「所属コード」等が使用される。このインタフェースにより管理システム１００において情報排他を一元管理する。尚、これらのインタフェースは全てＸＭＬ言語にて記述される。

「端末番号」は、要求元のクライアント端末２ｃの番号を指す。「クラス名」は、情報排他を要求したクラス名を指す。「プロセスＩＤ」は、クラス名に該当するプロセスの内部番号を指す。「排他区分」は、情報排他として設定する内容の分類コードを指す。「排他キー情報」は、情報排他の内容、例えば、文字列による排他の内容とする。排他チェック上、排他分類＋排他キー情報により複数情報に対する排他処理が可能となる。「所属コード」は、プロセスの実行環境に属する所属コードを指す。

（ｂ）ステップＳ５０２において、情報排他部１４ａは、排他区分、排他キー情報等の取得した情報が利用可能であるかを判定するため、図６の情報排他管理情報記憶部１５ｄを検索し、同一情報排他の存在をチェックする。尚、引数で渡された所属コードにより、所属コード内または全体を対象に排他判定を行なうことが可能である。排他判定の結果、処理可能と判定した場合には、情報排他管理情報記憶部１５ｄ内に要求された情報を登録する。また、機能排他処理部１１ａと同様に管理番号の発番を依頼する。尚、クライアント端末２ｃは機能情報管理部１３より所望の情報を取得する。

（ｃ）ステップＳ５０３においては、情報排他部１４ａは、排他判定処理の結果を、要求元クライアント端末２ｃに通知する。結果通知では、図１８に示すように、処理可能の場合、「０」、排他中である場合「１」、異常である場合は「−１」の戻り値を返す。

（情報排他解除部の動作）
以下、情報排他解除部１４ｂの動作について図１９のフローチャートを参照して詳細に説明する。

（ａ）先ずステップＳ６０１において、情報排他解除部１４ｂは、要求元クライアント端末２ｄからの情報排他解除要求の受け付けを行なう。情報排他解除部１４ｂにおいては、インタフェースとして、「端末番号」、「クラス名」、「プロセスＩＤ」、「排他区分」、「排他キー情報」、「所属コード」等が使用される。インタフェースはステップＳ５０１のものと同様である為説明は省略する。

（ｂ）ステップＳ６０２においては、情報排他解除部１４ｂは、排他区分、排他キー情報等の取得した情報を基に、図６の情報排他管理情報記憶部１５ｄを検索し、同一情報のデータを削除する。

（ｃ）ステップＳ６０３において、情報排他解除部１４ｂは、排他解除処理の結果より、要求元クライアント端末２ｄに結果通知を行なう。結果通知では、図２０に示すように、排他解除の場合、「０」、異常である場合は「−１」の戻り値を返す。

（情報排他一括解除部の動作）
以下、情報排他一括解除部１４ｃの動作について図２１のフローチャートを参照して詳細に説明する。

（ａ）先ずステップＳ７０１において、情報排他一括解除部１４ｃは、要求元クライアント端末２ｅからの情報排他一括解除要求の受け付けを行なう。情報排他一括解除部１４ｃにおいては、インタフェースとして、「端末番号」、「クラス名」、「プロセスＩＤ」、「管理番号」等が使用される。「管理番号」は、ステップＳ５０２において情報排他部１４ａより発番され、通知される管理番号である。その他のインタフェースはステップＳ５０１のものと同様である為説明は省略する。

（ｂ）ステップＳ７０２において、情報排他一括解除部１４ｃは、取得した管理番号により情報排他管理情報記憶部１５ｄ内を検索し、同一情報のデータを一括削除する。

（ｃ）ステップＳ７０３において、情報排他一括解除部１４ｃは、排他一括解除処理の結果より、要求元クライアント端末２ｅに結果通知を行なう。結果通知では、図２２に示すように、排他解除の場合、「０」、異常である場合は「−１」の戻り値を返す。

（実施例１）
次に、上述した管理システム１００が、クライアント端末ａ及びクライアント端末ｂから機能排他関係にある機能処理を平行して即時起動した場合について図２３を参照して説明する。尚、以下の実施例では、クライアント端末ａから処理Ａを起動要求し、その後クライアント端末ｂから処理Ｂを即時で起動要求するが、機能排他情報には処理Ａと処理Ｂは同時に起動できない設定がされているものとする。

（ａ）先ずステップＳ１において、クライアント端末ａから処理Ａを起動要求する。ステップＳ２では、機能排他処理部１１ａが機能排他チェックを行なう。結果は、処理Ａに対し機能排他対象となる処理が動作していないため処理Ａの起動が可能となる。

（ｂ）ステップＳ３では、機能排他処理部１１ａが起動結果をクライアント端末ａに返す。処理Ａに対し機能排他対処の処理が動作していないため、起動済みが返される。

（ｃ）ステップＳ４では、クライアント端末ｂから処理Ｂを即時起動要求する。ステップＳ５では、機能排他処理部１１ａが機能排他チェックを行なう。結果は処理Ａが機能排他ロックをかけているため起動失敗となる。

（ｄ）ステップＳ６では、機能排他処理部１１ａが起動結果をクライアント端末ｂに返す。処理Ｂは起動失敗となる。

（実施例２）
次に、管理システム１００が、クライアント端末ａ及びクライアント端末ｂから機能排他関係にある機能処理を平行して起動した場合について図２４を参照して説明する。尚、クライアント端末ａから処理Ａを起動要求、その後クライアント端末ｂから処理Ｂを起動要求する。機能排他情報には処理Ａと処理Ｂが同時に起動できない設定がされている。

（ａ）ステップＳ１１において、クライアント端末ａから処理Ａを起動要求する。ステップＳ１２では、機能排他処理部１１ａが機能排他チェックを行なう。

結果は、処理Ａに対し機能排他対象となる処理が動作していないため処理Ａの起動が可能となる。

（ｂ）ステップＳ１３では、機能排他処理部１１ａが起動結果をクライアント端末ａに返す。処理Ａに対し機能排他対処の処理が動作していないため、起動済みが返される。

（ｃ）ステップＳ１４では、クライアント端末ｂから処理Ｂを起動要求する。ステップＳ１５では、機能排他処理部１１ａが機能排他チェックを行なう。結果は処理Ａが機能排他ロックをかけているため機能排他待ちとなる。

（ｄ）ステップＳ１６では、機能排他処理部１１ａが起動結果をクライアント端末ｂに返す。処理Ｂは機能排他待ちとなる。

（ｅ）ステップＳ１７では、機能排他処理部１１ａが機能排他待ちを行い、処理Ａが終了した後に処理Ｂの起動を行いクライアント端末ｂに処理Ｂ起動済みを返す。

（実施例３）
次に、管理システム１００が、クライアント端末ａ及びｂから同じ機能を平行して起動した場合について図２５を参照して説明する。以下においては、クライアント端末ａから処理Ａを起動要求、その後クライアント端末ｂから処理Ａを起動要求する。機能排他情報には処理Ａは同時に１つしか起動できない設定がされている。

（ａ）先ずステップＳ２１において、クライアント端末ａから処理Ａを起動要求する。ステップＳ２２において、機能排他処理部１１ａが機能排他チェックを行なう。結果は、処理Ａに対し機能排他対象となる処理が動作していないため処理Ａの起動が可能となる。

（ｂ）ステップＳ２３において、機能排他処理部１１ａが起動結果をクライアント端末ａに返す。処理Ａに対し機能排他対処の処理が動作していないため、起動済みが返される。ステップＳ２４において、クライアント端末ｂから処理Ａを起動要求する。

（ｃ）ステップＳ２５において、機能排他処理部１１ａが機能排他チェックを行なう。結果は同一の処理Ａが既に動作中であるため、処理待ちとなる。

（ｄ）ステップＳ２６において、機能排他処理部１１ａが起動結果をクライアント端末ｂに返す。処理Ａは処理待ちとなる。

（ｅ）ステップＳ２７において、処理待ちを行い、クライアント端末ａから起動された処理Ａが終了した後にクライアント端末ｂから起動要求された処理Ａの起動を行いクライアント端末ｂに処理Ａ起動済みを返す。

（実施例４）
次に、管理システム１００が、クライアント端末ａ及びクライアント端末ｂから同じ情報データを操作しようとした場合について図２６を参照して説明する。以下においては、クライアント端末ａからデータ１の操作のため情報排他要求を行い、クライアント端末ａでデータ１操作中にクライアント端末ｂから同一のデータ１を操作するために情報排他要求する。

（ａ）先ずステップＳ３１において、クライアント端末ａからデータ１に対して情報排他要求を行なう。ステップＳ３２において、情報排他部１４ａが排他チェックを行なう。結果は、データ１は誰も使用していないので、排他設定が行われる。

（ｂ）ステップＳ３３において、情報排他部１４ａが排他結果をクライアント端末ａに返す。ここでは排他成功が返される。

（ｃ）ステップＳ３４において、クライアント端末ａでデータ１操作中にクライアント端末ｂからデータ１の情報排他要求を行なう。ステップＳ３５において、情報排他部１４ａが排他チェックを行なう。データ１はクライアント端末ａで操作中であり、排他設定は行われない。このため、情報排他部１４ａが排他結果をクライアント端末ｂに返し、排他結果は失敗となる。

（第２の実施の形態）
上述した本発明の第１の実施の形態に係る管理サーバ１においては、管理サーバ１とクライアント端末２ａ〜２ｅのみの、ＬＡＮ等で閉じられた通信で発生する排他処理について説明したが、管理サーバは複数存在し、図２７に示すように、通信網５を介して他の管理サーバ等の装置と接続されていてもよい。更に通信網５上に中央管理サーバを設置し、管理サーバＡと管理サーバＢの管理、及び両サーバが保持する機能記憶装置４ａ、情報記憶装置４ｂのマスタファイルの新規登録、更新、削除等の管理を行なうようにしてもよい。

管理サーバＡと中央管理サーバ間、管理サーバＢと中央管理サーバ間、管理サーバＡと管理サーバＢ間、管理サーバＡとその下位ノードであるクライアント端末間、管理サーバＢとその下位ノードであるクライアント端末間におけるウェブサービスには全てＸＭＬ言語データを使用する。この為、通信網５を介した中央管理サーバ、管理サーバＡ、管理サーバＢ、クライアント端末間でのデータ解析、エラー解析が容易となり、ひいては排他制御性能を向上させる。

尚、図２７の場合の排他処理について説明すると、管理サーバＡのクライアント端末２ｆと管理サーバＢのクライアント端末２ｇより、管理サーバＡの情報記憶部４ｂへ対するデータアクセス要求が出ているが、先にクライアント端末２ｇが管理サーバＡの情報記憶装置４ｂにすでにアクセスしているため、クライアント端末２ｆに対して排他制御が行なわれる。

このようにシステムを構成することにより、より大規模なシステムにおいても同様に排他制御を意識することなく、情報排他及び機能排他を行なうことができる。

本発明の実施の形態に係る管理システムの構造を示す構造図である。 管理サーバのシステム構造を示す図である。 起動管理パラメータ情報記憶部のデータ構造を示す図である。 起動機能管理情報記憶部のデータ構造を示す図である。 バッチ要求管理情報記憶部のデータ構造を示す図である。 情報排他管理情報記憶部のデータ構造を示す図である。 管理サーバの全体動作を示すフローチャートである。 機能排他処理部の動作を示すフローチャートである。 機能排他処理部の排他判定結果を表すテーブル図である。 機能排他解除処理部の動作を示すフローチャートである。 機能排他解除処理部の排他解除結果を表すテーブル図である。 バッチ処理管理部の動作を示すフローチャートである。 バッチ処理管理部のバッチ起動管理部による削除結果を表すテーブル図である。 バッチ監視部によるバッチ処理結果を表すテーブル図である。 バッチ要求取消部によるバッチ取消結果を表すテーブル図である。 バッチ再起動要求部によるバッチ再起動結果を表すテーブル図である。 情報排他部の動作を示すフローチャートである。 情報排他部による情報排他結果を表すテーブル図である。 情報排他解除部の動作を示すフローチャートである。 情報排他解除部による情報排他解除結果を表すテーブル図である。 情報排他一括解除部の動作を示すフローチャートである。 情報排他一括解除部による情報排他一括解除結果を表すテーブル図である。 実施例１の機能排他処理を模式的に示す模式図である。 実施例２の機能排他処理を模式的に示す模式図である。 実施例３の機能排他処理を模式的に示す模式図である。 実施例４の情報排他処理を模式的に示す模式図である。 排他処理の動作を模式的に示した模式図である。

符号の説明

１…管理サーバ
２ａ，２ｂ，２ｃ，２ｄ，２ｅ，ａ，ｂ，２ｆ，２ｇ…クライアント端末
３…データ管理部
４ａ…機能記憶装置
４ｂ…情報記憶装置
５…通信網
１１…機能排他管理部
１１ａ…機能排他処理部
１１ｂ…機能排他解除処理部
１２…バッチ処理管理部
１２ａ…バッチ即時起動要求部
１２ｂ…バッチ起動要求部
１２ｃ…バッチ再起動要求部
１２ｄ…バッチ監視部
１２ｅ…バッチ要求取消部
１２ｆ…バッチ起動管理部
１４…情報排他管理部
１４ａ…情報排他部
１４ｂ…情報排他解除部
１４ｃ…情報排他一括解除部
１５…排他記憶部
１５ａ…起動管理パラメータ情報記憶部
１５ｂ…起動機能管理情報記憶部
１５ｃ…バッチ要求管理情報記憶部
１５ｄ…情報排他管理情報記憶部
５１…入力装置
５２…出力装置
５３…主記憶装置
５４…補助記憶装置
５５…ＣＰＵ
５６…通信インタフェース
５７…通信制御装置
１００…管理システム

Claims (4)

1. クライアント端末からの機能若しくは情報の要求を受けた際に前記機能若しくは前記情報の排他制御を行なう管理サーバであって、
   前記機能の管理に必要なデータを格納する起動機能管理情報記憶部及び前記情報の管理に必要なデータを格納する情報排他管理情報記憶部を有する排他記憶部と、
   複数の前記クライアント端末より前記機能の使用要求を依頼された時の排他制御として前記機能のバッチ処理を行なうバッチ処理管理部と、
   前記クライアント端末より前記機能の使用要求を受信すると前記起動機能管理情報記憶部のデータを基に前記機能が使用可能か否かを判断し、使用可能な場合には前記使用要求毎に管理番号を発番して実行する前記機能の起動情報を起動機能管理情報記憶部に登録し、使用不可能な場合には前記バッチ処理管理部に前記バッチ処理の依頼を行なう機能排他処理部及び前記機能の処理終了の検知若しくは前記クライアント端末からの前記機能の排他解除の要求を受信すると前記管理番号を基に前記起動機能管理情報記憶部を検索し前記管理番号に該当する情報の削除を行なう機能排他管理部と、
   前記クライアント端末より前記情報の使用状態の調査を受信すると前記情報管理情報記憶部を検索して前記情報が使用可能であるかを判定し、使用可能と判定された場合には前記情報排他管理情報記憶部内の前記情報を情報排他に更新して前記更新毎に前記管理番号の発番を行なう情報排他処理部及び前記クライアント端末より前記情報排他の解除の要求を受信すると前記情報排他管理情報記憶部内の前記管理番号に該当する情報の削除を行なう情報排他解除部を有する情報排他管理部
   とを備えることを特徴とする管理サーバ。
2. 機能及び情報を管理し、クライアント端末からの使用要求により前記機能若しくは前記情報を送信する機能情報管理部と、
   前記機能の管理に必要なデータを格納する起動機能管理情報記憶部及び前記情報の管理に必要なデータを格納する情報排他管理情報記憶部を有する排他記憶部、複数の前記クライアント端末より前記機能の使用要求を依頼された時の排他制御として前記機能のバッチ処理を行なうバッチ処理管理部と、
   前記クライアント端末より前記機能の使用要求を受信すると前記起動機能管理情報記憶部のデータを基に前記機能が使用可能か否かを判断し、使用可能な場合には前記使用要求毎に管理番号を発番して実行する前記機能の起動情報を起動機能管理情報記憶部に登録し、前記クライアント端末に前記機能情報管理部が管理する前記機能の使用を許可し、使用不可能な場合には前記バッチ処理管理部に前記バッチ処理の依頼を行なう機能排他処理部及び前記機能の処理終了の検知もしくは前記クライアント端末からの前記機能の排他解除の要求を受信すると前記管理番号を基に前記起動機能管理情報記憶部を検索し前記管理番号に該当する情報の削除を行なう機能排他管理部と、
   前記クライアント端末より前記情報の使用状態の調査を受信すると前記情報管理情報記憶部を検索して前記情報が使用可能であるかを判定し、使用可能と判定された場合には前記情報排他管理情報記憶部内の前記情報を情報排他に更新して前記更新毎に前記管理番号の発番を行ない、前記クライアント端末に前記機能情報管理部が管理する前記情報の使用を許可する情報排他処理部と、
   前記クライアント端末より前記情報排他の解除の要求を受信すると前記情報排他管理情報記憶部内の前記管理番号に該当する情報の削除を行なう情報排他解除部を有する情報排他管理部
   とを備えることを特徴とする管理サーバ。
3. クライアント端末から前記機能若しくは前記情報の使用要求を受けた際に排他制御を行なう管理方法であって、
   複数の前記クライアント端末より前記機能の使用要求を依頼された時の排他制御としてバッチ処理管理部が前記機能のバッチ処理を行なうステップと、
   前記クライアント端末より前記機能の使用要求を受信すると前記起動機能管理情報記憶部のデータを基に前記機能が使用可能か否かを判断し、使用可能な場合には前記使用要求毎に管理番号を発番して実行する前記機能の起動情報を起動機能管理情報記憶部に登録して前記クライアント端末に前記機能情報管理部が管理する前記機能の使用を許可し、使用不可能な場合には前記バッチ処理管理部に前記バッチ処理の依頼を行なうステップと、
   前記クライアント端末より前記機能の排他解除の要求を受信すると前記管理番号を基に前記起動機能管理情報記憶部を検索し前記管理番号に該当する情報の削除を行なうステップと、
   前記クライアント端末より前記情報の使用状態の調査を受信すると前記情報管理情報記憶部を検索して前記情報が使用可能であるかを判定し、使用可能と判定された場合には前記情報排他管理情報記憶部内の前記情報を情報排他に更新して前記更新毎に前記管理番号の発番を行ない、前記クライアント端末に前記機能情報管理部が管理する前記情報の使用を許可するステップと
   前記機能の処理終了の検知もしくは前記クライアント端末からの前記情報排他の解除の要求を受信すると前記情報排他管理情報記憶部内の前記管理番号に該当する情報の削除を行なうステップ
   とを有することを特徴とする管理方法。
4. 機能及び情報を管理する機能情報管理部に、クライアント端末から前記機能若しくは前記情報の使用要求を受けた際に排他制御を行なうコンピュータに、
   複数の前記クライアント端末より前記機能の使用要求を依頼された時の排他制御としてバッチ処理管理部が前記機能のバッチ処理を行なう命令と、
   前記クライアント端末より前記機能の使用要求を受信すると前記起動機能管理情報記憶部のデータを基に前記機能が使用可能か否かを判断し、使用可能な場合には前記使用要求毎に管理番号を発番して実行する前記機能の起動情報を起動機能管理情報記憶部に登録して前記クライアント端末に前記機能情報管理部が管理する前記機能の使用を許可し、使用不可能な場合には前記バッチ処理管理部に前記バッチ処理の依頼を行なう命令と、
   前記クライアント端末より前記機能の排他解除の要求を受信すると前記管理番号を基に前記起動機能管理情報記憶部を検索し前記管理番号に該当する情報の削除を行なう命令と、
   前記クライアント端末より前記情報の使用状態の調査を受信すると前記情報管理情報記憶部を検索して前記情報が使用可能であるかを判定し、使用可能と判定された場合には前記情報排他管理情報記憶部内の前記情報を情報排他に更新して前記更新毎に前記管理番号の発番を行ない、前記クライアント端末に前記機能情報管理部が管理する前記情報の使用を許可する命令と
   前記機能の処理終了の検知もしくは前記クライアント端末からの前記情報排他の解除の要求を受信すると前記情報排他管理情報記憶部内の前記管理番号に該当する情報の削除を行なう命令
   とを実行させることを特徴とする管理プログラム。
   
   

Images