JP2021022392A - ローカルまたは分散型コンピュータ・システムにおける柔軟なノード構成方法およびシステム - Google Patents

Abstract

【課題】サービスのスケーリング、第１サービス・バージョンから第２バージョンへの移行、および外部システム統合サービスを実装する。【解決手段】コンピュータ・システムにおいて、第１サービス・バージョンから第２バージョンに移行するための方法であって、サービスの第１バージョンをインスタンス化するステップと、同じサービスの第２バージョンをインスタンス化し、サービスの第１バージョンおよびサービスの第２バージョンを同時に実行するステップと、サービスの第１バージョンの処理のために送られたメッセージを、サービスの第２バージョンに送るべきことを決定するステップと、サービスの第２バージョンを使用して、メッセージを処理するステップと、を含む。【選択図】図３

Description

関連出願に対する相互引用
[0001] 本願は、"METHOD AND SYSTEM FOR FLEXIBLE NODE COMPOSITION ON LOCAL OR DISTRIBUTED COMPUTER SYSTEMS"（ローカルまたは分散型コンピュータ・システムにおける柔軟なノード構成方法およびシステム）と題し、２０１３年５月２０日に出願された米国仮特許出願第６１／８２５，２８４号の恩恵および優先権を主張する。この仮特許出願をここで引用したことにより、その内容全体が本願にも含まれるものとする。

[0002] 本明細書において説明する実施形態は、スケーリング・サービス(scaling service)、第１サービス・バージョンから第２バージョンへの移行、および外部システム統
合サービスの実装を対象とする。一実施形態では、コンピュータ・システムは、サービス間における通信を可能にするメッセージ・キューを維持するメッセージ・ブローカ・サービス(message broker service)を設置する(establish)。メッセージ・キューは、パブリ
ッシャからのメッセージを受け入れ、メッセージをサブスクライバに転送する。このコンピュータ・システムは、サービス毎に指定されたメッセージ・キューを示し、指定されたメッセージ・キューは、そのサービスに対するメッセージを維持するように構成される。また、このコンピュータ・システムは、サービスの内少なくとも１つを、第２の異なるコンピュータ・システムに移動させるのを可能にしつつ、指定されたメッセージ・キューは、移動されるサービスに対するメッセージを維持する。

[0003] 他の実施形態では、コンピュータ・システムは第１サービス・バージョンから第２サービス・バージョンに移行する。このコンピュータ・システムは、サービスの第１バージョンをインスタンス化し、同じサービスの第２バージョンをインスタンス化して、サービスの第１バージョンおよびサービスの第２バージョンが同時に実行することになる。次いで、コンピュータ・システムは、処理のためにサービスの第１バージョンに送られたメッセージ（または、いずれのサービスにも未だ送られていないメッセージ）をサービスの第２バージョンに送るべきであると判断し、サービスの第２バージョンを使用してこのメッセージを処理する。

[0004] 更に他の実施形態では、コンピュータ・システムは、外部システム統合サービスを実装する。このコンピュータ・システムは、内部メッセージ・ブローカ・サービスが設置されていると判断する。メッセージ・ブローカ・サービスは、サービス間における通信を可能するメッセージ・キューを維持するように構成される。メッセージ・キューは、パブリッシャからのメッセージを受け入れ、メッセージをサブスクライバに転送する。コンピュータ・システムは、内部メッセージ・ブローカ・サービスと合同して、外部システム統合サービスをインスタンス化する。外部システム統合サービスは、指定された登録済みメッセージにサブスクライブし(subscribe)、登録済みメッセージを種々の外部エンテ
ィティに転送するように構成される。外部システム統合サービスの構成設定(configuration)は、コンピュータ・システムによって、または外部システム統合サービスを使用して
いる外部システムによって実行することができる。また、コンピュータ・システムは、外部システム統合サービスが登録したメッセージを受信し、外部システム統合サービスは、受信した登録済みメッセージを、指定された外部エンティティに転送する。

[0005] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主
要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するときに補助として使用されることを意図するのでもない。

[0006] 更に他の特徴および利点については、以下に続く説明において明記され、当業者にはその説明から部分的に明らかになり、または本明細書における教示の実施によって習得することもできる。本明細書において説明する実施形態の特徴および利点は、添付した特許請求の範囲において特定的に指摘した手段および組み合わせによって実現し修得することができる。本明細書において説明する実施形態の特徴は、以下の説明および添付した特許請求の範囲から一層明らかになるであろう。

[0007] 本明細書において説明する実施形態の以上のおよびその他の特徴を更に明確化するために、添付図面を参照しながら更に特定的な説明を行う。尚、これらの図面は本明細書において説明する実施形態の例を図示するに過ぎず、したがってその範囲を限定するように見なしてはならないことは認められよう。実施形態について、更に具体的にそして詳細に、添付図面の使用によって説明する(described and explained)。
図１は、本明細書において説明する実施形態がスケーリング・サービスを含んで動作することができるコンピュータ・アーキテクチャを示す。 図２は、スケーリング・サービスのための方法例のフロー・チャートを示す。 図３は、第１サービス・バージョンから第２バージョンに移行するための方法例のフロー・チャートを示す。 図４は、外部システム統合サービスを実装するための方法例のフロー・チャートを示す。 図５は、受信したメッセージをサービスの第１バージョンからサービスの第２バージョンに送る実施形態を示す。 図６は、メッセージを外部エンティティに転送するために外部システム統合サービスを実装する実施形態を示す。 図７は、指定されたトピック・キーを使用して、メッセージ・ブローカ・サービスによってメッセージを発送する(route)実施形態を示す。

[0015] 本明細書において説明する実施形態は、スケーリング・サービス、第１サービス・バージョンから第２バージンへの移行、および外部システム統合サービスの実施を対象とする。一実施形態では、コンピュータ・システムは、サービス間における通信を可能にするメッセージ・キューを維持するメッセージ・ブローカ・サービスを設置する。メッセージ・キューは、パブリッシャからのメッセージを受け入れ、メッセージをサブスクライバに転送する。このコンピュータ・システムは、サービス毎に指定されたメッセージ・キューを示し、指定されたメッセージ・キューは、そのサービスに対するメッセージを維持するように構成される。また、このコンピュータ・システムは、サービスの内少なくとも１つを、第２の異なるコンピュータ・システムに移動させるのを可能にしつつ、指定されたメッセージ・キューは、移動されるサービスに対するメッセージを維持する。

[0016] 他の実施形態では、コンピュータ・システムは第１サービス・バージョンから第２サービス・バージョンに移行する。このコンピュータ・システムは、サービスの第１バージョンをインスタンス化し、同じサービスの第２バージョンをインスタンス化して、サービスの第１バージョンおよびサービスの第２バージョンが同時に実行することになる。次いで、コンピュータ・システムは、処理のためにサービスの第１バージョンに送られたメッセージ（または、いずれのサービスにも未だ送られていないメッセージ）をサービスの第２バージョンに送るべきであると判断し、サービスの第２バージョンを使用してこ
のメッセージを処理する。

[0017] 更に他の実施形態では、コンピュータ・システムは、外部システム統合サービスを実装する。コンピュータ・システムは、内部メッセージ・ブローカ・サービスが設置されていると判断する。メッセージ・ブローカ・サービスは、サービス間における通信を可能にするメッセージ・キューを維持するように構成される。メッセージ・キューは、パブリッシャからのメッセージを受け入れ、メッセージをサブスクライバに転送する。コンピュータ・システムは、内部メッセージ・ブローカ・サービスと合同して、外部システム統合サービスをインスタンス化する。外部システム統合サービスは、指定された登録済みメッセージにサブスクライブし、登録済みメッセージを種々の外部エンティティに転送するように構成される。外部システム統合サービスの構成設定(configuration)は、コンピ
ュータ・システムによって、または外部システム統合サービスを使用している外部システムによって実行することができる。また、コンピュータ・システムは、外部システム統合サービスが登録したメッセージを受信し、外部システム統合サービスは、受信した登録済みメッセージを、指定された外部エンティティに転送する。

[0018] 次に、以下の論述は、実行することができる多数の方法および方法のアクトに言及する。尚、方法のアクトは、ある順序で論じられること、または特定の順序で行われるようにフロー・チャートにおいて示されることもあるが、特に述べられない限り、または要求されない限り、特定の順序付けは必ずしも必要とはされないことは注記してしかるべきである。何故なら、１つのアクトは、そのアクトが実行される前に完了する他のアクトに従属するからである。

[0019] 本明細書において説明する実施形態は、例えば、以下で更に詳しく論ずるように、１つ以上のプロセッサおよびシステム・メモリというようなコンピュータ・ハードウェアを含む特殊目的または汎用コンピュータを含むまたは利用することができる。また、本明細書において説明する実施形態は、コンピュータ実行可能命令および／またはデータ構造を搬送または格納するために、物理および他のコンピュータ読み取り可能媒体も含む。このようなコンピュータ読み取り可能媒体は、汎用または特殊目的コンピュータ・システムによってアクセスすることができる任意の入手可能な媒体とすることができる。コンピュータ実行可能命令をデータの形態で格納するコンピュータ読み取り可能媒体は、コンピュータ記憶媒体である。コンピュータ実行可能命令を搬送するコンピュータ読み取り可能媒体は、送信媒体である。つまり、一例として、そして限定ではなく、本明細書において説明する実施形態は、少なくとも２つの全く異なる種類のコンピュータ読み取り可能媒体、即ち、コンピュータ記憶媒体および送信媒体を含むことができる。

[0020] コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、ＲＡＭに基づくソリッド・ステート・ドライブ（ＳＳＤ）、フラッシュ・メモリ、相変化メモリ（ＰＣＭ）、または他のタイプのメモリ、あるいは他の光ディスク記憶デバイス、磁気ディスク記憶デバイス、または他の磁気記憶デバイス、あるいはコンピュータ実行可能命令、データ、またはデータ構造の形態で所望のプログラム・コードを格納するために使用することができ、更に汎用または特殊目的コンピュータ・システムによってアクセスすることができる任意の他の媒体を含む。

[0021] 「ネットワーク」とは、コンピュータ・システムおよび／またはモジュールおよび／または他の電子デバイス間における電子データの移送を可能にする１つ以上のデータ・リンクおよび／またはデータ・スイッチとして定義するものとする。ネットワークを通じて情報をコンピュータに転送または提供するとき（ハードワイヤ、ワイヤレス、あるいはハードワイヤまたはワイヤレスの組み合わせのいずれか）、コンピュータがこの接続を送信媒体と見なすのは適正である。送信媒体は、データまたは所望のプログラム・コー
ド手段をコンピュータ実行可能命令の形態でまたはデータ構造の形態で搬送するために使用することができ、汎用または特殊目的コンピュータ・システムによってアクセスすることができるネットワークを含むことができる。以上のものの組み合わせも、コンピュータ読み取り可能媒体の範囲に含まれてしかるべきである。

[0022] 更に、種々のコンピュータ・システムのコンポーネントに達したときに、コンピュータ実行可能命令またはデータ構造の形態であるプログラム・コード手段を自動的に送信媒体からコンピュータ記憶媒体に（またはその逆に）転送する(transfer)ことができる。例えば、ネットワークまたはデータ・リンクを通じて受信されたコンピュータ実行可能命令またはデータ構造を、ネットワーク・インターフェース・モジュール（例えば、ネットワーク・インターフェース・カードまたは「ＮＩＣ」）内にあるＲＡＭにバッファし、次いで最終的にコンピュータ・システムのＲＡＭにおよび／またはコンピュータ・システムにおいてそれよりも揮発性が少ないコンピュータ記憶媒体に転送することができる。このため、コンピュータ記憶媒体は、送信媒体も利用する（または主に利用する場合も）コンピュータ・システム・コンポーネントに含めることができることは理解されてしかるべきである。

[0023] コンピュータ実行可能（またはコンピュータ解釈可能）命令は、例えば、汎用コンピュータ、特殊目的コンピュータ、または特殊目的処理デバイスに、ある種の機能または１群の機能を実行させる命令を含む。コンピュータ実行可能命令は、例えば、バイナリー、アセンブリ言語のような中間フォーマット命令、またはソース・コードであってもよい。主題については、構造的特徴および／または方法論的アクトに特定的な文言で説明したが、添付した特許請求の範囲において定められる主題は、必ずしも以上で説明した特徴やアクトには限定されないことは理解されよう。逆に、説明した特徴およびアクトは、特許請求の範囲を実現する形態例として開示したまでである。

[0024] 当業者は、種々の実施形態を、多くのタイプのコンピュータ・システム構成を有するネットワーク計算環境において実施できることを認めよう。コンピュータ・システム構成には、パーソナル・コンピュータ、デスクトップ・コンピュータ、ラップトップ・コンピュータ、メッセージ・プロセッサ、ハンドヘルド・デバイス、マルチプロセッサ・システム、マイクロコンピュータ−ベースまたはプログラマブル消費者用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、移動体電話機、ＰＤＡ、タブレット、ページャ、ルータ、スイッチ等が含まれる。また、本明細書において説明する実施形態は、分散型システム環境において実施することも可能である。分散型システム環境では、ネットワークを通じてリンクされた（ハードワイヤ・データ・リンク、ワイヤレス・データ・リンク、またはハードワイヤおよびワイヤレス・データ・リンクの組み合わせによって）ローカルおよびリモート・コンピュータ・システムの各々がタスク（例えば、クラウド・コンピューティング、クラウド・サービス等）を実行する。分散型システム環境では、プログラム・モジュールはローカルおよびリモート双方のメモリ記憶デバイスに配置されてもよい。

[0025] この説明およびそれに続く特許請求の範囲において、「クラウド・コンピューティング」とは、構成変更可能な計算リソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、およびサービス）の共有プールに対する、応需型(on-demand)
ネットワーク・アクセスを可能にするモデルとして定義するものとする。「クラウド・コンピューティング」の定義は、このようなモデルが適正に展開されたときに得ることができる他の多数の利点のいずれにも限定されないものとする。

[0026] 例えば、クラウド・コンピューティングは、現在、構成変更可能な計算リソースの共有プールに対する遍在的で便利な、応需型アクセスを提供するように、マーケット
プレースにおいて採用されている。更に、構成変更可能な計算リソースの共有プールは、仮想化によって素早くプロビジョニングすることができ、少ない管理の手間やサービス・プロバイダの介入で解放することができ、次いでこれらに応じてスケーリングすることができる。

[0027] クラウド・コンピューティング・モデルは、例えば、応需型セルフ・サービス、ブロード・ネットワーク・アクセス、リソース・プーリング、即時性(rapid elasticity)、計測可能であること(measured service)等というような、種々の特性で構成することができる。また、クラウド・コンピューティング・モデルは、例えば、サービスとしてのソフトウェア（「ＳａａＳ」）、サービスとしてのプラットフォーム（「ＰａａＳ」）、およびサービスとしてのインフラストラクチャー（「ＩａａＳ」）というような、種々のサービス・モデルを露出することもできる。また、クラウド・コンピューティング・モデルは、プライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、ハイブリッド・クラウド等というような、異なる配備モデルを使用して配備することもできる。この説明および特許請求の範囲では、「クラウド・コンピューティング環境」とは、クラウド・コンピューティングが採用された環境である。

[0028] 加えてまたは代わりに、本明細書において説明する機能は、少なくとも部分的に、１つ以上のハードウェア論理コンポーネントによって実行することができる。例えば、限定ではなく、使用することができるハードウェア論理コンポーネントの代表的なタイプは、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定プログラム集積回路（ＡＳＩＣ）、特定プログラム標準製品（ＡＳＳＰ）、チップ上システム・システム（ＳＯＣ）(System-on-a-Chip System)、複合プログラマブル論理デバイス（ＣＰＬＤ）
、および他のタイプのプログラマブル・ハードウェアを含む。

[0029] 更にまた、本明細書において説明するシステム・アーキテクチャは、複数の独立したコンポーネントを含むことができ、その各々がシステム全体としての機能に寄与する。このモジュール性は、プラットフォームのスケーラビリティの問題に取り組むときに、柔軟性を高めることを可能とし、このために、種々の利点が得られる。システムの複雑さおよび成長は、機能範囲が制限された小規模な(smaller-scale)部品の使用によって、
一層容易に管理することができる。プラットフォームのフォールト・トレランスは、これらの疎結合モジュールの使用によって高められる。業務上の必要性から求められるに連れて、個々のコンポーネントを漸増的に増大させることができる。また、モジュール型の開発は、新たな機能を市場に投入するまでの時間の短縮となる。新たな機能は、コア・システムに影響を及ぼすことなく、追加または削除することができる。

[0030] 図１は、少なくとも１つの実施形態を採用することができるコンピュータ・アーキテクチャ１００を示す。コンピュータ・アーキテクチャ１００は、第１コンピュータ・システム１０１および第２コンピュータ・システム１０８を含む。第１および第２コンピュータ・システム１０１および１０８は、クラウド・コンピューティング・システムを含む、任意のタイプのローカルまたは分散型コンピュータ・システムであってもよい。これらのコンピュータ・システムは、種々の異なる機能を実行するモジュールを含むことができる。例えば、第１コンピュータ・システム１０１はメッセージ・ブローカ・サービス１０２を含む。メッセージ・ブローカ・サービスは、第１コンピュータ・システム上でインスタンス化され、サービスＡ、Ｂ、およびＣ（それぞれ、１０５Ａ、１０５Ｂ、および１０５Ｃ）を含むがこれらに限定されないサービスと相互作用するために使用することができる。サービスＡ〜Ｃは、任意のタイプのコンピュータ・サービス、アプリケーション、機能、または他のタイプのソフトウェア機能でもよい。

[0031] メッセージ・ブローカ・サービス１０２は、メッセージ・キュー１０３を維持
するように構成することができる。メッセージ・キューは、サービス（１０５Ａ〜１０５Ｃ）から発行されたメッセージを受け入れることができ、これらのメッセージのサブスクライバに、これらのメッセージを送ることができる。つまり、図１に示すように、サービスＡはサービスＢおよびＣからのメッセージにサブスクライブされる。したがって、サービスＢまたはＣがメッセージ（例えば、発行メッセージ１０６）を発行するときはいつでも、対応するメッセージ・キューＢおよびＣ（それぞれ、１０３Ｂおよび１０３Ｃ）が、サブスクライブされたいずれのメッセージ１０７もサービスＡに転送する。同様に、サービスＢはサービスＣのメッセージにサブスクライブされたので、メッセージ・キューＣ（１０３Ｃ）は、サービスＣによって発行されサブスクライブされたメッセージ１０７を、サービスＢに転送する。更に、サービスＣはサービスＡのメッセージにサブスクライブされたので、メッセージ・キューＡ（１０３Ａ）は、サービスＡによって発行されサブスクライブされたメッセージ１０７をサービスＣに転送する。場合によっては、メッセージ・ブローカ・サービス１０２は１つのキューまたは多数のキューを維持してもよいことは注記してしかるべきである。例えば、サービスは、トピックに基づいてメッセージにサブスクライブすることもできる。したがって、実際には１つのメッセージ・キューが多くの異なるトピックのメッセージを有するときでも、サービスにとっては、キューがそのトピックのメッセージのみをサービスするように思われるであろう。

[0032] 図１には３つのサービスを示すが、そしてこれらのサービスの各々は、パブリッシャおよびサブスクライバ双方として示されているが、実質的にいかなる数のサービスでもインスタンス化することができ、これらのサービスのいずれもが、パブリッシャのみ、サブスクライバのみ、またはパブリッシャおよびサブスクライバ双方になれることは理解されよう。このように、サービスが、ある種のサービスからメッセージを受信するためにサブスクライブすることができ、これらのサービスは、誰がサブスクライブされたか、そして誰にメッセージを送るのかについて心配する必要はない。むしろ、サービスは彼らのメッセージをメッセージ・ブローカに発行することができ、メッセージ・ブローカのメッセージ・キューが、メッセージを受信するためにサブスクライブしたサービスに、これらのメッセージを適正に転送する。

[0033] 尚、サービスを１つの計算システムから他に移動させてもよいことも注記してしかるべきである。例えば、サービスＢ（１０５Ｂ）を第１コンピュータ・システム１０１から第２コンピュータ・システム１０８に移動させてもよい。サービスは、サービスが実行を停止した後に移動させればよいが、サービスが実行している間に、動的に移動させることもできる。したがって、コンピュータ・システム１０１のサービス移動モジュール１０４によってランタイム中に計算システム間でサービスを移動させるまたは移転させることができる。これらの概念については、それぞれ、図２、図３、および図４の方法２００、３００、および４００に関して、以下で更に説明する。

[0034] 以上で説明したシステムおよびアーキテクチャに関して、開示する主題にしたがって実装することができる方法(methodologies)は、図２、図３、および図４のフロー
・チャートを参照すると、一層良く評価できよう。説明の簡単さのために、一連のブロックとして方法を示し説明する。しかしながら、特許請求する主題は、ブロックの順序によって限定されないことは理解され認められてしかるべきである。何故なら、あるブロックは異なる順序で現れてもよく、および／または本明細書において図示および説明する他のブロックと同時に現れてもよいからである。更に、図示するブロックの全てが、以下に説明する方法を実現するために必要ではない場合もある。

[0035] 図２は、スケーリング・サービスのための方法２００のフロー・チャートを示す。これより、方法２００について、環境１００のコンポーネントおよびデータを頻繁に参照しながら説明する。

[0036] 方法２００は、サービス間において通信を可能にする１つ以上のメッセージ・キューを維持するメッセージ・ブローカ・サービスを設置するブロック（２１０）を含む。メッセージ・キューは、パブリッシャからメッセージを受信し、メッセージをサブスクライバに転送するように構成される。例えば、第１コンピュータ・システム１０１がメッセージ・ブローカ・サービス１０２を設置してもよい。メッセージ・ブローカ・サービス１０２は、サービス１０５Ａ〜１０５Ｃ（または図示しないその他）というようなサービス間における通信を容易にする。メッセージ・ブローカ・サービス１０２は、パブリッシャからのメッセージ（即ち、発行メッセージ１０６）を受信し、メッセージ（即ち、サブスクライブされたメッセージ１０７）をサブスクライバに転送する種々のメッセージ・キュー１０３を始動させ(initiate)管理する。つまり、パブリッシャ（例えば、サービス１０５Ａ）が、その動作ステータスに関係するメッセージ、その動作結果、通知メッセージ、または他のタイプのメッセージを発行することができる。これらのメッセージは、誰が実際にこれらのメッセージにサブスクライブしているかに関係なく、発行することができる。

[0037] ある場合には、メッセージ・ブローカ・サービス１０２と通信するサービスは、パブリッシャだけであってもよい（即ち、これらはいずれの他のサービスのメッセージにもサブスクライブされない）。他の場合では、サービスがサブスクライバだけであってもよい（即ち、これらは他のサブスクライバのためにメッセージを発行しない）。更に他の場合では、サービス１０５Ａ〜１０５Ｃは、パブリッシャおよびサブスクライバ双方であってもよい（即ち、これらは、メッセージの発行、これらがサブスクライブされたメッセージ（例えば、サブスクライブされたメッセージ１０７）の受信の双方を行う）。サービス１０５Ａ〜１０５Ｃは、１つのコンピュータ・システム、または多数のコンピュータ・システム上で実行することもできる。更に、サービスは、動作の前、後、または最中に、コンピュータ・システム間で移動させることができる。ある場合には、サービスが、同じまたは多数の異なるコンピュータ・システム上で実行する、それ自体の少なくとも２つの異なるインスタンスを有することもできる。例えば、メッセージ・ブローカ・サービス１０２は、フェイルオーバーまたは他の目的のために、多数の異なるコンピュータ・システム上において、それ自体の２つ以上の異なるインスタンスを有することができる。

[0038] 更に、方法２００は、１つ以上のサービスの各々に対して、指定されたメッセージ・キューを示すブロック（２２０）を含む。指定されたメッセージ・キューは、そのサービスのためにメッセージを維持するように構成される。メッセージ・ブローカ・サービス１０２は、多くの異なるメッセージ・キュー１０３を始動させることができる。これらのメッセージ・キューの一部または全部が、ある種のサービスのためのメッセージを処理するために特定的に割り当てられてもよい。つまり、サービスＡ（１０５Ａ）のメッセージを処理するために、メッセージ・キューＡ（１０３Ａ）を特定的に指定することができる。したがって、メッセージ・キューＡは、サービスＡの発行メッセージ１０６を受信し、サービスＡのメッセージを受信するためにサブスクライブされたサービス（または他のエンティティ）（例えば、サービスＣ（１０５Ｃ））にこれらを送る。同様に、メッセージ・キューＢ（１０３Ｂ）が、サービスＢのメッセージを処理するために割り当てられてもよく、メッセージ・キューＣ（１０３Ｃ）が、サービスＣのメッセージを処理するために割り当てられてもよい。

[0039] 次いで、方法２００は、サービスの内少なくとも１つを第２の異なるコンピュータ・システムに移動させるブロック（２３０）を含み、指定されたメッセージ・キューが、移動されるサービスに対するメッセージを維持する。第１コンピュータ・システム１０１のサービス移動モジュール１０４は、サービス１０５〜１０５Ｃの内任意の１つ以上を他のコンピュータ・システムに移動させることができる。つまり、例えば、サービス移
動モジュール１０４は、サービスＢ（１０５Ｂ）をコンピュータ・システム１０１から第２コンピュータ・システム１０８に移動させることができる。サービスは、サービスの動作中における任意の時点に移動させることができる。ランタイムの前、後、または最中に、追加のサービスを動的に追加することができる。同様に、ランタイムの前、後、または最中に、既存のサービスを動的に除去することもできる。スループットを高めるため、または追加のコンピュータ・システムを使用するコストを低減するため、負荷均衡化を補助するため、フェイルオーバーを補助するため、または他の理由のために、サービスを移動させる、追加する、または除去することができる。本明細書において説明する実施形態は、２つ以上のサービスを伴う実施態様について説明するが、これは簡単さのために行われるに過ぎず、スループット、負荷均衡化、フェイルオーバー、または他の理由で補助するために、実質的にいかなる数のサービスでも移動させる、追加する、または除去することができる。

[0040] 図７に示すようなある実施形態では、メッセージ・ブローカ・サービス７０１のトピック・キー割り当てモジュール７０２が、各メッセージ７０３にトピック・キー７０４を割り当てることができる。トピック・キー７０４は、そのメッセージ７０３についてのトピックを示す。トピックは、例えば、メッセージ７０３が通知メッセージである、または報告メッセージであることを示すことができる。これらのメッセージは、その対応するトピック・キーによって、メッセージの指定されたトピック・キーに基づいてサブスクライバに発送することができる。したがって、指定されたトピック・キー７０４に関連付けられたメッセージは、メッセージ・ブローカ・サービス７０１によって、そのトピックのメッセージにサブスクライブしたサブスクライバに発送される。例えば、サービスＡ（７０５Ａ）がある種のトピック（例えば、「エラー」または「完了」または「動作ステータス」）のメッセージにサブスクライブした場合、これらのメッセージ主題に対応するトピック・キーを有するメッセージがサービスＡに発送される。メッセージ・ブローカ・サービス７０１は、同様に、サービスＢ（７０５Ｂ）およびＣ（７０５Ｃ）がどのメッセージ・トピックにサブスクライブしたかに基づいて、メッセージをこれらのサービスに発送する。このように、これらの実施形態では、サブスクライバは、ある種のパブリッシャからの全てのメッセージにサブスクライブすること、またはそのパブリッシャからのメッセージの内、指定されたトピック・キーを有するものだけにサブスクライブすることもできる。更に、サブスクライバは、単に、誰がパブリッシャであるかには関係なく、ある種のトピック・キーを有するメッセージにサブスクライブすることもできる。このように、パブリッシャは、イベントが発生するに連れてメッセージを発行することができ、メッセージ・ブローカ・サービス７０１によってこれらのメッセージをサブスクライバに発送することができる。

[0041] 少なくともある場合には、パブリッシャは、それらのメッセージに誰がサブスクライブしているのか全く知らなくてもよい。メッセージ・ブローカは、サービスの内任意のものがメッセージをメッセージ・キューに発行することを可能にすることができ、更に、任意のサブスクライバがメッセージ・キューからメッセージを受信することを可能にすることができる。サブスクライブされたメッセージ１０７は、サブスクライバに、誰がメッセージを発行したか示すことができ、更にこのメッセージに割り当てられたトピック・キーを示すこともできる。ある場合には、メッセージは、メッセージの出所（即ちパブリッシャ）を検証するセキュリティ・トークンを含むこともできる。メッセージ・サブスクライバは、セキュリティ・トークンにアクセスし、それが有効か否か判定することができる。有効である場合、メッセージはメッセージ・キュー上に発行される。セキュリティ・トークンが無効である場合、メッセージには無効の印が付けられ、破棄または無視することができる。更に、無効なセキュリティ・トークンのパブリッシャ、および／またはサブスクライバに、そのセキュリティ・トークンが無効であることを通知することもできる。ある実施形態では、セキュリティ・ポリシーを立案し(initiate)、あるメッセージは、
セキュリティ・トークンなしでアクセスし発送することを許可し、一方他の（恐らく優先度が高い）メッセージは、メッセージにアクセスできるようになる前に有効なトークンを要求する。更に、ある実施形態では、第１コンピュータ・システム１０１があるサービスから他のサービスに移行しなければならない場合もある。このような実施形態については、以下で図３と関連付けて説明する。

[0042] ある実施形態では、サービス監視サービスを実装することもできる。サービス監視サービスは、システムにおけるサービスの動作状態を監視することができる。サービス監視サービスは、１つの指定されたサービス、またはメッセージ・ブローカ・サービスを含む複数の異なるサービスを監視するように構成することができる。監視は、ステータス・チェックをサービスの内１つ以上に送ることを含んでもよい。これらのステータス・チェックは、サービスとサービス監視サービスとの間で送られる内部メッセージであってもよい。これらのステータス・チェックは、サービスが適正に機能しているか否か判定するために使用することができる。このように、サービス監視サービスは、サービスがステータス・チェックに応答したか否か判定し、ステータス・チェックに応答していないサービス毎に、そのサービスが正しく動作していないことを種々のユーザ（例えば、システム・アドミニストレータを含む）に通知することができる。

[0043] サービス監視サービスは、更に、どのサービスが、指定されたメッセージ・タイプを待ち受けているか判定し、指定されたメッセージ・タイプを発行し、指定されたメッセージ・タイプにサブスクライブし、指定された数のメッセージを処理し、またはシステム全体によって処理されるメッセージの数を判定するように構成することができる。ある場合には、サービスが既知の量以上または以下に処理している場合、そのサービスは誤って機能しているおそれもある。同様に、ある種のメッセージ・タイプに対するパブリッシャまたはサブスクライバが、比較的大量のメッセージを受信または発行することもあり、つまり一層エラーを生じ易くなるおそれがある。サービス監視サービスからのデータは、サービスの数を増やしメッセージ処理スループットを高めるために使用することができ、またはサービスの数を減らし処理コストを低減することもできる。これらのサービスの増減は、自動的に、または処理の必要性が変化するに連れて動的に実施することができる。更に、サービス監視サービスは、手動でサービスを追加または除去するための推奨を与えるように構成することもできる。

[0044] 更にまた、サービス監視サービスは、従属サービスを含むどのサービスが、現在メッセージ処理のために利用可能か識別することもできる。次いで、この情報に基づいて、サービス監視サービスは、判定された現在のサービスの利用可能性に基づいて、種々のメッセージ処理設定を制御することができる。例えば、システム内部のサービス、または外部システム統合サービスを使用する外部システムにおけるサービスは、サービス監視サービスによって提示される利用可能性情報にしたがって、メッセージを異なって処理するように構成することができる。例えば、パブリッシャが、利用可能性情報から、現在利用可能なサービスにメッセージをどのようにして発送するか決定することができるのでもよい。

[0045] 図３は、第１サービス・バージョンから第２バージョンに移行するための方法３００のフロー・チャートを示す。これより、図１の環境１００および図５の環境５００のコンポーネントおよびデータを頻繁に参照しながら、方法３００について説明する。

[0046] 方法３００は、サービスの第１バージョンをインスタンス化するブロック（３１０）を含む。例えば、コンピュータ・システム５０１のサービス・インスタンス化モジュール５０２が、サービス５０３Ａの第１バージョンをインスタンス化することができ、更に同じサービスの第２バージョン５０３Ｂをインスタンス化することができ、サービス
の第１バージョンおよびサービスの第２バージョンが同時に実行することになる（３２０）。前述のように、このサービスは、３つ以上のバージョンを含む、多数の異なるバージョンにインスタンス化することもできる（図５には示されていない）。これらのサービスは、サービス、アプリケーション、ソフトウェア機能、または他のソフトウェア・エレメントを含む、任意のタイプの計算機能とすることができる。ある場合には、第１バージョン５０３Ａが、サービスの新しいアップグレードされたバージョンであってもよく、一方第２バージョン５０３Ｂは、古いアップグレードされていないバージョンであってもよい。これらの新旧バージョンは、同時に実行することができ、別個に実行することもできる。

[0047] 次に、方法３００は、処理のためにサービスの第１バージョンに送られたメッセージをサービスの第２バージョンに送るべきことを決定するブロック（３３０）を含む。例えば、第１バージョンの方が新しいバージョンであり、第２バージョンの方が古いバージョンである先の例では、サービスの古い方のバージョンにのみ有効である、または
新しい方のソフトウェア・バージョンによって認識されないまたは処理できない１つのエレメントを少なくとも含むメッセージ５０６が受信され場合があり得る。逆の場合も成り立つことができ、その場合、第１バージョン５０３Ａが古い方のバージョンであり、第２バージョン５０３Ｂが新しい方のバージョンであり、メッセージ５０６は新しい方のバージョン（５０３Ｂ）によってのみ処理することができる。１つのバージョンが着信メッセージを処理することができればよく、他方のサービス・バージョンができないことには、多くの異なる理由があると考えられる。その理由には関係なく、コンピュータ・システム１０１は、メッセージ５０６をサービスの第１バージョン５０３Ａからサービスの第２バージョン５０３Ｂに渡すべきことを決定することができる。次いで、メッセージ５０６を処理するために、サービスの第２バージョンを使用することができる（３４０）。

[0048] 一実施形態では、第１バージョンが誤動作したときに、メッセージ５０６をサービスの第２バージョンに転送することができる。つまり、サービスの第２バージョン５０３Ｂは、第１サービス・バージョンに対するフェイルオーバーを設ける。このようなフェイルオーバーのシナリオでは、第２バージョンは第１バージョンよりも古くても新しくてもよい。ある場合には、これらのサービス・バージョンの一方（例えば、バージョン１（５０３Ａ））を、インストール時に自動的に実装することもできる。つまり、インストールが終了すると直ぐに、着信メッセージ５０６を処理するために、新たにインストールされたサービス・バージョンを自動的に使用することができる。したがって、サービスをアップグレードし、アップグレードの後には自動的に実装し（例えば、サービス・アップグレード・モジュール５０４によって）、アップグレードのダウンタイムを大幅に短縮するか、または解消する。ある場合には、新たにアップグレードされたものが実行していると一旦判定されたなら、他方（例えば、第２）のサービス・バージョンは自動的にアンインストールされる。

[0049] 更にまた、着信メッセージをサービスの第１バージョン５０３Ａから第２バージョン５０３Ｂに処理のために送るべきか否かについての判定は、種々の論理的評価に基づくこともできる。例えば、第１バージョンがメッセージに応答するためには２秒以上かかる場合、コンピュータ・システム１０１は、第１バージョンは利用できないと判定することができ、次いでメッセージを同じサービスの第２バージョンに発送し直すことができる。他のロジックも同様に構成し実施することができる。以上は、論理的判定の一例に過ぎない。加えてまたは代わりに、メッセージ５０６を処理のためにサービスの第１バージョン５０３Ａから第２バージョン５０３Ｂに送るべきか否についての判定は、ユーザまたはシステム・アドミニストレータによって設定される構成設定５０５に基づくこともできる。

[0050] ある場合には、メッセージを第１バージョンから第２バージョンに転送することができ、第１および第２バージョンの双方によって同時に処理することもできる。このような場合、同時に実行するサービスの第１および第２バージョンの出力を比較して、処理の間に発生するエラーを発見することもできる。このようにして、サービス・プロバイダが、アプリケーションの双方のバージョンを検査し、どのバージョンが最も少ないエラーでメッセージ５０６を処理するか判定することができるのでもよい。第２（新しい方、恐らくベータ）バージョンをインストールし、現在のバージョンと共に実行することもでき、プログラム開発者が新しい方のバージョンの結果を記録し、危険性を全く高めることなく、新しい方のバージョンを検査することになる。加えてまたは代わりに、サービス・プロバイダ（または他のユーザ）が、どのバージョンがどのエラーを発生したか判定できるであろう。このデータを使用して、サービス・プロバイダは、着信メッセージのタイプ毎に、どのサービス・バージョンが最良であるか指定することができるであろう。この指示は、着信メッセージを第２バージョン５０３Ｂに転送するか、またはそれらを第１バージョン５０３Ａに留めるかの判定において、コンピュータ・システム５０１によって使用することができる。このように、コンピュータ・システム１０１は、受信するメッセージ毎に、どのサービス・バージョンを使用すべきか（または、使用するのが最良であるか）継続的に判定することができる。

[0051] 図４は、外部システム統合サービスを実現するための方法４００のフロー・チャートを示す。これより、図１の環境１００および図６の環境６００のコンポーネントおよびデータを頻繁に参照しながら、方法４００について説明する。

[0052] 方法４００は、外部メッセージ・ブローカ・サービス６０３が設置されていることを判定するブロック（４１０）を含む。このメッセージ・ブローカ・サービスは、サービス間（例えば、パブリッシャ６０６および／またはサブスクライバ６０７）における通信を可能にする１つ以上のメッセージ・キュー６０４を維持するように構成され、メッセージ・キューは、パブリッシャ６０６からメッセージを受信し、メッセージ６０５Ａ／６０５Ｂをサブスクライバ６０７に転送するように構成される。メッセージは、サブスクライブ(subscription)に基づいて、および／またはトピック・キー（図７に示すような）に基づいて、発送することができる。内部メッセージ・ブローカ・サービス６０３をインスタンス化するために、コンピュータ・システム６０１のサービス・インスタンス化モジュール６０２を使用することもできる。内部メッセージ・ブローカ・サービスは、図１において説明したメッセージ・ブローカ・サービス１０２と実質的に同じでよい。また、メッセージ・キューも、図１において説明したメッセージ・キュー１０３と同様または同じでよい。メッセージは、製品を生産している機械についての情報を含むことができ、動作ステータス・メッセージ、計画ステータス・メッセージ、エラー・メッセージ、または他のタイプのメッセージを含む。

[0053] 更に、方法４００は、内部メッセージ・ブローカ・サービス６０３と合同で、外部システム統合サービス６０８をインスタンス化するブロック（４２０）も含む。外部システム統合サービス６０８は、指定された、登録メッセージ６０５Ａ／６０５Ｂにサブスクライブし、登録メッセージ６０５Ｃを１つ以上の外部エンティティ６１１に転送するように構成される。外部エンティティ６１１は、外部ユーザ、会社、コンピュータ・システム、データ・ストア、あるいはコンピュータ・システム６０１に対して外部である、または内部メッセージ・ブローカ・サービス６０３を動作させているところに対して外部である他のエンティティであってもよい。外部システム統合サービス６０８は、サービス・インスタンス化モジュール６０２によってインスタンス化することができ、パブリッシャ６０６とサブスクライバ６０７との間で転送されるメッセージを待ち受けるように構成することができる（例えば、図１のサービスＡ、Ｂ、またはＣ（１０５Ａ〜１０５Ｃの内任意のもの）。

[0054] 次いで、外部システム統合サービス６０８は、メッセージの内どれを、指定された外部エンティティに送るべきか決定することができる。例えば、外部エンティティが、任意のエラー・メッセージ、またはエラーが発生したことを示す任意の動作ステータス・メッセージを受信したいことを指定することもできる。これらのメッセージは、「登録済み」メッセージ、即ち、外部エンティティが受信するためにサブスクライブした(subscribe)または登録した(register)メッセージであろう。外部システム統合サービスがサブ
スクライブされたメッセージは、外部システム統合サービスによって構成されても、または外部システム統合サービス内部から選択されても、外部システム統合サービスを使用している外部システム内部から選択されても、またはコンピュータ・システム１０１内部から選択されてもよい。このような登録済みメッセージが外部システム統合サービスによって受信されると（４３０）、外部システム統合サービス６０８は、受信した登録済みメッセージ６０５Ｃを、種々の指定された外部エンティティに転送することができる（４４０）。

[0055] また、外部システム統合サービスは、指定された外部システム通信プロトコルまたはフォーマットへのメッセージの変換も処理するために使用することもできる。例えば、外部システムがある種のファイル・タイプまたはプロトコルを使用して通信する場合、外部システム統合サービス６０８は、内部メッセージをある種のフォーマット（例えば、コンマ分離フォーマット）に変換し(translate)、次いで指定されたプロトコルを使用
してこのファイルを送信することができる。各外部エンティティ６１１は、異なるタイプのメッセージ、またはある種のパブリッシャからのメッセージ、あるいは双方を要求することもできる。外部システム統合サービス６０８は、メッセージング・キュー６０４を使用して、サービスの内任意のものと相互作用することができる。外部システム統合サービスは、更に、外部エンティティ６１１に利用可能にしたメソッドも発行することができる。

[0056] ある実施形態では、制御システム６０９が、サービス・インスタンス化モジュール６０２によって、サービスとしてインスタンス化されることも可能である。制御システムは、設置された内部メッセージ・ブローカ・サービス６０３および／または外部システム統合サービスと合同して、サービスとしてインスタンス化されてもよい。制御システムは、１つ以上の指定された機械６１０のために機械機能を動作させるように構成することもできる。例えば、制御システムは、機械をいつオンまたはオフに切り替えるか、いつ機械がある種のジョブを処理すべきか、どのように機械がジョブを処理すべきか（ジョブ毎に構成設定値を含む）制御する、または他の機械動作を制御するように構成することができる。機械６１０は、コンピュータ・システム６０１に対してローカルでもリモートでもよく、付加的に手動制御によって制御されてもよい。

[0057] サービス・インスタンス化モジュール６０２は、少なくともある実施形態では、メッセージ・パイプライニング・サービス(message pipelining service)もインスタンス化することができる。メッセージ・パイプライニング・サービスは、指定された順序で処理されることになっているメッセージをメッセージ・パイプラインにおいて受信するように構成することができる。メッセージ・パイプライニング・サービスは、受信したメッセージを発行し、そのメッセージの結果にサブスクライブする。例えば、メッセージが機械コマンド（例えば、機械６１０に対する）である場合、メッセージ・パイプライニング・サービスはそのコマンドにサブスクライブし、このコマンドの結果として発生したことの結果を受信する。これらのメッセージ結果は、次いで、パイプラインにおいて以後受信するメッセージ毎に、入力引数として追加することができる。メッセージ・パイプライニング・サービスは、メッセージ・パイプラインにおける最後のメッセージを受信したと判断し、次いでメッセージ・パイプラインの結果をサブスクライバ６０７に発行する。この
ように、コールする側のサービス(calling service)が、任意の中間ステップをパイプラ
イン・サービスに移譲することができる。

[0058] 以上によれば、サービスをスケーリングする、および／または複数のコンピュータ・システムにわたって移動させることを可能にする方法、システム、およびコンピュータ・プログラム製品を提供する。更に、１つのサービス・バージョンから他のバージョンに移行し、外部エンティティがサブスクライバによって発行されたメッセージを受信することを可能にする外部システム統合サービスを実装する方法、システム、およびコンピュータ・プログラム製品を提供する。

[0059] 本明細書において説明した概念および特徴は、それらの主旨や記述的特性(descriptive characteristics)から逸脱することなく、他の特定形態においても具体化する
ことができる。説明した実施形態は、あらゆる観点において、限定ではなく例示として見なされるものとする。したがって、本開示の範囲は、以上の説明によってではなく、添付した請求項によって示される。請求項の均等の意味および範囲に該当するあらゆる変更は、その範囲内に包含されるものとする。

Claims (15)

1. １つ以上のプロセッサと、
   システム・メモリと、
   コンピュータ実行可能命令が格納されている１つ以上のコンピュータ読み取り可能記憶媒体と、
   を含むコンピュータ・システムであって、前記命令が前記１つ以上のプロセッサによって実行されると、前記計算システムに、第１サービス・バージョンから第２バージョンに移行するための方法を実行させ、前記方法が、
   サービスの第１バージョンをインスタンス化するステップと、
   前記同じサービスの第２バージョンをインスタンス化し、前記サービスの第１バージョンおよび前記サービスの第２バージョンが同時に実行することになるようにするステップと、
   前記サービスの第１バージョンに処理のために送られたメッセージを、前記サービスの第２バージョンに送るべきことを決定するステップと、
   前記サービスの第２バージョンを使用して、前記メッセージを処理するステップと、
   を含む、コンピュータ・システム。
2. 請求項１記載のコンピュータ・システムにおいて、前記サービスの第１バージョンが新しいバージョンであり、前記サービスの第２バージョンが古いバージョンであり、前記サービスが、当該サービスの前記第１の新しいバージョンから前記第２の古いバージョンに引き継がれる、コンピュータ・システム。
3. 請求項１記載のコンピュータ・システムにおいて、サービスのアップグレードが、実質的にダウンタイムなく実行されるように、前記サービスの第１バージョンがインストール時に自動的に実装される、コンピュータ・システム。
4. 請求項３記載のコンピュータ・システムにおいて、前記サービスの第２バージョンが、前記サービスの第１バージョンが一旦実装されたなら、自動的にアンインストールされる、コンピュータ・システム。
5. 請求項１記載のコンピュータ・システムにおいて、前記サービスの第１バージョンに処理のために送られたメッセージを、前記サービスの第２バージョンに送るべきことを決定するステップが、１つ以上の論理評価に基づく、コンピュータ・システム。
6. 請求項５記載のコンピュータ・システムにおいて、前記サービスの第１バージョンに処理のために送られたメッセージを、前記サービスの第２バージョンに送るべきことを決定するステップが、１つ以上の構成設定に基づく、コンピュータ・システム。
7. 請求項１記載のコンピュータ・システムにおいて、前記サービスの第１バージョンおよび前記サービスの第２バージョンの双方が、前記受信したメッセージを同時に処理する、コンピュータ・システム。
8. 請求項７記載のコンピュータ・システムにおいて、同時に実行する前記サービスの第１および第２バージョンの出力が、発生したエラーについて、比較される、コンピュータ・システム。
9. 少なくとも１つのプロセッサとメモリとを含むコンピュータ・システムにおいて、外部システム統合サービスを実装するためのコンピュータ実装方法であって、
   内部メッセージ・ブローカ・サービスが設置されたと判定するステップであって、前記
   メッセージ・ブローカ・サービスが、サービス間における通信を可能にする１つ以上のメッセージ・キューを維持するように構成され、前記メッセージ・キューが、パブリッシャからメッセージを受信し、メッセージをサブスクライバに転送するように構成される、ステップと、
   前記内部メッセージ・ブローカ・サービスと合同して、外部システム統合サービスをインスタンス化するステップであって、前記外部システム統合サービスが、指定された登録済みメッセージにサブスクライブし、前記登録済みメッセージを１つ以上外部エンティティに転送するように構成される、ステップと、
   前記外部システム統合サービスが登録したメッセージを受信するステップと、
   前記外部システム統合サービスが、前記受信した登録済みメッセージを、前記１つ以上の指定された外部エンティティに転送するステップと、
   を含む、コンピュータ実装方法。
10. 請求項９記載の方法であって、更に、少なくとも１つの制御システムを、前記設置された内部メッセージ・ブローカ・サービスと合同して、サービスとしてインスタンス化するステップであって、前記制御システムが、１つ以上の指定された機械に対して、機械機能を動作させるように構成される、ステップを含む、コンピュータ実装方法。
11. 請求項９記載の方法において、前記外部システム統合サービスが、前記メッセージング・キューにおける１つ以上のサービスと相互作用する、コンピュータ実装方法。
12. 請求項９記載の方法において、前記外部システム統合サービスが、前記外部エンティティに利用可能にした１組のメソッドを発行する、コンピュータ実装方法。
13. 少なくとも１つのプロセッサとメモリとを含むコンピュータ・システムにおいて、第１サービス・バージョンから第２バージョンに移行するためのコンピュータ実装方法であって、
    サービスの第１バージョンをインスタンス化するステップと、
    前記同じサービスの第２バージョンをインスタンス化し、前記サービスの第１バージョンおよび前記サービスの第２バージョンが同時に実行することになるようにするステップと、
    前記サービスの第１バージョンに処理のために送られたメッセージを、前記サービスの第２バージョンに送るべきことを決定するステップと、
    前記サービスの第２バージョンを使用して、前記メッセージを処理するステップと、
    を含む、コンピュータ実装方法。
14. 請求項１３記載の方法において、前記サービスの第１バージョンが新しいバージョンであり、前記サービスの第２バージョンが古いバージョンであり、前記サービスが、当該サービスの前記第１の新しいバージョンから前記第２の古いバージョンに引き継がれる、コンピュータ実装方法。
15. 請求項１３記載の方法において、サービスのアップグレードが、実質的にダウンタイムなく実行されるように、前記サービスの第１バージョンがインストール時に自動的に実装される、コンピュータ実装方法。

Images