JP6632394B2 - ネットワークシステム、情報処理装置、情報処理装置における制御方法、及びプログラム - Google Patents

Description

本発明は、複数のサービスモジュールが動作する情報処理装置と第１管理システムを含むネットワークシステム、情報処理装置、情報処理装置における制御方法、及びプログラムに関する。

クラウドサービスやＩｏＴ（Internet of Things）の普及に伴い、通信制御装置が搭載された画像形成装置などの機器データを、ネットワーク経由でサーバが受信して管理を行うシステムが登場してきている。また、コンテンツの保管や変換処理をサーバが担い、画像形成装置などからのリクエストに応じて、ネットワーク経由でサーバが保持しているコンテンツの出力が行えるシステムも登場してきている。このようなシステムでは、画像形成装置などのクライアントと、クライアントにサービスを提供するサーバとが、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）、インターネットなどを介して互いに接続されている。

クライアントには、画像形成装置の動作を監視する監視サービスや、画像形成装置の出力実績を管理する出力管理サービス、出力ドキュメントを変換して提供するドキュメント変換サービスなど、ウェブサービスとして複数のサービスが提供される。それらのウェブサービスは、しばしば機能追加のバージョンアップや構成変更が行われるために接続先が切り替わることがある。そのため、サービスを提供するサーバは、クライアントが利用できる複数のウェブサービスの接続先を一元的に管理し、クライアントに通知できる手段を備えることも多い。

クライアントは、契約などにより利用が許可されたサービスのみを利用するため、サービスが提供する全てのサービスに接続するわけではない。クライアントが各々のサービスの利用開始時にサーバにサービスの接続先を問い合わせるようにすることで、切り替わるかもしれないサービスの接続先を、各クライアントが管理する煩雑さを除くことができる。

一方で、サービスを提供するサーバ自身が、サーバの故障やインフラ構成の変更などの要因で、別のサーバへの変更を必要とすることがある。サーバの変更に当たっては、ＤＮＳ（Domain Name System）サーバ情報の変更を行うなどで、クライアントからのサービスの送信先（ＦＱＤＮ（Fully Qualified Domain Name）などのアドレス情報）を変わらないようにするのが望ましい。しかし、インフラ構成やサーバの切替方式の都合などにより、止むを得ず、送信先の変更が必要となる場合もある。

特許文献１には、クライアントに設定されている監視情報の送信先を変更する技術が開示されている。特許文献１では、変更後の送信先（監視装置）からの指示で変更後の送信先との接続を試み、接続に成功したことに応じて監視情報の送信先を該監視装置に変更する。また、特許文献１では、変更後の送信先との接続に失敗した場合には、監視情報の送信先を元の送信先に戻すように構成されている。

特開２０１１−１３５５５２号公報

クライアント−サーバシステムにおいては、サーバは、クライアントからのリクエストを受けて動作し、応答を返すのが一般的である。サーバが提供するサービスの接続先が変更になる場合には、クライアントは、クライアントから各サービスへリクエストが発行された際のレスポンスで、サービスの接続先の変更が通知され、サービスの接続先を再取得することで接続先を切り替える。

クライアントは、サービスを利用するタイミングで、サービスに接続を行う。
画像形成装置の出力実績を管理する出力管理サービスであれば、１日１回など定期的に送信を行うことが考えられる。
一方で、出力ドキュメントを変換して提供するドキュメント変換サービスなどは、画像形成装置を利用するユーザからの操作によりリクエストが発行されるために、ユーザの利用状況によっては、なかなかサービスにリクエストが送信されない場合がある。そのため、そのようなサービスについては、クライアントの持つサービスの接続先がなかなか切り替わらない可能性が考えられる。

クライアントの持つサービスの接続先が切り替わらないままに、変更前の接続先を閉じてしまうと、クライアントに接続先の変更を通知できなくなってしまう。そのため、変更前の接続先はサービスを利用する全てのクライアントからリクエストを受信するまで、変更前の接続先を閉じることができない。変更前と変更後の接続先を同一のサーバで運用している場合は良いが、サービスを提供するサーバごと別のサーバに切り替えるようなケースもある。そのようなケースでは、各サービスで全てのクライアントからリクエストを受信するまで、クライアントへの接続先の変更の通知のために変更前のサーバを維持しなければならず、その維持のためのコストやメンテナンスの負荷もかかってしまう。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、管理システムが提供するサービスを利用する情報処理装置への接続先の変更の通知のために変更前の管理システムを長期で維持することなく、サービスを提供する管理システムごと別の管理システムに切り替え可能な仕組みを提供することである。

本発明は、複数のサービスモジュールが動作する情報処理装置と、第１管理システムを含むネットワークシステムであって、前記情報処理装置は、前記複数のサービスモジュールのそれぞれの第１管理システムに対する接続先を示す情報と、接続先を問い合せるための接続情報とを管理する管理手段と、前記いずれかのサービスモジュールにより、要求を送信する要求手段と、前記要求に対する前記第１管理システムから受信した応答が接続先の変更を通知するための所定の応答であった場合に、該所定の応答で指定された接続先の問い合せ先を示す情報を利用して、新たな接続先を取得する第１取得手段と、前記管理手段で管理される、前記要求を送信したサービスモジュールの接続先を示す情報を前記第１取得手段により取得された新たな接続先を示す情報に更新し、前記接続情報を前記所定の応答で指定された接続先の問い合せ先を示す情報に更新する更新手段と、前記管理手段で管理される、前記更新手段により接続先を示す情報が更新されたサービスモジュール以外のサービスモジュールの接続先を示す情報を削除または所定値に変更する第１変更手段と、を有し、前記要求手段は、前記第１取得手段により取得された新たな接続先に対して、要求を送信し、前記第１管理システムは、前記要求を受信した場合に、接続先の問い合せ先を示す情報を指定した前記所定の応答を送信する応答手段を有する、ことを特徴とする。

本発明によれば、管理システムが提供するサービスを利用する情報処理装置への接続先の変更の通知のために変更前の管理システムを長期で維持することなく、サービスを提供する管理システムごと別の管理システムに切り替えることができる。

本実施例のネットワークシステムの構成を例示する図 サービス提供サーバ、サービス利用クライアントのハードウェア構成図 サービス提供サーバ、サービス利用クライアントのソフトウェア構成図 実施例１のサービス利用クライアントがサービス提供サーバへリクエストを発行するときの処理を示すフローチャート 実施例２のサービス利用クライアントがサービス提供サーバへリクエストを発行するときの処理を示すフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。

図１は、本発明の一実施例を示すネットワークシステムの構成を例示する図である。
図１に示すように、本発明のネットワークシステムとしてのサービス接続管理システムは、サービス提供サーバ１１０、１１１とサービス利用クライアント１２０を有する。

サービス提供サーバ１１０、１１１は、それぞれ、クライアントからのリクエストに応じて種々のサービスを提供するウェブＡＰＩ(Application Programming Interface）を持ち、サービス利用クライアント１２０へ公開、提供している管理システムである。サービス提供サーバ１１０、１１１は、契約などにより利用が許可される単位ごとにサービスが分かれ、例えば、画像形成装置の出力実績を管理する出力管理サービスや、出力ドキュメントを変換して提供するドキュメント変換サービスなどを提供する。なお、サービス提供サーバ１１０、１１１は、それぞれ、複数のサーバから構成されていてもよく、例えばクラウドシステムであってもよい。

サービス利用クライアント１２０は、例えば、画像形成装置、或いは画像形成装置と互いに通信可能に接続されて稼働状況を監視する監視クライアントである。サービス利用クライアント１２０は、サービス提供サーバ１１０、１１１とインターネットなどの通信回線１３０を介して接続される。サービス利用クライアント１２０は、サービス提供サーバ１１０、１１１の公開するウェブＡＰＩにリクエストを送信することで、提供されるサービスを利用する。

なお、サービス利用クライアント１２０は、画像形成装置や画像形成装置の稼働状況を監視する監視クライアントに限定されるものではない。サービス利用クライアント１２０は、サービス提供サーバ１１０，１１１等により提供される複数のサービスを利用する情報処理装置であれば、どのような装置であってもよい。例えば、ネットワークカメラ、ナビゲーションシステム、テレビジョン等のネットワーク家電などであっても、これらの装置を監視する装置であってもよい。また、サービス利用クライアント１２０は、通常、複数存在する。

サービス提供サーバ１１０、１１１が公開するウェブＡＰＩは、しばしば機能追加のバージョンアップや構成変更が行われるために、接続先が切り替わることがある。特に、故障やインフラ構成の変更などの要因でサービスを提供するサーバ自身が別のサーバへの変更を必要とするような場合には、サービス提供サーバ１１０のサービスを、別のサービス提供サーバ１１１に移動させる必要が生じる。このような場合には、サービス利用クライアント１２０の保持する接続先を、サービス提供サーバ１１０のサービスから別のサービス提供サーバ１１１のサービスへと、利用する全てのサービスで切り替えることになる。

即ち、本実施例では、サービス提供サーバ１１０ごと別のサービス提供サーバ１１１に切り替えるようなケースを想定している。そして、一部にクライアントからの定期的なリクエストが発生しないサービスがある場合でも、クライアントへの接続先の変更の通知のために変更前のサーバを長期で維持する必要がなく、安全にサービスの接続先を変更できる仕組みを提供することを目的とする。

本実施例では、サービス提供サーバ１１１は、サービス提供サーバ１１０を置き換えるサーバであり、サービス提供サーバ１１１もサービス提供サーバ１１０と同様のハードウェア構成を備えるものとする。以下、サービス提供サーバ１１０、１１１のハードウェア構成について説明する。

図２（Ａ）は、サービス提供サーバ１１０、１１１のハードウェア構成を例示する図である。
サービス提供サーバ１１０は、出力Ｉ／Ｆ部２０１、入力Ｉ／Ｆ部２０２、記憶装置２０３、メモリ２０４、ＣＰＵ２０５、通信Ｉ／Ｆ部２０６等を有する。

出力Ｉ／Ｆ部２０１は、ディスプレイなどの出力装置と接続するためのインタフェースである。入力Ｉ／Ｆ部２０２は、キーボードやポインティングデバイスなどの入力装置と接続するためのインタフェースである。通信Ｉ／Ｆ部２０６は、ネットワークなどに接続するためのインタフェースである。

記憶装置２０３は、例えばハードディスクドライバブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）等である。記憶装置２０３には、ＯＳ（Operating System）や、サービス利用クライアント１２０からのリクエストを受け付けてサービスを提供するためのサービスアプリケーション等の各種プログラムや、各種データなどが格納される。

ＣＰＵ２０５は、記憶装置２０３からＯＳやサービスアプリケーション等のプログラムをメモリ２０４にロードし、実行することにより、各種制御を実現する。
通信Ｉ／Ｆ部２０６は、通信回線１３０に接続され、サービス利用クライアント１２０と、ＳＯＡＰプロトコルやＲＥＳＴアーキテクチャスタイルなどにより相互にメッセージの送受信を行う。

図２（Ｂ）は、サービス利用クライアント１２０のハードウェア構成を例示する図である。
サービス利用クライアント１２０は、出力Ｉ／Ｆ部２１１、入力Ｉ／Ｆ部２１２、記憶装置２１３、メモリ２１４、ＣＰＵ２１５、通信Ｉ／Ｆ部２１６等を有する。

出力Ｉ／Ｆ部２１１は、ディスプレイなどの出力装置と接続するためのインタフェースである。入力Ｉ／Ｆ部２１２は、キーボードやポインティングデバイスなどの入力装置と接続するためのインタフェースである。通信Ｉ／Ｆ部２１６は、ネットワークなどに接続するためのインタフェースである。

記憶装置２１３は、例えばＨＤＤやＳＳＤ等である。記憶装置２０３には、ＯＳや、サービス提供サーバ１１０の提供するサービスに接続して利用するためのサービス利用アプリケーション等の各種プログラムや、各種データなどが格納される。

ＣＰＵ２１５は、記憶装置２１３からＯＳやサービス利用アプリケーション等のプログラムをメモリ２１４にロードし、実行することにより、各種制御を実現する。
通信Ｉ／Ｆ部２１６は、通信回線１３０に接続され、サービス提供サーバ１１０、１１１とのメッセージの送受信を行う。

図３（Ａ）は、サービス提供サーバ１１０上で動作するサービスアプリケーションをはじめとするソフトウェア構成の中で、特に本発明に係る部分の機能ブロックを例示する図である。図３（Ａ）に示す各部は、サービス提供サーバ１１０のＣＰＵ２０５が記憶装置２０３に格納されるプログラムをメモリ２０４にロードして実行することにより実現されるものである。

サービス提供部３０１は、ウェブＡＰＩを公開し、サービス利用クライアント１２０からのリクエストを受け付けてサービスを提供するサービスアプリケーションである。サービス提供サーバ１１０は、複数のサービス提供部３０１を有し、その夫々のサービス提供部３０１ごとにサービスアプリケーションが独立して動作する。

サービス提供サーバ１１０の移転などに伴ってサービス提供サーバ１１０でのウェブＡＰＩの公開を終了し、新たに用意したサービス提供サーバ１１１にその機能を移動させることがある。そのときには、サービス利用クライアント１２０からのリクエストに対してサービス提供部３０１は、サービス提供サーバ１１１への移転を通知するサーバ変更応答を返却する。このサーバ変更応答には、変更後のサーバ（サービス提供サーバ１１１）のアドレス情報が含まれる。サーバ変更応答とは、例えばＨＴＴＰステータスコードで定義される"HTTP 301/Moved Permanently"や"HTTP 308/Permanent Redirect"の応答であり、変更後のサーバのアドレス情報をLocationヘッダにて通知する。

サービス接続先管理部３０２は、複数のサービス提供部３０１が提供するサービスを利用するための夫々の接続先アドレスを、一元的に保持、管理する。サービス接続先管理部３０２は、サービス利用クライアント１２０からの各サービスの接続先の問い合わせを受け付け、各サービスを利用するための接続先アドレスを返却する。サービス接続先管理部３０２が管理する接続先アドレスは、サービス提供サーバ１１０が提供するサービスだけでなく、他のサーバが提供し、サービス利用クライアント１２０が利用するサービスもまとめて管理してもよい。
表１に、サービス接続先管理部３０２が管理するサービスの接続先アドレスの情報の例を示す。

表１において、サービスＩＤは、サービス提供部３０１が提供するサービスを一意に特定するためのＩＤ情報である。そして、表示１は、それぞれのサービスＩＤごとに、対応するサービスのウェブＡＰＩを利用するためのサービス接続先アドレスを保持する。

図３（Ｂ）は、サービス提供サーバ１１１上で動作するサービスアプリケーションをはじめとするソフトウェア構成の中で、特に本発明に係る部分の機能ブロックを例示する図である。なお、サービス提供サーバ１１１は、サービス提供サーバ１１０を置き換えるサーバであり、サービス提供サーバ１１１もサービス提供サーバ１１０と同様の機能ブロックを備える。図３（Ｂ）に示す各部は、サービス提供サーバ１１１のＣＰＵ２０５が記憶装置２０３に格納されるプログラムをメモリ２０４にロードして実行することにより実現されるものである。

サービス提供部３１１は、サービス提供部３０１の置き換えとしてウェブＡＰＩを公開し、サービス利用クライアント１２０からのリクエストを受け付けてサービスを提供するサービスアプリケーションである。サービス提供サーバ１１１は、複数のサービス提供部３１１を有し、その中には従来のサービスアプリケーションの置き換えだけでなく、サービス提供部３０１では提供されていなかった新たなサービスアプリケーションが追加されることもある。

サービス接続先管理部３１２は、複数のサービス提供部３１１が提供するサービスを利用するための夫々の接続先アドレスを、一元的に保持、管理する。サービス接続先管理部３１２は、サービス利用クライアント１２０からの各サービスの接続先の問い合わせを受け付け、各サービスを利用するための接続先アドレスを返却する。サービス接続先管理部３１２が管理する接続先アドレスは、サービス提供サーバ１１１が提供するサービスだけでなく、他のサーバが提供し、サービス利用クライアント１２０が利用するサービスもまとめて管理してもよい。

図３（Ｃ）は、サービス利用クライアント１２０上で動作するサービス利用アプリケーションのソフトウェア構成の中で、特に本発明に係る部分の機能ブロックを例示する図である。図３（Ｃ）に示す各部は、サービス利用クライアント１２０のＣＰＵ２１５が記憶装置２１３に格納されるプログラムをメモリ２１４にロードして実行することにより実現されるものである。

サービス接続先保持部３５１は、サービス提供サーバ１１０から各サービスの接続先アドレスを取得するための取得先アドレスと、サービス提供サーバ１１０から取得した各サービスのサービス接続先アドレスを保持する。
表２に、サービス接続先保持部３５１が保持するアドレス情報の例を示す。

表２において、サービスＩＤは、サービス利用クライアント１２０が利用するサービスのＩＤ情報である。そして、表２は、それぞれのサービスＩＤごとに、対応するサービスのウェブＡＰＩを利用するためのサービス接続先アドレスを保持する。

表２に保持されるアドレス情報のうち、「アドレス取得先」は、サービス提供サーバ１１０から各サービスの接続先アドレスを取得するための取得先アドレス（接続情報）であり、予め登録されている情報である。他のアドレス情報は、サービスの利用開始に伴って取得先アドレスを利用してサービス提供サーバ１１０から取得した各サービスのサービス接続先アドレスである。なお、サービスへのリクエストの度に、サービス接続先アドレスを取得するのでは効率的とはいえないため、取得したサービス接続先アドレスをサービス接続先保持部３５１に保持して、次回以降のリクエストの際に再利用できるようにしている。表２の例では、サービス利用クライアント１２０は、２つのサービス「BasicService」、「Service-B」を利用するため、その各々のサービスの接続先アドレスをサービス提供サーバ１１０から取得し、サービス接続先保持部３５１に保持している。このように、サービス接続先保持部３５１は、複数のサービスモジュールのそれぞれのサービス提供サーバの接続先を示す情報（サービス接続先アドレス）と、接続先の問い合せるための接続情報（アドレス取得先）とを管理する。

サービス利用アプリケーション動作部３５２は、サービス提供サーバ１１０が提供するサービスを利用するサービス利用アプリケーション（サービスモジュール）であり、サービスへのリクエスト送信を指示する。サービス利用クライアント１２０は、しばしば利用するサービスごとなどの単位で、複数のサービス利用アプリケーション動作部３５２から構成され、夫々のサービス利用アプリケーション動作部３５２が独立して動作する。

サービス接続先取得部３５３は、各々のサービス利用アプリケーション動作部３５２からのサービスへのリクエスト送信の指示を受けて動作し、リクエストを送信するための当該サービスの接続先アドレスを取得する。このとき、サービス接続先取得部３５３は、サービス接続先保持部３５１が接続先アドレスを保持していれば、サービス接続先保持部３５１から、その接続先アドレスを取得する。一方、サービス接続先保持部３５１が接続先アドレスを保持していなければ、サービス接続先取得部３５３は、サービス提供サーバ１１０へ当該サービスの接続先アドレスを問い合わせる。

サービスリクエスト送信部３５４は、サービス接続先取得部３５３が取得した接続先アドレス宛てに、サービス利用アプリケーション動作部３５２からの指示に従ってリクエストを送信する。
サービス接続先更新部３５５は、サービスリクエスト送信部３５４のリクエストへの応答でサービス提供サーバ１１０の移転通知応答を受信した場合に動作し、サービス接続先保持部３５１の保持する接続先アドレスの更新処理を行う。

以下、図４のフローチャートに従って、サービス利用アプリケーション動作部３５２からの指示によってサービス提供サーバ１１０の提供するサービスへリクエストを送信するときのサービス利用クライアント１２０の接続先管理処理を説明する。
図４は、実施例１においてサービス利用クライアント１２０がサービス提供サーバ１１０の提供するサービスへの接続先管理処理の一例を示すフローチャートである。なお、このフローチャートの処理は、サービス利用クライアント１２０のＣＰＵ２１５が記憶装置２１３に格納されるプログラムをメモリ２１４にロードして実行することにより実現されるものである。

サービスリクエスト送信部３５４は、サービス利用アプリケーション動作部３５２からサービスへのリクエスト送信の指示を受けると、該リクエスト送信の指示に基づいて、接続するサービスを特定する（Ｓ４０１）。
サービスリクエスト送信部３５４は、特定したサービスのサービスＩＤに対応するサービス接続先アドレスを、サービス接続先取得部３５３に要求する。サービス接続先取得部３５３は、該サービスＩＤに対応するサービス接続先アドレスをサービス接続先保持部３５１から取得するよう試みる。

そして、サービス接続先取得部３５３は、サービス接続先保持部３５１からサービス接続先アドレスを取得できたか否かを判断する（Ｓ４０２）。サービス接続先取得部３５３は、サービス接続先保持部３５１に該当するサービスのサービス接続先アドレスが格納されておらず取得できなかった場合、又は、所定値を取得した場合には、サービス接続先アドレスなし（Ｓ４０２でＮｏ）と判断する。一方、サービス接続先取得部３５３は、サービス接続先保持部３５１からサービス接続先アドレス（所定値以外）を取得した場合には、サービス接続先アドレスあり（Ｓ４０２でＹｅｓ）と判断する。なお、上述の所定値は、予め決められた値であり、サービス接続先アドレスとなり得ないような値であればどのような値であってもよい。

サービス接続先取得部３５３は、サービス接続先保持部３５１からサービス接続先アドレス（所定値以外）を取得した場合（Ｓ４０２でＹｅｓの場合）、該サービス接続先アドレスをサービスリクエスト送信部３５４に返却する。サービスリクエスト送信部３５４は、サービス接続先保持部３５１からサービス接続先アドレスが返却されると、Ｓ４０５に処理を進める。

一方、サービス接続先取得部３５３は、サービス接続先保持部３５１からサービス接続先アドレスを取得できなかった（又は、所定値を取得した）場合（Ｓ４０２でＮｏの場合）、Ｓ４０３に処理を進める。

Ｓ４０３において、サービス接続先取得部３５３は、サービス接続先保持部３５１の保持する「アドレス取得先」に対して該サービスの接続先アドレスを問い合わせ、該サービスの接続先アドレスを取得する。該接続先アドレスが取得できたら、サービス接続先取得部３５３は、該接続先アドレスをサービス接続先保持部３５１に保存するとともに、該接続先アドレスをサービスリクエスト送信部３５４に返却する。サービスリクエスト送信部３５４は、サービス接続先保持部３５１からサービス接続先アドレスが返却されると、Ｓ４０５に処理を進める。なお、上記Ｓ４０３、Ｓ４０４では、上記Ｓ４０１で特定されたサービスの接続先のみでなく、前記「アドレス取得先」から取得できる全ての接続先のそれぞれについて、接続先アドレスを取得し、サービス接続先取得部３５３に保存するようにしてもよい。例えば、サービス接続先保持部３５１が保持するアドレス情報（例えば表２）を取得して、サービス接続先取得部３５３を更新するようにしてもよい。また、サービス接続先取得部３５３は、サービス接続先保持部３５１にサービス接続先アドレスが保存されていない（又は、所定値が保存されている）全てのサービスＩＤに対応するサービス利用アプリケーション動作部３５２のそれぞれについて、接続先アドレスを取得し、サービス接続先取得部３５３に保存するようにしてもよい。

Ｓ４０５において、サービスリクエスト送信部３５４は、サービス接続先取得部３５３から返却された接続先アドレス宛てに（即ちサービス提供サーバ１１０の提供するサービスへ）、リクエストを送信する。

次に、Ｓ４０６において、サービスリクエスト送信部３５４は、サービスへのリクエストの応答で、変更後のサーバ（サービス提供サーバ１１１）のアドレス情報を含むサーバ変更応答を受け取ったか否かを判断する。
そして、上記サーバ変更応答を受け取っていないと判断した場合（Ｓ４０６でＮｏの場合）、サービスリクエスト送信部３５４は、本フローチャートの処理を終了し、サービス利用クライアント１２０において応答内容に基づく処理が行われる。

一方、上記サーバ変更応答を受け取ったと判断した場合（Ｓ４０６でＹｅｓの場合）、サービスリクエスト送信部３５４は、サービス接続先更新部３５５に処理を渡し、サービス接続先更新部３５５において、Ｓ４０７以降の処理が行われる。

サービス接続先更新部３５５は、まず、上記サーバ変更応答で通知（指定）された変更後のサーバのアドレスに対して、該サービスの接続先アドレスを問い合わせ、該サービスの接続先アドレスを取得する（Ｓ４０７）。このとき、サービス提供サーバ１１１のサービス接続先管理部３１２が、サービス利用クライアント１２０からのサービスの接続先の問い合わせを受け付け、サービス提供部３１１の該サービスを利用するための接続先アドレスを返却する。

次に、サービス接続先更新部３５５は、上記Ｓ４０７で取得した接続先アドレス宛てに（即ちサービス提供サーバ１１１の提供するサービスへ）、改めてリクエストを送信する（Ｓ４０８）。

次に、サービス接続先更新部３５５は、上記Ｓ４０８で送信したサービスへのリクエストの応答で、リクエストがサービス提供サーバ１１１の該サービスで正常に受け付けられて処理されたこと（リクエスト成功）を示す応答を受け取ったか否かを判断する。そして、リクエスト失敗を示す応答を受け取ったと判断した場合（Ｓ４０９でＮｏの場合）、サービス接続先更新部３５５は、本フローチャートの処理を終了する。

一方、リクエスト成功を示す応答を受け取ったと判断した場合（Ｓ４０９でＹｅｓの場合）、サービス接続先更新部３５５は、アドレス情報を更新する（Ｓ４１０）。まず、サービス接続先更新部３５５は、サービス接続先保持部３５１の接続先アドレスのうち、「アドレス取得先」を、上記Ｓ４０５で送信したリクエストへの応答で通知されたサーバのアドレスで更新する。さらに、サービス接続先更新部３５５は、該サービスの接続先アドレスを、上記Ｓ４０７で取得した接続先アドレスで更新する。

次に、Ｓ４１１において、サービス接続先更新部３５５は、上記Ｓ４１０で接続先アドレスを更新したサービス以外のサービスの接続先アドレスをクリア（削除、又は、上述した所定値に更新）する。これにより、変更前の接続先だったサービス提供サーバ１１０のアドレス情報がサービス接続先保持部３５１に残ることを防ぐことができる。

上記Ｓ４１１のようにすることで、その後に、該サービス以外のサービスへのリクエストが発生したときには、サービス接続先保持部３５１にアドレス情報が残っていない（又は所定値となる）ため、Ｓ４０３において、サービス提供サーバ１１１へ接続先アドレスの取得処理が行われる。このように、１つのサービスでサーバ変更応答を受け取れば、変更前の接続先だったサービス提供サーバ１１０へのリクエストが発生しなくなる。よって、特定の条件下でしかリクエストの発生しないサービスが存在していても、そのサービスのためだけに変更前のサーバを維持しなくて済むようになる。

なお、本実施例において、Ｓ４１１では、該サービス以外の全てのサービスの接続先アドレスをクリアする構成について説明した。しかし、サービス提供サーバ１１０以外が提供するサービスも利用している場合もある。そのような場合を想定し、Ｓ４１１では、該サービスの接続先アドレスと同一ドメインのアドレスのみをクリアするようにしてもよい。また、特定の条件下でしかリクエストの発生しないサービスが予めわかっているのであれば、そのサービスを登録等しておき、そのサービスの接続先アドレスのみをクリアするようにしてもよい。

以上、実施例１のクライアント通信管理システムにおいて、サービス利用クライアント１２０は、１つのサービスモジュールでサーバ変更応答を受け取ったら、該サービスモジュールの接続先アドレスを更新するとともに、該サービスモジュール以外のサービスモジュールの接続先アドレスをクリアする。このような構成により、一部にクライアントからの定期的なリクエストが発生しないサービスがあっても、クライアントに変更前のサービスの接続先アドレスが残ることがなくなる。よって、クライアントへの接続先の変更の通知のために、変更前のサーバを長期で維持する必要がなくなり、維持のためのコストやメンテナンスの負荷を抑え、安全にサービスの接続先を変更できるクライアント通信管理システムを構築できる。

上述した実施例１では、サービスの接続先アドレスの変更形態として、サービス提供サーバ１１０ごと別のサービス提供サーバ１１１へ切り替わるようなケースを想定したものであった。しかし、サービスアプリケーションのバージョンアップなどで、サービス提供サーバ１１０の提供する複数のサービスのうち、一部のサービスのみを別の接続先アドレスへ変更するようなケースもある。このケースでは、サービス接続先管理部３０２は、そのままサービス提供サーバ１１０に維持されるため、各サービスの接続先アドレスを取得するための取得先アドレスである「アドレス取得先」の変更は伴わない。このような場合に、サービス提供サーバ１１０ごと別のサービス提供サーバ１１１へ切り替わることを前提としたアドレス更新処理（実施例１）は、一旦全サービスの接続先アドレスをクリアすることになり処理のオーバーヘッドが大きくなる。

そこで、実施例２では、一部のサービスのみを別の接続先アドレスへ変更するケースを考慮した実施の形態を説明する。
実施例２のシステム構成図は図１と、ハードウェア構成は図２（Ｂ）、図２（Ｂ）と同一である。サービス提供サーバ１１０、１１１やサービス利用クライアント１２０のソフトウェア構成も、それぞれ図３（Ａ）、図３（Ｂ）、図３（Ｃ）と同一である。以下、実施例１と異なる部分のみ説明する。

以下、図５のフローチャートに従って、実施例２において、サービス利用アプリケーション動作部３５２からの指示によってサービス提供サーバ１１０の提供するサービスへリクエストを送信するときのサービス利用クライアント１２０の接続先管理処理を説明する。
図５は、実施例２においてサービス利用クライアント１２０がサービス提供サーバ１１０の提供するサービスへの接続先管理処理の一例を示すフローチャートである。なお、このフローチャートの処理は、サービス利用クライアント１２０のＣＰＵ２１５が記憶装置２１３に格納されるプログラムをメモリ２１４にロードして実行することにより実現されるものである。

まず、Ｓ５０１〜Ｓ５０５は、図４のＳ４０１〜Ｓ４０５と同一の処理であるので説明を省略する。
Ｓ５０６において、サービスリクエスト送信部３５４は、サービスへのリクエストの応答で、サービスへ接続できなかったことを示す応答（接続エラー応答）を受け取ったか否かを判断する。そして、上記接続エラー応答を受け取ったと判断した場合（Ｓ５０６でＹｅｓの場合）、サービスリクエスト送信部３５４は、サービス接続先更新部３５５に処理を渡し、サービス接続先更新部３５５において、Ｓ５０７以降の処理が行われる。

Ｓ５０７において、サービス接続先更新部３５５は、上記サーバ変更応答を受け取ったサービスの接続先アドレスをクリア（削除、又は、所定値に更新）し、再びサービス接続先取得部３５３に処理を戻し、サービス接続先取得部３５３において、Ｓ５０２以降の処理（該サービスの接続先アドレス取得の処理）が行われる。

なお、上記サービスへ接続できなかったことを示す応答（接続エラー応答）とは、例えばＨＴＴＰステータスコードで定義される"HTTP 404/Not Found"や"HTTP 410/Gone"の応答である。サービス提供サーバ１１０が該サービスへのリクエストに対して、サービス利用クライアントに接続先アドレスの変更処理を動作させるために意図的にこれらの応答を返すようにしてもよい。

一方、上記Ｓ５０６において、接続エラー応答を受け取っていないと判断した場合（Ｓ５０６でＮｏの場合）、サービスリクエスト送信部３５４は、Ｓ５０８に処理を進める。なお、Ｓ５０８〜Ｓ５１３は、図４のＳ４０６〜Ｓ４１１と同一の処理であるので説明を省略する。

以上のように、サービスへのリクエスト時の応答（接続エラー応答、サーバ変更応答など）により、サービス接続先更新部３５５の接続先アドレスの更新処理を変えることで、一部のサービスのみを別の接続先アドレスへ変更する場合にも対応可能となる。また、一部のサービスの接続先アドレスが無効になった場合であっても、該サービスの接続先アドレスを更新させることができる。このように、一部にクライアントからの定期的なリクエストが発生しないサービスがあっても、変更前のサービスの接続先アドレスに繋がらなければ変更後のサーバに接続先アドレスを再取得させることができる。接続先アドレスの変更を通知するために変更前のサーバを残す必要がないので、変更前のサーバを長期で維持することなしに、安全にサービスの接続先を変更できるクライアント通信管理システムを提供できる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

Claims (9)

1. 複数のサービスモジュールが動作する情報処理装置と、第１管理システムを含むネットワークシステムであって、
   前記情報処理装置は、
   前記複数のサービスモジュールのそれぞれの第１管理システムに対する接続先を示す情報と、接続先を問い合せるための接続情報とを管理する管理手段と、
   前記いずれかのサービスモジュールにより、要求を送信する要求手段と、
   前記要求に対する前記第１管理システムから受信した応答が接続先の変更を通知するための所定の応答であった場合に、該所定の応答で指定された接続先の問い合せ先を示す情報を利用して、新たな接続先を取得する第１取得手段と、
   前記管理手段で管理される、前記要求を送信したサービスモジュールの接続先を示す情報を前記第１取得手段により取得された新たな接続先を示す情報に更新し、前記接続情報を前記所定の応答で指定された接続先の問い合せ先を示す情報に更新する更新手段と、
   前記管理手段で管理される、前記更新手段により接続先を示す情報が更新されたサービスモジュール以外のサービスモジュールの接続先を示す情報を削除または所定値に変更する第１変更手段と、を有し、
   前記要求手段は、前記第１取得手段により取得された新たな接続先に対して、要求を送信し、
   前記第１管理システムは、
   前記要求を受信した場合に、接続先の問い合せ先を示す情報を指定した前記所定の応答を送信する応答手段を有する、
   ことを特徴とするネットワークシステム。
2. 第１管理システムと通信可能であり、複数のサービスモジュールが動作する情報処理装置であって、
   前記複数のサービスモジュールのそれぞれの第１管理システムに対する接続先を示す情報と、接続先を問い合せるための接続情報とを管理する管理手段と、
   前記いずれかのサービスモジュールにより、要求を送信する要求手段と、
   前記要求に対する前記第１管理システムから受信した応答が接続先の変更を通知するための所定の応答であった場合に、該所定の応答で指定された接続先の問い合せ先を示す情報を利用して、新たな接続先を取得する第１取得手段と、
   前記管理手段で管理される、前記要求を送信したサービスモジュールの接続先を示す情報を前記第１取得手段により取得された新たな接続先を示す情報に更新し、前記接続情報を前記所定の応答で指定された接続先の問い合せ先を示す情報に更新する更新手段と、
   前記管理手段で管理される、前記更新手段により接続先を示す情報が更新されたサービスモジュール以外のサービスモジュールの接続先を示す情報を削除または所定値に変更する第１変更手段と、を有し、
   前記要求手段は、前記第１取得手段により取得された新たな接続先に対して、要求を送信することを特徴とする情報処理装置。
3. 前記サービスモジュールの接続先を示す情報が、前記管理手段に存在しない、又は、所定値であった場合には、前記管理手段により管理される接続情報を利用して、該サービスモジュールの接続先を示す情報を取得する第２取得手段を有することを特徴とする請求項２に記載の情報処理装置。
4. 前記第２取得手段は、前記複数のサービスモジュールのそれぞれについて、接続先を示す情報を取得することを特徴とする請求項３に記載の情報処理装置。
5. 前記更新手段は、前記第１取得手段により取得された新たな接続先に対して前記要求手段が行った前記要求の送信が失敗であった場合には、前記新たな接続先を示す情報を用いた更新を行わず、前記要求の送信が成功であった場合には、前記新たな接続先を示す情報を用いた更新を行うことを特徴とする請求項２乃至４のいずれか１項に記載の情報処理装置。
6. 前記要求に対する前記第１管理システムから受信した応答が接続先に対応するサービスへ接続できなかったことを示す応答であった場合に、前記管理手段により管理される、該接続先を示す情報を削除または所定値に変更する第２変更手段を有することを特徴とする請求項２乃至５のいずれか１項に記載の情報処理装置。
7. 前記第１管理システムからの前記所定の応答で指定された接続先の問い合せ先を示す情報を利用して取得された前記新たな接続先は、前記第１管理システムとは異なる第２管理システムの接続先を示すことを特徴とする請求項２乃至６のいずれか１項に記載の情報処理装置。
8. 第１管理システムと通信可能であり、複数のサービスモジュールが動作し、該複数のサービスモジュールのそれぞれの第１管理システムに対する接続先を示す情報と、接続先を問い合せるための接続情報とを管理する情報処理装置における制御方法であって、
   前記いずれかのサービスモジュールにより、要求を送信する要求ステップと、
   前記要求に対する前記第１管理システムから受信した応答が接続先の変更を通知するための所定の応答であった場合に、該所定の応答で指定された接続先の問い合せ先を示す情報を利用して、新たな接続先を取得する第１取得ステップと、
   前記要求を送信したサービスモジュールの接続先を示す情報として管理された情報を前記第１取得ステップで取得された新たな接続先を示す情報に更新し、前記管理された接続情報を前記所定の応答で指定された接続先の問い合せ先を示す情報に更新する更新ステップと、
   前記更新ステップで接続先を示す情報が更新されたサービスモジュール以外のサービスモジュールのために管理された接続先を示す情報を削除または所定値に変更する第１変更ステップと、を有し、
   前記要求ステップでは、前記第１取得ステップで取得された新たな接続先に対して、要求が送信されることを特徴とする制御方法。
9. コンピュータを、請求項２乃至７のいずれか１項に記載の手段として機能させるためのプログラム。

Images