"同等の機能を有する複数台のアプリケーションサーバを連結してなるマルチサーバシステムのアプリケーションサーバであって、ネットワークで接続された外部から自サーバの死活状態を判定させるための対外部死活監視ポートと、自サーバに実装されている監視対象アプリケーションが正しく動作しているか否かを監視する監視手段と、この監視手段による監視結果を前記対外部死活監視ポートに反映させる死活反映手段と、を具備したことを特徴とするアプリケーションサーバ。連結された相手サーバから自サーバの死活状態を判定させるための対サーバ死活監視ポートと、連結された相手サーバの前記対サーバ死活監視ポートの状態により前記相手サーバの死活状況を判定する判定手段と、をさらに具備し、前記死活反映手段は、前記監視手段による監視結果を前記対外部死活監視ポートと前記対サーバ死活監視ポートとに反映させることを特徴とする請求項1記載のアプリケーションサーバ。前記判定手段により判定される相手サーバの死活状況をデータベースに記録する記録手段、をさらに具備したことを特徴とする請求項2記載のアプリケーションサーバ。同等の機能を有する複数台のアプリケーションサーバを連結してなるマルチサーバシステムのアプリケーションサーバに、自サーバに実装されている監視対象アプリケーションが正しく動作しているか否かを監視する監視機能と、ネットワークで接続された外部から自サーバの死活状態を判定させるための対外部死活監視ポートに前記監視結果を反映させる死活反映機能と、を実現させるための監視プログラム。前記死活反映機能は、前記対外部死活監視ポートに加えて、連結された相手サーバから自サーバの死活状態を判定させるための対サーバ死活監視ポートに前記反映結果を反映させるものであり、さらに、前記アプリケーションサーバに、連結された相手サーバの前記対サーバ死活監視ポートの状態により前記相手サーバの死活状況を判定する判定機能を実現させるための請求項4記載の監視プログラム。さらに、前記アプリケーションサーバに、前記判定機能により判定される相手サーバの死活状況をデータベースに記録する機能を実現させるための請求項5記載の監視プログラム。本発明が解決しようとする課題は、同等の機能を有する複数のアプリケーションサーバを連結してなるマルチサーバシステムにおいて、クライアント端末からの要求に対してアプリケーションサーバが誤ったサービスを提供するのを未然に防ぐことにある。一実施形態によれば、アプリケーションサーバは、対外部死活監視ポートと、監視手段と、死活反映手段とを備える。対外部死活監視ポートは、ネットワークで接続された外部から自サーバの死活状態を判定させるためのものである。監視手段は、自サーバに実装されている監視対象アプリケーションが正しく動作しているか否かを監視する。死活反映手段は、監視手段による監視結果を対外部死活監視ポートに反映させる。以下、マルチサーバシステムを構成するアプリケーションサーバの一実施形態について、図面を用いて説明する。なお、この実施形態は、負荷分散装置であるロードバランサを用いてマルチサーバシステムを構築した場合である。図1は、本実施形態におけるマルチサーバシステム1の全体構成図である。マルチサーバシステム1は、同等の機能を有する2台のアプリケーションサーバ10A,10Bと、データベース21の管理に特化したデータベースサーバ20と、前記ロードバランサ30とを備え、各アプリケーションサーバ10A,10Bとロードバランサ30とを、専用の通信回線40で連結している。また、マルチサーバシステム1は、ロードバランサ30を例えばインターネットのような汎用のネットワーク50に接続している。ネットワーク50には、多数のクライアント端末60が接続されている。かかる構成のマルチサーバシステム1は、クライアント端末60から所望のサービスに対する処理要求が送出されると、この処理要求は、ネットワーク50を介してロードバランサ30に与えられる。ロードバランサ30は、クライアント端末60からの処理要求をアプリケーションサーバ10A,10Bに配分する。アプリケーションサーバ10A,10Bは、クライアント端末60からの処理要求に応じた処理を実行する。このとき、アプリケーションサーバ10A,10Bは、必要に応じてデータベースサーバ20にアクセスして、データベース21に対するデータの書込みや読出しを行う。アプリケーションサーバ10A,10Bは、処理結果であるサービス情報を、ロードバランサ30経由で要求元のクライアント端末6に提供する。なお、ロードバランサ30は、クライアント端末60からの処理要求を、アプリケーションサーバ10A,10Bの能力に応じて配分する。すなわち、両サーバ10A,10Bの能力が同じで有れば均等に配分し、異なるので有ればサーバ10A,10Bの反応速度に応じて配分する。図2は、一方のアプリケーションサーバ10Aのハードウェア構成を示すブロック図である。なお、他方のアプリケーションサーバ10Bもアプリケーションサーバ10Aと同一構成であるので、その説明は省略する。アプリケーションサーバ10Aは、制御部本体としてCPUCentralProcessingUnit11を搭載している。またアプリケーションサーバ10Aは、主記憶部を構成するROMReadOnlyMemory12及びRAMRandomAccessMemory13と、補助記憶部を構成するHDDHardDiskDrive14と、タイマ15と、通信回線40を介して送受信されるデータ信号を入出力するI/Oポート16と、前記データベースサーバ20との間のデータ通信を司るインターフェース17とを搭載している。そして、CPU11と、ROM12、RAM13と、HDD14、タイマ15、I/Oポート16及びインターフェース17とを、アドレスバス,データバス等のバスライン18で接続している。かかる構成のアプリケーションサーバ10A,10Bは、図3に示すように、クライアント端末60からの要求に応じたサービスを提供するための同一のアプリケーションプログラム71A及び71Bを実装している。またアプリケーションサーバ10A,10Bは、上記アプリケーションプログラム71A,71Bをそれぞれ監視対象とする監視プログラム72A,72Bを実装している。これらのアプリケーションプログラム71A,71B及び監視プログラム72は、前記ROM12またはHDD14に保存されている。アプリケーションサーバ10A,10Bは、I/Oポート16として、対外部死活監視ポート73A,73Bと、対サーバ死活監視ポート74A,74Bを含む。対外部死活監視ポート73A,73Bは、ロードバランサ30からの信号を受付ける。対サーバ死活監視ポート74A,74Bは、相手側のアプリケーションサーバ10A.10Bからの信号を受付ける。図4は、一方のアプリケーションサーバ10Aに実装された監視プログラム72Aに従い、同アプリケーションサーバ10AのCPU11が実行する処理手順を示す流れ図である。なお、他方のアプリケーションサーバ10Bに実装された監視プログラム72Bに従い、同アプリケーションサーバ10BのCPU11が実行する処理手順もこれと同一なので、ここでの説明を省略する。監視プログラム72Aが起動すると、CPU11は、先ず、異常フラグFを0にリセットするST1。異常フラグFは、RAM13で記憶する。次いで、CPU11は、自らが実装するアプリケーションプログラム71Aの状態をチェックする。例えばCPU11は、仮想的にアプリケーションプログラム71Aを動かして正常に処理が進むか否かを監視するST2:監視手段。アプリケーションプログラム71Aが正常な場合ST3のNO、CPU11は、異常フラグFが1にセットされているか否かをチェックするST4。異常フラグFが1にセットされていない場合ST4のNO、対外部死活判定ポート73A及び対サーバ死活判定ポート74Aは、いずれも開状態にある。この場合、CPU11は、ステップST10の処理に進む。ステップST4において、異常フラグFが1にセットされていた場合ST4のYES、対外部死活判定ポート73A及び対サーバ死活判定ポート74Aは、いずれも閉状態にある。この場合、CPU11は、対外部死活判定ポート73A及び対サーバ死活判定ポート74Aをいずれも開状態とするST5:死活反映手段。またCPU11は、異常フラグFを0にリセットするST6。しかる後、CPU11は、ステップST10の処理に進む。一方、ステップST3において、アプリケーションプログラム71Aに異常が見つかった場合ST3のYES、CPU11は、異常フラグFが0にリセットされているか否かをチェックするST7。異常フラグFが0にリセットされていない場合ST7のNO、対外部死活判定ポート73A及び対サーバ死活判定ポート74Aは、いずれも閉状態にある。この場合、CPU11は、ステップST10の処理に進む。ステップST7において、異常フラグFが0にリセットされていた場合ST7のYES、対外部死活判定ポート73A及び対サーバ死活判定ポート74Aは、いずれも開状態にある。この場合、CPU11は、対外部死活判定ポート73A及び対サーバ死活判定ポート74Aをいずれも閉状態とするST8:死活反映手段。またCPU11は、異常フラグFを1にセットするST9。しかる後、CPU11は、ステップST10の処理に進む。ステップST10では、CPU11は、通信回線40を介して相手側のアプリケーションサーバ10Bの対サーバ死活監視ポート74Bに問合せ信号を送出する。そして、タイマ15をスタートさせST11、アプリケーションサーバ10Bからの応答を待機するST12:判定手段。ここで、タイマ15がタイムアウトする前にST13のNO、アプリケーションサーバ10Bから応答があった場合にはST12のYES、監視プログラム72Aが終了する。これに対し、アプリケーションサーバ10Bから応答がないままST12のNO、タイマ15がタイムアウトした場合にはST13のYES、CPU11は、相手側のアプリケーションサーバ10Bが異常である旨のデータを、データベース21に記録するST14:記録手段。以上で、監視プログラム72Aが終了する。監視プログラム72A,72Bは、周期的に起動する。あるいは、監視プログラム72A,72Bは、アトランダムに起動してもよい。各アプリケーションサーバ10A,10BのCPU11は、監視プログラム72A,72Bが起動する毎に、図4の流れ図に示した手順の処理を実行する。したがって、各アプリケーションサーバ10A,10Bにそれぞれ実装されているアプリケーションプログラム71A,71Bがいずれも正常なときには、アプリケーションサーバ10Aの対外部死活監視ポート73A及び対サーバ死活監視ポート74Aと、アプリケーションサーバ10Bの対外部死活監視ポート73B及び対サーバ死活監視ポート74Bは、いずれも開状態にある。一方、ロードバランサ30は、クライアント端末60から処理要求を受ける毎に、例えばアプリケーションサーバ10A,アプリケーションサーバ10B,アプリケーションサーバ10A,アプリケーションサーバ10Bの順に交互に転送する。このとき、アプリケーションサーバ10A,10Bの各外部死活監視ポート73A,73Bはいずれも開状態なので、クライアント端末60からの処理要求はアプリケーションサーバ10A,10BのCPU11に届く。その結果、CPU11は、処理要求に応じたアプリケーションプログラム71A,71Bを実行し、その処理結果であるサービス情報をロードバランサ30経由で要求元のクライアント端末6に提供する。したがって、クライアント端末60側からは、あたかも1台のアプリケーションサーバからサービスの提供を受けているように見える。このような状況下で、今、何らかの理由により、一方のアプリケーションサーバ10Aに実装されているアプリケーションプログラム71Aが異常を来たしたとする。その場合、そのアプリケーションサーバ10Aの監視プログラム72Aに従ったCPU11の機能により、当該アプリケーションサーバ10Aの対外部死活監視ポート73Aと対サーバ死活監視ポート74Aとがいずれも閉状態となる。したがって、クライアント端末60からの処理要求を受けたロードバランサ30が、その要求をアプリケーションサーバ10Aに転送しても、対外部死活監視ポート73Aが閉状態にあるので、要求はアプリケーションサーバ10AのCPU11に届かない。ロードバランサ30は、アプリケーションサーバ10Aの対外部死活監視ポート73Aが閉状態にあることから、要求を他方のアプリケーションサーバ10Bに転送する。このとき、アプリケーションサーバ10Bの対外部死活監視ポート73Aは開状態にあるので、要求はアプリケーションサーバ10BのCPU11に届く。その結果、アプリケーションサーバ10Bにおいて、要求に応じた処理が正しく実行されて、サービス情報が要求元のクライアント端末60に提供される。したがって、クライアント端末60からの要求に対してアプリケーションサーバ10A,10Bが誤ったサービスを提供するのを未然に防ぐことができる。また、本実施形態において、アプリケーションサーバ10Aは、定期的あるいはアトランダムに、相手側のアプリケーションサーバ10Bに問合せ信号を送出している。この問合せ信号は、アプリケーションサーバ10Bの対サーバ死活監視ポート74Bを経て、アプリケーションサーバ10BのCPU11に届く。そして、アプリケーションサーバ10Aに応答が返される。同様に、アプリケーションサーバ10Bは、定期的あるいはアトランダムに、相手側のアプリケーションサーバ10Aに問合せ信号を送出している。この問合せ信号は、アプリケーションサーバ10Aの対サーバ死活監視ポート74Aを経て、アプリケーションサーバ10AのCPU11に届く。そして、アプリケーションサーバ10Bに応答が返される。したがって、前述したようにアプリケーションサーバ10Aの対サーバ死活監視ポート74Aが閉状態になると、アプリケーションサーバ10Bからの問合せ信号に対してアプリケーションサーバ10Aからの応答がなくなる。その結果、アプリケーションサーバ10Bは、アプリケーションサーバ10Aのアプリケーションプログラム71Aに異常が発生したことを認識できる。このとき、アプリケーションサーバ10BのCPU11は、アプリケーションサーバ10Aが異常である旨の情報をデータベース21に記録する。したがって、マルチサーバシステム1のユーザは、アプリケーションサーバ10Bからの情報により、アプリケーションサーバ10Aに異常が発生したことを迅速に知ることができる。また、ユーザは、データベース21の情報からその異常がいつ発生したのかと言うような詳細な情報を容易に知ることができる。以下、前記実施形態の変形例について説明する。例えば前記実施形態では、同等の機能を有するアプリケーションサーバの台数を2台としたが、3台以上のアプリケーションサーバを連結してなるマルチサーバシステムに対しても、本発明を適用することは可能である。また、前記実施形態では、ロードバランサ30を用いてマルチサーバシステムを構築した場合を示したが、クラスタリング機能を利用して各アプリケーションサーバをクラスタ化してなるマルチサーバシステムに対しても、本発明を適用できる。さらに、前記実施形態は、サーバ内部のプログラム記憶部であるROM12またはHDD14に発明の機能を実現させる監視プログラムが予め記録されているものとした。しかしこれに限らず、同様のプログラムがネットワークからアプリケーションサーバにダウンロードされてもよい。あるいは、記録媒体に記録された同様のプログラムが、アプリケーションサーバにインストールされてもよい。記録媒体は、CD-ROM,メモリカード等のようにプログラムを記憶でき、かつ装置が読み取り可能であれば、その形態は問わない。また、プログラムのインストールやダウンロードにより得る機能は、装置内部のOSオペレーティングシステム等と協働してその機能を実現させるものであってもよい。この他、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。"