(57)【要約】【課題】効率を向上させるために、着信クライアント要求の利用度メトリクスなどの条件（または負荷バランシング検討材料など他のネットワーク条件）を監視し、それを使用して、ネットワーク内の場所へのウェブ・サービスの動的配備、再配備、または配備解除をトリガする。【解決手段】配備解除は、分散サービス場所（２４０）に適用することができ、サービスが元々配備されていたオリジン・サーバ（２９０）にも適用することができる。サービス要求は、サーバが置かれた宛先に、クライアントにとって透過的な方式で動的にルーティングされる。任意選択の態様では、この同じ動的配備手法を使用してサービスを再配備することにより、システム更新内容のプログラム式複製を実現することもでき、それによって、以前に配備されたソフトウェアを更新する複雑さを大幅に軽減することができる。【特許請求の範囲】
【請求項１】
コンピューティング・ネットワークにおいてサービスを動的に配備する方法であって、
選択されたサービスに対するクライアント要求を受け取るステップと、
前記選択されたサービスがまだ動的に配備されていない場合、前記受け取った要求を第１のサーバから満たすステップと、
前記動的配備がトリガされると、前記選択されたサービスを前記第１のサーバから１つまたは複数の他のサーバにプログラム式に移動することによって動的配備を実現するステップと、
前記実現ステップが前記選択されたサービスを動的に配備させた後で、前記受け取った要求を前記１つまたは複数の他のサーバから満たすステップとを含む方法。
【請求項２】
前記選択されたサービスに対する前記受け取ったクライアント要求の数を監視するステップと、
前記監視した数が所定の閾値を超えた場合、前記動的配備をトリガするステップとを含む、請求項１に記載の方法。
【請求項３】
前記所定の閾値が複数の動的に配備されたサービスに適用される、請求項２に記載の方法。
【請求項４】
前記所定の閾値が前記選択されたサービスに適用される、請求項２に記載の方法。
【請求項５】
前記監視ステップが、前記１つまたは複数の他のサーバのそれぞれにおいて前記受け取ったクライアント要求をカウントする、請求項２に記載の方法。
【請求項６】
前記監視ステップが、前記１つまたは複数の他のサーバのうちの複数のサーバにおいて、前記受け取ったクライアント要求をカウントする、請求項２に記載の方法。
【請求項７】
前記コンピューティング・ネットワークの負荷を監視するステップと、
監視した前記負荷が所定の閾値を超えた場合、前記動的配備をトリガするステップとをさらに含む、請求項１に記載の方法。
【請求項８】
コンピューティング・ネットワークにおいてサービスを動的に配備するシステムであって、
選択されたサービスに対するクライアント要求を受け取る手段と、
前記選択されたサービスがまだ動的に配備されていない場合、受け取った前記要求を第１のサーバから満たす手段と、
前記動的配備がトリガされると、前記選択されたサービスを前記第１のサーバから１つまたは複数の他のサーバにプログラム式に移動することによって動的配備を実現する手段と、
前記実現手段が前記選択されたサービスを動的に配備させた後で、前記受け取った要求を前記１つまたは複数の他のサーバから満たす手段とを含むシステム。
【請求項９】
コンピューティング・ネットワークにおいてサービスを動的に配備するコンピュータ・プログラムであって、前記コンピュータ・プログラム製品は１つまたは複数のコンピュータ可読媒体に上に実現され、
選択されたサービスに対するクライアント要求を受け取るコンピュータ可読プログラム・コード手段と、
前記選択されたサービスがまだ動的に配備されていない場合、前記受け取った要求を第１のサーバから満たすコンピュータ可読プログラム・コード手段と、
前記動的配備がトリガされると、前記選択されたサービスを前記第１のサーバから前記１つまたは複数の他のサーバにプログラム式に移動することによって動的配備を実現するコンピュータ可読プログラム・コード手段と、
選択された前記サービスを動的に配備させた後で、前記受け取った要求を前記１つまたは複数の他のサーバから満たすコンピュータ可読プログラム・コード手段とを含むコンピュータ・プログラム。
【請求項１０】
コンピューティング・ネットワークにおいてサービスを動的に配備解除する方法であって、
選択されたサービスの配備解除トリガを受け取るステップと、
前記選択されたサービスが配備されている１つまたは複数のネットワーク場所を判断するステップと、
前記ネットワーク場所のうちの１つまたは複数の選択されたネットワーク場所から、前記選択されたサービスをプログラム式に除去することにより、動的配備解除を実現するステップとを含む方法。
【請求項１１】
前記選択されたサービスに対するクライアント要求を受け取るステップと、
前記選択されたサービスがプログラム式に除去された前記１つまたは複数の選択されたネットワーク場所とは異なる前記ネットワーク場所から、前記選択された要求を継続して満たすステップとを含む、請求項１０に記載の方法。
【請求項１２】
前記配備解除トリガが、前記ネットワーク場所における前記選択されたサービスの利用度に基づく、請求項１０に記載の方法。
【請求項１３】
前記配備解除トリガが、前記ネットワーク場所におけるネットワーク負荷に基づく、請求項１０に記載の方法。
【請求項１４】
前記配備解除トリガが、前記選択されたサービスが最初に配備されたオリジン・サーバによって発行された配備解除要求である、請求項１０に記載の方法。
【請求項１５】
前記選択されたサービスの前記利用度を所定の閾値と比較し、前記利用度が前記所定の閾値を下回る場合に前記配備解除トリガを送るステップとをさらに含む、請求項１２に記載の方法。
【請求項１６】
前記所定の閾値が、配備された複数のサービスに適用される、請求項１５に記載の方法。
【請求項１７】
前記所定の閾値が、前記ネットワーク場所のうちの前記１つまたは複数の選択されたネットワーク場所に適用される、請求項１５に記載の方法。
【請求項１８】
前記利用度が、所定の時間間隔内における前記選択されたサービスに対する平均クライアント要求数である、請求項１２に記載の方法。
【請求項１９】
前記比較ステップで使用するために時間間隔における前記利用度を入手するステップをさらに含む、請求項１５に記載の方法。
【請求項２０】
前記コンピューティング・ネットワークの負荷を監視するステップと、
監視した前記負荷が所定の閾値と一致する場合、前記動的配備解除をトリガするステップとをさらに含む、請求項１０に記載の方法。
【請求項２１】
前記プログラム式に除去するステップが、前記選択されたサービスに対する配備解除要求を前記１つまたは複数の選択されたネットワーク場所に対して発行するステップをさらに含む、請求項１０に記載の方法。
【請求項２２】
前記ネットワーク場所のうちの、特定の１つのネットワーク場所において前記配備解除要求を受け取るステップであって、前記特定の１つのネットワーク場所が、前記選択されたサービスが動的に配備解除される前記ネットワーク場所のうちの前記選択された１つのネットワーク場所であるステップと、
前記受け取るステップに応答して、前記特定の１つのネットワーク場所における前記選択されたサービスを停止し、前記選択されたサービスを実現する実行コードを前記特定の１つのネットワーク場所の実行時環境から除去するステップとを含む、請求項２１に記載の方法。
【請求項２３】
コンピューティング・ネットワークにおいてサービスを動的に配備解除するシステムであって、
選択されたサービスの配備解除トリガを受け取る手段と、
前記選択されたサービスが配備されている１つまたは複数のネットワーク場所を判断する手段と、
前記ネットワーク場所のうちの１つまたは複数の選択されたネットワーク場所から、前記選択されたサービスをプログラム式に除去することにより、動的配備解除を実現する手段とを含むシステム。
【請求項２４】
コンピューティング・ネットワークにおいてサービスを動的に配備解除するコンピュータ・プログラム製品であって、１つまたは複数のコンピュータ可読媒体上に実現され、
選択されたサービスの配備解除トリガを受け取るコンピュータ可読プログラム・コード手段と、
前記選択されたサービスが配備されている１つまたは複数のネットワーク場所を判断するコンピュータ可読プログラム・コード手段と、
前記ネットワーク場所のうちの１つまたは複数の選択されたネットワーク場所から、前記選択されたサービスをプログラム式に除去することにより、動的配備解除を実現するコンピュータ可読プログラム・コード手段とを含むコンピュータ・プログラム製品。
【請求項２５】
コンピューティング・ネットワークにおいてサービスを動的に再配備する方法であって、
選択されたサービスに対する再配備トリガを受け取るステップと、
前記選択されたサービスがオリジン・サーバにおける元の場所から配備された１つまたは複数のネットワーク場所を判断するステップと、
前記選択されたサービスを前記ネットワーク場所と前記オリジン・サーバとからプログラム式に除去するステップと、
前記選択されたサービスを前記ネットワーク場所と前記オリジン・サーバとにプログラム式に再配置するステップとを含む方法。
【請求項２６】
前記再配備トリガが前記オリジン・サーバからの再配備要求を含む、請求項２５に記載の方法。
【請求項２７】
前記選択されたサービスを改訂する場合に前記再配備トリガを送るステップをさらに含む、請求項２５に記載の方法。
【請求項２８】
前記選択されたサービスに対するクライアント要求を受け取るステップと、
前記再配備トリガを受け取る前に、前記受け取った要求を前記ネットワーク場所から満たすステップと、
プログラム式に除去する前記ステップとプログラム式に再配置する前記ステップとの後に、前記受け取った要求を前記再配置されたサービスを使用して満たすステップとをさらに含む、請求項２５に記載の方法。
【請求項２９】
前記再配備トリガを受け取った後で、プログラム式に除去する前記ステップとプログラム式に再配置する前記ステップとが完了するまで前記選択されたサービスをアンパブリッシュし、その後で、前記選択されたサービスを再パブリッシュするステップをさらに含む、請求項２５に記載の方法。
【請求項３０】
前記オリジン・サーバから前記再配備要求を受け取るのに応答して、前記ネットワーク場所の各ネットワーク場所に後続の再配備要求を送るステップをさらに含む、請求項２６に記載の方法。
【請求項３１】
プログラム式に再配置する前記ステップが、
前記ネットワーク場所のうちの選択された１つのネットワーク場所から、前記選択されたサービスに対する配備要求を発行するステップと、
前記ネットワーク場所のうちの前記選択された１つのネットワーク場所において、前記選択されたサービスの置換えを含む応答メッセージを受け取るステップと、
前記ネットワーク場所のうちの前記選択された１つのネットワーク場所に、前記選択されたサービスの置換えを配備するステップとをさらに含む、請求項３０に記載の方法。
【請求項３２】
コンピューティング・ネットワークにおいてサービスを動的に再配備するシステムであって、
選択されたサービスに対する再配備トリガを受け取る手段と、
前記選択されたサービスがオリジン・サーバにおける元の場所から配備された１つまたは複数のネットワーク場所を判断する手段と、
前記選択されたサービスを前記ネットワーク場所と前記オリジン・サーバとからプログラム式に除去する手段と、
前記選択されたサービスを前記ネットワーク場所と前記オリジン・サーバとにプログラム式に再配置する手段とを含むシステム。
【請求項３３】
コンピューティング・ネットワークにおいてサービスを動的に再配備するコンピュータ・プログラム製品であって、１つまたは複数のコンピュータ可読媒体上に実現され、
選択されたサービスに対する再配備トリガを受け取るコンピュータ可読プログラム・コード手段と、
前記選択されたサービスがオリジン・サーバにおける元の場所から配備された１つまたは複数のネットワーク場所を判断するコンピュータ可読プログラム・コード手段と、
前記選択されたサービスを前記ネットワーク場所と前記オリジン・サーバとからプログラム式に除去するコンピュータ可読プログラム・コード手段と、
前記選択されたサービスを前記ネットワーク場所と前記オリジン・サーバとにプログラム式に再配置するコンピュータ可読プログラム・コード手段とを含むコンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ・ネットワークに関し、より詳細には、ネットワーク内の様々なサイトとの間で、サービス（ウェブ・サービスまたはその他のネットワーク・アクセス可能サービスなど）を動的に配備、再配備、および配備解除する方法、システム、およびコンピュータ・プログラム製品に関する。
【背景技術】
【０００２】
ウェブ・サービス技術は、分散アプリケーション統合のための機構として急速に普及している。一般に、「ウェブ・サービス」とは、ネットワーク・アクセス可能な処理の集合を表すインタフェースである。ウェブ・サービスは、特定のタスクまたはタスクのセットを実行する。ウェブ・サービスは、１つまたは複数の他のウェブ・サービスと、連携可能に協働して、複雑なワークフローや業務のそれぞれの部分を実施する場合がある。たとえば、複雑な購入発注業務の遂行には、発注側企業における発注サービス（すなわち発注ソフトウェア）と１つまたは複数の取引先における納品サービスとの間の自動化された相互連絡が必要な場合がある。
【０００３】
多くの業界専門家が、サービス中心型ウェブ・サービス構想をインターネットにおける次の発展過程とみなしている。ウェブ・サービスにより、人間の介入を必要としないソフトウェアへの分散ネットワーク・アクセスが、プログラム間動作のために広く利用可能になる。初期のインターネットは、主として、利用者が、生成済みの静的ドキュメントの配信を要求することができる分散ファイル・システムとして機能していたが、近年では、要求者に提供されるコンテンツに対して一層動的でパーソナライズされた特徴を加える傾向にある。一般に、従来、このような動的かつパーソナライズされたコンテンツは、企業ネットワークで生成されてきた。しかし、この手法は、企業のコンピューティング資源に多大な負担を強いる。静的コンテンツのキャッシング（および限られた範囲で動的に生成された後のコンテンツのキャッシング）、作業負荷バランシング、コンテンツ配信など、バックエンド・サービスに対する処理負担を軽減するための技法がいくつか開発されている。
【０００４】
キャッシングは、コンテンツを格納し、その後要求があったときに可能であればそのコンテンツを提供することによって、コンテンツを繰り返し生成するのを避けようとするものである。キャッシュしたコンテンツの提供は、バックエンド・コンピューティング資源の作業負荷を軽減するだけでなく、ユーザへの応答時間も短縮する。作業負荷バランシングは、クラスタ化されたサーバから成るグループ内の各サーバに送られる作業の量を動的に調整することにより、ウェブ・サイトのパフォーマンスを向上させる。コンテンツ配信では、たとえばキャッシュから要求に応じられる可能性を高めるためにキャッシュ・サーバなど、ネットワーク内の様々な場所に対して静的コンテンツを事前に（静的に）にパブリッシュすることを試みる。コンテンツ配信サービス・プロバイダ（ＣＤＳＰ）は、エンド・ユーザの近傍で静的コンテンツをキャッシングするために自社の広いネットワーク基盤へのアクセスを提供することによって、有用なサービスを提供する。これにより、各企業は費用効果の高い方式で業務規模を拡張することができる。動的コンテンツ配信（すなわち、生成したコンテンツを動的にユーザの近くに移動させること）を行うならば、これと同じ拡張性の利点が得られることになるはずである。アプリケーションによっては（たとえば、プレゼンテーション・ロジック内でのセッション管理を行うものや、バッチ・モードでバックエンド業務ロジックにのみアクセスするものなど）、プレゼンテーション・ロジックをエッジに（静的に）配備することができるものもある。その場合、コンテンツ配信プロセスによって、一般に応答時間も短縮される。
【０００５】
ネットワーク構成において「エッジ・サーバ」を使用し、静的なアプリケーション構成要素（画像やフォームなど）を、要求者に迅速に返すことができる（または要求者に配信する応答の組み立てに使用するプレゼンテーション・ロジックによって迅速に取り出すことができる）ネットワークのエッジ付近にキャッシュすることにより、ネットワーク効率と可用性が向上する。エッジ・サーバとは、ネットワーク・エッジまたはその付近に物理的に配置されたサーバである。エッジ・サーバは、作業負荷バランシングを行うこともでき、分散ウェブ・キャッシュ、サロゲート、プロキシなどと呼ばれることもある（たとえば、ＩＢＭ  ＷｅｂＳｐｈｅｒｅ（登録商標）エッジ・サーバは、作業負荷バランシングを行い、リバース・プロキシ・サーバまたはプロキシ・キャッシュ・サーバあるいはその両方としても機能する）。図１に、ネットワーク内の代表的なサーバ・サイト１００（すなわち、所与の完全ドメイン名に関連づけられたウェブ・コンテンツとして機能するサーバ・ノードの集合）の図を示す。このコンテンツは、（たとえば）「www.ibm.com」のようなドメイン名のサーバ・コンテンツとすることができる。この例のサーバ・サイト１００は、アプリケーション・サーバ１４０（ＩＢＭ  ＷｅｂＳｐｈｅｒｅアプリケーション・サーバなど）のクラスタ１５０と、複数のバックエンド・エンタープライズ・データ・サーバ１６０（ＩＢＭのＤＢ／２、ＣＩＣＳ（登録商標）、またはＭＱＩ製品などを稼働させたＩＢＭ  ＯＳ／３９０（登録商標）サーバなど）と、複数のウェブ・サーバ１３０（Ａｐａｃｈｅ（アパッチ）、Ｎｅｓｃａｐｅ（ネットスケープ）、Ｍｉｃｒｏｓｏｆｔ（マイクロソフト）サーバなど。アプリケーション・サーバおよびウェブ・サーバは、単一のハードウェア・ボックス内に共存することが多いことに留意されたい）と、複数のファイアウォール１１０と、複数のエッジ・サーバまたはリバース・プロキシ・キャッシュ・ロード・バランサ１２０とを含む（「ＷｅｂＳｐｈｅｒｅ」、「ＯＳ／３９０」、および「ＣＩＣＳ」は、ＩＢＭの登録商標である）。
【０００６】
次世代エッジ・サーバ技術により、ネットワークのエッジに、アプリケーション・プログラムの動的特徴がいくつかもたらされるであろう。これは、ネットワーク・エッジでウェブ・アプリケーションをホスティングし、その各エッジ・サーバにプレゼンテーション・ロジック（サーブレット、ＪＳＰ（商標）、ＰＨＰなど）を静的に配備することにより、実現される。ＪＳＰ、すなわちＪａｖａ  Ｓｅｒｖｅｒ  Ｐａｇｅｓ（商標）は、ウェブ・ドキュメントにコンテンツを動的に組み込むスクリプト・コマンドの使用により表されるプレゼンテーション・ロジックである。（「ＪＳＰ」および「Ｊａｖａ  Ｓｅｒｖｅｒ  Ｐａｇｅｓ」はサン・マイクロシステムズ社の商標である）。ＰＨＰ（Personal Home Page（パーソナル・ホーム・ページ）も、ウェブドキュメントにコンテンツを動的に組み込むために使用可能なスクリプト言語である。
【０００７】
ウェブ・サービスにより、ＨＴＴＰ（Hypertext TransferProtocol（ハイパーテキスト転送プロトコル））、またはＳＯＡＰ（Simple Object Access Protocol（シンプル・オブジェクト・アクセス・プロトコル）、またはＸＭＬ（ExtensibleMarkup Language（拡張マークアップ言語））プロトコル、あるいはこれらの組合せ、ＷＳＤＬ（Web Services DescriptionLanguage（ウェブ・サービス記述言語））、およびＵＤＤＩ（Universal Description, Discovery, andIntegration（ユニバーサル・ディスクリプション、ディスカバリ、アンド・インテグレーション）などのオープン・ウェブ基盤標準を介した「ジャスト・イン・タイム」アプリケーション統合が容易になるであろう。ＨＴＴＰは、インターネットなどのＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）ネットワークを介したメッセージの交換に一般的に使用されている。ＳＯＡＰは、分散環境においてメソッドを呼び出すために使用されるＸＭＬベースのプロトコルである。ＸＭＬプロトコルは、アプリケーション間メッセージ交換を可能にするアプリケーション層伝送プロトコルのための、ワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）の発展型仕様である。ＸＭＬプロトコルは、ＳＯＡＰと一緒にされることもある。ＷＳＤＬは、分散ネットワーク・サービスを記述するためのＸＭＬ書式である。ＵＤＤＩは、企業が自社のサービスをリストすることができ、サービス要求者が特定のサービスを提供する企業を見つけ出すことができる、ＸＭＬベースのレジストリ技法である。ジャスト・イン・タイム・アプリケーション統合は、ＵＤＤＩ要求を発行してＵＤＤＩレジストリを介した分散サービスを探索し、ＳＯＡＰ／ＸＭＬプロトコルおよびＨＴＴＰメッセージを使用してプラットフォーム中立ＷＳＤＬ書式で伝達されるサービス情報を使用して、探索したサービスに要求者を動的に対応づけることによって可能になる。（以下、ＳＯＡＰと言う場合、ＸＭＬプロトコルの意味的に同様な側面をも同等に指すものと解釈されたい。）これらの構成要素を使用して、ウェブ・サービスは、要求者に、１つまたは複数の遠隔場所にあるプログラム構成要素への透過的アクセスを提供する。これは、プログラム構成要素が要求者のものとは異なるオペレーティング・システム上で稼働し、異なるプログラミング言語で作成されている場合であっても同様である。（ＳＯＡＰの詳細については、http://www.w3.org/TR/2000/NOTE-SOAP-20000508の「シンプル／オブジェクト・アクセス・プロトコル（SimpleObject Access Protocol）（SOAP）」２０００年５月８日、W3Cノート（W3C Note）１．１を参照されたい。ＸＭＬプロトコルの詳細については、http://www.w3.org/2000/xpを参照されたい。ＷＳＤＬの詳細は、http://www.w3.org/TR/2001/NOTE-wsdl-20010315の「ウェブ・サービス記述言語（WebServices Description Language（WSDL））２００１年３月１５日、Ｗ３Ｃノート（W3C Note）１．１」）を参照されたい。ＵＤＤＩの詳細は、http://www.uddi.org/specification.htmlを参照されたい。ＨＴＴＰについては、インターネット技術標準化委員会（InternetEngineering Task Force）のリクエスト・フォア・コメント（Request for Comments（RFC））２６１６「ハイパーテキスト転送プロトコル（HypertextTransfer Protocol）-- HTTP/1.1」（１９９９年６月））に記載されている。
【０００８】
ネットワーク・エッジにおけるプレゼンテーション・ロジックの静的配備は、バックエンド・コンピューティング資源の負担の一部を軽減し、バックエンド・ビジネス・ロジックの実行を必要としないコンテント要求に対する応答時間を短縮するが、コンテンツ生成のために企業内に送らなければならない要求も依然として多いであろう。ビジネス・ロジックが、企業の中核内にとどまる場合、ネットワーク効率化は実現されず、企業が処理ボトルネックであり続け、企業の発展の制限要因であり続けると考えられる。さらに、ネットワーク・エッジにおけるプレゼンテーション・ロジックの静的配備が効率的なのは、利用パターンが一定していて予測可能な場合に限られる。すなわち、利用パターンが変化した場合、静的に配備されたロジックは、あまり有効に活用できなくなるであろう。さらに、ソフトウェアをこのように静的に配備すると、どのシステムにどのレベルのソフトウェアを配備したかを記録するための手段と、配備されたソフトウェアを必要に応じて修正する手段を設けなければならないため、管理の複雑さ、特にソフトウェアのアップグレードが増える可能性が高くなる。このアップグレード処理は、手作業であることが多く、手間がかかる上、誤りを犯しやすい作業である。しかも、ウェブ・サービスは、分散ソフトウェア資源をより広く利用可能にするが、サービスによってはその物理的な場所のために、多数の遠隔サービス要求者にとって応答時間が最適とは言えなくなる可能性が高い。
【非特許文献１】
http://www.w3.org/TR/2000/NOTE-SOAP-20000508「シンプル／オブジェクト・アクセス・プロトコル（SimpleObject Access Protocol）（SOAP）」２０００年５月８日、Ｗ３Ｃノート（W3C Note）１．１
【非特許文献２】
http://www.w3.org/2000/xp
【非特許文献３】
http://www.w3.org/TR/2001/NOTE-wsdl-20010315「ウェブ・サービス記述言語（WebServices Description Language（WSDL））２００１年３月１５日、Ｗ３Ｃノート１．１（W3C Note）」
【非特許文献４】
http://www.uddi.org/specification.html
【非特許文献５】
インターネット技術標準化委員会（InternetEngineering Task Force）リクエスト・フォア・コメント（Request for Comments（RFC））２６１６「ハイパーテキスト転送プロトコル（HypertextTransfer Protocol）-- HTTP/1.1」（１９９９年６月）」
【発明の開示】
【発明が解決しようとする課題】
【０００９】
したがって、従来の技術の上記の欠点および制約を回避する技法が必要である。
【課題を解決するための手段】
【００１０】
本発明の第１の目的は、分散ネットワークにおいて、ネットワーク・アクセス可能サービス（ウェブ・サービスを含むがこれには限定されない）を動的に配備する技法を提供することである。
【００１１】
本発明の第２の目的は、分散ネットワークにおいて、ネットワーク・アクセス可能サービス（ウェブ・サービスを含むがこれには限定されない）を動的に再配備する技法を提供することである。
【００１２】
本発明の第３の目的は、分散ネットワークにおいて、ネットワーク・アクセス可能サービス（ウェブ・サービスを含むがこれには限定されない）を動的に配備解除する技法を提供することである。
【００１３】
本発明の他の目的は、利用度メトリクスに基づいてネットワーク・アクセス可能サービスを動的に配備する技法を提供することである。
【００１４】
本発明の他の目的は、利用度メトリクスに基づいてネットワーク・アクセス可能サービスを動的に配備解除する技法を提供することである。
【００１５】
本発明の他の目的は、負荷バランシング検討要素に基づいてネットワーク・アクセス可能サービスを動的に配備する技法を提供することである。
【００１６】
本発明の他の目的は、負荷バランシング検討要素に基づいてネットワーク・アクセス可能サービスを動的に配備解除する技法を提供することである。
【００１７】
本発明のその他の目的および利点は、以下の説明および図面に一部を記載し、また、一部は本明細書の説明を読めば明らかになるであろうし、本発明を実施すればわかるであろう。
【００１８】
上記の目的を達成するため、また、本明細書にその概略を記載する本発明の主旨によると、本発明は、コンピューティング・ネットワークにおいてサービスを動的に配備する方法、システム、およびコンピュータ・プログラム製品を提供する。好ましい実施形態では、本技法は、選択されたサービスに対するクライアント要求を受け取るステップと、前記選択されたサービスがまだ動的に配備されていない場合、受け取った前記要求を第１のサーバから満たすステップと、前記動的配備がトリガされると、選択された前記サービスを前記第１のサーバから１つまたは複数の他のサーバにプログラム式に移動することによって動的配備を実現するステップと、前記実現ステップが選択された前記サービスを動的に配備させた後で、受け取った前記要求を１つまたは複数の他の前記サーバから満たすステップとを含む。
【００１９】
また、本発明は、コンピューティング・ネットワークにおいてサービスを動的に再配備する方法、システム、およびコンピュータ・プログラム製品も提供する。好ましい実施形態では、この技法は、選択されたサービスの再配備トリガを受け取るステップと、クライアントが選択されたサービスを要求する１つまたは複数のネットワーク場所を判断するステップと、選択された前記サービスがオリジン・サーバにおける元の場所から配備された場合、受け取った前記要求を第１のサーバから満たすステップと、まだ動的に配備されていない（サービス）をプログラム式に除去するステップと、前記ネットワーク場所および前記オリジン・サーバから、選択された前記サービスをプログラム式に移動することによって動的配備を実現するステップと、前記ネットワーク場所および前記オリジン・サーバに選択された前記サービスをプログラム式に再配置するステップとを含む。
【００２０】
また、本発明は、コンピューティング・ネットワークにおいてサービスを動的に配備解除する方法、システム、およびコンピュータ・プログラム製品も提供する。好ましい実施形態では、この技法は、選択されたサービスの配備解除トリガを受け取るステップと、選択された前記サービスが配備されている１つまたは複数のネットワーク場所を判断するステップと、前記ネットワーク場所のうちの１つまたは複数の選択されたネットワーク場所から、選択された前記サービスをプログラム式に除去することにより、動的配備解除を実現するステップとを含む。
【００２１】
また、本発明は、各種営業方法において使用すれば、以下によって有利である。すなわち、たとえば、１）ウェブ・ホスト・サイトがより効率的になる動的配備サービスの提供（それによって終端間コストの低減または顧客サイトの効率向上あるいはその両方の利点を顧客に与えることができる）２）ウェブ・ホスト・サイトの効率向上をもたらす動的再配備サービスの提供（これによりたとえば、配備されたサービスが、より迅速かつ現在必要とされているよりも少ない労力で更新される）、３）ウェブ・ホスト・サイトの効率向上をもたらす動的配備解除サービスの提供（たとえば、ネットワーク・エッジで不要になったサービスをプログラム式に除去する）などである。
【００２２】
本発明について、以下に図面を参照しながら説明する。全図面を通じて、同じ要素は同じ参照番号で示す。
【発明を実施するための最良の形態】
【００２３】
本発明は、ネットワーク・アクセス可能なサービスを動的に配備することによってネットワーク動作を向上させ、それによって従来の技術の欠点に対処する技法を定義する。さらに、以前に開発したソフトウェアをアップグレードする複雑さが、同じ動的配備機構に基づく任意選択の拡張機能により、自動化され、プログラム化されたシステム・アップグレードの反復によって軽減される。他の任意選択の拡張機能では、以前に配備したソフトウェアも、本発明の技法を使用して自動的かつプログラム化された方式で、配備解除することができる。（本明細書では、本発明の好ましい実施形態についてネットワーク・エッジで動作するものとして説明するが、当業者には明らかなように、これらの技法は、サーバ・ファームのフロントエンドで使用するように適合化することもできる。さらに、本明細書では、好ましい実施形態をウェブ・サービスと共に使用するものとして説明するが、これは例示的なものであり、限定的なものではない。開示の技法は、他のタイプのネットワーク・アクセス可能サービスとも有利に使用することができる。
【００２４】
好ましい実施形態によると、利用度メトリクスを特定のウェブ・サービスに対する着信クライアント要求に基づいて動的に計算する。サービスをユーザの要求に応じて動的に配備することにより、利用パターンが急激に変動する場合でも、エッジから適切なソフトウェアにアクセス可能になる。
【００２５】
一般に、ウェブ・サービスは、当技術分野で周知のように、Ｊａｖａ（Ｒ）クラス、ＣＯＭクラス、ＥＪＢ（エンタープライズＪａｖａ（Ｒ）Ｂｅａｎｓ）、ストアード・プロシージャ、ＩＭＢ、またはその他のデータベース・トランザクションを含めて、どのような形態のプログラミング・ロジックでもカプセル化することができる。（「Ｊａｖａ（Ｒ）」および「エンタープライズＪａｖａ（Ｒ）Ｂｅａｎｓ」はサン・マイクロシステムズ社の商標である。）ウェブ・サービスは、オペレーティング・システム、コンポーネント・モデル、プログラミング言語に対して中立的であるため、本発明を使用した場合、エッジにプレゼンテーション・ロジックのみ配備するという従来技術の制約がなくなる（以下で詳述するように、配備点に必要な実行時間が存在することを前提とする）。したがって、従来技術では静的コンテンツのキャッシングにより得ていたネットワーク効率を、真に動的性質のコンテンツの場合にも実現可能になる。
【００２６】
本明細書で使用する「利用度メトリクス」とは、特定のウェブ・サービスの要求回数に関して収集された情報を指す。利用カウンタに閾値を設定することができ、この閾値を使用して、サービスをエッジ・サーバに配備することによって効率化を実現するのに十分な頻度でサービスが要求される時点を判断することができる。本発明の実施態様によっては、すべてのウェブ・サービスについて単一の閾値を使用することが望ましい場合もあり、（ウェブ・サービスごとに異なる閾値も含めて）複数の閾値を設定するのが望ましい場合もある。一般には、閾値は、システム管理者が、ネットワーク・パラメータを設定するときに設定する。（別法として、一部の閾値にデフォルト値を使用し、一部の閾値をプログラム式に設定し、あるいはその両方を可能にすることもできる）。
【００２７】
本発明の動的配備技法は、本明細書に記載のように動的配備が可能になるようにエッジ・サーバ１２０に変更を加えた、図１に示す例示のネットワークのようなネットワーク構成内で動作可能である。図２に、本発明が動作可能なネットワーク構成の抽象表現を示す。図２には、動的配備プロセスを行う構成要素の配置と、それらの構成要素のネットワーク相互接続が示されている。これらの構成要素について以下に説明する。
【００２８】
図２に示すように、この配備システムの構成要素は、ポイント・オブ・プレゼンス（Pointof Presence：ＰＯＰ）配備ファシリテータ２３０（本明細書では、単に「配備ファシリテータ」または「ＤＦ」とも呼ぶ）と、ＣＤＳＰ配備ノード２６０（本明細書では「配備ノード」または「ＤＮ」とも呼ぶ）と、配備プロバイダ２８０（ＤＰ）とを含む。任意選択により、配備実行時コンテナ（ＤＲＴＣ）２４５を備えることもできる。（ＤＲＴＣは、後述の配備解除および再配備に備える本発明の任意選択の拡張機能に使用される。所望の場合には、ＤＲＴＣを動的配備システムでも使用してもよい。）さらに、サービス要求者２１０（たとえば、クライアント・アプリケーション）と、パブリックＵＤＤＩレジストリ２２０と、エッジ・サーバまたはＰＯＰ２４０と、ドメイン名システム（ＤＮＳ）ベースのホスト解決システム２５０と、プライベートＵＤＤＩレジストリ２７０と、オリジン・サーバ２９０が図示されている。要素２１０、２２０、２４０、２５０、２７０、および２９０は、当技術分野で周知であり（ただし、本明細書に記載の動的配備、配備解除、および再配備機能を除く）、これらの既存要素については、本明細書では詳述しない。
【００２９】
配備ファシリテータ構成要素２３０は、エッジ・サーバ２４０上に常駐し、１つまたは複数のオリジン・サーバ２９０から、ＤＦ２３０と同じ場所に配置されたＣＤＳＰアクセス・ポイントへのウェブ・サービスの配備を調整する。これについては、図４を参照しながら後で詳述する。
【００３０】
好ましい実施形態では、配備ノード２６０には、当該ＣＤＳＰの利用度メトリクスが記憶され、着信サービス要求を監視しながら利用度メトリクスを更新する。閾値利用度値に達すると、配備ノードは、対応するサービスの特定のＰＯＰ（たとえば特定のエッジ・サーバ）への配備を初期設定する機能を果たす。配備ノードは、さらにプライベートＵＤＤＩレジストリ２７０を含み、このプライベートＵＤＤＩレジストリは、当該特定のＣＤＳＰのためのサービス配備の現在の状態を管理する。本明細書では、プライベートＵＤＤＩノードは、ＣＤＳＰのファイアウォール内でホストされ、審査済みのパートナーのみに、ＵＤＤＩレジストリに含めるサービスをパブリッシュさせるパートナー・カタログＵＤＤＩノードであることが好ましい。さらに、組織内（すなわちファイアウォール内）の要求者のみが、当該プライベートＵＤＤＩノードに対して情報を要求することができる。プライベートＵＤＤＩレジストリ２７０の内容を、パブリックＵＤＤＩレジストリ２２０と置き換えることによって、組織外の要求者は組織内にあるサービスを要求することができる。
【００３１】
ＵＤＤＩレジストリ２２０は、別法として、ＣＤＳＰの非武装地帯（ＤＭＺ）でホストされているポータルＵＤＤＩノード（すなわち他のタイプのプライベートノード）とすることもできる。ポータルＵＤＤＩノードでは、どの要求者でもサービスを検索することができるが、サービスをパブリッシュすることが許されるのはＣＤＳＰのみである。
【００３２】
従来技術のＣＤＳＰは、一般に、要求されたコンテンツを提供するサーバを動的に突き止めるＤＮＳ２５０と、要求者の地理的場所を判断するｐｉｎｇ三角測量手段と、クライアント要求を、共通要求ＵＲＬが与えられた適切なＰＯＰ（すなわち要求者に比較的近い位置にあるＰＯＰ）に透過的に宛先変更するために使用するＩＰアドレス・マップとを含む、内部サービスを提供する。本発明によると、ＤＮ２６０は、このようなシステムと、動的サービス配備が透過的にクライアントに反映されるように対話する。（すなわち、クライアントは、特定のサービスを要求し、ＤＮＳシステムはそのサービスが現在どこに配備されているかを判断し、クライアントの要求をその現在配備場所に自動的にルーティングする。）この透過的な宛先変更については、図４を参照しながら以下で詳述する。
【００３３】
配備プロバイダ２８０は、企業ネットワーク内、好ましくはオリジン・サーバ２９０にあり、サービスを要求側エッジ・サーバ２４０に自動的および設定に従って配備するために、配備要求に応答する。サービス・アプリケーションの「エッジ可能」態様（すなわち、ネットワーク・エッジへへの配備が可能な態様）は、配備プロバイダのコンテキスト内に適切に（すなわち、エンタープライズ・アーカイブ（ＥＡＲ）、ウェブ・アーカイブ（ＷＡＲ）、Ｊａｖａ（Ｒ）アーカイブ（ＪＡＲ）などとして）パッケージ化され、格納されているものとする。
【００３４】
本発明の好ましい実施形態で使用可能なデータ構造を図３に示す。好ましい実施形態では、このデータ構造は、ＤＮ２６０が各ＰＯＰにおける特定のサービスの利用カウントを格納するために使用する。（実施形態によっては、システム規模の活動を反映する利用度メトリクスに基づいてサービスの追跡と配備を行うことが望ましい場合もある。）図３に示すように、サービスは、それぞれのＵＤＤＩバインディング・キーによって識別されることが好ましい。（あるいは、サービス名またはその他の同様の識別名、サービス・プロバイダ、最終エンドポイントで識別してもよい。）本明細書では、例示のためにこのデータ構造を「テーブル」と呼び、テーブル内に格納されたサービス情報を、ＣＤＳＰによって管理されているＰＯＰごとに別個の行を有するものとして示す。
【００３５】
好ましい実施形態では、本明細書で説明する１２段階のプロセスを使用して、ウェブ・サービスを動的に配備する。この配備プロセスでは、標準に準拠したウェブ・サービス・プラットフォームを利用することが好ましく、このプラットフォームとしては、ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、ＨＴＴＰメッセージ・フローがある。Ｗ３Ｃによって発表された、「添付ファイル付きＳＯＡＰメッセージ（SOAP Messages with Attachments）２０００年１２月１１日、Ｗ３Ｃノート」（http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211参照）という標題の仕様では、ＳＯＡＰメッセージに、添付物送信用のマルチパートＭＩＭＥ（「汎用インターネット・メール拡張機能（Multi-purposeInternet Mail Extensions）」）構造を使用する固有書式の１つまたは複数の添付物を関連づける標準的な方法について記載されている。ＳＯＡＰは、ウェブ・サービスを呼び出すための標準メッセージ形式であるため、本発明の好ましい実施形態では、ウェブ・サービスを動的に配備するための機構としてこのＳＯＡＰ添付標準を使用する。当然ながら、意味的に類似したコンテンツを、本発明の範囲から逸脱することなく、本明細書に記載のコンテンツの代わりに使用することもできる。たとえば、実施形態によってはＨＴＴＰフローの代わりにＳＭＴＰ（「簡易メール転送プロトコル（SimpleMail Transfer Protocol）」）フローを使用することもでき、前述のように、ＳＯＡＰの代わりにＸＭＬプロトコルを使用することもできる。
【００３６】
図４では、図２に示した各構成要素を使用し、丸番号を使用して好ましい実施形態の１２段階プロセスにおける各段階を示す。１２段階の各段階について、図４を参照しながら以下に説明する。
【００３７】
段階１では、オリジン・サーバ２９０にウェブ・サービス４９５を配備する。この段階では、本発明に含まれない従来技術の配備技法を使用する。次に、ウェブ・サービス４９５は配備ノード２６０に対してパブリッシュされる（段階２）。好ましい実施形態では、このパブリッシュ処理ではＵＤＤＩプログラマーＡＰＩ（「アプリケーション・プログラム・インタフェース（Application Program Interface）」）（UDDI Programmer's API）を使用してＷＳＤＬドキュメントをプライベートＵＤＤＩレジストリ２７０に格納するためにオリジン・サーバ２９０から配備ノード２６０に送信する。（ＵＤＤＩプログラマーＡＰＩは、http://www.uddi.org/pubs/ProgrammersAPI-V1-1.pdfに、「ＵＤＤＩプログラマーＡＰＩ１．０（UDDIProgrammer's API 1.0）２０００年９月３０日、ＵＤＤＩ公開仕様草案」という標題で記載されている。）送信されたＷＳＤＬドキュメントは、ＷＳＤＬ仕様で規定されている書式を使用して配備サービスを記述している。レジストリ２７０にＷＳＤＬドキュメントを格納するほかに、配備ノード２６０は、当該ドキュメントに関連づけられたプロバイダ・メタデータ（当該ドキュメントを送信したオリジン・サーバ２９０のネットワーク上の場所など）も格納することが好ましい。
【００３８】
段階３では、配備ノード２６０が、好ましくは「パブリッシュ（publish）」ＡＰＩのＵＤＤＩコマンド（「ｓａｖｅ＿ｓｅｒｖｉｃｅ」など）を使用して、そのプライベートＵＤＤＩレジストリ２７０をパブリックＵＤＤＩレジストリ２２０に置き換える。たとえば、次のようなＨＴＴＰ要求を使用して、「ｔｅｓｔｒｅｇｉｓｔｒｙ」という名前のテストレベルＩＢＭレジストリに情報をパブリッシュすることができる。
http://www-3.ibm.com/services/uddi/testregistry/protect/publishapi
配備ノード２６０は、この時点でリポジトリ４５２内のＤＮＳエントリの更新も行うことが好ましい。それによって、ＤＮＳ２５０は、その後、当該ウェブ・サービス４９５を求めるクライアント要求があった場合にそれらの要求が配備ノード２６０に自動的にルーティングされるようにする。（配備ノードはその場合、図３の３００に示すデータ構造に格納されている情報を使用して、そのような後続の要求をウェブ・サービス４９５の適切な場所に転送する。着信クライアント要求に対するＤＮの処理については、段階５を参照しながら後述する。）また、ＤＮは、パブリッシュされた当該サービスのＵＤＤＩバインディング・キーを含み、利用カウントが０の初期エントリをそのテーブル３００内に作成することが好ましい。
【００３９】
任意選択により、プライベートＵＤＤＩレジストリ２７０（すなわちパートナー・カタログ）と２２０に示すパブリックＵＤＤＩオペレータ・ノードとの間に、ホスティング・リダイレクタ関係を確立することもできる。この関係により、パブリック・ノードに対する「検索（find）」要求が、プライベート・ノード内のエントリを参照することができるようになる。この場合、要求をルーティングする際に、段階５で説明する三角測量プロセスは不要である。
【００４０】
段階４では、クライアント（すなわちサービス要求者）２１０が、「照会（ｉｎｑｕｉｒｙ）」ＡＰＩの「ｆｉｎｄ＿ｓｅｒｖｉｃｅ」などのＵＤＤＩコマンドを発行して、パブリックＵＤＤＩレジストリ２２０に特定のサービスの場所を問い合わせる。たとえば、次のようなＨＴＴＰ要求を使用して、「ｔｅｓｔｒｅｇｉｓｔｒｙ」という名前のレジストリを使用するサービスの場所を問い合わせることができる。
http://www-3.ibm.com/services/uddi/testregistry/inquiryapi
本発明の好ましい実施形態によると、解決されたサービス宛先には、配備ノード２６０のＵＲＬを参照するエンド・ポイント情報が含まれることになる（これにより、クライアント２１０はその後続の要求をＤＮに送信する）。あるいは、ホスティング・リダイレクタ手法を使用する場合は、ＵＤＤＩバインディング・テンプレートによって、配備ノードが管理する第２のバインディング・テンプレート「Ｂ」を参照するバインディング・キー「Ａ」が与えられる。バインディング・テンプレート「Ｂ」によって、配備ノードでホストされている宛先変更サービスの「アクセス・ポイント」要素が得られる。この宛先変更サービスは、適切なバインディング・キー「Ａ」が与えられたｇｅｔ＿ｂｉｎｄｉｎｇＤｅｔａｉｌメッセージに応答して、所望のサービスのアクセス・ポイントを提供するバインディング・テンプレートを返す。
【００４１】
次にクライアントは、サービスへの「バインディング」として、図４に示すサービス要求を発行する（段階５）。段階４でＵＤＤＩレジストリ２２０から得たエンド・ポイント情報を使用して、このサービス要求は配備ノード２６０にルーティングされる。ＣＤＳＰのＤＮＳ機能２５０が、この要求をインターセプトし、要求されたサービスの現在の場所をそのＤＮＳリポジトリ４５２から入手する。このサービスがクライアントのＰＯＰ２４０にすでに配備されている場合（これは、クライアントの場所を判断するためのｐｉｎｇ三角測量などの技法およびクライアントのＰＯＰを探索するＩＰマップ、またはホスティング・リダイレクタ関係を使用して判断することができる）、要求は（図４に示すように）そのＰＯＰにルーティングされ、処理される。サービスがまだクライアントのＰＯＰに配備されていない場合は、段階６の処理が行われる。
【００４２】
段階６では、配備ノードがクライアントのサービス要求を受け取り、それを、要求されたウェブ・サービス４９５が現在配備されているオリジン・サーバ２９０に転送する。サービスはオリジン・サーバで処理され、サービスの結果がクライアントに返される（図４には図示せず）。
【００４３】
配備ノードが各サービス要求を受け取った後、好ましい実施形態の段階７で、配備ノードはサービスの利用度メトリクスを更新して当該クライアント要求を反映させる（図３のテーブル参照。ＤＮ配備ノードはクライアント要求の情報を維持することが好ましい。）サービスが以前にアクセスされている場合、利用カウンタがインクリメントされる。これが当該サービスに対して最初に発行された要求の場合、利用カウンタは１に設定される。図３の例では、ＵＤＤＩバインディングキー「ｘｘｘ」を有するサービスがサンフランシスコにあるＰＯＰから１００回要求されているが、ニューヨーク市にあるＰＯＰからは３３回しか要求されていない。
【００４４】
利用度メトリクスを更新した後、段階８で、ＤＮ２６０は管理者によって（またはその他の方法で）設定された利用カウンタが閾値以上であるか否かを調べる。閾値以上である場合は、サービスをクライアントのＰＯＰに配備する必要があることを示している。すなわち、当該ＰＯＰのクライアントは、ローカルＰＯＰに当該サービスのコピーを配備するのが有用かつ効率的である（たとえば、ネットワーク往復時間を短くしてクライアントに対する応答時間を短縮すると同時に、バックエンド・システム内の伝送と処理の負担を減らす）と思われるほど頻繁に当該サービスを要求している。したがって、配備ノードは、適切なＰＯＰ２４０で配備ファシリテータに配備要求を発行する（図４のフロー８で示す）。この配備要求は、配備プロバイダ２８０からの配備を開始するために使用することができるサービス記述を提供することが好ましい。図５に、ＷＳＤＬを使用してコード化されたサービス記述を含む配備要求のサンプルを示す。
【００４５】
ＷＳＤＬコード化を熟知している業者には明らかなように、図５および図６に示す配備要求サンプルは、インタフェース定義を指定している。この例では、インタフェース定義は、本発明の配備サービスのインタフェース定義である。５１０に示すように、例示のインタフェースは、「Deployment-interface」という名前で、「getDeployedService」メソッド５４０を使用して呼び出される（図６）参照。２つのメッセージ「DeploymentRequest」５２０と「DeploymentResponse」５３０を定義する。DeploymentRequestメッセージは、「runtimeEnvironment」部を含み、これによって配備ファシリテータは、特定のサービスを当該ＰＯＰに配備するように準備する際に配備プロバイダが使用するＰＯＰ固有情報を指定することができる（段階９を参照しながら以下で詳述する）。５５０に示すように、ＷＳＤＬ処理とＳＯＡＰへのメッセージとのマッピングを行うバインディングを定義する。配備（Deploy）メソッドの呼び出しの結果は、アーカイブ参照またはサービス・アーカイブである（要素５６０参照）。図７では、段階８で送られる配備サービスの実施定義を指定している。
【００４６】
次に、段階９で、クライアントのＰＯＰにおいて配備ファシリテータ２３０が、段階８で配備ノード２６０から入手した情報を使用して配備プロバイダ２８０にＳＯＡＰ要求を発行する。この、ＳＯＡＰ要求は、当該サービスを動的に配備するように求めるものである。段階９で送信されるＳＯＡＰ要求の一例を、図８に示す。配備するサービスの名前またはその他の識別子は、「serviceName」６１０のようなタグの内容として指定されることに留意されたい。この例では、固有のサービス識別子「urn:www.acme.com:stockquoteservice」が指定されており、クライアント２１０によって要求され、「www.acme.com」にある「stockquoteservice」サービスを、動的に配備することを示している。
【００４７】
ＰＯＰ上の実行時環境が既知であって、特定のサービスが配備されるＰＯＰごとに一定している場合、段階９で送られる配備要求は、要求するサービスを識別するだけでよい。たとえば、この単純な手法は、要求されたサービスがＪａｖａ（Ｒ）で作成されている場合、各ＰＯＰがＪａｖａ（Ｒ）実行時を有する場合、各ＰＯＰが同じオペレーティング・システムを稼働させている場合、各ＰＯＰが同一バージョンのＳＯＡＰに対応していて同じ配備メッセージ構文を解釈することができる場合に、適切である。しかし、多くのネットワーク環境では、異なるＰＯＰ間でこれらの情報のタイプに相違がある場合がある。たとえば、いくつかのＰＯＰで異なるＳＯＡＰサーバが稼働しており、それらのサーバのサービス配備方法が異なる場合がある。あるいは、要求されたウェブ・サービスが高移植性言語で書かれていない場合もある。したがって、オリジン・サーバ（またはオリジン・サーバがアクセス可能なリポジトリ）には、配備する各サービスについて複数のバージョンを格納してもよい。その場合、特定のＰＯＰに対して、当該ＰＯＰで使用可能なサポートに応じて、異なるバージョンのサービスを送ることができる。たとえば、Ｗｉｎｄｏｗｓ（Ｒ）オペレーティング・システム用のＣＯＭアプリケーションを、特定のサービスの要求者に配備し、同じサービスをＬｉｎｕｘ（商標）オペレーティング・システムを稼働させているＰＯＰにＣプログラムとして配備することもできる。（「Ｌｉｎｕｘ」はライナス・トーバルズ（Linus Torvalds）氏の商標である。）したがって、本発明の好ましい実施形態は、サービスの配備を要求するときにＰＯＰが当該ＰＯＰの構成に関する情報を配備プロバイダに提供することができるように図５の５２０で定義されている「runtimeEnvironment」要素をサポートする。図８の６２０でこの技法の一例を示す。ここでは、配備ファシリテータが数種類の実行時情報を提供している。この例では、この情報には、ＰＯＰで稼働しているオペレーティング・システム名（Ｗｉｎｄｏｗｓ（Ｒ）２０００）と、ＳＯＡＰサーバ名（Apache  ＳＯＡＰ  Ｖ２．１）と、実行時環境（Ｊａｖａ（Ｒ））とが含まれる。この情報を使用して、配備プロバイダは、当該ＰＯＰに配備するウェブ・サービスの正しい情報を選択することができる。配備実行時環境の内容は、環境全体の必要に応じて単純にも複雑にもすることができる（すなわち、環境全体を通じて同じＳＯＡＰサーバを使用し、すべてのウェブ・サービスがたとえばＪａｖａ（Ｒ）で作成されている場合は、パラメータ値は空とすることもでき、あるいは、異なる種類の情報または追加情報を含めてもよい。追加情報を加える一例として、配備プロバイダからウェブ・サービスの複数のバージョンを入手可能な場合、配備ファシリテータは配備プロバイダが使用するバージョン番号を指定することができる。）
【００４８】
再び図４を参照すると、段階９で配備要求が送られた後、配備プロバイダ２８０は（段階１０で）配備ファシリテータ２３０にＳＯＡＰエンベロープを返す。ＳＯＡＰエンベロープには、（図５の要素５６０を参照しながら前述したように）アーカイブ参照またはサービス・アーカイブが含まれている。図９の例示のＳＯＡＰエンベロープの７３０に示すように、エンタープライズ・アーカイブ（ＥＡＲ）が、前述の「添付ファイル付きＳＯＡＰメッセージ」仕様に従って、このＳＯＡＰエンベロープを転送するＨＴＴＰ資源内のＭＩＭＥ添付物として含められている。（別法として、ＷＡＲまたはＪＡＲを、ＳＯＡＰエンベロープの添付物として含めるか、ＳＯＡＰエンベロープからの参照先としてもよい。）この例の７１０に示すように、「ArchiveRef」などの名前を持つタグの「href」属性により、バイナリ添付物内のコンテンツＩＤ７２０と一致するアドレスを指定する。（別法として、ＳＯＡＰサーバがArchiveRefタグを処理し、その後、ArchiveRefタグの内容を使用して添付物のコンテンツＩＤ要素に対する検索を発行することを前提とすれば、href属性を省いてもよい。）
【００４９】
段階１１で、ＳＯＡＰエンベロープと添付物とを受け取った後、配備ファシリテータ２３０は、ローカルＳＯＡＰサーバＡＰＩにアクセスして、クライアントのＰＯＰ２４０上にサービスを配備する。（ＳＯＡＰサーバＡＰＩは当業界で周知であり、本発明には含まれない。）
【００５０】
最後に、段階１２で、配備ファシリテータ２３０は、好ましくは配備ノード２６０に成功戻りコードを返した後、リポジトリ４５２内のＤＮＳエントリを更新して、当該ウェブ・サービスが（図４の４４８に示すように）エッジ・サーバ２４０に配備されたことを示す。このようにしてＤＮＳを更新することにより、当該エッジ・サーバ２４０をＰＯＰとして使用するクライアントからの当該サービスを求める後続の要求が、オリジン・サーバ２９０に配備されたサービス４９５ではなく４４８に配備されたサービスに自動的にルーティングされることになる。
【００５１】
以上に示したように、本発明の配備システムは、ウェブ・サービスを動的に配備するための拡張性のある枠組みを提供する。本明細書に記載の好ましい実施形態は、利用度メトリクスを使用してサービス配備を開始する。他の実施形態では、本明細書で開示する本発明の概念から逸脱することなく、他のトリガ事象を使用することもできる。たとえば、ＤＮは、ネットワークの負荷を監視し、その情報を段階８の動的配備決定の際に、上述の利用度メトリクスの代わりに（あるいはそれに加えて）使用することもできる。本配備システムの好ましい実施形態は、上述のようにＵＤＤＩ、ＷＳＤＬ、ＳＯＡＰ／ＸＭＬプロトコル、およびＨＴＴＰのウェブ・サービス・スタックを利用するため、それらを多くのプラットフォーム上でシームレスに統合することができる。エッジ・サーバは、このような配備システムを利用する１つのアプリケーション・プラットフォームを示すものであり、例示のために示したものであって、限定的なものではない。
【００５２】
本発明の任意選択の拡張機能では、一実施態様によりウェブ・サービスの配備解除または再配備あるいはその両方を動的に行うこともできる。以下に、これらの機能について述べる。（これらの任意選択の拡張機能の好ましい意実施形態について、前述の配備プロセスを参照しながら説明するが、これは例示のためであって、限定的なものではないことに留意されたい。以下に述べる配備解除技法および再配備技法は、他の方法で配備されたサービスとも有利に使用することができる。）
【００５３】
第１の任意選択拡張機能
ウェブ・サービスを動的に配備するのと同様に、本発明の任意選択の拡張機能により、ウェブ・サービスを動的に配備解除することができる。一態様では、この配備解除は、条件付きまたは選択的とすることができる。他の態様では、無条件である。以下、各態様について順に説明する。
【００５４】
条件付き配備解除を可能にするために、ウェブ・サービスの利用メトリクスを使用して、サービスを配備解除すべき時を判断することができる。典型的には、利用メトリクスは、ある期間に受け取った利用要求の平均数である。この利用度メトリクスに基づいて、サービスを配備解除すべき利用率を示す閾値を設定することができる。この閾値は、配備ノード２６０に格納することが好ましく、任意選択により必要に応じて（たとえば配備プロバイダ２８０、システム管理者などが）変更することもできる。たとえば、利用度メトリクスが１ヶ月間の１日当たり平均要求数であり、閾値が１日当たり１００件の要求に設定した場合、ウェブ・サービスは、月末に利用率が１日当たりの要求１００件未満に下がった場合に配備解除される。（利用要求以外の基準によってサービスの動的配備が決定される実施態様では、配備解除は当該他の基準を反映することが好ましい。）
【００５５】
この利用度メトリクスは、エッジ・サーバ２４０で維持することが好ましい。上記の例を使用すると、利用度メトリクスは１ヶ月に相当する期間中、利用カウンタを維持することによって算出する。この例では、利用率を算出するために、エッジ・サーバはカウントを開始した日付も記憶し、毎月末に利用カウンタをリセットする。あるいは、スライド制月期を使用することもできる。（必ずしも各エッジ・サーバが当該サーバに配備された特定のサービスについて利用度メトリクスを維持する必要はないことに留意されたい。実施態様によっては、選択されたエッジ・サーバにおける代表利用度メトリクスを累算するだけで十分である場合もある。）
【００５６】
利用度メトリクスはエッジ・サーバで維持されるが、この任意選択拡張機能の好ましい実施形態によると、配備ノード２６０が配備解除要求を発行する役割を負う。したがって、配備ノードは、エッジ・サーバにおけるウェブ・サービスを配備解除すべき時期を判断するために使用する利用率を監視する。配備ノードは、各エッジ・サーバに周期的に問い合わせて利用度メトリクスを入手する。利用メトリックスが閾値を下回る場合、ウェブ・サービスは配備解除される。
【００５７】
本発明によりウェブ・サービスが動的に配備された後、好ましい実施形態では以下のプロセスを使用して、ウェブ・サービスを条件付きで動的に配備解除する。図１０を参照すると、このプロセスを実行するために使用可能な動作の流れが丸番号で示されている。
【００５８】
１．配備ノード２６０が起動されると、配備ノードは、配備されたサービスの状態を指定された時間間隔で調べるように設定される。この時間間隔は、配備されたウェブ・サービスの利用パターンに基づいて設定する必要がある。使用する特定の時間間隔は重要ではなく、（たとえば）分、時間、日、週、または月単位で表すことができる。
２．新しいウェブ・サービスが配備されると、当該サービスの配備解除閾値を配備ノード２６０に記憶することが好ましい。この閾値は、動的に配備されたウェブ・サービスを配備解除すべき時期を判断するために使用することができる。
３．指定された時間間隔で、配備ノードが動的に配備されたすべてのウェブ・サービスのリストを入手する。このリストは、プライベート・リポジトリ２７０から入手するが、これは動的に配備されたウェブ・サービスごとにレジストリに新しいビジネス・サービス・エントリが作成されるためである。このリストには、ウェブ・サービスが配備されたすべての配備ファシリテータへの参照が格納される。図１１のテーブル９００に、この情報を格納することができるフォーマットの単純な例を示す。図に示すように、配備された各サービスがＵＤＤＩバインディング・キーなどのサービス識別子９１０によって識別され、ＩＰアドレスなどの情報９２０によって、それらのサービスがどこに配備されたかが識別される。（図３のテーブル３００と図１１のテーブル９００内の情報は、任意で、１つにまとめることも別々に格納することもできることに留意されたい。）
４．各配備ファシリテータ２３０に、利用度メトリクス要求が送られる。これに応答して、配備ファシリテータは配備実行時コンテナから利用度メトリクスを入手し、それを配備ノード２６０に返す。（各ＰＯＰ２４０において、各配備ファシリテータ２３０が配備実行時コンテナ２４５にアクセスすることができ、配備実行時コンテナ２４５は、ウェブ・サービスの実行時環境へのインタフェースを提供する。配備実行時コンテナは、この配備解除機構に使用されるＰＯＰ固有の利用度メトリクスを維持する。）
５．配備ノード２６０は、利用度メトリクスを閾値と比較する。利用度メトリクスが閾値を下回る場合、配備ノードは当該ウェブ・サービスの配備解除プロセスを開始する。
６．配備解除プロセスは、ＤＮＳサーバ２５０に対して、ＤＮＳリポジトリ４５２からウェブ・サービスのエントリを削除する要求を送ることから開始する。この要求が処理された後、ウェブ・サービスは、それ以上要求を受け取らない。
７．次に、配備ノードは配備ファシリテータに、ウェブ・サービスを配備解除する要求を送る。
８．配備ファシリテータが配備解除要求を受け取ると、ウェブ・サービス４４８は停止され、ウェブ・サービスの実行可能コードがエッジ・サーバ２４０の実行時環境から削除される。配備解除要求の処理が完了した後、ウェブ・サービスが成功裏に配備解除されたことを示す応答が、配備ノードに送られることが好ましい（図１０では図示せず）。
９．次に、配備ノードは、配備解除されたウェブ・サービスのエントリをプライベート・レジストリから削除する。
【００５９】
無条件配備解除を行うこの拡張機能の一態様では、ウェブ・サービスは、不要になったとき、または新しいウェブ・サービスに置き換えられるときに、配備解除される。従来技術のように静的に配備されるウェブ・サービスの場合、一般的な配備解除プロセスには基本的な２ステップがある。
【００６０】
１．サービス・レジストリからウェブ・サービスのサービス記述をアンパブリッシュする。サービスがアンパブリッシュされた後は、そのサービス記述を誰も見つけることができなくなる。
２．実行時環境からウェブ・サービスを除去する。これには、実行中のウェブ・サービスを順序に従って停止し、実行時環境で必要であったメタ情報を除去し、ウェブ・サービスの実行可能コードを実行時環境から削除する必要がある。（この種のメタ情報の一例は、ＳＯＡＰサービスの配備に必要な配備記述子である。）
【００６１】
本発明により動的に配備されるサービスの場合、この配備解除プロセスは、元のウェブ・サービスと、動的に配備されたすべてのウェブ・サービスを配備解除するように強化する必要がある。好ましい実施形態でこれを行う方法について、図１２を参照しながら以下に説明する。図１２では、丸番号が以下に列挙する各ステップに対応する。
【００６２】
１．配備プロバイダ２８０が、オリジン・サーバ２９０から配備ノード２６０に配備解除要求を発行する。配備プロバイダは、この方式でこの種の要求を発行することができる唯一の当事者であることが好ましい。
２．配備ノードは、プライベート・レジストリ２７０でウェブ・サービスを検索することにより、そのノードにウェブ・サービスが配備されていることを検証する。
３．ウェブ・サービスがプライベート・レジストリ内で見つかった場合、配備ノードでの配備解除処理が継続される。配備ノードは、配備プロバイダからの配備解除要求の処理を完遂する役割を負う。ウェブ・サービスがプライベート・レジストリ内で見つからない場合、配備プロバイダにエラー・メッセージを返送することが好ましい（図１２では図示せず）。
４．配備ノードは、パブリック・レジストリ２２０にアンパブリッシュ要求を送ることによって配備解除プロセスを開始する。この要求が処理された後、サービス要求者２１０は当該ウェブ・サービス記述を見つけることができないが、すべてのウェブ・サービスが依然として稼働し続ける。
５．アンパブリッシュ要求の処理が完了した後、配備ノードはＤＮＳ２５０サーバに通知して、当該ウェブ・サービスのすべてのエントリを削除する。エントリが削除されると、サービス要求者がアクセスすることができるウェブ・サービスのバージョンは、オリジン・サーバで稼働しているもののみとなる。
６．配備ノード２６０上のプライベート・レジストリには、配備ファシリテータとオリジン・サーバ２９０への参照が格納されている。配備ノードは、オリジン・サーバのエントリを削除して、オリジン・サーバにサービス要求が転送されなくなるようにする。
７．配備ノード２６０は、ウェブ・サービスが配備されていた配備ファシリテータ２３０のリストを入手する。このリストは、プライベート・レジストリ２７０から入手されるが、これは、動的に配備された各ウェブ・サービスごとに新しいビジネス・サービス・エントリが作成されるためである、
８．ステップ７で入手したリスト内の各配備ファシリテータに配備解除要求が送られる。
９．配備ファシリテータが配備解除要求を受け取ると、ウェブ・サービス４４８は停止され、ウェブ・サービスの実行可能コードが、エッジ・サーバ２４０の実行時環境から削除される。配備解除要求の処理が完了した後、ウェブ・サービスが成功裏に配備解除されたことを示す応答が配備ノードに送られることが好ましい（図１２では図示せず）。
１０．配備ノードが配備プロバイダからの配備解除要求の処理を完了すると、好ましくは、配備解除要求の処理が完了したことを示す応答が配備プロバイダに送られる。
１１．配備プロバイダは、オリジン・サーバで稼働しているウェブ・サービス４９５停止し、実行可能コードを削除する。
【００６３】
第２の任意選択拡張機能
ウェブ・サービスは最初に配備された後、（たとえば障害の修正や新機能の追加などのために）更新する必要がある場合がある。従来技術により静的に配備されたウェブ・サービスの場合、一般的なウェブ・サービス更新プロセスには基本的な４ステップがある。
【００６４】
１．サービス・レジストリからエントリを削除することによってウェブ・サービスへの動的アクセスを使用不能にする。このエントリが削除された後は、サービス要求者は当該ウェブ・サービスのサービス記述を見つけることができないようにする必要がある。
２．実行時環境からウェブ・サービスを除去する。これには、ウェブ・サービスの稼働を順序に従って停止し、実行時環境に必要であったメタ情報を削除し、ウェブ・サービスの実行可能コードを実行時環境から除去する必要がある。順序正しい停止では、ウェブ・サービスを停止する前に、未処理の要求が処理されていることが検証される。
３．実行時環境に更新されたウェブ・サービス・コードとメタ情報を配備し、サービスを開始する。
４．ウェブ・サービスのサービス記述を再パブリッシュする。これにより、ウェブ・サービスへの動的アクセスが可能になる。
【００６５】
本発明により動的に配備されるサービスの場合、この再配備プロセスを、配備された元のウェブ・サービスと、動的に配備されたすべてのウェブ・サービスとを更新するように強化する必要がある。すべてのウェブ・サービスを更新し、それによって、その更新が同時にすべての配備システムで利用可能になるようにすることが好ましい。好ましい実施形態でこれを行う方式を、図１３を参照しながら以下に説明する。図１３の丸番号は以下に列挙する各ステップに対応する。
【００６６】
１．更新ステップは、配備プロバイダがオリジン・サーバ２９０上のウェブ・サービスを更新すると開始することが好ましい。これは、ウェブ・サービスを停止し、サービスの実行可能コードとメタ情報を更新し、再びサービスを開始することによって行うことができる。
２．配備プロバイダ２８０が、オリジン・サーバ２９０から配備ノード２６０に更新要求を発行する。配備プロバイダは、この方式でこの種の要求を発行することができる唯一の当事者であることが好ましい。
３．配備ノードは、プライベート・レジストリ２７０内を検索することによって、ウェブ・サービスが配備されていることを検証する。プライベート・レジストリには、オリジン・サーバ２９０上に配備されているウェブ・サービスと、動的に配備されているすべてのウェブ・サービスへの参照が格納されている。
４．プライベート・レジストリ内で当該ウェブ・サービスが見つかった場合、更新要求は配備ノードによって処理される。配備ノードは、配備プロバイダからの更新要求の処理を完遂する役割を負う。プライベート・レジストリ内でウェブ・サービスが見つからない場合、配備プロバイダにエラー・メッセージが返送されることが好ましい（図１３では図示せず）。
５．配備ノードは、パブリック・レジストリ２２０にアンパブリッシュ要求を送信することで更新プロセスを開始する。この要求が処理された後、サービス要求者２１０は当該ウェブ・サービスを見つけることができなくなるが、すべてのウェブ・サービスが依然として稼働している。
６．アンパブリッシュ要求の処理が完了した後、配備ノードはそのレジストリ２７０から、ウェブ・サービスが配備されていた配備ファシリテータ２３０のリストを入手する。
７．リスト上の各ウェブ・サービスについて、すべての要求が配備ノードに送られるようにＤＮＳサーバ２５０が更新される。この更新が処理されている間に、配備ノードは、当該サービスへのアクセスを試みるサービス要求者があればその要求者にエラー・メッセージを返すことが好ましい。
８．ＤＮＳサーバが更新された後、配備ノードは、ステップ５で入手したリスト上の各配備ファシリテータに更新要求を送る。この更新要求は、好ましくは、配備プロセスの段階８（図４参照）で送られる配備要求と同様に書式設定され、同様の構文を使用するが、更新要求を伝達する点が異なる。
９．配備ファシリテータは更新要求を受け取ると、ウェブ・サービスを停止し、オリジン・サーバに配備要求を送って更新されたウェブ・サービスを入手する。好ましい実施形態では、この（再）配備要求は、配備プロセスの段階９（図４参照）を参照しながら前述したのと同じ書式および構文を使用する。
１０．更新されたウェブ・サービス・パッケージを配備プロバイダ２８０から受け取った後、配備ファシリテータは、ウェブ・サービス・コードとメタ情報を実行時環境に配備し、サービスを開始する。
１１．配備ノードは、配備プロバイダからの更新要求の処理を完了すると、配備されたウェブ・サービスの元のＤＮＳエントリを再起動する要求をＤＮＳサーバに送り、更新されたサービス記述をパブリック・レジストリ２２０にパブリッシュする。
１２．サービス記述がパブリッシュされた後、サービス要求者は更新されたサービス記述を見つけることができ、更新されたウェブ・サービスのいずれでも使用することができる。サービス要求は、配備プロセスの段階５および段階６について前述したようにして、ＤＮＳサーバによって、配備されたウェブ・サービスにリルーティングされるか、または、配備ノードにルーティングされて、オリジン・サーバ上で稼働しているウェブ・サービスに転送される。（これらのフローの説明は図１３には図示していないため、図４を参照されたい。）
１３．更新プロセスは、配備ノードが更新要求に対する応答を配備プロバイダに送ると完了することが好ましい（図１３には図示せず）。
【００６７】
以上、任意選択拡張機能のいずれかあるいは両方を使用することにより、前述の動的配備技法に加えた利点が得られることがわかる。
【００６８】
本発明の実施形態は、方法、システム、またはコンピュータ・プログラム製品として提供することができることが、当業者にはわかるであろう。したがって、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはソフトウェア態様とハードウェア態様を組み合わせた実施形態の形をとることができる。さらに、本発明は、コンピュータ使用可能プログラム・コードが実現された、１つまたは複数のコンピュータ使用可能記憶媒体（ディスク記憶装置、ＣＤ−ＲＯＭ、光記憶装置などを含む）上に実現されたコンピュータ・プログラム製品の形を取ることもできる。
【００６９】
以上、本発明について、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品の流れ図またはブロック図あるいはその両方を参照しながら説明した。流れ図またはブロック図（あるいはその両方）の各フローまたはブロック（あるいはその両方）、および流れ図またはブロック図（あるいはその両方）のフローまたはブロック（あるいはその両方）の組合せは、コンピュータ・プログラム命令によって実施可能であることがわかるであろう。このようなコンピュータ・プログラム命令は、汎用コンピュータ、特殊目的コンピュータ、内蔵プロセッサ、またはその他のプログラム可能データ処理装置に提供して、コンピュータまたはその他のプログラム可能データ処理装置のプロセッサを介して実行されるそれらの命令によって、流れ図の１つまたは複数のフローまたはブロック図の１つまたは複数のブロックで規定されている機能を実施する手段を形成するような機械を実現することができる。
【００７０】
このようなコンピュータ・プログラム命令は、コンピュータまたはその他のプログラム可能データ処理装置に対して特定の方式で機能するよう指示することができるコンピュータ可読メモリに記憶することもでき、それによって、コンピュータ可読メモリに記憶された命令が、流れ図の１つまたは複数のフローまたはブロック図の１つまたは複数のブロック、あるいはそれらの組合せに規定された機能を実施する命令手段を含む製造品を実現することができる。
【００７１】
コンピュータ・プログラム命令は、コンピュータまたはその他のプログラム可能データ処理装置にロードされて、コンピュータまたはその他のプログラム可能装置上で一連の動作ステップを実行させ、それによって、当該コンピュータまたはその他のプログラム可能装置上で実行される命令が、流れ図の１つまたは複数のフローまたはブロック図の１つまたは複数のブロック、あるいはそれらの組合せで規定されている機能を実施するためのステップを提供するようにすることもできる。
【００７２】
以上、本発明の好ましい実施形態について説明したが、上記実施形態のその他の変形態様および変更も、当業者なら本発明の基本概念を知れば考えつくであろう。したがって、特許請求の範囲は、本発明の主旨および範囲に含まれる上記好ましい実施形態と変形態様および変更の両方を含むものと解釈すべきである。
【図面の簡単な説明】
【００７３】
【図１】従来技術による、エッジ・サーバが着信コンテンツ要求をルーティングする、サーバ・サイトを示す図である
【図２】本発明の構成要素と、そのネットワーク構成内における配置および相互接続とを示す図である。
【図３】本発明と共に使用する、利用度メトリクスを蓄積するために使用可能なデータ構造を示す図である。
【図４】本発明の好ましい実施形態による、動的サービス配備を行うために使用可能な１２段階のプロセスを示す図である。
【図５】本発明の好ましい実施形態による、発行可能な配備要求サンプルの内容を示す図である。
【図６】本発明の好ましい実施形態による、発行可能な配備要求サンプルの内容を示す図である。
【図７】本発明の好ましい実施形態による、発行可能な配備要求サンプルの内容を示す図である。
【図８】本発明の好ましい実施形態による、図５に示すメッセージの受信に応答して発行されるＳＯＡＰ要求の内容を示す図である。
【図９】本発明の好ましい実施形態による、図８の配備要求に対する応答として返すことができるＳＯＡＰエンベロープの例の内容を示す図である。
【図１０】本発明の任意選択の拡張機能による、サービスを動的に配備解除するために使用可能な２つの手法を示す図である。
【図１１】配備されたサービスの配備場所を記録するために使用可能なデータ構造を示す図である。
【図１２】本発明の任意選択の拡張機能による、サービスを動的に配備解除するために使用可能な２つの手法を示す図である。
【図１３】本発明の他の任意選択の拡張機能による、サービスを動的に更新または再配備するために使用可能なプロセスを示す図である。
【図１】
2004533687.tif 000002
【図２】
2004533687.tif 000003
【図３】
2004533687.tif 000004
【図４】
2004533687.tif 000005
【図５】
2004533687.tif 000006
【図６】
2004533687.tif 000007
【図７】
2004533687.tif 000008
【図８】
2004533687.tif 000009
【図９】
2004533687.tif 000010
【図１０】
2004533687.tif 000011
【図１１】
2004533687.tif 000012
【図１２】
2004533687.tif 000013
【図１３】
2004533687.tif 000014
【国際公開パンフレット】
2004533687.tif 000015
2004533687.tif 000016
2004533687.tif 000017
2004533687.tif 000018
2004533687.tif 000019
2004533687.tif 000020
2004533687.tif 000021
2004533687.tif 000022
2004533687.tif 000023
2004533687.tif 000024
2004533687.tif 000025
2004533687.tif 000026
2004533687.tif 000027
2004533687.tif 000028
2004533687.tif 000029
2004533687.tif 000030
2004533687.tif 000031
2004533687.tif 000032
2004533687.tif 000033
2004533687.tif 000034
2004533687.tif 000035
2004533687.tif 000036
2004533687.tif 000037
2004533687.tif 000038
2004533687.tif 000039
2004533687.tif 000040
2004533687.tif 000041
2004533687.tif 000042
2004533687.tif 000043
2004533687.tif 000044
2004533687.tif 000045
2004533687.tif 000046
2004533687.tif 000047
2004533687.tif 000048
2004533687.tif 000049
2004533687.tif 000050
2004533687.tif 000051
2004533687.tif 000052
2004533687.tif 000053
2004533687.tif 000054
2004533687.tif 000055
2004533687.tif 000056
2004533687.tif 000057
2004533687.tif 000058
2004533687.tif 000059
2004533687.tif 000060
2004533687.tif 000061
2004533687.tif 000062
2004533687.tif 000063
2004533687.tif 000064
2004533687.tif 000065
2004533687.tif 000066
【国際調査報告】
2004533687.tif 000067