(57)【要約】【課題】  分散ネットワーキング・アーキテクチャ内に、特に、サービス指向アーキテクチャ内でサービスをモデル化し、動的にデプロイするための新しいシステムおよび方法を提供することにある。【解決手段】  分散ネットワーキング・アーキテクチャの一部であるサービス・コンテナは、その機能性をサービスとして公開する。これは、サービス記述をデプロイするための登録サービスを提供する。任意の宣言記述言語で新しいサービス記述（すなわち、（ステートフル）サービス、たとえば、ステートフルＷｅｂサービスの記述）を作成すると、記述プロバイダは、サービス・コンテナを再始動せずにランタイム中にその新しいサービス記述の登録（すなわち、デプロイ）を可能にする登録サービスをサービス・コンテナで呼び出す。サービス・コンテナは、サブミットされた新しいサービス記述を分析して、妥当性をチェックし、サービス記述を保管し、それをインスタンス化を必要とするサービスコンシューマに使用可能なものにする役割を有する。新しいサービスが正常に登録されている場合、その新しいサービスにアクセスするための新しいサービス・インターフェースがサービス・コンテナによって自動的に作成される。サービスコンシューマは、ホスティングされている使用可能サービスについてホスティング環境に照会し、その後、新しいサービスをインスタンス化することができる。次に、サービスコンシューマは、一般に要求応答パターンに従う所与のサービス・インスタンスについて任意の公開されたサービス動作を呼び出すことができる。【選択図】  図２
2007538313.tif 000002
【特許請求の範囲】
【請求項１】
サービス指向アーキテクチャの一部であるサービス・コンテナ内にサービスをデプロイするための方法であって、前記サービス・コンテナが
ランタイム中に前記サービス・コンテナ内にサービスをデプロイするためのそれ自体の登録サービス（４０）を提供すること
によって特徴付けられ、
前記登録サービス（４０）が少なくとも、
サービス記述を記述プロバイダ（３）から受信するステップであって、前記サービス記述がリソースのサービスを表現し、宣言記述言語でモデル化されるステップと、
前記サービス記述が正常に登録された場合に、前記サービス・コンテナ（４）で前記サービス記述に関するサービス・インターフェース（４３）を自動的に作成し提供するステップであって、前記サービス・インターフェースが前記サービス記述によって表現されたサービスへのアクセスを可能にするステップと、
を含む、方法。
【請求項２】
前記登録サービス（４０）が、
新しいサービス・インターフェースを公開する前に前記サービス記述を分析し妥当性検査するステップ
をさらに含む、請求項１に記載の方法。
【請求項３】
前記登録サービス（４０）が、
前記サービス記述が正常に登録された場合に、前記サービス記述を参照するユニークな記述ハンドル（ＩＤ）を前記記述プロバイダに返すステップ
をさらに含む、請求項１に記載の方法。
【請求項４】
前記サービス・コンテナ（４）が、
登録されたサービスに関する情報を検索するための検索サービス（４１）を提供すること
によってさらに特徴付けられ、前記検索サービスが、
サービスコンシューマ（２）の検索要求に応答して、すでに登録されたサービスを参照する記述ハンドルのリストを提供するステップと、
記述ハンドルを含むサービスコンシューマの要求に応答して、前記サービスコンシューマにサービス記述を提供するステップと、
を含む、請求項１に記載の方法。
【請求項５】
前記検索サービスが、
コンシューマの要求に応答して、前記サービスコンシューマにサービス・インターフェース情報を提供するステップ
をさらに含む、請求項４に記載の方法。
【請求項６】
前記サービス・コンテナが、
登録されたサービスをインスタンス化するためのインスタンス化サービス（４２）を提供すること
によってさらに特徴付けられ、前記インスタンス化サービスが、
少なくとも登録されたサービスを参照する記述ハンドルを含む、サービスコンシューマのインスタンス化要求に応答して、新しいサービス・インスタンスを作成し、前記新しいインスタンスを登録するステップと、
前記インスタンス化が成功した場合に、前記サービスコンシューマにユニークなインスタンス・ハンドルを提供するステップと、
を含む、請求項１に記載の方法。
【請求項７】
前記サービス・カスタマからインスタンス・ハンドルを受信するステップと、
前記サービス・インスタンスの前記サービスを参照する前記サービス・カスタマに記述ハンドルを提供するステップと、
前記記述ハンドルを含む前記サービスコンシューマの要求に応答して、前記サービス・カスタマにサービス・インターフェースを提供するステップと、
前記サービス・インスタンスで前記サービスコンシューマによって呼び出された動作をインターセプトし、それを正しいサービス・インスタンスに経路指定するステップと、
前記サービス記述に応じて前記コンテナ・ランタイム環境により呼び出された動作を解釈するステップと、
をさらに含む、請求項６に記載の方法。
【請求項８】
前記サービス・コンテナが、
もはや使用されないインスタンスをサービスコンシューマが削除できるようにするインスタンス削除サービスを提供すること
によってさらに特徴付けられる、請求項１に記載の方法。
【請求項９】
前記サービス・コンテナが、
もはや使用されないサービス記述を登録取消しするためのサービス記述登録取消しサービスを提供すること
によってさらに特徴付けられる、請求項１に記載の方法。
【請求項１０】
前記サービス・コンテナがステートフルＷｅｂサービス・コンテナである、請求項１に記載の方法。
【請求項１１】
前記サービス記述が、エンティティ・タイプ記述を使用することによってモデル化される、請求項１に記載の方法。
【請求項１２】
リソースのサービスを宣言記述言語で表現するサービス記述を記述プロバイダ（３）が登録できるようにする登録サービス・インターフェース（４０）と、
サービス記述に割り当てられ、割り当てられた前記サービス記述が前記登録サービス・インターフェース（４０）を介して正常に登録されたときに自動的に作成されるサービス・インターフェース（４３）と、
を含む、サービス指向環境内のサービス・コンテナ。
【請求項１３】
サービス・インターフェース（４３）を自動的に作成し、それをサービス記述に割り当てる前に、前記サービス記述を分析し妥当性検査するためのコンポーネント
をさらに含む、請求項１２に記載のサービス・コンテナ。
【請求項１４】
デプロイされたサービスまたはサービス・インスタンスについて前記サービス・コンテナに照会するために使用される情報検索サービス・インターフェース（４１）と、
前記サービス・コンテナ（４）によって提供されたサービス記述をサービスコンシューマがインスタンス化できるようにするインスタンス化サービス・インターフェース（４２）と、
をさらに含む、請求項１３に記載のサービス・コンテナ。
【請求項１５】
前記サービス・コンテナにすでに登録された前記サービス記述を含むサービス記述データ・ストア（２２）と、
前記サービス記述データ・ストア内の前記サービスに属すすべてのインスタンスを含むサービス・インスタンス・データ・ストア（２３）と、
をさらに含む、請求項１３に記載のサービス・コンテナ。
【請求項１６】
もはや使用されないサービス記述を登録取消しするために使用される記述登録取消しサービス・インターフェースと、
もはや使用されないインスタンスをサービスコンシューマが削除できるようにするサービス・インスタンス削除インターフェースと、
をさらに含む、請求項１３に記載のサービス・コンテナ。
【請求項１７】
前記サービス・インスタンスによって提供されたワークフロードリブン動作の実行を管理するワークフロー・エンジンと、
前記サービス・コンテナと、モデル化されたリソースとの間の通信のためのプロトコル固有インターフェースと、
をさらに含む、請求項１３に記載のサービス・コンテナ。
【請求項１８】
前記サービス指向環境が、リソースプロバイダ（１３）と、サービスコンシューマ（２）と、記述プロバイダ（３）とをさらに含み、前記サービス指向環境がＷｅｂサービス・プロトコルを使用する、請求項１３に記載のサービス・コンテナ。
【請求項１９】
コンピュータ上で実行されたときに、請求項１ないし１１のいずれか１項に記載の前記方法をコンピュータに実行させるためのコンピュータ可読プログラム手段を含む、コンピュータ使用可能媒体に保管されたコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散ネットワーキング・アーキテクチャの分野に関し、詳細には、分散ネットワーキング・アーキテクチャ内に、特に、リソースプロバイダ（Resource Provider）、サービスコンシューマ（ServiceConsumer）、およびサービスコンシューマにサービスを提供するサービス・コンテナ（Service Container）（すなわち、ホスティング環境）からなるサービス指向アーキテクチャの一部であるサービス・コンテナ内に、サービスをモデル化し、動的にデプロイするためのシステムおよび方法に関する。
【背景技術】
【０００２】
今日のＩＴ環境は、非常に多くの種類のシステムとアプリケーションとの間の相互運用性のための手段を提供する必要性によって作り出されている。これらのシステムおよびアプリケーションの大部分は潜在的に状態情報を保持する。その特性がステートフルであるので、システムおよびアプリケーションは同様にリソースと見なすことができる。このようなリソースの状態への同種アクセスを可能にするために、サービス指向アーキテクチャ・リソースでは、個々のリソースの状態に関係する機能インターフェースにより、サービス（たとえば、Ｗｅｂサービス）としてそれぞれの状態をそれぞれ公開することができる。
【０００３】
任意のリソース（すなわち、物理または論理システムまたはアプリケーション）の状態および機能性を、サービスとして（すなわち、機能インターフェースにより）公開することによって、そのリソースへのアクセスを可能にする場合、任意のプログラミング言語（たとえば、Ｊａｖａ、Ｎｅｔなど）を使用して、それぞれのリソースをカプセル化するサービス・インターフェースおよびインプリメンテーション（たとえば、Ｗｅｂサービス、グリッド・サービス、ＣＯＲＢＡなど）を開発しなければならない。
【０００４】
新しいサービスが開発され展開（デプロイ）されている今日に発生する問題は、現況技術のアプリケーション開発およびデプロイメントの静的性にある。現行の開発およびデプロイメント・プロセスは、非常に厳格であり、ランタイム中に既存のサービスの変更を許さない。新しいサービスを開発するかまたは既存のサービスを変更する場合、アプリケーション・ライフ・サイクル全体をもう一度開始しなければならず、アプリケーションのソース・コードに新しい機能を追加しなければならず、次に一般にそのソース・コードをコンパイルし、さらに記述し、パッケージ化し、ターゲット・ホスティング環境に転送しなければならず、次にそのホスティング環境は使用のためにそのサービスの機能性を提供することになる（使用するプログラミング言語または方法に応じて、サービスを使用できるようになるまでに遂行すべきステップがもっと多く存在する可能性もある。それに関する詳細は以下に示す。）加えて、既存のサービスを結合してより高レベルの複合サービスにする場合、開発者は、２つの既存のサービスの機能性を結合するコードを提供しなければならない。この開発および既存のサービスの結合は必ずビルドタイム（buildtime）（アプリケーションまたはサービスはアクティブではないかまたは実行されていない）中に行われ、ランタイム中には行われない。
【０００５】
現況技術
現在、ホスティング環境内に新しいサービスをどのように開発しデプロイするかについてより詳細に説明するために、図１は、Ｊ２ＥＥ（すなわち、Ｊａｖａ  ２  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎプラットフォーム）の場合に開発およびデプロイメントがどのように行われるかを示す例示的な概略表現を示している。この例示では、ビルドタイム（アプリケーションまたはサービスが静的に開発される）とランタイム（完成したサービスがホスティング環境内で使用可能なものになり、サービスコンシューマによってアクセス可能なものになる）とを区別している。新しいサービスを開発しデプロイする場合、サービスまたはアプリケーション開発者は、いくつかの事前定義アクティビティを遂行しなければならない。第一に、サービスを開発しなければならない（これは、サービスの機能インターフェースの指定ならびにサービスのロジックの機能インプリメンテーションを含む）。第二に、完成したサービスをＪａｖａバイト・コードにコンパイルしなければならない。次に、いわゆるデプロイメント記述子の形の追加情報を追加することにより、新しいコードをさらに記述しなければならず、そのデプロイメント記述子はアプリケーション・サービスの追加の動作プロパティ（たとえば、トランザクション動作またはセキュリティ設定）を指定する。１つまたは多数のデプロイメント記述子でそのコードを記述した後、記述子およびコードをたとえば．ｊａｒファイルまたは．ｅａｒファイル（Ｊ２ＥＥ実行可能ファイルを表す）内にまとめてパッケージ化しなければならない。その後、この実行可能ファイルは、将来のホスティング環境内の事前定義位置に転送しなければならない（これは一般に、様々なファイル転送手段、たとえば、ＦＴＰによって行われる）。続いて、開発者またはデプロイヤは、必要なデータベース・テーブルを作成し、アプリケーションのステートフル部分をそれぞれのテーブルにマッピングしなければならない場合がある。最後に、様々な手段を使用して（それをディレクトリ内にドロップし、サーバを再始動するかまたはインストール・クライアントまたは管理インターフェースを呼び出して）実行可能ファイルをホスティング環境にインストールすることができる。通常、これは、ホスティング環境（すなわち、Ｊ２ＥＥアプリケーション・サーバ）を停止しなければならず、実行可能ファイルがインストールされ、その後、サーバが再始動されることを意味する。結局、新しいサービスは、正常再始動後のみ、サービスコンシューマによって使用することができる（すなわち、新しいステートフル・サービス・インスタンスを作成することができ、これらのインスタンスに関する動作を呼び出すことができる）。ちなみに、記載した静的プロセスは、ステートフル・サービスのみならず、一般にサービスおよびアプリケーション開発およびデプロイメントにも有効である。
【０００６】
いくつかのサービスを結合してより高レベルの複合サービスにする場合、単一サービスとまったく同じ方法で新しい複合サービスを開発しなければならない。すべての新しいサービスについて開発ステップ全体（ビルドタイム中）が必要であり、既存のサービスの結合も非常に厳格かつ厄介なものになる。
【０００７】
現況技術の手法の問題は以下の通りである。すなわち、静的な開発およびデプロイメント・プロセスは、動的なサービス開発およびより複雑な複合サービスへの既存のサービスの結合を非常に厳格かつ厄介なものにする。加えて、サービス（すなわち、その後ろにあるアプリケーション・インプリメンテーション）は、ランタイム中に動的に構成することができない（たとえば、トランザクション動作またはセキュリティ機能はランタイム中に調整することができないが、その調整はビルドタイム中に行う必要があり、その後、サービスを再デプロイする必要がある）。同様に、サービスに対するあらゆる種類の変更により適応コードの再開発が強制される。さらに、任意の種類のリソースをサービスとして表現する場合、その状態情報および機能性をサービス指向世界に公開するために、追加のプロトコル層をインプリメントする必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の一目的は、現況技術の欠点を回避し、ネットワーキング・アーキテクチャ内でサービスを開発しデプロイするためのシステムおよび方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明は、分散ネットワーキング・アーキテクチャ内で、特に、サービス指向アーキテクチャ内にサービスをモデル化し、動的にデプロイするための新しいシステムおよび方法を提供する。分散ネットワーキング・アーキテクチャの一部であるサービス・コンテナは、その機能性をサービスとして公開する。これは、サービス記述をデプロイするための登録サービスを提供する。任意の宣言記述言語で新しいサービス記述（すなわち、（ステートフル）サービス、たとえば、ステートフルＷｅｂサービスの記述）を作成すると、記述プロバイダは、サービス・コンテナを再始動せずにランタイム中にその新しいサービス記述の登録（すなわち、デプロイ）を可能にする登録サービスをサービス・コンテナで呼び出す。サービス・コンテナは、サブミットされた新しいサービス記述を分析して、妥当性をチェックし、サービス記述を保管し、それをインスタンス化のためにサービスコンシューマに使用可能なものにする役割を担う。新しいサービスが正常に登録されている場合、その新しいサービスにアクセスするための新しいサービス・インターフェースがサービス・コンテナによって自動的に作成される。サービスコンシューマは、ホスティングされている使用可能サービスについてホスティング環境に照会し、その後、新しいサービスをインスタンス化することができる。次に、サービスコンシューマは、一般に要求応答パターン（リクエスト・レスポンスパターン）に従う所与のサービス・インスタンスについて任意の公開されたサービス動作を呼び出すことができる。
【００１０】
本発明の上記ならびに追加の目的、特徴、および利点は、以下の詳細な説明書に明らかになるであろう。
【００１１】
本発明の新規な特徴は特許請求の範囲に示されている。しかし、本発明そのものならびに本発明の好ましい使用態様、その他の目的、および利点は、添付図面に併せて読んだときに例示的な一実施形態に関する以下の詳細な説明を参照することによって最も良く理解されるであろう。
【発明を実施するための最良の形態】
【００１２】
図２に関しては、少なくとも記述プロバイダ３と、ホスティング環境４（サービス・コンテナ）と、サービス・カスタマ（service customer）２とを含むサービス指向アーキテクチャ内のサービスの開発および動的デプロイメントの発明的な方法の概略表現が示されている。任意の宣言記述言語８でサービス記述（すなわち、（ステートフル）サービス、たとえば、ステートフルＷｅｂサービスの記述）を作成すると、記述プロバイダ３は、任意の種類のリソース（たとえば、ステートフル・リソース）を表現できる新しいサービス記述の登録１０（すなわち、デプロイ）を可能にする、ホスティング環境４の動作を呼び出す。新しいサービス記述がホスティング環境４に登録された後（これは、新しいサービスを登録またはインスタンス化するためにホスティング環境を再始動せずにランタイム中に行われる可能性がある）、ホスティング環境４（たとえば、アプリケーション・サーバまたはサービス・コンテナなど）は、サブミットされたサービス記述を分析して、妥当性をチェックし、記述されたサービスを保管し、それをインスタンス化のために関心のあるサービスコンシューマ２に使用可能なものにする役割を担う。サービスコンシューマ２は、ホスティングされている使用可能サービスについてホスティング環境４に照会し、その後、任意の既存のサービスの新しいサービス・インスタンスをインスタンス化することができる。サービス・インスタンスが作成された場合、それは、ホスティング環境４によって自動的に公開される、基礎となるサービスに対応するサービス・インターフェース１２（たとえば、Ｗｅｂサービス・インターフェース）を介してアクセスすることができる（ホスティング環境はその動作もサービスとして公開するので、これはホスティング・サービスと呼ぶこともできる）。次に、サービスコンシューマ２は、一般に要求応答パターンに従う所与のサービス・インスタンス（記述されたサービス・タイプから得られるサービス・インターフェースの後ろにある）について任意の公開されたサービス動作を呼び出すことができる。
【００１３】
図３は、図２による発明的なデプロイメント方法を実行するために必要な分散ネットワーキング・アーキテクチャ内の関係メンバーを示している。
【００１４】
サービス・コンテナ４（すなわち、ホスティング環境）は、好ましくはステートフル・サービス・コンテナであり、管理されたランタイム環境を提供し、透過的トランザクション処理、パーシスタンス、メッセージング・サブシステム、およびサービス・インスタンスのワークフロードリブンな動作の実行を制御するワークフロー・エンジンを提供する。このサービス・コンテナは、プロセッサ、作業メモリ、２次ストレージ、および理想的にはネットワーク（有線または無線）アクセスを有する、通常のＰＣ、特殊なサーバなどのような任意の種類のデータ処理装置上で実行することができる。
【００１５】
リソースプロバイダ１３は、サービス・コンテナ４を介して潜在的なサービスコンシューマ２に提供される物理リソースまたは論理リソースを提供するものである。
【００１６】
記述プロバイダ３は、専用サービスの記述（潜在的にステートフル・リソースおよび物理リソースを表現する）をサービス・コンテナ４に提供するものである。
【００１７】
サービスコンシューマ２は、サービス・コンテナ４によって提供され、サービス・コンテナ４内に存続する１つまたは多数のサービスの使用を必要とするものである。
【００１８】
これらの関係メンバーはいずれも、ネットワークを介して接続され、このインフラストラクチャ内で通信し、情報を交換することができる。
【００１９】
本発明では、リソースプロバイダ１３が任意の種類の（ステートフル）リソースをどのようにサービス・カスタマ２に提供できるかを詳細に記載している。これを行うために、記述プロバイダ３（リソースプロバイダそのものになりうる）は、自分で選んだリソース（複数も可）を表現するサービス記述を作成しなければならない。自分のリソースのこのような表現（ソース・コード）を記述すると、記述プロバイダ３はその記述をサービス・コンテナ４に登録することができる。そこで、サービスコンシューマ２は、サービス記述（＝リソースのタイプ）の個別インスタンスを作成し、選択したプロトコル（サービス・コンテナの提供によって定義される。少なくともＳＯＡＰによるＷｅｂサービスを提供しなければならない）を介してそれと返信することができる。
【００２０】
図４は、関係メンバーのコンポーネントを示している。
【００２１】
サービス・コンテナ４は少なくとも
サービス・コンテナ４にすでに登録されているサービス記述を含むサービス記述データ・ストア２２と、
サービス・ストア２２内のサービス記述に属すすべてのインスタンスを含むサービス・インスタンス・データ・ストア２３と、
本発明を実行するために必要なインターフェース８０であって、
記述プロバイダが任意の種類のリソースを表現する新しいサービスのサービス記述を登録できるようにする登録サービス・インターフェース４０と、
サービス記述の登録が成功したときに自動的に作成されるサービス・インターフェース４３
という１組のサブインターフェース４０、４３を含むインターフェース８０
というコンポーネントを有する。
【００２２】
サービス・コンテナには、好ましくは、
デプロイされたサービスおよびサービス・インスタンスについてコンテナに照会するために使用可能な情報検索インターフェース４１と、
サービスコンシューマがコンテナによって提供されるサービス記述をインスタンス化できるようにするインスタンス化サービス・インターフェース４２
という追加のサブインターフェースが含まれなければならない。
【００２３】
最後に、サービス・コンテナには、
もはや使用されないインスタンスをサービスコンシューマが明示的に削除できるようにするサービス・インスタンス削除インターフェースと、
前にコンテナに登録されたすべてのサービス用のインターフェースであって、このインターフェースと、このインターフェースに適合する個別インスタンスを指し示す固有ハンドルとを使用すると、サービスコンシューマがインスタンスにアクセスし、それについて操作することができるインターフェースと、
もはや使用されないサービス記述を登録取消しするために使用される記述登録取消しインターフェース
という追加のインターフェースをさらに含むことができる。
【００２４】
リソースプロバイダ１３は、物理リソースおよび論理リソース１４、たとえば、ＣＰＵ（サイクル・タイムを計算する）、ストレージ（データの保管のための物理的手段）、ネットワーク（様々なサービス品質、すなわち、帯域幅、スループットなどに関するサービス品質を備えたネットワーク・リソース）、ソフトウェア・サービス（すなわち、データベースまたはＷｅｂサーバ）、請求サービス、計量サービス（任意のサービスコンシューマについて時間レベル、負荷レベル、スループット・レベルなどでリソースの使用量を測定し、エンティティ・サービス・カスタマにこの計量情報を提供するサービス）、会計サービス（リソースの従量料金制による使用量に関する請求書を作成するために請求および計量を介して収集されたデータを使用するサービス）へのアクセスを提供する。リソースプロバイダ１３は、ＣＩＭ、ＳＮＭＰ、ＳＳＨ、Ｔｅｌｎｅｔなどの様々なプロトコルによりそのリソースへのアクセスを可能にすることができる。
【００２５】
リソースプロバイダ１３の役割と記述プロバイダ３の役割は、同じメンバーによって担われても良い。記述プロバイダならびにリソースプロバイダはいずれも、サービスコンシューマの役割で動作することもできる。
【００２６】
記述プロバイダ３は、サービスの記述を作成し、好ましくはステートフル・サービス・コンテナである可能性のあるサービス・コンテナに作成した記述を登録する役割を担う。サービス記述を作成するために、記述プロバイダ３は、ある種の宣言記述言語（すなわち、ＸＭＬベースのもの）の構文および意味体系を指定する文法を固守する。この文法は、リソースを反映するサービスの記述を指定するために使用される。サービス・コンテナ４に記述を登録するために、コンテナの登録インターフェースを指し示すエンドポイント参照が必要である。加えて、記述プロバイダは、記述されることになっているサービスによって表現されるリソースについてある種の情報または何らかの概念を持っている必要がある。これは、（バックグラウンドで直接、物理リソースにアクセスするために）プロトコル固有情報を含んでも良い。
【００２７】
サービスコンシューマ２は、サービス・コンテナ・インターフェース４３をアドレス指定する方法のみを知る必要がある（すなわち、コンテナのインターフェースのエンドポイントを指し示すエンドポイント参照／ＵＲＬが必要である）。サービスコンシューマ２が必要とするその他のすべての情報は、ステートフル・サービス・プロバイダのインターフェースに照会することによって動的に入手することができる。
【００２８】
サービスコンシューマ２は、サービスおよびサービス・インスタンスなどを参照するハンドルを永続的に保持するために、キャッシュまたはストアを有していても良い。しかし、これは、１つの最適化にすぎず、命令的に設ける必要はない。この情報はいずれも、ステートフル・サービス・コンテナの情報検索インターフェースを使用して、処理中に入手することもできる。
【００２９】
図５は、図３による関係メンバーのコンポーネントの相互作用ダイヤグラムを示している。
【００３０】
図５は、すべてのコンポーネントがどのように相互作用するかに関する概要を示し、新しいサービス記述の動的デプロイメントまたは登録を示し、サービス・インスタンス、たとえば、ステートフル・サービス・インスタンスの後続インスタンス化と、それらとの相互作用を実証している。
【００３１】
第一に、ある種のリソースがリソースプロバイダによって提供されなければならない（０）。これらのリソースに対する実際のアクセスは、様々な方法で（すなわち、ＳＮＭＰ、ＣＩＭ、ＳＳＨ、Ｔｅｌｎｅｔなどを介して）可能にすることができる。
【００３２】
その後、記述プロバイダは、実リソースを反映するサービスの記述を作成し、登録する（１）。
【００３３】
好ましくはステートフルＷｅｂサービス・コンテナであるサービス・コンテナ内に使用可能なサービスが存在するとすぐに、サービスコンシューマは登録されたサービスおよびインスタンスに関する情報を検索することができる（２；それらが存在する場合）。
【００３４】
サービス記述が登録された後、それらは、サービスコンシューマによってインスタンス化することができる（３）。
【００３５】
それぞれに登録されたサービス記述の自動的に公開されたサービス・インターフェースを介して、サービスコンシューマは、その後、サービス・インスタンスと直接、相互作用することができる。したがって、サービスコンシューマは、サービス・インスタンスについて動作を呼び出し、その結果、サービス・インスタンスの状態を変更することができる（４）。
【００３６】
あるサービス・インスタンスがもはや使用されない場合、サービスコンシューマはこのインスタンスの削除を選択することができる（５）。
【００３７】
対応するサービス・インスタンスを持たず、もはや使用されないサービス記述は、ステートフル・サービス・コンテナから登録取消しすることができる（６）。
【００３８】
図６〜図１２は、本発明により任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときの相互作用を示している。
【００３９】
以下のアクティビティは、任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときに行われる（図６を参照）。
【００４０】
記述プロバイダ３は、ある種の宣言記述言語の手段を使用して、それが選んだサービス記述（すなわち、仮想化すべきある種の物理リソースまたは論理リソースに適合するもの）を定義し宣言する。新しいサービスの記述は、自動的に（テンプレートを使用する）または手動で行うことができる。
【００４１】
記述プロバイダ３は、サービス・コンテナ４のある種の登録（サービス記述）動作を呼び出し、それにより、サービス記述を登録する。サービス・コンテナ４は、新しいタイプのリソース（たとえば、ステートフル・リソース）を表現するサービス記述を分析し、妥当性を検査し、それをサービス・ストアに登録する。正常登録後、サービス記述はインスタンス化のために提供される。
【００４２】
登録動作が成功した場合、サービス・コンテナ４は、固有ＩＤと記述ハンドル（登録されたサービスを参照する）を記述プロバイダ３に返す。
【００４３】
登録されたサービス、その記述およびインターフェイスならびに既存のサービス・インスタンスに関する情報を検索するために、以下のメソッドが提供される。
【００４４】
サービス情報の検索（図７を参照）
第１のステップ１０では、サービスコンシューマ２は、記述ハンドル（サービス・コンテナ４にすでに登録されているサービス記述への固有の参照）のリストを検索することができる。
【００４５】
このような記述ハンドルを持っている場合、サービスコンシューマ２は、記述ハンドルに対応するサービス記述を検索することができる（２０）。
【００４６】
加えて、サービスコンシューマ２は、パラメータとして記述ハンドルをサブミットすることにより、登録されたサービスによって自動的に公開されるサービス・インターフェース（すなわち、Ｗｅｂサービスの場合のＷＳＤＬ）も入手することができる（３０）。
【００４７】
さらに、サービスコンシューマ２は、サブミットされた記述ハンドルによって記述されたサービスに属すすべてのサービス・インスタンスを参照するインスタンス・ハンドルのリストも検索することができる（４０）。
【００４８】
あるサービスがサービスコンシューマ２によって使用できるようになる前に、そのサービスはインスタンス化する必要がある。
【００４９】
サービスのインスタンス化（図８を参照）
登録されたサービスをインスタンス化するために、サービスコンシューマ２は、ＩｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ（．．．）動作を呼び出し、サービス・インスタンスのタイプになる記述ハンドルならびにオプション・データ（インスタンス化用）をパラメータとして渡す（１０）。オプション・データとしては、サービス・インスタンスの初期設定に関する状態情報、それぞれのエンティティに関する必要なサービス品質要件などを含むことができる。
【００５０】
サービス・コンテナ２は、新しいサービス・インスタンスを作成し、その新しいインスタンスをサービス・インスタンス・ストアに登録する。サービス・インスタンスは、サービスによって規定されたインターフェースに適合する。
【００５１】
任意選択でサブミットされたデータもサービス・インスタンス・ストア内で永続的なものになる。
【００５２】
インスタンス化が成功した場合、サービスコンシューマ２は、新たに作成されたサービス・インスタンスを参照する固有のインスタンス・ハンドルを入手する。
【００５３】
既存のサービス・インスタンスは、基礎となるサービスのサービス・インターフェースを介してアクセスすることができる。サービスコンシューマ２とサービス・インスタンスとの間の様々な対話、すなわち、動作呼出し、通知生成および受信、外部ワークフロー・アクティビティへの呼出し、サービス品質プロパティの動的変更または設定が考えられる。典型的な相互作用方式については以下に記載する。
【００５４】
サービス・インスタンス１の使用（図９を参照）
サービスコンシューマ２が所望のサービス・インスタンスへの参照をすでに保持している場合、そのサービスコンシューマはこのインスタンス・ハンドルをサービス・コンテナ４にサブミットすることができる。
【００５５】
サブミットされたインスタンス・ハンドルの結果として、サービスコンシューマ２は、サービス・インスタンスのサービスを参照する、対応する記述ハンドルを受信する（１０）。
【００５６】
サービスコンシューマ２がサービス・インスタンスと相互作用できるようになる前に、そのサービス・インスタンスが適合するサービスの記述ハンドルをサブミットすることにより、サービス・インターフェースを入手しなければならない（２０；サービス・インターフェースはＷＳＤＬで記述することができる）。
【００５７】
サービスコンシューマ２がサービス・インターフェースを入手した後、インターフェースを介して公開される任意の動作を使用して、サービス・インスタンスと対話することができる（３０）。動作が呼び出されると、他の可能なパラメータとともにインスタンス・ハンドルを渡さなければならない。
【００５８】
サービス・コンテナ４は、サービス・インターフェースで動作呼出しをインターセプトし、それを正しいサービス・インスタンス（サブミットされたインスタンス・ハンドルによって示される）に経路指定する（４０）。
【００５９】
呼び出された動作が複雑なワークフロードリブン動作（ワークフロー実行エンジンによって解釈され管理されるもの）である場合、外部アクティビティ・プロバイダは、ワークフロー動作に含まれる１つまたは複数のアクティビティを提供することができる（６０）。これらのアクティビティは、ワークフロー動作定義によって規定された順序で呼び出される。
【００６０】
この動作は潜在的にサービス・インスタンスの状態を更新するものである。
【００６１】
潜在的な戻り値（Potentialreturn value）はサービス・コンテナを介してサービスコンシューマ２に返される。
【００６２】
サービス記述の変更（図１０を参照）
既存のサービスを変更するために、記述プロバイダは、変更動作を呼び出し、記述に対する所望の変更とともに記述ハンドルをパラメータとしてサブミットする（１０）。
【００６３】
サービス・コンテナ４は、その後、サービスを変更し、サービス・データ・ストアを更新する（２０）。
【００６４】
加えて、可能なトピックが追加されるかまたはトピック・レジストリから除去され、このため、変更はトピック・ストア内で永続的なものになる。
【００６５】
未使用のサービス・インスタンスは削除することができる。
【００６６】
サービス・インスタンスの削除（図１１を参照）
既存のサービス・インスタンスがもはや必要ではない場合、サービスコンシューマ２は、削除動作を呼び出し、削除すべきサービス・インスタンスを指し示す所望のインスタンス・ハンドルを渡すことができる（１０）。
【００６７】
コンテナは、その後、サービス・インスタンス・データ・ストアからそのインスタンスを削除する（２０）。
【００６８】
続いて、サービスコンシューマ２は、削除動作が成功したかどうかを示す状況コードを受信する。
【００６９】
もはや必要ではないサービス記述は、このタイプに適合するすべてのサービス・インスタンスが存在しなくなった後、動的に登録取消しすることができる。
【００７０】
サービス記述の登録取消し（図１２を参照）
既存のサービスがもはや必要ではない場合、サービスコンシューマ２は、登録取消し動作を呼び出し、登録取消しすべきサービス記述を指し示す所望の記述ハンドルを渡すことができる（１０）。
【００７１】
サービス・コンテナ４は、その後、サービス・ストアからその記述を登録取消しする（２０）。
【００７２】
続いて、サービスコンシューマ２は、登録取消し動作が成功したかどうかを示す状況コードを受信する（３０）。
【００７３】
図１３〜図２４は、Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示している。
【００７４】
Ｗｅｂサービス・コンテナは、サービス・インプリメンテーションのライフ・サイクル管理、メソッド呼出しの同時管理、パーシスタンス、およびトランザクション・サービスのためのＷｅｂサービスのホスティング環境を表現する。これらのサービスを完了すると、それは、トピック・ベースのメッセージングおよびセキュリティをサポートすることができる。
【００７５】
その好ましいインプリメンテーションでは、サービスは宣言記述言語でＷｅｂサービス・コンテナ内にデプロイされ、前記宣言記述言語はエンティティ・タイプ記述を使用することによってモデル化される。
【００７６】
エンティティ・タイプは、宣言記述言語により記述され、任意の考えられるリソース・タイプのサービス指向表現を提示する。リソースのサービス指向表現は抽象的に行われるので、エンティティ・タイプはサービス指向アーキテクチャの任意の考えられる実現例（すなわち、ステートフルＷｅｂサービス）にマッピングすることができる。
【００７７】
図１３は、リソース・タイプと、それに対応するエンティティ・タイプと、そのエンティティ・タイプを潜在的なサービス・クライアントに公開するための可能性の１つとの関係を例示している。エンティティ・タイプは、リソース・タイプの抽象的なサービス指向表現を提供し、サービス指向世界で特定のリソース・タイプをどのように公開するかを定義するものである。リソースとエンティティとのこのような分離により、リソース・タイプの属性のうちのいずれを、したがって、どの状態情報を使用可能なものにするかを微細細分レベルで定義することが可能になる。次に、ホスティング環境、たとえば、ステートフルＷｅｂサービス・コンテナは、Ｗｅｂサービス規格を使用して抽象サービス表現を自動的に公開する。
【００７８】
リソースのモデル化に対するこの手法はいくつかの利点を結合するものである。第一に、これは、リソースとその状態の抽象サービス表現を生成するために使用されるエンティティから実リソース・タイプを分離する。第二に、これは、Ｗｅｂサービス以外のサービス・インプリメンテーションを使用してリソースの状態を公開することを可能にする。第三に、それらはいずれも、自動的に公開されるサービス・インターフェースを使用してアクセス可能であるので、すべての種類のリソースの統一ビューを提供する。
【００７９】
リソースは、論理または物理のいずれでも、宣言記述言語および文法を使用して宣言的に記述することができる。結果として得られるエンティティ・タイプ記述は、抽象的かつサービス指向的にリソース・タイプを表現する（図１４のこのような記述の例を参照）。エンティティ・タイプ記述はリソース・タイプの抽象サービス指向表現を定義するだけであるので、これはＷｅｂサービス・コンテナに転送しなければならず、そのＷｅｂサービス・コンテナは自動的にエンティティ・タイプを対応するＷｅｂサービス・インターフェースにバインドし、新しいエンティティ・タイプ記述を登録し、既存のエンティティ・タイプ記述を登録取り消しするためにライフタイム管理動作を提供する。この理論の道筋に従うと、いずれのエンティティ・タイプ記述も個別の寿命を有する。
【００８０】
第一に、Ｗｅｂサービス・インターフェースによりリソース・タイプを表現または公開できるようになる前に、それぞれのリソース・タイプのエンティティ・タイプ記述を指定しなければならない。これは、＜エンティティ・タイプ＞エレメントと、そのサブエレメントと、属性とを使用して行われる。通常、エンティティ・タイプ記述は、名前と、グループと、いくつかの動作と、その他のエンティティ・タイプに対する関係とを含む。表現すべきリソース・タイプからこのようなエンティティ・タイプ記述が得られ、どの状態情報を公開すべきかという決定が行われた後、作成されたエンティティ・タイプ記述をＷｅｂサービス・コンテナに登録することができる。登録の結果として、Ｗｅｂサービス・コンテナは、エンティティ・タイプのサービス・インターフェースを潜在的なサービスコンシューマにとって使用可能なものにし、登録されるすべての新しいエンティティ・タイプに関する個別Ｗｅｂサービス・インターフェースを公開することになる。加えて、すべての登録されたエンティティ・タイプ記述には汎用固有ＩＤが割り当てられ、この汎用固有ＩＤにより、さらに参照およびインスタンス化が可能になる。すべてのデプロイされたリソースに関するこのサービス・パースペクティブは、ＳＯＡの利点、すなわち、境界を越えたプラットフォーム独立相互運用性を利用するものであり、したがって、表現されたリソース・タイプの均一サービス・ビューを標準化して提供する。エンティティ・タイプがＷｅｂサービス・コンテナに登録されるとすぐに、それは、Ｗｅｂサービス・コンテナのそれぞれのライフタイム管理動作を介してインスタンス化のために提供される。
【００８１】
最も単純なケースでは、Ｗｅｂサービス・コンテナは、任意の追加のパラメータまたは暗黙的仮定なしに所望のエンティティ・タイプを単にインスタンス化するだけである。この結果、エンティティ・タイプのＷｅｂサービス・インターフェースを介してアクセスされる新しいエンティティ・インスタンスがホスティング環境によって作成される。このようなエンティティ・インスタンスがもはや必要ではない場合、これは、コンテナの破棄インターフェースを使用して、明示的に削除しなければならない。明示的なエンティティ・インスタンス削除が適切ではない場合（たとえば、そのエラー傾向、信頼できないネットワーク接続のため、または単にそれが忘れられる可能性があるため）、Ｗｅｂサービス・コンテナは、ＯＧＳＡから分かるようにソフト状態管理セマンティクスとともにインスタンス化も提供する。このため、所与の存続時間とともにエンティティ・タイプをインスタンス化するようにコンテナに命じることができる。これは、そのインスタンスがそれまで存続しなければならない将来の日付および時間を指定するか、または単にインスタンスが存続可能な期間のミリ秒の長さを宣言することにより、行うことができる。あるインスタンスがインスタンス化されたときに指定された時間フレームより長い間、そのインスタンスが必要である場合、Ｗｅｂサービス・コンテナは、専用エンティティ・インスタンスに関する新しい存続時間の定義を可能にする、キープアライブ動作も提供する。これは、そのコンテナがインスタンス破棄を担当し、サービスコンシューマがもはや使用されないインスタンスを忘れてもよいという利点を有する。エンティティ・インスタンスが作成され、汎用固有ＩＤも割り当てられた後、そのエンティティ・インスタンスは、その基礎となるエンティティ・タイプのＷｅｂサービス・インターフェースを介してアクセスすることができる。これにより、そのエンティティ・インスタンスと対話することが可能になり、それにより、状態情報を検索するか、エンティティ・インスタンスの内部状態について操作する動作を実行するか、またはその他の外部サービス動作を呼び出すことが可能になる。
【００８２】
図１５は、実リソースと、エンティティ・インスタンスと、対応するＷｅｂサービス・インターフェースとの可能なセットアップを図示している。Ｗｅｂサービス・コンテナ４は、それぞれが異なるエンティティ・タイプに適合し、それぞれの個別Ｗｅｂサービス・インターフェースにより公開される２つのＷｅｂサービス（たとえば、ステートフル）をホスティングしている。Ｗｅｂサービス・インターフェース１の基礎となるエンティティ・タイプは、リソース・タイプＲＴ１のサービス指向表現を提供する。エンティティ・タイプ２は、Ｗｅｂサービス・インターフェース２を定義し、リソース・タイプＲＴ２を表現する。ＲＴ１は、既存の物理または論理リソース・タイプを表現し、そのリソース・インスタンス（Ｒ１ａ、Ｒ１ｂ、Ｒ１ｃ、およびＲ１ｄ）は、何らかのリソース固有プロトコルを使用してリモート管理することができる（破線矢印によって示される）。対照的に、ＲＴ２は、純粋に概念的なリソース・タイプを表現し、そのリソース・インスタンス（Ｒ２ａおよびＲ２ｂ）はＷｅｂサービス・コンテナ内で直接ホスティングされ、永続的なものになる。いくつかのエンティティ・インスタンスは、ステートフルＷｅｂサービス・コンテナのファクトリ・インターフェース（図示せず）を介して作成されている。エンティティ・タイプ１の場合、これらのインスタンス（エンティティ・インスタンス１ａ、エンティティ・インスタンス１ｂ、およびエンティティ・インスタンス１ｃ）は、外部に位置するリソースに対するプロキシとして動作する。あるエンティティ・インスタンスがエンティティ・タイプによって表現されるリソース・タイプのインスタンスを表現する単一実リソースと必ず関連付けられるわけではないことをこの時点で認識することは重要である。いわゆる仮想化１技法は、幅広いサービス・インスタンスをカバーするために、いくつかの実リソースのクラスタ化を可能にする（エンティティ・インスタンス１ａがＲ１ａ、Ｒ１ｂ、およびＲ１ｃからなる複合リソースによって供応される）か、またはいくつかのエンティティ・インスタンスが１つかつ同じ実リソースによって処理されることを可能にする（エンティティ・インスタンス１ｂとエンティティ・インスタンス１ｃがいずれもＲ１ｄ上で動作する）。エンティティ・タイプ２およびそのエンティティ・インスタンスに関しては、実リソースがエンティティ・インスタンスと連結されるので、リソース状態はいずれのリソース固有プロトコルもなしに直接管理できると言うことができる。この場合、新しいエンティティ・インスタンスが作成されると、実リソースのプロビジョニングは単に、リソース状態を永続的なものにするために、データベース・テーブルなどの作成を含むだけである。外部論理または物理リソースが表現されると必ず、それぞれのリソースの実際のプロビジョニングは、かなり複雑なものになり、インストール、ハードウェア・リブート、またはネットワーク設定の変更などのプロセスを含んでも良い。
【００８３】
エンティティ動作は、２部方式で現れ、記述されても良い。一方では、従来のプログラミング手法から分かるように、単純なプログラマチック動作を定義することが可能である。
【００８４】
このような単純または細かい動作は、一般的なプログラミング構成体、演算子、パラメータ、およびｒｅｔｕｒｎ文によって定義することができる。その一方で、すべてのエンティティ・タイプについて、いわゆるワークフロードリブン動作も指定することができる。単純な動作とは対照的に、このようなより複雑な宣言プログラミング構成体は、様々なワークフロー方法から分かるように、より包括的なセマンティクスに従う。これらは、個別アクティビティまたはタスクの所与のセットをどのように直列化、並列化、または同期化しなければならないかを管理する任意のタイプの制御フローを定義し、管理し、モニターするために特に適切なものである。これらの明確な種類のエンティティ・タイプ動作の公開に関して、外部Ｗｅｂサービスコンシューマは、２通りの動作タイプを区別できないことになっている。Ｗｅｂサービス・インターフェースは両者の差を公開せず、それぞれの固有の特異点をそのクライアントに対して透過なものにするが、これらの動作のインプリメンテーションはこのように十分差別する。このため、言語プロセッサは、２通りの明確な動作モードで異なるセマンティクスによりそれらを実行することになる。
【００８５】
図１６は、Ｗｅｂサービス・アーキテクチャのコンポーネントを記載している。
【００８６】
第１の最も主要なコンポーネントは、好ましくはステートフルＷｅｂサービス・コンテナである、Ｗｅｂサービス・コンテナ４を表している。一見して、ホスティング環境そのものが個別の役割を表すものと考えられないかもしれないが、コンテナはいくつかの役割に関連付けられるので、このように見なされる。とりわけ、潜在的な記述プロバイダが新しいエンティティ・タイプの記述を登録または登録取消しできるようにする、１組のＷｅｂサービス・インターフェースを外部に提供する役割を持つ。加えて、サービスコンシューマ２が様々なやり方でエンティティ・インスタンスを作成し、管理し、結合し、破棄できるようにするインターフェースを公開しなければならない。サービスコンシューマ２が登録されたエンティティ・タイプをインスタンス化し使用できるようにするために、コンテナは、登録された記述および既存のエンティティ・インスタンスに関する情報（たとえば、参照のための固有のハンドル）を検索できるようにする照会インターフェースも提供しなければならない。その上、Ｗｅｂサービス・コンテナ４は、エンティティ・インスタンスに関する管理対象ランタイム環境を提供しなければならず、対応するエンティティ・タイプ記述に適合するそれぞれのＷｅｂサービス・インターフェースの自動公開の役目を持つ。さらに、コンテナ４は、登録されたエンティティ・タイプならびにインスタンス状態を永続的に保管する責任がある。エンティティ・インスタンスが外部リソースを表現する場合、コンテナはさらに、そのリソースの状態がエンティティ・インスタンス内で反映され、関心のあるサービスコンシューマによってアクセスできることを保証する必要がある。
【００８７】
リソースプロバイダ１３
リソースプロバイダコンポーネント１３の役目は、あとでエンティティ・タイプ記述によって記述可能な任意の種類のリソースを提供することである。リソースプロバイダ１３によって提供されるリソースは、リソース固有プロトコルによりアクセス可能である必要がある。
【００８８】
記述プロバイダ３
記述プロバイダ３は、宣言言語でそれらを記述することにより新しいエンティティ・タイプを作成する役割を持つ。さらに、記述プロバイダ３は、その専用登録インターフェースを介して新たに指定された記述をＷｅｂサービス・コンテナに登録する役割も担う。このアーキテクチャの結果として、エンティティ・タイプのプロバイダは、従来の手法から分かるように、単調でエラーを発生しがちなデプロイメント・プロセスから解放される。
【００８９】
実行可能ファイルをコーディングし、コンパイルし、記述し、パッケージ化し、最後にそれをホスティング環境内の事前定義場所に転送する代わりに、記述プロバイダは、Ｗｅｂサービス・コンテナ自体のインターフェース上で専用登録動作を呼び出し、呼出しパラメータとしてその記述を渡すだけでよい。
【００９０】
サービスコンシューマ２
記述プロバイダ３が新しいエンティティ・タイプ記述を登録するとすぐに、このエンティティ・タイプに基づく新しいエンティティ・インスタンスをインスタンス化することができる。この新しいエンティティ・インスタンスの作成はサービスコンシューマ２の責任である。エンティティ・タイプをインスタンス化するために、サービスコンシューマ２はまず、Ｗｅｂサービス・コンテナの情報検索インターフェースに照会し、所望のエンティティ・タイプ記述を参照するハンドルを入手しなければならない。インスタンス化の後、サービスコンシューマ２は、固有のインスタンスＩＤを入手し、その後、エンティティ・タイプから得られ、そのエンティティ・タイプに準拠するＷｅｂサービス・インターフェースを介してエンティティ・インスタンスと対話することができる。基礎となるエンティティ・タイプのＷｅｂサービス・インターフェースを使用して、サービスコンシューマは、任意の公開されたインスタンス動作を呼び出し、その結果、エンティティ・インスタンスの固有状態を変更することができる。コンテナのソフト状態管理インターフェースを使用してエンティティ・インスタンスが作成されない限り、サービスコンシューマ２は、結局、もはや使用されない既存のエンティティ・インスタンスを削除しなければならなくなる。
【００９１】
外部メッセージング・ソースおよびシンク１５
ステートフルＷｅｂサービス・コンテナはホスティング環境内に存続するエンティティ・インスタンス間だけでなく、Ｗｅｂサービス・コンテナ４と外部メンバーとの間の非同期メッセージの送受信もサポートするので、外部メッセージング・ソースと外部メッセージング・シンクの役割がそれぞれ存在する。外部メッセージング・ソースの場合、任意のコンポーネントは、コンテナのメッセージング・ブローカ・インターフェースにより新しいメッセージング宛先を作成することができる。既存のメッセージング宛先の結果として、外部メッセージング・ソースは、公開のために任意の既存のメッセージング・トピックまたはキューに登録することが可能である。このような登録されたメッセージング・ソースの側で特定のイベントが発生すると必ず、発生したイベントを示す新しいメッセージがコンテナのメッセージング・ブローカ・インターフェースを介してそれぞれの宛先に公開されることになる。外部メッセージング・シンクの役割に関しては、外部システム・コンポーネントは、新しい宛先を作成するかまたは関心のある任意の既存の宛先にサブスクライブすることが可能である。この結果、メッセージがそれぞれのメッセージング宛先に公開されると必ず、外部メッセージング・シンクに通知されることになる。
【００９２】
外部サービス・プロバイダ１６
ステートフルＷｅｂサービスのホスティングが示す通り、Ｗｅｂサービス・コンテナ４は、サービス指向アーキテクチャの要件に従ってそのサービスを提供する。ホスティング環境内に存続するエンティティ・インスタンスはＳＯＡ内に存続するサービスのように動作することもできるので、それらは、エンティティ自体の内部で実現されないが、他のサービスによって提供される機能性を含むことができる。このようなカプセル化された機能性は、同じコンテナ内に存続する他のエンティティ・インスタンスまたは所望の機能を実現する外部サービス・プロバイダのいずれかによって提供することができる。これらの２通りのメソッドの前者は同じコンテナ内に存続するエンティティ・インスタンスによって提供される機能性のみに関係し、前に確立された関係を使用してアドレス指定することができるが、後者は外部サービスの呼出しを含む。このようなサービスは、外部サービス・プロバイダによって提供され、エンティティ・インスタンスの単純動作ならびにワークフロードリブン動作の両方から呼び出すことができる。
【００９３】
Ｗｅｂサービス・コンテナ・コンポーネント４
動的にデプロイ可能なステートフルＷｅｂサービス・コンテナの一般的なアーキテクチャに含まれる個別のコンポーネントについて説明した後、このセクションでは、エンティティがホスティング環境の機能を実現できるようにする役割を担う、個別コンポーネントについてより詳細に考察する。ちなみに、以下に示す単一コンポーネントへのステートフルＷｅｂサービス・コンテナの分解は、規範的なものまたはインプリメンテーション固有のものいずれとしても見なしてはならないことに留意することが重要である。このように言うと、以下に記載するコンポーネントは、適用されたアーキテクチャ内でコンテナの役割をどのように反映できるかという可能な手法の１つを表している。これは、これらの部分のいずれも（コンテナのインターフェースを除く）ステートフルＷｅｂサービス・コンテナの実際のインプリメンテーション内の具体的な対応物によって表現される必要があることを意味しないが、ホスティング環境の役割をより詳細に解明し、これらの説明をより具体的なものにする働きをするだけである。
【００９４】
図１７は、それぞれの部分およびそれらの関係の概略図を示している。
【００９５】
コンテナ・インターフェース２０（２０ａ〜２０ｄ）
前述の通り、コンテナの機能性は、適切に定義されたＷｅｂサービス・インターフェース２０によりサービス指向的な手法で公開される。インターフェースは、具体的なオペレーションのセットをサービスコンシューマに提供する、いくつかのポート・タイプ（２０ａ〜２０ｄ）にグループ化される。コンテナのＷｅｂサービス・インターフェースのポート・タイプとそれぞれの動作の概要は図１７に図示されている。この時点でその動作は要点のみ記載されることに留意されたい。これらの動作とどのように相互作用するか、どのパラメータを渡すか、ならびにどのような戻り値が予想されるかに関する詳細な実証については、図１８〜図２４に対する説明に示される。
【００９６】
当然のことながら、ステートフルＷｅｂサービス・コンテナのポート・タイプによって公開された機能は、提供されるサービスの内部インプリメンテーションによって認識されなければならない。図１８では、これは、それぞれのマネージャ・コンポーネントによって概略的に示される。これらは、アーキテクチャ内の部分であって、等しくパーシスタンス層（すなわち、データ・ストア）ならびにサービス・ランタイム環境と相互作用する役割を持つ部分を表している。
【００９７】
サービス・インターフェース２１（２１ａ／２１ｂ）
任意のエンティティ・タイプのＷｅｂサービス・インターフェース２１は、主として基礎となるエンティティ・タイプ記述に依存する。前に示した通り、エンティティ・タイプ記述は、具体的オペレーションがＷｅｂサービス動作として公開されるかどうかを定義することを可能にする。公開されると宣言されたすべての動作のセットは、所与のエンティティ・タイプに属す少なくとも１つのエンティティ・インスタンスが存在するとすぐに、エンティティ・タイプのＷｅｂサービス・インターフェース２１によりアクセスすることができる。しかし、宣言されたエンティティ・インスタンス動作に加えて、デフォルトではさらに２つのインスタンス動作が公開される。一方では、照会されたエンティティ・インスタンスの基礎となるエンティティ・タイプを返すｇｅｔＥｎｔｉｔｙＴｙｐｅ動作であり、その一方で、それぞれのエンティティ・インスタンスが関与するすべての関係についてサービスコンシューマに通知するｇｅｔＲｅｌａｔｉｏｎｓｈｉｐｓ動作である。
【００９８】
エンティティ・タイプ記述ならびにそれに対応する外部Ｗｅｂサービス・インターフェースの具体的な例は図１３に示されている。
【００９９】
ランタイム環境６０
新しいエンティティ・タイプ記述が登録されインスタンス化された後、エンティティ・インスタンスはＷｅｂサービス・コンテナのサービス・ランタイム環境６０内に存続することになる。エンティティ・インスタンスは、ランタイム環境内に存在し、それが削除されるまで基礎となるエンティティ・タイプに対応するＷｅｂサービス・インターフェース２１により使用することができる。前に示した通り、エンティティ・インスタンスの削除は、コンテナのＷｅｂサービス・インターフェース上でｄｅｌｅｔｅＩｎｓｔａｎｃｅ動作を呼び出す外部サービスコンシューマによるか、専用演算子を使用するエンティティ・インスタンスによるか、エンティティ・インスタンスが従属コンテンツの役割において含む（contains）という関係で動作するためまたはエンティティ・インスタンスがすでに経過した所与のライフタイムでインスタンス化されているために、ランタイム環境６０そのものにより、開始することができる。エンティティ・インスタンスは潜在的にステートフルであるので、ランタイム環境６０は、エンティティ・インスタンスまたはそれらの間の関係に関するすべてのデータがそれぞれのデータ・ストアに対して自動的に永続的なものになることを確かめる役目も持つ。さらに、ランタイム環境６０は、これが必要な正しいトランザクション・コンテキスト下で呼び出された動作が実行されることを保証するために、トランザクション・マネージャと密接に相互運用する。加えて、ランタイム環境６０は、新しいエンティティ・インスタンスおよび関係をユニバーサルにユニークなリファレンスに関連付け、そのインスタンスが作成された後で、即座にエンティティ・インスタンス上で正しいコールバック動作（ｏｎ−ｉｎｉｔエレメントに対して宣言されマッピングされたもの）を呼び出す役目を有する。これに類似して、ランタイム環境６０は、エンティティ・タイプ記述に宣言されたように、それぞれのオンデリート（on-delete）コールバック動作を確実に呼び出す。同様に、宣言され開始されたタイマのタイムアウトの結果、正しいエンティティ・インスタンス動作も呼び出されることになる。さらに、ランタイム環境６０は、コンテナのメッセージング・サブシステムと相互運用し、したがって、それぞれの宛先にサブスクライブしたすべてのメッセージ消費エンティティ・インスタンスに対して非同期通知を配信し、それについて正しい動作を呼び出す役目を持つ。
【０１００】
言語プロセッサ２５およびワークフロー・エンジン２６
登録動作によりＷｅｂサービス・コンテナにサブミットされた宣言サービス記述はどの宣言言語でも指定されるので、コンテナは、サブミットされたエンティティ・タイプ記述を解釈できる言語処理装置を備えている必要がある。まず第一に、言語プロセッサは、サブミットされた記述を分析し、検証し、妥当性検査する役目を有する。インスタンス化の後、言語プロセッサ２５は、個別エンティティ・インスタンスについて動作呼出しを実行し管理する。このようなエンティティ・インスタンス動作の呼出しは、単純動作モードまたはワークフロードリブン動作モードのいずれかで実行しなければならない。ワークフロードリブン動作の場合、その動作は、言語プロセッサ２５のサブシステムであるワークフロー・エンジン２６によって実行されることになる。ワークフロー・エンジン２６は、長期実行トランザクションを処理するためにトランザクション・マネージャとのシームレス統合を保証し、補正アクティビティを可能にし管理することにより、前に終了したサブタスクの効果の取消しを可能にする。
【０１０１】
トランザクション・マネージャ２７
トランザクション・マネージャ２７は、調整およびトランザクション・コンテキストの作成、実行、および破棄を処理し管理する役割を持つ。これは、トランザクション動作が呼び出されたときの新しいトランザクション・コンテキストの作成ならびに実行中のトランザクションおよび既存のコンテキストの管理を含む。単純動作の場合、トランザクションは常に、ＡＣＩＤ特性下で実行中であるものと見なされる。
【０１０２】
しかし、ワークフロードリブンの場合、トランザクションは、Ｗｅｂサービス・ビジネス・トランザクション・フレームワーク２６で定義される状態モデルを使用して実行されるものと想定される。個別Ｗｅｂサービスが相互作用するときに発生する場合が多い、長期実行トランザクションでは、分散トランザクションのアトミック性および独立性を効率よく満たすことができないので、このモデルは、厳格なＡＣＩＤ要件を緩和し、ワークフロードリブン動作の場合に使用されるように、長期実行トランザクションに対して一貫性および耐久性を保証しなければならないことを要求するだけである。加えて、これらのトランザクションは、ワークフロー全体のうちの何らかの他のタスクであって、最終結果がそれに依存するようなタスクが失敗した場合に、前に正常終了したアクティビティの効果を逆にする場合もある、補正アクティビティをワークフローが定義できることも考慮に入れている。
【０１０３】
アクセス・コントローラ２８
アクセス・コントローラは、そのエンティティ・タイプがアクセス制御リストに指定されているエンティティ・インスタンスのみが実際にターゲット・エンティティ・インスタンス上の個々のオペレーションへのアクセスを許可されるようにする役割を持つ。これに加えて、アクセス・コントローラは、特定のエンティティ・タイプの所与のインスタンス上の所与のオペレーションセットに対して共同でアクセス可能な複数のエンティティ・タイプのグループを管理する役目も有する。
【０１０４】
メッセージング・サブシステム２９
エンティティ・インスタンスと外部メッセージング・クライアントとの間の、コンテナにより仲介された（Container-brokered）非同期通知を可能にするために、Ｗｅｂサービス・コンテナは、従来型のメッセージング・サブシステムのフィーチャーに基づいて構築されており、メッセージング・ポート・タイプを介してその外部ブローカ・インターフェースを公開する、（それぞれのメッセージング・サブシステム２９の一部である）メッセージ・ブローカ（図示せず）も提供する。その内部メッセージ・ブローカにより、メッセージング・サブシステム２９は、外部メッセージング・クライアントと内部メッセージング・クライアント（同様にメッセージ・プロバイダとコンシューマ）との間のブリッジとして動作し、宛先、サブスクリプション、登録、ならびに、それに関するメッセージが公開されたときにメッセージングコンシューマが使用可能である場合に公開されたメッセージを永続的に保管することを保証する。発展を続けるＷｅｂサービス規格との互換性を保証するために、メッセージ・ブローカのＷｅｂサービス・インターフェースは、最近リリースされたＷｅｂサービス通知指定１７に適合するように拡張することができるであろう。しかし、これは、タイプ・キューのメッセージング宛先がもはやサポートされなくなるという面もある。
【０１０５】
データ・ストア３０
Ｗｅｂサービス・コンテナのステートフル・プロパティを扱うために、コンテナは、すべての様々な情報を永続的なものにする役割を持つ１組のデータ・ストア３０を提供しなければならない。それぞれのデータ・ストアに関する簡単な説明を以下に示す。
【０１０６】
エンティティ・タイプ・データ・ストア３０ａ
エンティティ・タイプ・データ・ストアは、前に登録されたエンティティ・タイプ記述が登録取消しまたは変更されるまで、それらをすべて保持する役目を持つ。エンティティ・タイプに対する変更は、エンティティ・タイプ・データ・ストア３０ａならびにそれぞれのエンティティ・タイプに対応するエンティティ・インスタンス内の両方に反映しなければならない。存続するエンティティ・インスタンスを伴うエンティティ・タイプが変更された場合、その変更はエンティティ・インスタンス・ストアまたは基礎となる具体的なリソース（実リソースがモデル化される場合）にも反映されなければならない。コンテナに正常に登録され、エンティティ・タイプ・ストア内で永続的なものになっているエンティティ・タイプは、後続インスタンス化に使用可能なものになる。
【０１０７】
エンティティ・インスタンス・ストア３０ｂ
前に登録されたエンティティ・タイプから新しいエンティティ・インスタンスが作成される場合、エンティティ・インスタンス・データ・ストア３０ｂは、この個別エンティティ・インスタンスに関するすべての状態データを保持する役割を有する。
【０１０８】
宛先データ・ストア３０ｃ
宛先データ・ストア３０ｃは、コンテナで仲介された非同期メッセージングに関するすべての情報を含む。これは、メッセージング宛先（すなわち、トピックおよびキュー）、既存のメッセージング宛先へのサブスクリプション、ならびに既存のメッセージング宛先への登録を含む。サブスクライブしたメッセージコンシューマが一時的に使用不能である場合、宛先ストアは、それぞれのクライアントがもう一度使用可能になった後、メッセージ・ブローカが欠落メッセージを送信できるようにするために、このようなメッセージング・シンクにメッセージを保管する役目を持つ。
【０１０９】
プロトコル・レジストリ３０ｄ
Ｗｅｂサービス・コンテナはリソース固有プロトコルに関してできるだけ柔軟かつ拡張可能なものでなければならないので、このアーキテクチャは、新しいリソース固有プロトコルに関するサポートをホスティング環境に動的に登録する可能性を提供する。これは、前に知られていない新規なプロトコルも言語プロセッサが処理できることを可能にするものである。新たに登録されたプロトコルを保管するために、コンテナは、専用プロトコル登録インターフェース動作２とともに使用されるプロトコル・レジストリを提供する。
【０１１０】
図１８は、エンティティ・タイプ記述を登録するための相互作用を示している。
【０１１１】
新しいエンティティ・タイプ記述を登録するために、第一に、記述プロバイダは、それが選んだ任意の種類のリソースの動作を記述する新しいエンティティ・タイプ記述（すなわち、ある種の物理または論理リソースに適合するもの）を指定する。新しいエンティティ・タイプの記述は、自動的に行う（テンプレート・リポジトリまたはパーツ・リポジトリからのテンプレートを使用する）か、またはスクラッチから新しい記述を指定することによって手動で行うことができる。新しいエンティティ・タイプを宣言すると、記述プロバイダは、Ｗｅｂサービス・コンテナの登録ポート・タイプのｒｅｇｉｓｔｅｒＥｎｔｉｔｙＴｙｐｅ動作を呼び出すことができ、それにより、伝送されたエンティティ・タイプ記述を登録するようホスティング環境に指示する。その後、コンテナは、新しいタイプのステートフル・リソースを表現する記述を分析し、妥当性検査し、それをエンティティ・タイプ・ストアに登録する。正常登録後、新規なエンティティ・タイプはインスタンス化のために提供される。この記述が新しい宛先の宣言も含む場合、これらはコンテナのブローカの宛先ストアに保管される。正常登録の結果として、Ｗｅｂサービス・コンテナは、ユニバーサルにユニークな記述ハンドル（登録されたエンティティ・タイプを参照する）を記述プロバイダに返すことになる。失敗した場合、コンテナは代わりに障害コードを返すことになっている。
【０１１２】
図１９は、既存のエンティティ・タイプを変更するための相互作用を示している。
【０１１３】
図１７が示す通り、Ｗｅｂサービス・コンテナの登録ポート・タイプにより、ランタイム中に既存のエンティティ・タイプを変更することも可能になる。エンティティ・タイプのインターフェースを拡張または最小化するために、記述プロバイダは、ｍｏｄｉｆｙＥｎｔｉｔｙＴｙｐｅ動作を呼び出し、それぞれのエンティティ・タイプ記述を指し示す記述ハンドルと変更されたエンティティ・タイプ記述をパラメータとして渡すことを選択することができる。その結果、Ｗｅｂサービス・コンテナは、サブミットされた変更に適合するように既存のエンティティ・タイプと対応するエンティティ・インスタンスを変更し、関連のデータ・ストアにその変更を保管する。その結果、コンテナは、変更が正常に採用されたかどうかを示す状況コードを返すことになる。
【０１１４】
図２０は、既存のエンティティ・タイプの登録取消しのための相互作用を示している。
【０１１５】
既存のエンティティ・タイプがもはや必要ではない（すなわち、このエンティティ・タイプに属すエンティティ・インスタンスがまったく残っていない）場合、記述プロバイダは、ｄｅｒｅｇｉｓｔｅｒＥｎｔｉｔｙＴｙｐｅ動作を呼び出し、登録取消しすべき所望のエンティティ・タイプ記述を指し示す記述ハンドルを渡すことを選択することができる。Ｗｅｂサービス・コンテナは、その後、エンティティ・タイプ・ストアからその記述を登録取消しすることになる。続いて、記述プロバイダは、登録取消し動作が成功したかどうかを示す状況コードを受信することになる。
【０１１６】
インスタンス化および破棄
エンティティ・タイプがコンテナに登録された後、そのエンティティ・タイプはインスタンス化し使用することができる。新しいインスタンスのインスタンス化および変更は、Ｗｅｂサービス・コンテナのインスタンス化ポート・タイプを介して行うことができる。このポート・タイプに属す動作については以下のサブセクションで説明する。
【０１１７】
図２１は、エンティティ・タイプをインスタンス化するための相互作用を示している。
【０１１８】
登録されたエンティティ・タイプをインスタンス化するために、サービスコンシューマは、Ｗｅｂサービス・コンテナのｉｎｓｔａｎｔｉａｔｅＥｎｔｉｔｙＴｙｐｅ動作のうちの１つを呼び出し、インスタンス化すべきエンティティ・タイプを参照する記述ハンドルをパラメータとして渡すことができる。インスタンスが所与のライフタイムで作成された場合、Ｗｅｂサービス・コンテナは、示された時間が経過した後でエンティティ・インスタンスを破棄する責任も負うことになっている。このため、すべての個別インスタンスのライフタイムを管理するために、エンティティ・インスタンスの初期設定データ（基礎となるエンティティ・タイプ記述に宣言されたもの）とともにライフタイム・データを永続的なものにしなければならない。インスタンス化プロセスが成功した場合、Ｗｅｂサービス・コンテナは、サービスコンシューマに返されるユニバーサルにユニークなインスタンス・ハンドルに新しいエンティティ・インスタンスを関連付けることになる。インスタンス化が失敗した場合、これは、サービスコンシューマに障害コードを返すことによって示される。新しいエンティティ・インスタンスが所与の存続時間で作成され、それぞれのインスタンスが前に設定された時間より長い間必要である場合、サービスコンシューマは、（反復的に）ｋｅｅｐＡｌｉｖｅ動作を呼び出し、そのライフタイムが延期されるターゲット・インスタンスを示すことを選択することができる。任意選択で、サービスコンシューマは、その後でエンティティが除去される新しい存続時間を指定することもできる。
【０１１９】
図２２は、エンティティ・インスタンスを削除するための相互作用を示している。
【０１２０】
ある時点で既存のエンティティ・インスタンスがもはや必要ではない場合、インスタンス化ポート・タイプのｄｅｌｅｔｅＥｎｔｉｔｙＩｎｓｔａｎｃｅ動作を使用して、それを明示的に破棄することができる。この動作がサービスコンシューマによって呼び出されると、削除すべきエンティティ・インスタンスを参照するインスタンス・ハンドルをパラメータとして渡さなければならない。サービスコンシューマがこの動作を実行することを許可されている場合、Ｗｅｂサービス・コンテナは、エンティティ・インスタンスの削除時コールバック動作を呼び出し、その後、ホスティング環境のエンティティ・インスタンス・ストアからそれぞれのインスタンスを除去することになる。その結果、サービスコンシューマは、削除動作が成功したかどうかを示す状況コードを受信することになる。
【０１２１】
サービスの利用および相互作用
登録されたエンティティ・タイプが初めてインスタンス化されると、所与のエンティティ・タイプに対応するエンティティ・インスタンスが少なくとも１つ存在する限り、基礎となるエンティティ・タイプのＷｅｂサービス・インターフェースにより個別エンティティ・インスタンスにアクセスすることができる。これらのサービスに固有なインターフェースは、ホスティング環境内のそれぞれの個別エンドポイント上でアクセス可能である。それぞれのエンティティ・タイプ記述に指定されたサービス固有の動作に加えて、すべての個別Ｗｅｂサービス・インターフェースは少なくとも２通りの追加動作を提供する。第一に、所与のエンティティ・インスタンスのエンティティ・タイプを返す動作と、第二に、それぞれのエンティティ・インスタンスが関与するすべての関係（暗黙ならびに明示の両方）を返す動作である。
【０１２２】
図２３は、単純インスタンス動作の呼出しを示している。
【０１２３】
専用エンティティ・インスタンスがどのようにサービスコンシューマと対話できるかを実証するために、このサブセクションでは、サービスコンシューマがエンティティ・インスタンスに関する単純動作を呼び出す場合の一例を示す。サービスコンシューマが所与のインスタンスと対話できるようになる前に、第一に、コンシューマは、所望のエンティティ・インスタンスを参照するインスタンス・ハンドルと、基礎となるエンティティ・タイプのＷｅｂサービス・インターフェースにアクセス可能なエンドポイント参照とを入手しなければならない。次のセクションに示すように、この目的のため、コンテナは、関心のあるサービスコンシューマが必要な情報を収集できるようにする特別なイントロスペクション・ポート・タイプを提供する。サービスコンシューマは、必要な情報を入手するとすぐに、それぞれのＷｅｂサービス・インターフェースにより公開されたエンティティ・インスタンスの動作のうちのいずれか１つに自由にアクセスすることができる。これは、Ｗｅｂサービス・エンドポイントをアドレス指定し、所望の動作を呼び出し、インスタンス・ハンドルならびに追加の必要なパラメータを提供することによって行われる。その結果として、コンテナ管理のＷｅｂサービス・エンドポイントは、呼出しをインターセプトし、所望のエンティティ・インスタンスに動作呼出しを経路指定することになる。動作が呼び出された結果として、それぞれのエンティティ・インスタンスは、その内部状態を変更し、呼出しの結果をエンティティコンシューマに返すことができる。
【０１２４】
図２４は、ワークフロードリブン動作の呼出しを示している。単純なインスタンスオペレーションの呼出しに類似して、サービスコンシューマは、所与のエンティティ・インスタンスに定義されているワークフロードリブン動作を代わりに呼び出すことを選択することもできる。単純なオペレーションの場合のように、サービスコンシューマは、動作を呼び出すときにインスタンス・ハンドルならびに可能なパラメータも提供しなければならない。動作がターゲット・エンティティ・インスタンスについて最後に実行されると、その動作はそれぞれのエンティティ・タイプ記述に規定されたアクティビティを実行する。これは、長期実行トランザクション・コンテキスト下で実行される外部ワークフロー・アクティビティも含んでも良い。単純なオペレーションのように、ワークフロードリブン動作も結局、サービスコンシューマに結果を返すことができる。しかし、ほとんどの場合、これはサービスコンシューマの側でのブロッキングを必要としないので、非同期通知を使用して結果についてサービスコンシューマに通知する方がより良い場合もあろう。
【０１２５】
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせで実現することができる。本発明によるツールは、１つのコンピュータ・システム内で集中方式で実現するか、または種々のエレメントが複数の相互接続コンピュータ・システムの全域に広がっている分散方式で実現することができる。本明細書に記載した方法を実行するために適合されたものであれば、どのような種類のコンピュータ・システムまたはその他の装置も適している。ハードウェアとソフトウェアの典型的な組み合わせは、ロードされ実行されたときに、本明細書に記載した方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを備えた汎用コンピュータ・システムにすることができるであろう。
【０１２６】
本発明は、本明細書に記載した方法の実現を可能にするすべての機能を含み、コンピュータ・システムにロードされたときに、これらの方法を実行できるコンピュータ・プログラム（computer program product）に組み込むこともできる。
【０１２７】
これに関連して、コンピュータ・プログラム手段またはコンピュータ・プログラムは、直接またはａ）他の言語、コード、または表記への変換、またはｂ）異なる物質的形式による複製のいずれか一方または両方の後、情報処理機能を有するシステムに特定の機能を実行させるための１組の命令を任意の言語、コード、または表記で表した任意の表現を意味する。
【０１２８】
定義
サービスの動的デプロイメント
動的デプロイメントをサポートするシステムは、開発者またはアプリケーションによって提供されたソース・コードを取得し、ユーザとの対話を更に必要とせずに、しかもアプリケーション・サーバを再始動せずに、ターゲットとなるサービス・コンテナ（すなわち、ホスティング環境）にそれを動的にインストールするメカニズムを提供する。したがって、アプリケーションは、そのユーザまたはサービスコンシューマにとって使用可能なものになる。
【０１２９】
エンティティ・タイプ
エンティティ・タイプは、宣言記述言語により記述され、任意の考えられるリソース・タイプのサービス指向表現を提示するものである。リソースのサービス指向表現は抽象的に行われるので、サービス指向アーキテクチャの任意の考えられる実現例（すなわち、ステートフルＷｅｂサービス）にエンティティ・タイプをマッピングすることができる。
【０１３０】
エンティティ・インスタンス
エンティティ・インスタンスは、抽象サービス指向インスタンスを表現するものであり、所与の具体的なリソース・インスタンスに関連付けることができる。どのエンティティ・インスタンスも、基礎となるエンティティ・タイプを有し、ＩＤ（ホスティング環境によってそのインスタンスに割り当てられたもの）を有し、ライフ・サイクルに従い、エンティティ・タイプによって定義された属性に具体的な値を割り当てる。
【０１３１】
リソース・タイプ
どの実リソース・インスタンス（物理または論理）も、基礎となるリソース・タイプを有し、そのリソース・タイプは、それぞれのリソースの本質的な特性、すなわち、リソースが提供する機能性（たとえば、文書のテキスト処理、コピー、カット、ペースト）、リソースが含む属性（たとえば、処理された文書の名前、文書がすでに保管されている場合はクリップボードの内容）、これらの属性についてリソースが許可する可能な状態を収集するものである。
【０１３２】
リソース・インスタンス
具体的なリソース・インスタンスは、あるリソース・タイプに適合するインスタンスと見なされなければならない。これは、適切に定義されたＩＤを有し、状態情報を保持し、すなわち、これはリソースの属性のそれぞれについて値を定義する。
【０１３３】
サービス・コンテナ
サービス・コンテナ（すなわち、ホスティング環境）は、好ましくはステートフル・サービス・コンテナであり、管理の対象となるランタイム環境を提供し、透過トランザクション処理、パーシスタンス、メッセージング・サブシステム、およびサービス・インスタンスのワークフロー主導動作の実行を制御するワークフロー・エンジンを提供する。このサービス・コンテナは、プロセッサ、作業メモリ、２次ストレージ、および理想的にはネットワーク（有線または無線）アクセスを有する、通常のＰＣ、特殊なサーバなどのような任意の種類のデータ処理装置上で実行することができる。
【０１３４】
Ｗｅｂサービス
Ｗｅｂサービスは、ネットワークによる相互運用可能なマシン間相互作用をサポートするように設計されたソフトウェア・システムである。これは、マシン処理可能なフォーマット（たとえば、ＷＳＤＬを使用する）で記述されたインターフェースを有し、規定の方法で（たとえば、いわゆるＳＯＡＰメッセージを使用する）他のシステムがそれと対話できるようにする。
【０１３５】
ステートフルＷｅｂサービス
ステートフルＷｅｂサービスは、サービスのタイプを表現するインターフェース（ＷＳＤＬによって記述される）と、インターフェースによりアクセス可能であり、ＩＤを有し、適切に定義されたライフ・サイクルに従うゼロから多数のサービス・インスタンスから構成される。サービス・インスタンスは、内部状態を維持し、そのため、サービス動作の効果がサービス・インスタンスの内部状態に依存する可能性があるので、有限状態オートマトンを表現する。グリッド・サービスと同様に、ステートフルＷｅｂサービスは、ディスカバリ、動的サービス作成、ライフタイム管理、通知、および一般的な管理の容易性のためにインターフェースを定義する。
【０１３６】
サービス指向アーキテクチャ
サービス指向アーキテクチャは、少なくとも１つのサービス・コンテナと、サービスコンシューマと、リソースプロバイダと、記述プロバイダから構成される。これらのメンバーはいずれも、ネットワークを介して接続され、このアーキテクチャ内で通信するか、または情報を交換する。
【図面の簡単な説明】
【０１３７】
【図１】現況技術のＷｅｂサービス開発およびデプロイメント・プロセスを示す図である。
【図２】本発明による発明的なデプロイメント方法を示す図である。
【図３】図２による発明的なデプロイメント方法を実行するために必要な分散ネットワーキング・アーキテクチャ内の関係メンバーを示す図である。
【図４】図３による発明的なデプロイメント方法を実行するための分散ネットワーキング・アーキテクチャの関係メンバーのコンポーネントを示す図である。
【図５】図３による関係メンバーのコンポーネントの対話図である。
【図６】本発明により任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときのアクティビティを示す図である。
【図７】本発明により任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときのアクティビティを示す図である。
【図８】本発明により任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときのアクティビティを示す図である。
【図９】本発明により任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときのアクティビティを示す図である。
【図１０】本発明により任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときのアクティビティを示す図である。
【図１１】本発明により任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときのアクティビティを示す図である。
【図１２】本発明により任意の種類のサービスのリソースの新しい表現がサービス・コンテナに登録されるときのアクティビティを示す図である。
【図１３】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図１４】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図１５】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図１６】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図１７】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図１８】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図１９】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図２０】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図２１】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図２２】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図２３】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図２４】Ｗｅｂサービス・コンテナを使用するＷｅｂサービス・アーキテクチャ内のサービスの動的デプロイメントのための発明的なシステムおよび方法の好ましい一実施形態を示す図である。
【図１】
2007538313.tif 000003
【図２】
2007538313.tif 000004
【図３】
2007538313.tif 000005
【図４】
2007538313.tif 000006
【図５】
2007538313.tif 000007
【図６】
2007538313.tif 000008
【図７】
2007538313.tif 000009
【図８】
2007538313.tif 000010
【図９】
2007538313.tif 000011
【図１０】
2007538313.tif 000012
【図１１】
2007538313.tif 000013
【図１２】
2007538313.tif 000014
【図１３】
2007538313.tif 000015
【図１４】
2007538313.tif 000016
【図１５】
2007538313.tif 000017
【図１６】
2007538313.tif 000018
【図１７】
2007538313.tif 000019
【図１８】
2007538313.tif 000020
【図１９】
2007538313.tif 000021
【図２０】
2007538313.tif 000022
【図２１】
2007538313.tif 000023
【図２２】
2007538313.tif 000024
【図２３】
2007538313.tif 000025
【図２４】
2007538313.tif 000026
【国際調査報告】
2007538313.tif 000027
2007538313.tif 000028