JP3374879B2 - 分散サービス処理システムの逐次復元処理方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、分散サービス処理シス
テムに係り、詳しくは、分散サービス処理シ ステム利用
の分散サービス環境において、要求があれば即時に実行
できる環境で、予め活性化されたサービス要求を依頼す
る主体（以降、サービス依頼主体と呼ぶ）とサービス要
求を実現する主体（以降、サービス実現主体と呼ぶ）お
よび両主体を動的に結び付け、サービスを依頼／実現す
る契機でのみ両主体のプロセス資源を保留し、このサー
ビス中での異常発生事象を考慮してこの主体を管理／監
視し、異常発生時の逐次復元処理方法に関するものであ
る。

【０００２】

【従来の技術】従来の分散サービス環境では、サービス
依頼主体がサービス実現主体を、利用者からのサービス
依頼電文が発生した時点で生成／消滅する動的なサービ
ス連携方式をとっている。

【０００３】図１１に、サービス依頼主体が、サービス
実現主体を動的にサービス依頼時点で生成し、サービス
実現主体の障害事象は全てサービス依頼主体が管理する
従来方式を示す。図１１において、利用者からのサービ
ス依頼電文１０００をサービス依頼主体１０１０が受け
付けるが、この時点でサービス依頼電文の内容に基づい
て、サービス依頼主体１０１０は個々のサービス実現主
体１０２０を生成する。従って、サービス依頼主体１０
１０と個々のサービス実現主体１０２０は親子関係にあ
るため、個々のサービス実現主体１０２０で異常事象が
発生した場合、その障害はサービス実現主体１０２０の
消滅の時点で判明し、サービス依頼主体１０１０は、そ
の消滅時の情報を受けて利用者のサービス依頼電文に応
答する。

【０００４】この様に、従来の分散サービス環境では、
サービス実現主体はサービス依頼電文が発生する毎に生
成消滅され、その生成／消滅の単位でサービス依頼に同
期しており、また当該サービス依頼のみに障害内容が限
定され、他のサービスに影響を与えないため、方式的な
障害復旧の手段は簡易であり、依頼電文での発生障害事
象に対する対処は全て利用者に委ねられることになる。
従って、障害に関する復旧処理は、再度サービス依頼電
文を利用者から送信する等の方法で行う必要がある。ま
た、この様な分散サービス環境においては、サービス実
現主体の生成に要するオーバーヘッドの発生及び電文の
引き継ぎ／情報の引き継ぎが不可能であることから、予
め複数種類のサービス内容が固定的に定まっている定型
的なサービスは実現できず、アドホックで単一の要求を
実現するだけの非定型的なサービスへの適用に限られて
いる。

【０００５】定型的なサービスの実現のためには、図１
２に示す様に、サービスの開始、サービス提供等の時間
的なフェーズ分けに応じて、サービス開始時の監視／管
理主体１１１０によって、サービス受け付け／依頼する
主体であるプロセス群１１２０とサービス実現をする主
体であるプロセス群１１３０を生成させ（１１４１、１
１４２）、さらに、このプロセス群間（１１２０と１１
３０はシステム環境によって自由な対応付けを行える様
に、互いにその生成数の相関制約は無いものとする）に
制御用通信路１１４０を保有し、サービス提供フェーズ
においては、利用者からのサービス依頼発生時に個別通
信路１１５０を開設する様に、１つのサービス実行プロ
セス（例えば１１２１）と制御用通信路１１４０を介し
て通信し、サービス実行プロセス（例えば１１３１）に
サービスを振り分けて、該サービス実行プロセスの保留
時間を最小限にする分散サービスを考える必要がある。
しかし、従来、これらのサービスのプロセス群等の障害
時においては、サービス依頼主体（例えば１１２１）と
サービス実現主体（例えば１１３１）に対する障害発生
時の復元方法は監視／管理主体１１１０が全てのサービ
ス依頼主体及びサービス実現主体を非同期に消滅させ
（１１５１、１１５２）、再度両主体を生成させる（１
１４１、１１４２）という一括復元処理方式であった。

【０００６】

【発明が解決しようとする課題】本発明の目的は、分散
サービス処理システム上でサービス依頼主体とサービス
実現主体が分散して制御される定型的なサービス実現環
境において、障害発生時に従来の様なシステム全体の一
括復元方式によるサービス停止時間の長期化を防止し、
オペレータの介入無しに障害事象の自動認識と該認識さ
れた障害事象に基づいた逐次復元処理方法を提供するこ
とにある。

【０００７】

【課題を解決するための手段】本発明は、サービス依頼
を実行するサービス依頼プロセス用サーバと、サービス
実現を実行するサービス実現プロセス用サーバと、サー
ビス依頼プロセスとサービス実現プロセスの起動・監視
を行う監視プロセス用監視モニタを具備してなる分散サ
ービス処理システムにて、依頼プロセスとサービス実現
プロセスが分散してサービスを実現する分散サービス環
境において、監視プロセスにより、サービス依頼を実行
する複数のサービス依頼プロセスとサービス実現を実行
する複数のサービス実現プロセスを予め生成して、利用
者端末（以下、利用者と呼ぶ）からサービス依頼電文が
発生した場合に、サービス依頼プロセスとサービス実現
プロセスを１対に括り付ける個別通信路の開設のための
情報通信用の制御用通信路をサービス依頼プロセス群と
サービス実現プロセス群で共用し、利用者からサービス
依頼電文が発生すると、前記制御用通信路により、サー
ビス依頼プロセスからサービス実現プロセスへ、該サー
ビス依頼プロセスとサービス実現プロセスを１対１に括
り付ける個別通信路の通信路識別情報を送信して、個別
通信路を開設し、該個別通信路を通してサービス依頼プ
ロセスとサービス実行プロセスの間で情報を伝達し、サ
ービス依頼プロセスで障害が発生すると、監視プロセス
が再度サービス依頼プロセスを生成し、該生成したサー
ビス依頼プロセスが、サービス実現プロセスとの間に、
前記開設済みの個別通信路と重複しない個別通信路を再
開設して自プロセスを逐次復旧することを特徴とする。
さらに、個別通信路開設後にサービス実現プロセスの自
プロセス識別子をサービス依頼プロセスと情報交換し、
サービス依頼プロセスは、当該サービス実現プロセスに
対する時間監視をし、時間超過時の停止を含めた当該サ
ービス実現プロセスの非同期障害の逐次復旧をすること
を特徴とする。

【０００８】

【作用】サービス依頼主体であるサービス依頼プロセス
群とサービス実現主体であるサービス実現プロセス群
は、実際の利用者にサービス提供以前に並列に生成さ
れ、これらのプロセス群の間には、サービス提供開始
後、利用者からサービス依頼電文が発生した場合に、サ
ービス依頼プロセスとサービス実現プロセスを１：１に
括り付ける個別通信路の通信路識別情報送信のための制
御用通信路（ソケットペア）を確保して、プロセス群で
共有する。サービス依頼プロセスでは、個別通信路の括
付けのために、通信路識別情報をある基底値からの範囲
で指定できる。この範囲の通信路識別子の指定によっ
て、サービス依頼プロセスの障害時には、開設済みの通
信路と重複すること無く通信路の再開設が可能になり、
サービス依頼プロセスの逐次復旧が可能となる。また、
個別通信路開設後にサービス実現プロセスの自プロセス
識別子をサービス依頼プロセスと情報交換することによ
り、サービス実現プロセスの非同期障害事象に対して
も、当該サービス実現プロセスのみに限定した障害の逐
次復旧が可能となる。

【０００９】

【実施例】以下、本発明の一実施例について図面により
説明する。

【００１０】図１は、分散サービス処理システム上で定
型の業務サービスを実現する分散サービス環境におい
て、サービス依頼主体とサービス実現主体を生成する過
程を示したものである。この生成過程において、初期化
プロセス（監視／管理主体）１００はサービスの開始
時、オペレータの指示に従って起動される。この初期化
プロセス（分散サービス全体の監視／管理も兼ねる）１
００は、オペレーティングシステム（ＯＳ）の機構を用
いて、サービス依頼主体１０５及びサービス実現主体１
０６間に、入力／出力が対となった１つの通信路のソケ
ットペアからなる制御用通信路１０１が開設できるよう
に、自ら事前に内部的に制御用通信路１０１′を開設す
る。その後、サービス依頼主体１０５及びサービス実現
主体１０６のおのおの個別の障害事象を管理／監視可能
とするためのプロセスとして、各々、依頼監視プロセス
１０２、実現監視プロセス１０３を生成する。最後に、
これらの監視プロセス１０２、１０３は、各々、サービ
ス依頼プロセス群１０５とサービス実現プロセス群１０
６を生成する。ここで、依頼監視プロセス１０２、実現
監視プロセス１０３、サービス依頼プロセス群１０５、
サービス実現プロセス群１０６は、生成された後も制御
用通信路１０１を閉じること無く保持し続ける。この制
御用通信路１０１は、サービス終了契機まで各プロセス
群内で共用される。

【００１１】この様な分散サービス環境のサービス開始
の準備処理後、サービスに関与する個別の障害事象に際
して、分散サービスが具体的に行われている場合の本発
明による逐次障害復旧処理方法を明確化するため、一般
性を欠くこと無く、サービス依頼主体及びサービス実現
主体が各々１プロセスから構成されている場合を例にと
って説明する。

【００１２】図２は、具体的にサービス処理を、分散サ
ービス処理システムの分散サービス環境において実行す
る処理内容を示したものである。

【００１３】サービス依頼プロセス２０１は生成元の依
頼監視プロセス１０２の通信路識別子２０３を、サービ
ス実現プロセス２０２は生成元の実現監視プロセス１０
３の通信路識別子２０４を、それぞれ制御用通信路１０
１として継承している。また、この制御用通信路１０１
は、サービス実現プロセス２０２への振り分けのために
も利用し、実際の電文内容の情報引き継ぎは、サービス
依頼プロセス２０１が該制御用通信路１０１に追加し、
かつ、サービス依頼プロセス２０１とサービス実現プロ
セス２０２の間で交換される仮通信路識別子（ポート番
号と呼ぶ２バイトの情報の下位１バイト）２０５によっ
て、サービス依頼プロセス２０１から実通信路識別子
（ポート番号と呼ぶ）での接続要求を受け取れたサービ
ス実現プロセス２０２の間で開設する個別通信路２０６
によって行う。図３に示すように、制御用通信路１０１
によって通信される通信路識別子は、各サービス依頼プ
ロセス内で固定値では無く、ポート番号の２バイトの上
位１バイトで指定するポート番号基底値３０１を除く下
位１バイトで指定する仮通信路識別子３０２（図２の２
０５）である。この仮通信路識別子３０２は、０から２
５５までの範囲で個々のサービス依頼プロセス内で自由
に払出しを行う。サービス実現プロセス２０２は、制御
用通信路１０１から受け取った仮通信路識別子３０２と
既知であるポート番号基底値３０１によって実通信路識
別子（ポート番号）を復元し、復元した実通信路識別子
（ポート番号）によって個別通信路２０６を開設要求す
る。個別通信路２０６は、開設された後はサービス要求
依頼からサービス実現終了までの間保留する。また、サ
ービス実現プロセス２０２は、個別通信路２０６を開設
した直後に、サービス依頼プロセス２０１に自プロセス
識別子２０７を送信し、サービス実現プロセス２０２の
非同期障害事象を監視可能とする。

【００１４】この状況において、システム全体の障害
（たとえばプロセッサ等の障害）を除き、依頼監視プロ
セス／実現監視プロセスで検出できる障害／非同期事象
の発生を以下のパターンに分類して、本発明の逐次復元
処理方法について説明する。

【００１５】 場合１；サービス依頼プロセス２０１で個別通信路２０
６をクローズ処理する以前に異常終了した場合 場合２；サービス依頼プロセス２０１で制御用通信路１
０１へ仮通信路識別子を追加した後に異常終了した場合 場合３；サービス実現プロセス２０２が制御用通信路１
０１から仮通信路識別子２０５を受け取った後に異常終
了した場合 場合４；サービス実現プロセス２０２でのループ等によ
り、サービス実現時間を無限に消費し、応答が永久に返
却されない障害に遭遇する場合 場合５；個別通信路２０５で通信中にサービス実現プロ
セス２０２が非同期に異常終了する場合 場合６；個別通信路で通信中にサービス依頼プロセス２
０１が非同期異常終了する場合。

【００１６】図４に、上記各場合の障害事象の状況を示
す。以下、各場合の復元処理を説明する。

【００１７】場合１においては、依頼監視プロセス１０
２がサービス依頼プロセス２０１の異常終了を、割り込
み（以降シグナルと呼ぶ）４０１で検出する。この場
合、依頼監視プロセス１０２は再度サービス依頼プロセ
ス２０１′を自動的に生成する。この再生されたサービ
ス依頼プロセス２０１′は、プロセス固定のポート番号
であれば過去に異常終了した通信路を開設することにな
り、当該通信路の閉塞まで待ち状態（これは実装されて
いるオペーティングシステムに依存して待ち時間が決定
される）になる。このため、定型サービスの実現は不可
能となるが、プロセス固定の規定値から順に２５６の範
囲で再度通信路開設待ちを行うため、個別通信路２０６
でなく別の個別通信路（例えば２０６′）で通信を行な
えるようにする。これにより、場合１に対してサービス
依頼プロセス２０１障害時の逐次復旧処理が可能とな
る。図５に、この場合１での詳害復旧処理フロー例を示
す。

【００１８】場合に２においては、サービス依頼プロセ
ス２０１が制御用通信路１０１へサービス依頼のための
仮通信路識別子（ポート番号の下位１バイト）２０５を
追加した後に異常終了した場合であるが、サービス実現
プロセス２０２側では仮通信路識別子を元に復元したポ
ート番号での個別通信路２０６の開設に失敗する（４０
２）。しかし、サービス実現プロセス２０２側では実際
にサービス依頼電文（４０３）を受け取れないだけであ
るため、サービス実現プロセス２０２は本失敗事象は無
視し、再度制御用通信路１０１の監視を行えば良い。な
お、サービス依頼プロセス２０１は場合１と同様にして
逐次復旧する。図６に、この場合２での障害復旧処理フ
ロー例を示す。

【００１９】場合３においては、サービス実現プロセス
２０２が制御用通信路１０１から仮通信路識別子２０５
を受け取った後に異常終了するため、その要求を出した
サービス依頼プロセス２０１は永久に個別通信路２０６
の開設依頼を待つことになる。この場合には、サービス
依頼プロセス２０１は制御用通信路１０１へ仮通信路識
別子２０５を追加した後に、通信路接続待ち（４０４）
でタイマ監視を行う（４０５）。そして、一定時間以内
にサービス実現プロセス２０２が個別通信路２０６を開
設要求してこない状況では、再度制御用通信路１０１へ
サービス依頼を追加する。なお、この場合、サービス依
頼プロセス２０１では、既に分散サービスが正常に行わ
れている場合には、サービス実現プロセス群が全て処理
中であることが、サービス実現プロセス２０２が個別通
信路開設後に最初に返却するサービス実現プロセス識別
子の情報（４０６）で検出でき、また、制御用通信路１
０１の溢れ情報を検出できるため、この両者のいずれか
の場合には、性能劣化の要因となるためサービス依頼の
追加は行わない。なお、タイムアウトに伴う多重のサー
ビス依頼が制御用通信路１０１に存在する場合には、最
初のサービス依頼が正常に処理され、後のサービス依頼
はサービス依頼プロセス２０１の異常終了と同等に扱う
ことによって、場合１に帰着される。図７に、この場合
３の障害復旧処理フロー例を示す。

【００２０】場合４においては、サービス実現プロセス
２０２は既に個別通信路２０６によって自プロセス識別
子をサービス依頼プロセス２０１に送信済みであるた
め、サービス依頼プロセス２０１は、タイマ監視時間に
よって監視し、該監視時間を超えた場合、通知されてい
るサービス実現プロセス２０２に非同期割り込み４０７
を送り終了させる。図８に、この場合３の障害復旧処理
フロー例を示す。

【００２１】場合５においては、個別通信路２０６で接
続され、サービス実現プロセス２０２の異常終了は、非
同期割り込み（４０８）で実現監視プロセス１０３で検
出され、個別通信路２０６から送信後の異常終了の返却
（４０９）を受けることできるため、異常処理の後処理
（４０１）を行う。図９に、この場合５の障害復旧処理
フロー例を示す。

【００２２】場合６においては、場合５と同様に、サー
ビス依頼プロセス２０１の異常終了は、非同期割り込み
（４０１）で依頼監視プロセス１０２で検出され、個別
通信路２０６から送信後の異常終了の返却（４１１）を
受けることができるため、異常処理の後処理（４１２）
を行う。図１０に、この場合３の障害復旧処理フロー例
を示す。

【００２３】図１３は、本発明が適用される分散サービ
ス処理システムの具体的構成例を示したものである。こ
こで、サービス依頼側の各サーバがサービス要求を依頼
するプロセスに、カスタムサーバの各々がサービス要求
を処理するプロセスにそれぞれ対応する。監視モニタは
起動／監視プロセスに対応する。サービス制御・リクエ
ストブローカはパソコン−サーバ間の交換処理を行うも
のである。オペレーションシステム（ＯＳ）は分散サー
ビス環境全体の監視／管理を司どり、該分散サービス環
境のサービス開始の準備処理として、監視モニタの起動
／監視プロセスを起動し、該起動／監視プロセスが、サ
ービス依頼サーバ側の各サービス要求を依頼するプロセ
スとカスタムサーバ側の各サービス要求を処理するプロ
セスを起動すると同時に、入力／出力が対の制御用通信
路（ソケットペア）を確保して、該ソケットペアの入力
側をサービス依頼側の各プロセスの共有とし、該ソケッ
トペアの出力側をカスタムサーバ側の各プロセスの共有
とする。個別通信路は、サービス依頼側の任意のプロセ
スとカスタムサーバ側の任意のプロセスとの間で動的に
設定される。

【００２４】

【発明の効果】以上説明した様に、本発明によれば、分
散サービス処理システムにおいて、サービス内容が予め
明確になっている定型業務処理を中心とする分散サービ
ス環境下で、システム障害（ハード障害等、システム全
体を復旧せざるを得ない障害）以外の、個々のサービス
依頼プロセス群、サービス実現プロセス群で発生する個
々の非同期の異常事象について、システム全体を中断す
ることなく、障害を自動認識して、個別の障害発生主体
のみを逐次復旧させることにより、システム全体へのサ
ービス遂行／稼働を継続させ、システム全体の安定的な
サービス提供を実現することが可能となる。

【図面の簡単な説明】

【図１】本発明で前提となる分散サービス環境のプロセ
ス構成の一実施例を示す図である。

【図２】サービス依頼プロセスとサービス実現プロセス
間の通信を説明する図である。

【図３】サービス依頼プロセスとサービス実現プロセス
での通信路識別子の設定を示す図である。

【図４】本発明による障害発生事象の逐次復旧処理を説
明する図である。

【図５】場合１の障害復旧処理フロー例を示す図であ
る。

【図６】場合２の障害復旧処理フロー例を示す図であ
る。

【図７】場合３の障害復旧処理フロー例を示す図であ
る。

【図８】場合４の障害復旧処理フロー例を示す図であ
る。

【図９】場合５の障害復旧処理フロー例を示す図であ
る。

【図１０】場合６の障害復旧処理フロー例を示す図であ
る。

【図１１】従来の分散サービスの処理を説明する図であ
る。

【図１２】定型的な分散サービスの実現を説明する図で
ある。

【図１３】本発明で対象とする分散サービス処理システ
ムのシステム構成例を示す図である。

【符号の説明】

１０１ 制御通信路 １０２ 依頼監視プロセス １０３ 実現監視プロセス ２０１ サービス依頼プロセス ２０２ サービス実現プロセス ２０６ 個別通信路

───────────────────────────────────────────────────── フロントページの続き (72)発明者 川崎 隆二 東京都千代田区内幸町１丁目１番６号 日本電信電話株式会社内 (56)参考文献 特開 平５−46572（ＪＰ，Ａ) 特開 平３−196243（ＪＰ，Ａ) 特開 平５−233333（ＪＰ，Ａ) 特開 平４−188234（ＪＰ，Ａ) 特開 平１−197850（ＪＰ，Ａ) 特開 平６−60029（ＪＰ，Ａ) 特開 平８−87477（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 15/16 - 15/177 G06F 9/46 G06F 13/00

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】 サービス依頼を実行するサービス依頼プ
   ロセス用サーバと、サービス実現を実行するサービス実
   現プロセス用サーバと、サービス依頼プロセスとサービ
   ス実現プロセスの起動・監視を行う監視プロセス用監視
   モニタを具備してなる分散サービス処理システムにおけ
   る障害発生時の復元処理方法であって、 監視プロセスにより、サービス依頼を実行する複数のサ
   ービス依頼プロセスとサービス実現を実行する複数のサ
   ービス実現プロセスを予め生成して、利用者端末からサ
   ービス依頼電文が発生した場合に、サービス依頼プロセ
   スとサービス実現プロセスを１対に括り付ける個別通信
   路の開設のための情報通信用の制御用通信路をサービス
   依頼プロセス群とサービス実現プロセス群で共用し、 利用者端末からサービス依頼電文が発生すると、前記制
   御用通信路により、サービス依頼プロセスからサービス
   実現プロセスへ、該サービス依頼プロセスとサービス実
   現プロセスを１対１に括り付ける個別通信路の通信識別
   情報を送信して個別通信路を開設し、該個別通信路を通
   してサービス依頼プロセスとサービス実行プロセスの間
   で情報を伝達し、 サービス依頼プロセスで障害が発生すると、監視プロセ
   スが再度サービス依頼プロセスを生成し、該生成したサ
   ービス依頼プロセスが、サービス実現プロセスとの間
   に、前記開設済みの個別通信路と重複しない個別通信路
   を再開設して自プロセスを逐次復旧する、 ことを特徴とする分散サービス処理システムの逐次復元
   処理方法。
2. 【請求項２】 請求項１記載の分散サービス処理システ
   ムの逐次復元処理方法において、 個別通信路開設後にサービス実現プロセスの自プロセス
   識別子をサービス依頼プロセスと情報交換し、サービス
   依頼プロセスは、当該サービス実現プロセスに対する時
   間監視をし、時間超過時の停止を含めた当該サービス実
   現プロセスの非同期障害の逐次復旧をすることを特徴と
   する分散サービス処理システムの逐次復元処理方法。