JP5437270B2 - 下位互換性の無いサーババージョンをクライアント／サーバコンピューティング環境に展開するための方法およびシステム - Google Patents

Description

本発明は、概して、クライアント／サーバ環境におけるコンピュータシステムに関し、より具体的には、クライアントバージョンとの下位互換性を必要としない、新しいバージョンのサーバソフトウェアアプリケーションの展開に関する。

ネットワーク上に実装されるクライアント／サーバコンピューティングモデルが、いたる所に採用されてきた。このモデルでは、クライアントノードのソフトウェアアプリケーションによって発行される問い合わせは、１つ以上の接続されたサーバに送信される。サーバによって処理されると、問い合わせされた情報がクライアントに返される。このモデルは、クライアントがウェブブラウザであり、かつサーバが、メールサーバ等の多数の特化したサーバを含むウェブサーバである、インターネットのうちの１つである。

このモデルは、概して、場合により、インターネットを含むプライベートおよびパブリックネットワークの組み合わせを通じて、サービスプロバイダのコンピューティングリソース上で実行するソフトウェアアプリケーションのエンドユーザである、クライアントのコミュニティの機能を果たす大量のコンピューティングリソースを動作させる、多数のサービスプロバイダのうちの１つでもある。このようなプロバイダの例には、航空会社、通常およびオンラインの旅行代理店（例えば、旅行の計画および予約用）、および空港（例えば、乗客の出国管理およびチェックイン用）を含む、旅行業界全体に旅行サービスを提供する予約／発券システム（Ｇｌｏｂａｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ：ＧＤＳ）が挙げられる。

ソフトウェアシステムは、概して、それらの寿命にわたって頻繁に更新される。開発段階が完了した後であっても、システムが稼働している時に、修正を加える、および新しい特徴の追加によってそれらを改善するように、ソフトウェアアプリケーションは、進化し続ける。また、新しいタイプの機械の性能を完全に活用するために、またはオペレーティングシステムが新しいか、進化したか、または異なるので、変更を行わなければならない場合がある。

クライアント／サーバモデルでは、サーバ側アプリケーションの新しいバージョンをロールアウトするために、標準的な技法は、新しいバージョンが下位互換性でなければならない。したがって、任意のノードにおいてどのようなクライアントアプリケーションのバージョンが使用されている時であっても、新しいサーバは、展開されると、クライアントの問い合わせを即座に処理し、かつ問い合わせされた情報を互換性がある形式で配信することができる。

この理想的な機構を、世界的なパブリックネットワークの無数のクライアントによって使用される全ての既存のウェブブラウザとの互換性をウェブサーバが必要とする、インターネットにある程度まで適用する。しかし、これが完全に当てはまるわけではない。全てのウェブブラウザブランドが、全く同じように作用するとは限らず、また、多くのサーバは、実際に、クライアントアプリケーションの最新バージョンだけしかサポートしていないことは周知である。例えば、世界で最も多く使用されている、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎによるＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（ＩＥ）の場合、多くの最近のサーバアプリケーションは、現在、バージョン５（ＩＥ５）以上しかサポートしていない。実際に、古いバージョンのブラウザ、またはサポートされていないブラウザブランドが、アップグレードされたサーバから情報を受け取る時に、クライアントのグラフィックユーザインタフェース（ＧＵＩ）が深刻な障害を受ける場合がある。

実際には部分的にしか達成できないにもかかわらず、下位互換性を保持するには、高い費用がかかる。サーバの新しいアプリケーションは、その領域でサポートされる全てのクライアントバージョンの、全てのオプション、特徴、非互換性、および欠陥に何らかの方法で対処しなければならない。これは、新しいサーバアプリケーションを開発するために長い時間と技能を必要とし、また、場合により、より多くのメモリおよびより速いハードウェアリソースを実装することを必要とする、開発段階中に高い費用がかかる。さらに重要なことに、確認するサーバ／クライアントブラウザ組み合わせの数は、試験段階が、妥当な時間量の範囲内で全ての組み合わせの網羅的な試験を可能にするために、不可能な数のリソース（機械および人的資源）の整備が必要となり得る程度まで、急速に増加している。

上述したことは、ウェブブラウザが、「シンクライアント」と呼ばれるクライアントであっても当てはまる。すなわち、要求されたジョブを実行するに際し、サーバアプリケーションとクライアントアプリケーションとの間において、実際には限られた共有作業しか実行しないクライアントであっても当てはまる。実際に、ウェブブラウザの主要なタスクは、ＧＵＩを通じてウェブサーバによって返されるページを表示することである。

公的にアクセスできないクライアント／サーバシステムの場合、概して関連するクライアント（例えば、航空会社、旅行代理店、空港等）だけとしか協働しない、上述のＧＤＳと同様に、クライアントアプリケーションは、むしろ、サーバとクライアントとの間で共有される作業全体のうちのより多くの部分を実行しなければならない、「リッチクライアント」であることが必要となる場合がある。それらの間の利用可能な帯域が制限され過ぎて、タスクごとにサーバを求めるクライアントアプリケーションを行うことができないようにしているので、これが必要になる場合がある。ＧＤＳの場合、これは、例えば、航空機の出発および、乗客が搭乗している混雑時に迅速に処理しなければならない作業である、乗客のチェックインを制御するために空港で使用されるクライアントアプリケーションシステムの場合である。実際に、小規模な空港は、依然として限られた外部通信リソースを有する場合がある。また、空港のコンピューティングリソースは、空港当局が所有して、その管理下に置かれ、展開および更新するために承認が必要であり、したがって、チェックインアプリケーションがＧＤＳに関連する航空会社によって使用される場合であっても、時間がかかる。

したがって、クライアントアプリケーションが、作業の大部分をそれ自体で実行するように考案されたリッチクライアントである時、下位互換性があるサーバを有するという問題は、不可能ではないとしても、シンクライアントによるものよりも、達成がさらに困難になる場合がある。実際に、サポートされる全てのバージョンのリッチクライアントアプリケーションのオプションおよび特徴の数は、潜在的に非常に大きくなり、したがって、サーバアプリケーションの開発および試験段階に関して上述した問題を一層悪化させる。

ＵＳ−Ａ−５．７３２．２７５は、ソフトウェアプログラムを管理し、かつ自動的に更新するための方法および装置を開示している。この文献は、サーバソフトウェアアプリケーションの新しい下位互換性の無いバージョンの展開前に、ネットワークの全てのクライアントソフトウェアアプリケーションを適合させるという問題には対処していない。この先行技術によれば、クライアントアプリケーションは、共有メモリからソフトウェアバージョンを自動的に行うことができるものと仮定されている。これが、この技術の応用範囲を制限しているのに対して、本発明は、制限されたソフトウェアリソースを伴う、かなりのダム端末を含むネットワークに適用することができる。

ＷＯ０１／６９３８２Ａは、クライアントデバイスを初期構成するための方法を開示している。この公報によれば、クライアントアプリケーションを初期構成するために、新しいテンプレートがダウンロードされる。このテンプレートは、クライアントアプリケーションを、サーバソフトウェアアプリケーション自体の新しいバージョンではなく、新しい形式のデータ編成に適合させることを意図している。

したがって、以上のことを考慮すると、クライアント／サーバ環境では、下位互換性がある必要の無い、新しいバージョンのサーバアプリケーションの展開を可能にすることが望ましい。

本発明のさらなる目的、特徴、および利点は、添付図面を参照して以下の説明を考察すれば、当業者に明らかになるであろう。あらゆる付加的な利点が本明細書に組み込まれることが意図されている。

下位互換性があるサーバをクライアント／サーバネットワーキング環境内に展開しなければならないといった上述の問題点は、アプリケーションサーバのソフトウェアプログラムの新しい下位互換性の無いバージョンの、クライアント／サーバネットワーキング環境内への導入を管理するための方法およびシステムを説明する、本発明によって対処される。
該方法は、最初に、アプリケーションサーバのソフトウェアプログラムの新しい下位互換性の無いバージョンが提供されるクライアントシステムに、アプリケーションサーバの現在バージョンと互換性があるモード、および新しい下位互換性の無いバージョンと互換性があるモードで動作可能である、クライアントアプリケーションを配布するステップから成る。
クライアントシステムへの組み込みに応じて、クライアントアプリケーションは、アプリケーションサーバの現在バージョンと互換性がある、ダウングレードモードに設定される。
アプリケーションサーバの現在バージョンが依然として稼動中である間、クライアントアプリケーションは、ダウングレードモードで動作し続ける。
アプリケーションサーバの新しい下位互換性の無いバージョンの導入に応じて、クライアントアプリケーションは、アプリケーションサーバの新しいバージョンと互換性がある、有効モードに設定される。
その時点から、クライアントアプリケーションは、有効モードで動作する。モードの設定は、クライアント／サーバネットワーキング環境内で動作するバージョンサーバに問い合わせるクライアントシステムの再起動ごとに、自動的にトリガされる。
問い合わせは、クライアントシステムをダウングレードモードおよび有効モードを含むモードで動作させるように、問い合わせられたバージョンサーバからステータス値を得るために、クライアントシステムの識別と、クライアントアプリケーションのバージョン番号とを含む。

付加的だが純粋に任意選択である本発明の実施形態によれば、該方法は、以下の通りである。
−設定ステップは、クライアントシステムの再起動ごとに自動的にトリガされ、
クライアント／サーバネットワーキング環境で動作するバージョンサーバに問い合わせるステップであって、該問い合わせは、クライアントシステムの識別を含み、クライアントアプリケーションのバージョン番号をさらに含む、ステップと、
クライアントシステムをダウングレードモードおよび有効モードを含むモードで動作させるように、問い合わせられたバージョンサーバからステータス値を得るステップとをさらに含む。
−問い合わせは、統計を確立するように、クライアントシステムに関する地理的位置、ユーザ識別、およびあらゆる種類の情報をさらに含む。
−問い合わせ内容は、バージョンサーバのデータベース内に格納される。
−クライアントシステムの再起動は、アプリケーションサーバのソフトウェアプログラムの新しい下位互換性の無いバージョンが稼働された時に、アプリケーションサーバを動作させるサービスプロバイダによって強制される。
−クライアントシステムの再起動は、アプリケーションサーバのソフトウェアプログラムの新しい下位互換性の無いバージョンがロードされた時に、自動的に強制される。
−クライアントシステムの再起動は、前バージョンに関するフォールバックの場合に、自動的に強制される。
−クライアントアプリケーションは、クライアントシステムを無効モードで動作させるように、バージョンサーバからステータス値を受け取る。
−得るステップは、 バージョンサーバにおいて、
メタ規則に対してクライアントアプリケーションのバージョン番号を確認して、メタ規則が指定するものよりも古いクライアントアプリケーションが無効であると即時に宣言する、先行ステップを含む。
−メタ規則の確認が成功した場合に、
一組の互換性規則に対してクライアントアプリケーションのバージョン番号を確認するステップと、
規則の内容に従って、互換性規則に関係するクライアントアプリケーションが、無効、非推奨、またはダウングレードであると宣言するステップと、
そうでない場合は、いかなる互換性規則にも関係しないクライアントアプリケーションが、有効であると宣言するステップとを含む。
−得るステップは、１つ以上のクライアントアプリケーションの問題を修正するように、パッチをさらに配信する。
−パッチは、クライアントシステムが再起動されるたびに、動的に適用される。
−クライアントアプリケーションは、グラフィックユーザインタフェースを含む。

本発明は、アプリケーションサーバのソフトウェアプログラムの新しい下位互換性の無いバージョンの、該方法の各ステップを実行するために適合される手段を備える、バージョンサーバと、データベースとを含むクライアント／サーバネットワーキング環境内への導入を管理するためのシステムにも関する。

本発明は、アプリケーションサーバのソフトウェアプログラムの新しい下位互換性の無いバージョンの、クライアント／サーバネットワーキング環境内への導入を管理するための方法を、少なくとも１つのコンピュータに動作させるための、コンピュータで読み取り可能なコード手段を備える、コンピュータで読み取り可能な記憶媒体に格納されるコンピュータプログラム製品にも関する。

図１は、バージョンサーバおよびデータベースを含むＧＤＳに基づく、本発明による例示的なシステムを説明する図である。 図２は、クライアントアプリケーションおよびＧＵＩが、稼働中のサーババージョンに依存して、どのように動作しなければならないのかを決定する、クライアントノードでの方法の主要なステップのハイレベル図である。 図３は、ログイン時に問い合わせが発行されたクライアントシステムに起因するステータスを、バージョンサーバがどのように管理するのかを論じる図である。 図４は、バージョンサーバの使用によってもたらされる機能拡張である、クライアントシステムのオンラインパッチングを説明する図である。

以下の本発明の詳細な説明は、添付図面を参照する。説明は、例示的実施形態を含むが、他の実施形態が可能であり、本発明の精神と範囲から逸脱することなく、説明される実施形態に対して変更が行われ得る。

図１は、発明の背景の項で論じられるＧＤＳ（１００）による、例示的なシステムを説明する。クライアント／サーバ環境内のネットワークを通じてサービスを提供するＧＤＳまたはあらゆる同等のシステムは、多数の遠隔設置されたクライアントアプリケーション（１２０）（クライアントのレベルで動作するソフトウェアアプリケーション）およびシステム（１２２）をサポートするように、概して大量のコンピューティングリソース（１１０）から、サーバを実装する。本発明を示すために用いられるこの特定の実施例では、クライアントシステムは、例えば乗客が航空機に搭乗している時に使用される、空港出発制御システム（ＤＣＳ）である。接続は、インターネットを含む、プライベートおよびパブリックネットワークの任意の組み合わせを場合により含む、ワイドエリアネットワーク（ＷＡＮ）を通じて、サーバとクライアントとの間で保持される（１３０）。コンピューティングリソースは、例えば、プライベートローカルエリアネットワークまたはＬＡＮ（１０５）と全て相互接続される。同様に、ローカルな一組のクライアントアプリケーションは、例えば空港ＬＡＮ（１２５）といったＬＡＮを通じて総合接続することができ、一方で、独立した複数組のクライアントアプリケーションは、ＷＡＮ（１３０）を通じてＧＤＳと通信する。クライアントアプリケーションとのインターフェースは、本実施例では、ゲートウェイ（１０１）を通じて実行され、クライアントが、本明細書で上述したＤＣＳアプリケーションを含むＧＤＳによって提供される全てのアプリケーション（１０９）にアクセスできるようにする。このようなシステムは、一般的に、接続しようとするそのクライアントアプリケーションが、正規のものであり、かつサポートされるアプリケーション（１０９）のうちのいずれかと協働することが許可される、予想される認証を提供できることを確認するように意図された、ログオンおよびセキュリティサーバ、またはＬＳＳ（１０３）を含む。

本説明では、アプリケーションサーバのソフトウェアプログラムは、その機能を実行するようにアプリケーションサーバのレベルで使用される、ソフトウェアリソースを意味する。明示的に示された場合を除き、「アプリケーションサーバのアプリケーションプログラムのソフトウェアプログラム」という用語は、以下、「アプリケーションサーバ」という表現に短縮される場合もある。実際に、サーバがハードウェア構成要素を含む場合であっても、本発明の主題は、ソフトウェア構成要素のバージョンを管理することである。

本発明は、データベース（１０７）と連動して機能するバージョンサーバ（１０５）を導入する。以下の説明で詳述するように、バージョンサーバの役割は、領域内に存在する全てのクライアントアプリケーションのバージョン（１２０）を追跡することである。一般的に、ＧＤＳおよび同等のシステム（１００）は、世界的なＷＡＮ（１３０）を通じて、数千のリモートクライアントアプリケーション（１２０）をインターフェースできるようにされる。クライアント特性は、それらが必要に応じてバージョンサーバによって読み出される、データベース内に格納される。

サーバの下位互換が、不可能であるか、または非常に高価になる時、本発明の方法は、最初に、クライアントアプリケーションおよびＧＵＩのアップグレードバージョンを、全てのリモートクライアントに展開するステップから成る。これは、クライアントアプリケーションの新しいバージョンを、サーバの現在バージョン、およびより新しいバージョンの両方、すなわち全てのものと互換させるという意味を含む。このような機構の場合、新しいサーバは、組み込まれる時に、古いクライアントアプリケーションおよびＧＵＩとの互換性を持つ必要が無くなる。

上述の方策の結果として、展開段階中に（完全な展開は、一般的に、数千のクライアントノードを備えるネットワークにおいて完了するまでに数週間を必要とし得る）、新しいクライアントアプリケーションは、組み込まれる時に、サーババージョンＮに、すなわち、稼働中の現在バージョンまでダウングレードされる。そのステータスは、それに応じて、バージョンサーバ（１０５）のデータベース（１０７）内で、「バージョンＮへのダウングレード」に変更される。したがって、クライアントアプリケーションがクライアントノード内に展開される暫定期間中、既にアップグレードされたノードのそれは、系統的に、すなわちクライアントが再起動されるたびに、現在のサーバと互換性があるバージョンＮを使用している。

分配が完了するか、またはほぼ完了すると、サーバシステム、例えば図１のＧＤＳ（１００）は、エンドユーザの全てまたは少なくとも大部分が、アップグレードされたクライアント／サーバの機能および特徴の活用を開始することができるように、新しいサーバを昇格させることを決定することができる。昇格は、システムの管理者によって手動で行うことができるか、またはソフトウェアのロード時に自動的にトリガすることができる。この場合、バージョンサーバは、サーバの次のバージョン（Ｎ＋１）を稼働させ、クライアントアプリケーションおよびＧＵＩもＮ＋１のレベルで動作させることができるように、データベースにおいてリモートクライアントノードのステータスを「有効」に変更するように指示される。これを達成するために、バージョンサーバは、バージョンＮ（および、もしあれば、古いバージョン）を使用する全てのセッションの切断を強制する。このために、ユーザセッションを終了させて、クライアントアプリケーションおよびＧＵＩの再起動を問い合わせるように、バージョンサーバによって、サインアウトメッセージが各クライアントリモートノードに送られる。次いで、次の再起動時に、本発明の以下の説明にさらに論じられるように、バージョンＮ＋１が自動的に使用される。ここでは、ＧＤＳサービスプロバイダシステムは、必要に応じて少数または多数のクライアントノードを、バージョンサーバを通じて制御する自由度を有することに留意されたい。特定のアップグレードが関係するクライアントノードだけを再起動する必要がある。アップグレード、ダウングレード（例えば、前バージョンに関するフォールバックの場合）、およびバージョンブロッキング（現在バージョンに互換性が無い場合）は、種々の非常に異なるレベルの細かさで実行することができる。これは、全世界、領域、国、都市、空港から、空港内の特定のターミナル、搭乗ゲート、オフィス等のあらゆる識別可能な場所に及び得、したがって、新しいクライアントバージョンにかなりの柔軟性を提供する。

図２は、クライアントアプリケーションおよびＧＵＩが、稼働中のサーババージョンに依存して、どのように動作しなければならないのかを決定する、クライアントノードでの方法の主要なステップを説明する。

プロセスは、クライアントアプリケーション（２１０）が再起動されるたびに実行される。トランザクション（transactions）は、バージョンサーバおよびデータベース（２２０）から、使用されるクライアントアプリケーションのバージョンの詳細（２１４）を読み出すように、ログイン時にクライアントアプリケーションによって開始される（２１２）。クライアントアプリケーションによってバージョンサーバに自動的に送られる問い合わせは、使用中のアプリケーション識別（ＩＤ）を含むクライアントノードのＩＤ、およびそのバージョン番号を含んでいる必要がある。

本発明の好適な一実施形態では、クライアントアプリケーションのバージョンの使用および新しいバージョンの展開の進捗に関する統計を確立するように、問い合わせは、以下を含む、クライアントに関するより多くの情報を含んでいなければならない。
−ユーザ識別、
−ユーザのオフィス、例えば：ロンドンにあるルフトハンザ（ＬＨ）代理店のＬＯＮＬＨ０３３、
−ユーザの場所、例えば：ロンドンヒースロー空港の第２ターミナルのゲート２０に対するＬＨＲ／Ｔ２／ＧＴＥ／２０、
−ユーザの組織、例えば：航空会社名であるＬＨ、
−その他。

いずれにしても認証の一部として図１に示されるログオンおよびセキュリティサーバ（ＬＳＳ）（１０３）に提供される情報は、アプリケーションサーバの正当なユーザとして認識されるように提供される。

したがって、クライアントアプリケーションによる問い合わせ（２１２）で提供されるものは、その領域での新しいアプリケーションのバージョンの展開、および概して、アプリケーションサーバとインターフェースするクライアントアプリケーションの集団の特性に関する非常に重要な情報を得るために用いることができる。例えば、ＧＤＳは、クライアントアプリケーションのあるバージョンを使用している世界中の場所のリストを確立することができるか、または非常に古いバージョンを依然として使用している場所を検出することができる。クライアントアプリケーションによって提供された情報は、データベース内に収集され、リモートクライアントノードの大集団の監視および管理を担当する管理センターから実行される、あらゆる種類のプログラムによって利用することができる。

バージョンサーバ（２２０）は、全てのクライアントノードで使用中のクライアントアプリケーションおよびＧＵＩのステータスリストを管理し続ける。次いで、現在稼働中のアプリケーションサーバのバージョンを知ること、および、上述のように、問い合わせでクライアントノードによって提供される情報に基づいて、ログイン時に、ステータスが各クライアントシステムに返される（２１４）。ステータスは、以下の値のうちの１つを取り込むことができる。

有効：クライアントアプリケーションおよびＧＵＩの最後にダウンロードしたバージョン（Ｎ＋１）のステータスである。これは、新しいクライアントアプリケーションが展開された後の通常のステータスであり、稼働させたサーバの新しいバージョンに対応する。
非推奨：クライアントアプリケーションおよびＧＵＩは、古いバージョンであるが、現在のプロダクションサーバと互換性があることを示す。このステータスは、ＧＵＩの新しいバージョンが利用できるが、古い展開されたＧＵＩは、現在サーバとの互換性を保持している時に用いられる。クライアント構成に応じて、任意で、ログイン時に警告メッセージがエンドユーザに表示される。
バージョンＮへダウングレード：新しく展開されたクライアントアプリケーションおよびＧＵＩのバージョンＮ＋１が、バージョンＮとして動作しなければならない（一方で、対応する新しいサーバを作動させる前に、新しいクライアントアプリケーションおよびＧＵＩが配布されている）ことを示す。上述のように、このステータスは、主に、下位互換性の無いサーバの起動を管理できるようにするために用いられる。以下に説明するように、サーバの（前バージョンへの）フォールバックを管理するためにも用いられる場合もある。
無効：クライアントアプリケーションおよびＧＵＩが、現在のプロダクションサーバとの互換性が無い、古いバージョンであることを示す。クライアントノードのエンドユーザは、ログイン時に警告通知を受け取り、通常は、ブロックされる。

上述のステータス値は、稼働中のアプリケーションサーバのバージョンに従って動作するように、クライアントシステム（２１６）によって翻訳される。その後、それらの処理を担当するクライアントアプリケーションとアプリケーションサーバ（２３０）との間で、通常のトランザクション（２１８）を行うことができる。

何らかの理由で、昇格したアプリケーションサーバに問題が生じて、これを取り除かなければならない場合、前バージョンに関するフォールバックが生じなければならない。よって、既にダウンロードされた新しいクライアントアプリケーションおよびＧＵＩは、展開が進行していた暫定期間中におけるように、以前のサーババージョンと互換性をもって動作を再開するように、「ダウングレード」のステータスに戻して設定しなければならない。一部のクライアントシステムが、依然としてクライアントアプリケーションおよびＧＵＩの前バージョンを使用していた場合、それらのステータスは、「非推奨」から「有効」に逆転される。

図３は、ログイン時に問い合わせが発行されたクライアントシステムに起因するステータスを、バージョンサーバがどのように管理するのかを論じる。

プロセスは、クライアントシステムによってバージョンサーバに発行される問い合わせに提供される、クライアントアプリケーションおよびＧＵＩのバージョン（３１０）から始まる。クライアントシステムによって問い合わせられた時に返されるステータスを決定するために、バージョンサーバは、提供されたクライアントバージョン（３１０）に対してそれぞれ確認される（３４０）互換性規則を使用し、アプリケーションのどのバージョンが稼働中であるのかを知る。しかしながら、互換性規則の拡大を回避するために、メタ規則に対するクライアントバージョンの先行確認（３２０）が存在する。メタ規則は、所与の値よりも古い全てのバージョン番号を直接的に排除するために用いられる。クライアントアプリケーションあたり１つのメタ規則が存在する。したがって、メタ規則の確認に失敗した場合（３３１）、「無効ステータス」が直接的に返される（３５２）。一方で、クライアントバージョンがメタ規則の確認を通過した場合（３３２）、互換性規則を確認する（３４０）ことが必要である。互換性規則は、規則に関係する全てのものが、最終的に有効であると宣言される（３８０）ように、稼働中のサーバと特定のクライアントシステムとの間に互換性が存在しない、全ての状況を追跡する。そうでない場合、規則に関係するクライアントシステムは、それらに適用する規則の内容に従って、「無効」である（３５０）、「非推奨」である（３６０）、または「ダウングレード」である（３７０）と宣言される。

図４は、バージョンサーバの使用によってもたらされる機能拡張である、クライアントシステムのオンラインパッチングを説明する。

バージョンサーバの使用は、場合により数千または数万のクライアントノードが関係する多数のクライアントシステムが関与する、大きいネットワークにおいて特に有用である。よって、新しいクライアントアプリケーションの展開は、一般的に完了までに数週間かかる、厄介で時間のかかるタスクである。リモートサイトは、サービスプロバイダ、例えば本発明を示すために用いられるＧＤＳの直接制御下にない場合があるので、例えば空港当局を担当するものは、実際に、それらのシステムに悪影響を与えるという恐れから、アプリケーションの新しいバージョンの組み込みを嫌う可能性がある。本発明によってサポートされるフォールバック機構は、この懸念に対する１つの回答であり、深刻な問題の場合に、サーバの前バージョンに戻すことができるようにする。本発明によるバージョンサーバは、クライアントアプリケーションの展開が進行中である間に、またはそれが達成された後のいずれかの時点で見出されるであろう問題を回避するために、さらなる機能的拡張を実施できるようにする。

主要なブロッキングの問題が、既に世界的に採用されているクライアントアプリケーションのバージョン（４１０）に見つかった場合、バージョンサーバ（４２０）は、クライアントアプリケーション全体を再配布する必要無く、問題を解決するように、コードの一部であるパッチを提供することができる。これを行うために、図２で既に説明されているように、バージョンサーバが、リモートクライアントシステムのログイン時に自動的に送信された問い合わせ（４１２）に回答する時に、その応答にパッチが追加される。問い合わせで提供されるバージョン番号およびアプリケーション名に基づいて、バージョンサーバは、クライアントアプリケーションのバージョンが、機能的問題を有することを認識する。次いで、バージョンサーバによって送られる応答は、既に論じたステータスと、機能的問題のパッチとを含む（４１４）。サーバの応答の受信時に、クライアントアプリケーションは、バージョンステータスに従ってその動作を変化させ、かつそれ自体にパッチを適用する（４１６）。パッチは、クライアントアプリケーション機械に恒久的に格納も組み込みも行われず、クライアントアプリケーションが再開されるたびに適用される。その後、通常のトランザクション（４１８）を、それらを担当するクライアントアプリケーションと、アプリケーションサーバ（４３０）との間で再開することができる。この動作モードは、新しいバージョンが再配布されるまで継続する。

Claims (17)

1. アプリケーションサーバ（１０９）内で実行されるソフトウェアプログラムの新しい下位互換性の無いバージョンの、クライアント／サーバネットワーキング環境（１３０）内への導入を管理するための方法であって、
   最初に、アプリケーションサーバの前記ソフトウェアプログラムの前記新しい下位互換性の無いバージョンが提供されるクライアントシステム（１２２）に、前記アプリケーションサーバの前記ソフトウェアプログラムの現在バージョンと互換性があるダウングレードモード、および前記ソフトウェアプログラムの前記新しい下位互換性の無いバージョンと互換性がある有効モードで動作可能である、クライアントアプリケーション（１２０）を配布するステップと、
   前記クライアントシステムへの組み込みに応じて、前記クライアントアプリケーションを、前記アプリケーションサーバの前記ソフトウェアプログラムの前記現在バージョンと互換性がある、ダウングレードモード（３７０）に設定するステップと、
   前記アプリケーションサーバの前記ソフトウェアプログラムの前記新しい下位互換性の無いバージョンの導入まで、前記クライアントアプリケーションを前記ダウングレードモードで動作させ続けるステップと、
   前記アプリケーションサーバの前記ソフトウェアプログラムの前記新しい下位互換性の無いバージョンの導入に応じて、前記クライアントアプリケーションを、前記アプリケーションサーバの前記ソフトウェアプログラムの前記新しい下位互換性のないバージョンと互換性がある、前記有効モード（３８０）に設定するステップと、
   その時点から、前記クライアントアプリケーション（１２０）を前記有効モードで動作させるステップと、
   を含む、方法。
2. 設定するステップは、前記クライアントシステムの再起動ごとに自動的にトリガされ、下記のステップ
   前記クライアント／サーバネットワーキング環境で動作するバージョンサーバ（１０５）に問い合わせるステップ（２１２）であって、前記問い合わせは、前記クライアントシステムの識別を含み、クライアントアプリケーションのバージョン番号をさらに含む、ステップと、
   前記クライアントシステム（２１６）を、前記ダウングレードモードおよび前記有効モードを含む複数のモードから選択された一つのモードで動作させるように、前記問い合わせられたバージョンサーバ（１０５）からステータス値を得るステップ（２１４）と、
   をさらに含む、請求項１に記載の方法。
3. 問い合わせ（２１２）は、統計を確立するように、前記クライアントシステムに関する地理的位置、ユーザ識別、およびあらゆる種類の情報をさらに含む、請求項２に記載の方法。
4. 問い合わせの内容は、前記バージョンサーバのデータベース（１０７）内に格納される、請求項２又は３に記載の方法。
5. 前記クライアントシステムの再起動は、前記アプリケーションサーバの前記ソフトウェアプログラムの前記新しい下位互換性の無いバージョンが稼働された時に、前記アプリケーションサーバ（１００）を動作させるサービスプロバイダによって強制される、請求項２に記載の方法。
6. 前記クライアントシステムの再起動は、前記アプリケーションサーバの前記ソフトウェアプログラムの前記新しい下位互換性の無いバージョンがロードされた時に、自動的に強制される、請求項５に記載の方法。
7. 前記バージョンサーバから前記クライアントシステムへ再起動の問い合わせ及びサインアウトメッセージが送られることにより再起動が強制される、請求項２から６のいずれか１項に記載の方法。
8. 前記クライアントシステムの再起動は、前記アプリケーションサーバの前記ソフトウェアプログラムの前バージョンに関するフォールバックの場合に、自動的に強制される、請求項５に記載の方法。
9. 前記クライアントアプリケーションは、前記クライアントシステムを無効モード（３５０）で動作させるように、前記バージョンサーバから前記ステータス値を受け取る、請求項２に記載の方法。
10. 前記得るステップは、バージョンサーバにおいて、
    メタ規則に対して前記クライアントアプリケーションのバージョン番号を確認して（３２０）、メタ規則が指定するものよりも古いクライアントアプリケーションが無効であると即時に宣言する、先行ステップを含む、
    請求項２に記載の方法。
11. メタ規則の確認に成功した場合に、
    一組の互換性規則（３４０）に対して前記クライアントアプリケーションのバージョン番号を確認するステップと、
    規則の内容に従って、前記互換性規則（３４０）に関係する前記クライアントアプリケーションが、無効（３５０）、非推奨（３６０）、またはダウングレード（３７０）であると宣言するステップと、
    そうでない場合は、いかなる互換性規則にも関係しない前記クライアントアプリケーションが、有効（３８０）であると宣言するステップと、
    をさらに含む、請求項１０に記載の方法。
12. 前記得るステップは、１つ以上のクライアントアプリケーションの問題を修正するように、パッチ（４１４）を前記クライアントシステムにさらに配信する、請求項２に記載の方法。
13. 前記パッチは、前記クライアントシステムが再起動される（４１６）たびに、動的に適用される、請求項１２に記載の方法。
14. 前記クライアントアプリケーションは、グラフィックユーザインタフェース（２１０）を含む、請求項１から１３のいずれか１項に記載の方法。
15. 前記アプリケーションサーバから遠隔設置された前記クライアントシステムにおいて実行される多数のクライアントアプリケーションのために使用されることを特徴とする請求項１から１４のいずれか１項に記載の方法。
16. アプリケーションサーバのソフトウェアプログラムの新しい下位互換性の無いバージョンの、請求項１〜１５のうちのいずれか１項に記載の前記方法の各ステップを実行するために適合される手段を備える、バージョンサーバ（１０５）と、データベース（１０７）とを含むクライアント／サーバネットワーキング環境（１００）内への導入を管理するためのシステム。
17. アプリケーションサーバのソフトウェアプログラムの新しい下位互換性の無いバージョンの、請求項１から１５のうちのいずれか１項に記載のクライアント／サーバネットワーキング環境内への導入を管理するための前記方法を、少なくとも１つのコンピュータ（１１０、１２２）に動作させるための、コンピュータで読み取り可能な記憶媒体に格納されるコンピュータプログラム。

Images