JP2009520268A - 更新されたコントラクトへのウェブサービスの準拠 - Google Patents

Abstract

実施形態の例は、既存のサービス実装の部分を更新するための自動化メカニズムを提供することによって、サービスコントラクトの変更に関連する現在の問題に対処する。例えば、あるメカニズムは、ＮＰＤＬ（例えば、ＷＳＤＬ）コントラクトに対する変更に準拠するために実装のスケルトン（例えば、メソッド、メソッドシグネチャ、データ構造など）を修正する。そのような実施形態では、開発者は、典型的にコントラクトの定義からは分からないビジネスロジックに対する必要な変更がもしあれば、その必要な変更を行うことだけを必要とする可能性がある。したがって、実装に対するそのような自動修正は、開発者がウェブサービス開発へのアプローチに基づいてコントラクトを採用することを容易にする。

Description

本発明は、ウェブサービスを、更新されたコントラクトに準拠させることに関する。

コンピュータシステムおよび関連技術は社会の多くの側面に影響を与える。実際、コンピュータシステムの情報処理能力は、我々の生活と労働の様式を変化させた。コンピュータシステムは現在、コンピュータシステムの出現以前は手動で実行されていたタスク（例えば、文書処理、スケジューリング、データベース管理など）のホストを一般的に実行する。より最近では、コンピュータシステムは、コンピュータシステムがデータを共有するために電子的に通信することができるコンピュータネットワークを形成するために、互いに結合されるようになった。ウェブサービスは、コンピュータシステム間のそのような通信を向上させる原動力であり、ソフトウェアを構築して使用するやり方を完全に変化させている。

ウェブサービスはアプリケーションに、データを共有させ、−より強力に−それらのアプリケーションがどのように構築されたか、どのようなオペレーティングシステムまたはプラットフォーム上でそれらのアプリケーションが実行されるか、およびそれらのアプリケーションにアクセスするためにどのようなデバイスが使用されるかに関係なく、他のアプリケーションからの機能を呼び出させる。ウェブサービスは、ＳＯＡＰ、ＸＭＬ、ＵＤＤＩ、ＷＳＤＬなどを含め、業界標準のプロトコルを用いてインターネットを介して呼び出すことができる。ウェブサービスは互いに独立したままであるが、それらのウェブサービスは、それらのウェブサービス自体を特定のタスクを実行する共同グループ（collaborating group）に緩やかにリンクすることができる。

多くの場合、ウェブサービスネットワーク上の電子的な通信には、サーバコンピュータシステム（以下、「サーバ」、「サービス」、または「ウェブサービス」と言う）のネットワークサービス（例えば、ウェブサービス）に対するアクセスを要求するクライアントコンピュータシステム（以下、「クライアント」と言う）が含まれる。したがって、クライアントは、そのシステムリソースへの特定のアクセスに関してサービスに要求を送信し、サービスは、所望の情報を提供する応答メッセージで応答する。当然、クライアントとサービスの間の他のメッセージングパターンが使用可能なことがあり、単純なシングルトンメッセージ（singleton messages）、ならびに、例えば通知、送信請求−応答（solicit-response）、Ｐｕｂ−Ｓｕｂパターン、ポーリング、キック−プッシュ（kick-push）、キューイングなどのような、より高度なマルチメッセージ交換を含むことがある。さらに、認証および検証のメカニズムなど、サービスリソースにアクセスするために必要とされる他の手順（procedure）が存在することがある。

サービスにアクセスするために使用されるメッセージパターンおよび／または手順のタイプにかかわらず、ウェブサービスは、クライアントとサービスの両方が基本コントラクト（contract）に合意するのでプラットフォームにとらわれないやり方で相互運用性（interoperability）を提供する。マシン読み取り可能な言語および人間の言語の混合によって表されるそのようなコントラクトは、特に、ウェブサービスによって提供される操作−機能の単位−、ならびに／あるいは呼び出されるときに各操作によって渡されるおよび／または返されるメッセージのフォーマットを定義する。ネットワークプロトコル記述言語（ＮＰＤＬ：Network Protocol Description Languages）（例えば、ＷＳＤＬ）は、共通または標準的な言語でウェブサービスコントラクトを記述するための全体的なラッパー（wrapper）または仕様（specification）を提供する。そのような仕様は、開発者および開発ツールがコントラクトを作成して解釈することを容易にし、また、その人気の大きな原因である広範なツーリングスイート（tooling suite）を有する。

ウェブサービスのコントラクトは、サービス実装（service implementation）（例えば、別の組織からのビジネスロジックを含む実装）とは独立して書かれることがあるか、または既存のサービスの振舞い（behavior）を反映するための何らかの自動化された手段によって生成されることがあるかのいずれかである。開発者はますます、実装とは独立にコントラクトを正確に述べる能力を必要としている。例えば、複数の企業間、あるいは同じ企業内のグループまたはチーム間の相互運用性のシナリオは、「コントラクト第一（contract-first）」または「コントラクト主導（contract-driven）」の開発戦略を使用することが多い。そのような場合、コントラクトが関係するものの間で合意されると、様々なエンドポイントのビジネスロジックに従うようにウェブサービスの特定の実装を作成することができる。既存のツールは、ウェブサービスコントラクトに基づいて、「スケルトン（skeleton）」ウェブサービス実装（web service implementation）の生成を可能にし、次いで、開発者が、サービスによって提供される各操作に関するビジネスロジックの詳細を完成させることを可能にする。典型的に、そのようなスケルトン実装は、コントラクトによって定義される各操作のためのメソッド（method）を有するサービスのためのクラス（class）を備える。さらに、各メソッドのシグネチャ（method's signature）は、操作によって送信および／または返信されるメッセージを記述し、シグネチャにおいて参照されるメッセージデータ構造を記述するために必要な場合に作成される追加的なクラスを有する。

しかし、多くの場合、ウェブサービスコントラクトは、ウェブサービス実装が開始された後で変化する。例えば、コントラクトは、新しいまたは修正されたビジネス要件を満たすために、あるいは開発者が反復的または追加的な開発戦略（iterative or incremental development strategy）を使用する場合に変更を必要とすることがある。したがって、ウェブサービスコントラクトに対する変更は典型的に、更新されたサービスコントラクトに準拠するために、スケルトン（メソッド、シグネチャ、およびクラスまたはデータ構造）とビジネスロジックの両方に対する変更を必要とする。しかし、現在のツールは、コントラクトに対する変更に対応するウェブサービス実装の更新をサポートしない。

したがって、開発者は、更新されたウェブサービスコントラクトに準拠するためのウェブサービス実装の修正に利用可能なオプションをわずかしか有しない。例えば、開発者は典型的に、（１）既存のツール（例えば、スケルトンツール）を使用して、訂正されたコントラクトから新しいサービス実装を再作成し、それらの開発者が残したい前のサービス実装の態様を手動で移行するか、または（２）既存の実装コードを手動で編集して、訂正されたコントラクトに準拠するために必要な変更を行う。変更の範囲に応じて、両方のアプローチとも大きな労働力を要し（labor intensive）、人為ミスを被りやすい。さらに、これらのアプローチは、開発者が、変更の本質、およびどのようにこの変更をそれらの実装にマッピングするかを理解するように、開発者が、使用されるＮＰＤＬ言語（例えば、ＷＳＤＬ）および／またはスキーマ（例えば、ＸＭＬスキーマ）の詳細な知識を有することを必要とすることがある。しかし、そのような言語およびスキーマの複雑性のために、そのような修正は、ほとんどの開発者の典型的なスキルの範囲を超えている。

コントラクトの変更に応じてサービス実装を修正するための現在のメカニズムについて、上記で特定された欠陥および欠点を、本明細書で開示される実施形態の例を通じて克服する。

この「課題を解決するための手段」は、「発明を実施するための最良の形態」において以下でさらに説明される概念の選択を簡素化された形式で紹介するために提供されることに留意されたい。この「課題を解決するための手段」は、特許請求の範囲に記載された対象の重要な特徴または本質的な特徴を特定するように意図されておらず、特許請求の範囲に記載された対象の範囲を決定する助けとして使用されるように意図されてもいない。

実施形態の一例は、ウェブサービスコントラクトドキュメント内の変更に応じてサービス実装の少なくとも一部分を自動的に変更することを提供する。この実施形態では、第１のウェブサービスコントラクトドキュメントに従って構成されたウェブサービス実装が受け取られる。第１のウェブサービスコントラクトドキュメントは、ウェブサービス実装がサービスとどのように通信すべきかを記述する。さらに、第１のウェブサービスコントラクトドキュメントとは異なる、第２のウェブサービスコントラクトドキュメントも受け取られる。１つまたは複数の変更は、ウェブサービス実装が、実装されるべき第２のコントラクトを予期するエンドポイントと通信することができないようなやり方で、ウェブサービス実装の振舞いに影響を与える。その後、ウェブサービス実装と第２のコントラクトドキュメントの間の１つまたは複数の変更が特定される。この特定に基づいて、ウェブサービス実装の一部分が自動的に修正され、その結果、ウェブサービス実装は少なくとも部分的に第２のウェブサービスコントラクトドキュメントに準拠する。

本明細書で開示される実施形態のさらなる特徴および利点は、以下の記述で述べられ、その記述からある程度明らかになるか、または本発明の実施によって知ることができる。本明細書で開示される実施形態の特徴および利点を、添付の特許請求の範囲において特に示された機器および組合せを用いて、実現し、取得することができる。本明細書で開示される実施形態のこれらおよび他の特徴は、以下の記述および添付の特許請求の範囲からより完全に明らかになるか、または後に説明されるような本明細書で開示される実施形態の実施によって知ることができる。

本発明の上述および他の利点および特徴を取得することができる手法を説明するために、添付の図面に図示される本発明の具体的な実施形態を参照することによって、上で簡潔に記述された本発明をより具体的に記述する。これらの図面は、本発明の典型的な実施形態のみを示し、したがって本発明の範囲の限定するものとみなされるべきではないという理解の下で、本発明が添付の図面の使用を通じてさらなる具体性および詳細で記述され、説明される。

本発明は、ウェブサービスコントラクトドキュメントの変更に従って自動的にサービス実装を修正または更新するための方法、システム、およびコンピュータプログラム生成物にまで及ぶ。本発明の実施形態は、以下でより詳細に検討されるように種々のコンピュータハードウェアまたはモジュールを含む専用または汎用コンピュータを備えることができる。

実施形態の例は、既存のサービス実装の部分を更新するための自動化メカニズムを提供することによって、サービスコントラクトの変更に関連する問題に対処する。例えば、あるメカニズムは、ＮＰＤＬ（例えば、ＷＳＤＬ）コントラクトに対する変更に準拠するために、実装のスケルトン（例えば、メソッド、メソッドシグネチャ、データ構造など）を修正する。そのような実施形態では、開発者は通常、典型的にはコントラクトの定義から分からないビジネスロジックに対する必要な変更がもしあれば、その必要な変更を行うことをのみを必要とする。したがって、実装に対するそのような自動修正は、開発者がウェブサービス開発へのアプローチに基づいてコントラクトを採用することを容易にする。

例えば、実施形態の一例では、サービス実装、ウェブサービスによって使用されるクラスの型、ウェブサービスコントラクト、および／または他の入力情報（例えば、バインディングに関するマッピング情報）を入力として受け取る。ウェブサービスによって現在実装されているコントラクトと異なる特定のウェブサービスコントラクトを使用して、現在の実装は、そのクラス、クラス属性、メソッド、メソッド属性、メソッドシグネチャ、および他の種々のデータ構造またはプロパティが特定のコントラクトに準拠するように更新される。しかし、更新されたウェブサービス実装は、準拠された後、コンパイル（compile）または実行しない可能性があることに留意されたい。したがって、プロセスを完了するために、開発者は、行われた変更を調べ、以下の１つまたは複数を行う必要がある可能性がある。すなわち、（１）新しいコントラクトに存在するが、前のコントラクトにはない操作に対応する追加されたメソッドに、適切なビジネスロジックおよび／またはメソッド本体のコードを提供すること、（２）シグネチャが変化し、新しいまたは変更された振舞いを必要とし、ならびに／あるいはシグネチャ内で新しいおよび／または変更された型を参照するメソッドに必要とされるように、ビジネスロジックおよび／またはメソッド本体のコードを修正すること、（３）前に存在していた操作がコントラクトから除去された結果として、もはや操作にマッピングされないメソッドを任意的に除去すること、の１つまたは複数を行う必要がある可能性がある。

本明細書の実施形態は、有益な情報を含む可能性がある、またはユーザが何らかの他の状況において使用したいと望むことがある多大な取り組みの結果を表す可能性があるメソッドの部分（例えば、ユーザ作成ビジネスロジック）を、更新された実装に保存することを可能にする。例えば、実装内の変更が、リネームされる操作に起因する場合、保存されるメソッド本体のコードは、単に新しく名前が付けられたメソッドに移動されることを必要とする可能性がある。さらに、メソッドの保存は、メソッド、メソッド属性、メソッドシグネチャなどをコメントアウトする何らかの形態とすることができる。さらに、他の実施形態は、更新されたコントラクトに実装を準拠させるプロセス中のコメントの生成も可能にし、したがって開発者がサービス更新活動全体を完了するのに必要とされる作業を特定することをさらに容易にする。

有利な特徴に対するより具体的な言及を、図面に関して以下でより詳細に述べるが、本発明の範囲内の実施形態は、その媒体上に格納されたコンピュータ実行可能命令またはデータ構造を搬送または保有するためのコンピュータ読み取り可能な媒体も含む。そのようなコンピュータ読み取り可能な媒体は、汎用または専用コンピュータによってアクセスすることができる任意の利用可能な媒体とすることができる。限定ではなく例として、そのようなコンピュータ読み取り可能な媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶装置、あるいはコンピュータ実行可能命令またはデータ構造の形態で所望のプログラムコード手段を搬送または格納するのに使用することができ、汎用または専用コンピュータによってアクセスすることができる任意の他の媒体を含むことができる。情報が、ネットワークまたは別の通信接続（有線、無線、あるいは有線または無線の組合せ、のいずれか）を介してコンピュータに転送または提供されるとき、コンピュータは、この接続をコンピュータ読み取り可能な媒体として適切に表示する。したがって、任意のそのような接続は、コンピュータ読み取り可能な媒体と適切に呼ばれる。上記の媒体の組合せもコンピュータ読み取り可能な媒体の範囲に含まれるべきである。

コンピュータ実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、または専用処理デバイスにある機能または一群の機能を実行させる命令およびデータを備える。本発明の対象を、構造的特徴および／または方法の動作に特有の言葉で説明してきたが、添付の特許請求の範囲で定義される本発明の対象は、必ずしも上述の特定の特徴または動作に限定されないことを理解されたい。むしろ、上述の特定の特徴および動作は、特許請求の範囲を実装する例示の形態として開示される。

本明細書で使用される際、「モジュール」または「コンポーネント」という用語は、コンピューティングシステム上で実行するソフトウェアオブジェクトまたはルーチンを指すことがある。本明細書で説明される様々なコンポーネント、モジュール、エンジン、およびサービスは、コンピューティングシステム上で実行されるオブジェクトまたはプロセスとして（例えば、別個のスレッドとして）実装されることがある。本明細書で説明されるシステムおよび方法はソフトウェアで実装されることが好ましいが、ハードウェア、あるいはソフトウェアおよびハードウェアの組合せの実装も可能であり、考慮されている。この説明では、「コンピューティングエンティティ」は、本明細書で既に定義された任意のコンピューティングシステム、またはコンピューティングシステム上で実行する任意のモジュールもしくはモジュールの組合せとすることができる。

図１Ａは、更新されたウェブサービスコントラクトドキュメントに準拠するようにウェブサービス実装の少なくとも一部分を自動的に修正するためのコンピューティングシステム１００を図示する。コンピューティングシステム１００は、実施形態を実装するときに使用することができる様々なモジュールおよびコンポーネントを示す。これらの様々なモジュールおよびコンポーネントを、単一のモジュールに統合することができ、ソフトウェア、ハードウェア、またはそれらの組合せを使用して実装することができる。さらに、これらのモジュール／コンポーネントを、同じコンピュータに含めることができ、または任意の数のシステムに分散させることができる。当然、本明細書で説明される実施形態によって提供される機能を実行するための他の構成およびメカニズムも、これらの実施形態で利用可能である。したがって、コンピューティングシステム１００は、例示の目的のためだけに使用され、本明細書の実施形態の範囲を限定するか、あるいは狭めるようには意図されていない。

コンピューティングシステム１００のタイプまたは構成にかかわらず、コンピューティングシステム１００は、ウェブサービス実装が、サービスまたはサービスに提供されるエンドポイントとどのように通信すべきかを定義する（本明細書で交換可能に使用される）第１のコントラクトドキュメント１１０または第１の記述ドキュメント１１０を受け取り、あるいはこれにアクセスする（本明細書で使用される際、「エンドポイント」という用語は、クライアント、サービス、またはコントラクトに従ってサービスと通信するように構成される任意の他のエンティティを含み得ることに留意されたい）。上述のように、いくつかの実施形態において、第１のコントラクトドキュメント１１０を、ウェブサービス実装１３０の構築前に、１人または複数の開発者１７０によって合意および作成することができる。開発者１７０を、個人の開発者１７０、あるいは２人またはそれ以上の開発者１７０のチーム、あるいは企業のチームとみなすことができ、正確な数または構成は本明細書で説明される実施形態にとって重要ではない。さらに、（個々のまたは組み合わされた）上記エンティティの任意の１つが、開発者１７０によって生成されるように、記述された様々なドキュメントを生成することがある。

誰にまたはどのようにウェブサービスの記述１１０が作成されるかにかかわらず、第１のコントラクト１１０は典型的に、提供される１つまたは複数のサービスの振舞いを記述する。したがって、第１の記述１１０は、特に、提供される操作、交換されるメッセージのフォーマット、ならびに他のプロパティを記述する。このリストは、包括的でも網羅的でもないことを留意されたい。例えば、サービスの操作は、入力メッセージを受信するが、出力メッセージを返さないことがある。さらに、ここに列挙されていない他の振舞いおよびデータオブジェクトが、第１の（および他の）記述１１０内に存在することがある。したがって、本明細書で提供される振舞いおよびデータオブジェクトのリストは、例示のみを目的とし、明示的に特許請求の範囲に記載されない限り、実施形態の範囲を限定するか、あるいは狭めるようには意図されていない。

また、図１のウェブサービスコントラクトドキュメント（例えば、第１のコントラクトドキュメント１１０および第２のコントラクトドキュメント１４０）は、そのようなフォーマットの分野で広く使用されているのでＷＳＤＬコントラクトドキュメントとして指定されることがあることに留意されたい。しかし、上述のように、ＷＳＤＬは、ＮＰＤＬに関するフォーマットの一例に過ぎない。したがって、ＷＳＤＬの指定（WSDL designation）は、別途明示的に特許請求の範囲に記載されない限り、開示される実施形態または添付の特許請求の範囲の範囲を限定するために使用されてはならない。

それでもやはり、ウェブサービスコントラクト１１０を使用して、ウェブサービス実装１３０を作成することができる。例えば、構築モジュール１２０を使用して、第１のウェブサービスの記述１１０に含まれるデータを取得し、特定の実装１３０を作成することができる。図１Ｂに示されるように、ウェブサービス実装１３０は、サービスによって使用されるウェブサービスのクラス型１３２を含むことができ、このウェブサービスのクラスの型１３２は、自己に関連する様々なクラス属性１３１を有する。ウェブサービスのクラス１３２は、提供される様々なメソッド１３３を含むウェブサービスの実際の実装１３０を定義する。上述のように、ウェブサービスは、それらのウェブサービスがサービスコントラクト（例えば、第１のコントラクトドキュメント１１０）内で定義された操作を使用して受け取るメッセージの型を定義する。これらの操作は、ウェブサービス実装１３０内のウェブサービスのメソッド１３３のそれぞれと相互に関連がある。

各メソッド１３３は、そのメソッドに関連する様々なメソッド属性１３４、ならびに他のデータ構造およびプロパティ１３７を有する。さらに、メソッド１３３は典型的に、メソッド１３３のメソッド名、メソッド型、予想入力パラメータおよび／または戻り型などを定義するメソッドシグネチャ１３５も含む。さらに、以下でより詳細に説明されるように、メソッドシグネチャは典型的に、開発者１７０によって定義されるビジネスロジック１３６を含むであろう。当然、メッセージングフォーマット（例えば、ＳＯＡＰ）、バインディングプロトコルなどの他のプロパティを、メソッド１３３、メソッド属性１３４、メソッドシグネチャ１３５、および／または他のデータ構造もしくはプロパティ１３７内で定義することもできる。

限定ではなく例として、構築モジュール１２０を使用して作成されたウェブサービス実装１３０は、様々なクラス属性１３１およびメソッド１３３を有する「ａｒｉｔｈｍｅｔｉｃ（演算）」クラス型１３２とすることができる。例えば、この場合のメソッド１３３は、「ａｄｄｉｔｉｏｎ（加算）」、「ｓｕｂｔｒａｃｔｉｏｎ（減算）」、「ｍｕｌｔｉｐｌｉｃａｔｉｏｎ（乗算）」、「ｄｉｖｉｓｉｏｎ（除算）」などを含むことができる。メソッド属性１３４、メソッドシグネチャ１３５、ならびに他のデータ構造またはプロパティ１３７は、各メソッド１３３について、特定の操作の名前（例えば、ｄｉｖｉｄｅ）、メソッド型（例えば、ｄｉｖｉｓｉｏｎ）、入力に必要な整数の数（例えば、２）、結果として生じる出力の型（例えば、単一のＩＮＴ）、入力および／または出力の両方のフォーマット（例えば、ＳＯＡＰメッセージ）、ならびに任意の他の適切なプロパティを、さらに定義することができる。

サービスを実装するクラス型１３２のメソッド１３３は通常、ウェブサービスの定義（例えば、第１のコントラクトドキュメント１１０）の操作に自動的にマッピングされないことに留意されたい。例えば、典型的なツール（例えば、スケルトンモジュール１１２）は、特に、メソッド１３３、メソッド属性１３４、メソッドシグネチャ１３５、クラスの型１３２などを定義するスケルトンコード１１５を、完全な実装のために必要とされるビジネスロジック１３６なしに作成する。結果として、開発者１７０は典型的に、サービス定義においてどのメソッド１３２がサービス要求および応答として公開されるべきかを（例えば、ビジネスロジック入力モジュール１６５を使用して）手動で示すことが必要となる。さらに、開発者１７０は、サービスに関する第１のコントラクト１１０によって定義される各操作について、ビジネスロジック１３６の詳細を完成する必要がある。しかし、いくつかの実施形態において、スケルトンコード１１５を作成し、次にウェブサービス実装１３０を作成する中間段階のステップは任意的であることに留意されたい。

述べられたように、構築モジュール１２０は、ウェブサービス実装１３０を作成する。ウェブサービス実装１３０は、第１のＮＰＤＬ（例えば、ＷＳＤＬ）コントラクト１１０によって指示されるクラス、メソッド、メソッド属性、ウェブシグネチャ（web signatures）、メッセージ型などを含むことができ、ウェブサービスの振舞いを実装する特定のビジネスコードも含むことができる。コンパイルされると、ウェブサービス実装１３０は、ＮＰＤＬコントラクトによって指示された振舞いを実行しなければならない。

ウェブサービス実装１３０がどのように作成されるかにかかわらず、上述のように、第１のサービスコントラクト１１０は、ウェブサービス実装１３０が作成された後に変化することがある。例えば、開発者１７０は、第１のサービスコントラクト１１０を更新し、修正し、あるいは完全に置き換える第２のサービスコントラクト１４０を作成することができる。これらの変更には、特に、提供される操作、交換されるメッセージのフォーマット、ならびに他のプロパティに対する変更を含めることができる。したがって、第１のコントラクト１１０を使用して生成されたウェブサービス実装１３０を使用するエンドポイントは、第２のコントラクト１４０内で特定されたサービスともはや通信することができない可能性がある。（しかし、いくつかの場合、第１のコントラクト１１０に対する変更は、元のサービス実装１３０を使用するエンドポイントが第２のコントラクト１４０で提供されるサービスと通信することができないことを必ずしも意味しないことに留意されたい。）

例えば、「ａｒｉｔｈｍｅｔｉｃ」クラス型の上記の例では、開発者は続いて、入力の数および／または型を変更することがある。例えば、第１のコントラクト１１０が、メソッド「ａｄｄｉｔｉｏｎ」が制限のない入力の配列を有することを可能にしたと想定する。開発者１７０は、サービス拒絶攻撃（denial of service attack）などがされやすい潜在的なセキュリティリスクを減少させるなどの理由、または任意の他の理由で、入力の数を制限したいことがある。したがって、開発者１７０は、制限された入力の配列、例えば、５つの明示的な数値型の引数（argument）だけを許可するように第１のコントラクト１１０を変更する（すなわち、第２のコントラクト１４０を作成する）ことができる。制限のない配列を有するように現在のウェブサービス実装１３０が作成された場合、５つを超える入力は、第２のコントラクト１４０に従ってもはやサービスと通信することはできない可能性がある。

したがって、実施形態の例は、ウェブサービス実装１３０と第２のコントラクト１４０の間の変更を自動的に評価し、実装１３０の少なくとも一部分を修正するために使用される準拠モジュール１５０を提供する。そのようなモジュール１５０は本質的に、第２のコントラクト１４０からクラスの新しいセットを作成して新しいクラスを実装１３０内の既存のクラスと比較して要求に応じて変更を行う差分システム（differencing system）を提供する。そのような変更は、例えば、実装のスケルトン（例えば、クラス、クラス属性、メソッド、メソッドシグネチャ、メソッド属性、データ構造など）が第２のコントラクト１４０に準拠することを保証する。例えば、比較モジュールが、ウェブサービス実装１３０、サービスによって現在および／または前に使用された型クラス（type class）１３５、更新されたまたは第２のサービスコントラクト１４０、ならびに／あるいは元のまたは第１のサービスコントラクト１１０、の１つまたは複数を入力として取得することができる。実装１３０（場合によっては、および／または第１のコントラクト１１０）と第２の１４０コントラクトの間で特定される変更に基づいて、ウェブサービス実装１３０の１つまたは複数の部分を修正して、元の実装１３０を第２のコントラクト１４０に準拠させるようにウェブサービス実装１６０を生成することができる。

実施形態の例は、実装１３０内のメソッドの部分（例えば、ビジネスロジック）が、典型的に修正された実装１６０に、未変更のままとなるように定めることに留意されたい。例えば、以下でより詳細に説明されるように、操作の除去により、対応するメソッドがコメントアウトされるか、あるいはフラグを立てられて、移動されることとなる可能性がある。したがって、修正された実装１６０は、コンパイルまたは実行しない可能性がある。したがって、プロセスを完了するために、開発者１７０は、ビジネスロジック入力モジュール１６５（または他のモジュール）を使用して、以下の１つまたは複数を行う必要がある可能性がある。すなわち、（１）新しいコントラクトに存在するが、前のコントラクトにはない操作に対応する追加されたメソッドに適切なビジネスロジックおよび／またはメソッド本体のコードを提供すること、（２）シグネチャが変化し、そして新しいまたは変更された振舞いを必要とし、ならびに／あるいはシグネチャ内で新しいおよび／または変更された型を参照するメソッドに対して必要とされるように、ビジネスロジックおよび／またはメソッド本体のコードを修正すること、（３）前に存在していた操作がコントラクトから除去された結果として、もはや操作にマッピングされないメソッドを任意的に除去すること、の１つまたは複数を行う必要がある。

修正された実装１６０のためのビジネスロジックが必要とされるか否かにかかわらず、サービス実装１３０を修正して第２のコントラクト１４０に準拠するために使用される入力は、様々である可能性がある。例えば、準拠モジュール１５０は典型的に、ウェブサービス実装１３０を入力として取得する必要がある。しかし、他の入力は、変更がどのように特定されるかに応じて変化する可能性がある。例えば、第２のサービスコントラクト１４０からの型クラス１３５を特定して、ウェブサービス実装１３０内のクラスと直接比較することができる。代替的または追加的に、第２のサービスコントラクト１４０のスケルトンコード１４５を、スケルトンモジュール１４２を使用して生成することができ、次いで、変更を特定するために、そのスケルトンコード１４５を、第１のコントラクト１１０のスケルトンコード１１５と比較することができる。

当然、ウェブサービス実装１３０と第２のサービスコントラクト１４０との間の変更を特定するための他の入力も利用可能であり、本明細書において意図される。例えば、以下でより詳細に説明されるように、修正されたサービス実装１６０を完成するのに必要とされる様々な仕様を決定するために、ユーザ入力または他のパラメータが必要とされる場合があり得る。したがって、図１Ａに示されるように、実施形態の例は、開発者１７０（または入力モジュール１４７内の何らかの自動化メカニズム）が、修正されたサービス実装１６０を生成するために、準拠モジュール１５０によって使用される（例えば、特定のバインディングのマッピングを指定する）他のパラメータを定義することを可能にする入力モジュール１４７を提供する。したがって、実装１３０と第２のコントラクト１４０の間の変更を特定するために準拠モジュール１５０によって使用される任意の特定の入力は、本明細書では例示のみを目的として使用される。

実装１３０のほとんどどの部分も、第２のサービスコントラクト１４０に準拠するように自動的に修正または更新することができることにも留意されたい。例えば、クラス属性は変化しなかった可能性があるが、メソッド、メソッドシグネチャ、メソッド属性、または他のプロパティは変化した可能性がある。したがって、実施形態の例は、実装のスケルトン（すなわち、クラス型、クラス属性、メソッド、メソッド属性、（名前、型、パラメータ、ビジネスロジックなどを含む）メソッドシグネチャ、データ構造、または他のプロパティ）に起こるほとんどどの変更も特定するように構成される。したがって、修正された実装１３０の任意の特定の部分は、例示のみを目的として使用されており、明示的に特許請求の範囲に記載されない限り、実施形態の範囲を限定するか、あるいは狭めるようには意図されていない。

上述のように、本明細書の実施形態は、有益な情報を含む可能性があるか、またはユーザが何らかの他の状況において使用したいと望むことがある多大な取り組みの結果を表す可能性があるユーザ作成ビジネスロジックなどのメソッドの部分を、更新または修正された実装１６０に保存することを可能にする。例えば、実装１３０の変更が、操作がリネームされていることに起因する場合、保存されるメソッド本体のコードは、単に新しく名前が付けられたメソッドに移動されることを必要とする。メソッドのビジネスロジックまたは他の部分の保存は、あらゆる方法で起こり得ることに留意されたい。例えば、操作の名前の変更が、対応するメソッドのリネームを引き起こさない可能性がある。さらに、第１のコントラクト１１０からの操作の消去により、コメントアウト、属性の除去、またはメソッドがウェブサービスの操作として公開されるべきでないことを指定する他のマーク、あるいは除去されないように前のメソッドおよびそれに含まれるビジネスロジックをマーキングすること、が引き起こされる可能性がある。

さらに、他の実施形態は、修正された実装１６０を生成するプロセス中のコメントの挿入も可能にする。例えば、コメントは、変更が起こった日時、および／または何が変更を引き起こしたのかなどの情報を含むことができる。当然、他の情報を提供することもできる。それでもなお、追加的なコメントは、開発者１７０がサービス更新活動全体を完了するために必要とされる作業を特定することをさらに助ける。

本明細書に記載される実施形態をより完全に理解するために、図３は、本明細書に記載の実施形態を実践するのに使用することができる特定のシステムのフロー図を提供する。特定の問い合わせ（inquire）についての判定は、図に示される順序と異なる順序で行うことができることに留意されたい。さらに、特定の問い合わせも、やはり例示のみを目的として使用され、本明細書に記載の実施形態の範囲を限定するか、あるいは狭めるようには意図されていない。

図３に示される特定のロジックは、基本的には差分システムであり、その差分システムは、サービスコントラクトからクラスの新しいセットを作成し、次いで新しいクラスを実装内の既存のクラスと比較して、要求に応じて変更を行う。フローは、サービス実装に対する変更の様々な態様に順に対処する。例えば、第１に、フローは、更新されたサービスコントラクトのウェブサービスの仕様に準拠するように、ウェブサービスのクラスの属性を修正する。次いで、図は、各メッセージバインディング（例えば、ＳＯＡＰ）によって参照される各操作に対処し、ウェブメソッド属性（web method attribute）を示すマッチングメソッドがあることを保証し、他の全てのメソッドからそのウェブメソッド属性を除去する。次いで、図は、メッセージ定義において参照されるスキーマの型（例えば、ＸＭＬ）に対処し、選択可能なユーザオプションとして、データシリアル化クラス（data serialization classes）の置換のセットを作成するか、または既存のクラスを更新するかのいずれかを行う。

示されるように、システムは、最初に、ウェブサービス実装のウェブサービスバインディング名および／またはバインディング名前空間が、第２の／更新されたウェブサービスコントラクトと異なるかどうかを判定する（判断ブロック３０２）。ウェブサービスバインディング名および／またはバンディング名前空間が異なる場合（判断ブロック３０２で「はい」の場合）、システムは、ウェブサービスバインディング名および／またはバンディング名前空間を自動的に更新する（３０４）。しかし、開発者は、バインディング名および名前空間を維持するとしても、異なるサービス名の下でその振舞いを提供することを決めている可能性があるので、サービス名／名前空間は典型的に、更新されるべきではないことに留意されたい。振舞いの型を定義し、第２の／更新されたウェブサービスコントラクトとのマッチングのために使用されるのは、バインディング名および名前空間であり、サービス名ではない。

例えば、バインディング名およびバンディング名前空間が、デフォルトのＷｅｂＳｅｒｖｉｃｅ１およびｈｔｔｐ：／／ｔｅｍｐｕｒｉ．ｏｒｇから、ＧｏｌｆＣａｔａｌｏｇおよびｈｔｔｐ：／／ｃａｔａｌｏｇ．ｏｒｇに変化したと想定する。ウェブサービス実装では、以下のコード修正が自動的に起こり得る。
第２のウェブサービスコントラクトに準拠する前：

第２のウェブサービスコントラクトドキュメントに自動的に準拠した後：

上記の例において、サービス名はバインディング名および名前空間の更新によって変化しなかったことに留意されたい。

ウェブサービスバインディング名および名前空間を更新した後、システムは、新しいバンディング名を含むために古いバンディング名を含むウェブサービス実装のメソッドを自動的に更新することができる（３０６）。例えば、以下の擬似コードの修正は、バインディング名「ＷｅｂＳｅｒｖｉｃｅ１」を「ＧｏｌｆＣａｔａｌｏｇ」に変更した後、ウェブサービス実装で自動的に起こり得る。
第２のウェブサービスコントラクトに準拠する前：

第２のウェブサービスコントラクトドキュメントに自動的に準拠した後：

新しいバインディング名でメソッドを更新した後、あるいはウェブサービスバインディング名またはバインディング名前空間が第２のサービスコントラクトと異なっていなかった場合（判断ブロック３０２で「いいえ」の場合）、システムは、ウェブサービスコントラクトの操作名にマッチするウェブサービス実装の各メソッドに関して、第２の／更新されたサービスコントラクトの操作に準拠するようにメソッドのシグネチャおよび属性を更新する。第２の／更新されたコントラクトの各操作に関して、システムは、次いでウェブサービス実装のメソッドを、第２の／更新されたサービスコントラクトの操作と比較する（３０８）。例えば、メソッド名を操作名と比較することができる−以下でより詳細に検討されるように、１対１のバインディングの相関（binding correlation）を前提としている−。一致するものが存在する場合（判断ブロック３１６で「はい」の場合）、システムは、次いでメソッドがウェブサービスの操作として公開されているかどうかを判定する（判断ブロック３１０）。ウェブサービスの操作として公開されていない１つまたは複数のメソッドが存在する場合（判断ブロック３１０で「いいえ」の場合）、そのメソッドは、ウェブメソッド属性を公開されていないメソッドに追加することによって自動的に公開される（３１２）。これは、例えば、ウェブメソッド属性が定義されているインターフェースを使用し、ウェブメソッド属性をクラス自体に定義しなかったユーザのためのアップグレードシナリオに対応する。

一方、一致するメソッドが公開されている場合（判断ブロック３１０で「はい」の場合、および／またはブロック３１２で新しく公開されたサービスメソッドからの場合）、公開されたウェブメソッドの実装のメソッドのシグネチャおよび属性は、第２の／更新されたウェブサービスコントラクトに準拠するために更新される（３１８）。システムはメソッド／メッセージ名およびウェブメソッド属性を変更しない可能性があることに留意されたい。

例えば、第２の／更新されたウェブサービスコントラクトが、ｇｅｔＣａｔａｌｏｇ操作がＰｒｏｄｕｃｔＩｄをパラメータとして取り、Ｓｙｓｔｅｍ．Ｘｍｌ．Ｘｍｌｄｏｃｕｍｅｎｔを返すことを示した場合、以下の更新が自動的に起こり得る。

（例１）
第２のウェブサービスコントラクトに準拠する前：

第２のウェブサービスコントラクトドキュメントに自動的に準拠した後：

（例２）
第２のウェブサービスコントラクトに準拠する前：

第２のウェブサービスコントラクトドキュメントに自動的に準拠した後：

システムは、ウェブサービス実装の属性を自動的に更新することもできる。例えば、第２の／更新されたウェブサービスコントラクトドキュメントが、本体のスタイル（body style）はＲＰＣとするべきであり、Ｄｏｃｕｍｅｎｔとするべきでないことを示した場合、以下の更新が起こり得る。
第２のウェブサービスコントラクトに準拠する前：

第２のウェブサービスコントラクトドキュメントに自動的に準拠した後：

メソッドシグネチャは、文字列型または整数型などのプリミティブメッセージ型を含むことができ、それらは第２の／更新されたウェブサービスコントラクトドキュメントに準拠するように修正されると変更されやすいことに留意されたい。実装を更新する１つのやり方は、単にプリミティブ型を置き換えることとすることができる。しかし、開発者がプリミティブ型の固有の機能（unique functionality）を保存したいと望む可能性がある場合がある。したがって、実施形態は、システムが、シリアル化の一部として含まれることはないメッセージに属性を追加することを可能にし、その結果、メソッドが公開されないままになる。これは、その機能は、除去されないが、しかし修正されたウェブサービス実装内では実装されない間は他の開発者の使用に利用可能であることを保証する助けとなる。

判断ブロック３１６に戻ると、第２の／更新されたコントラクトの操作名がメソッド名と一致しない場合（判断ブロック３１６で「いいえ」の場合）、システムは、（ブロック３２６に示されるように）シグネチャとともにウェブメソッドを修正されたサービス実装に追加することによって、残りのメソッド（すなわち、更新されたコントラクト内の操作および／または元の実装内のメソッド）を自動的に公開する。

修正された実装内の全てのメソッドが公開されると（すなわち、判断ブロック３１８または３２６のいずれかを抜けると）、修正された実装内の各メソッドに関して、システムは、公開されたメソッドが、修正されたウェブサービス実装には存在するが、第２の／更新されたウェブサービスコントラクトドキュメントには存在しないかどうかを判定する（判断ブロック３２２）。公開されたメソッドが、修正されたウェブサービス実装に存在し、第２の／更新されたコントラクトにも存在する場合、システムは終了する（３２５）（判断ブロック３２２で「いいえ」の場合）。一方、公開された操作が、修正されたウェブサービス実装には存在するが、第２の／更新されたウェブサービスコントラクトドキュメントには存在しない場合（判断ブロック３２２で「はい」の場合）、ウェブメソッドの少なくとも一部分が保存される。例えば、メソッド、メソッド属性、メソッドシグネチャ、または他のデータ構造を、自動的にコメントアウトすることができ、その結果、メソッドがもはやウェブサービスの操作として公開されないことになる。代替として、メソッド、メソッド属性、メソッドシグネチャなどを別のやり方で除去し、将来の参照のために別の所に格納することができる。さらに、システムは、いつ、どうしてメソッドがそれ以上公開されなくなるのかを示す追加的なコメントを追加することができる。これは、対応するメソッドのシグネチャ、パラメータ、および／または任意の特定のビジネスロジックを有するウェブメソッドが、ウェブサービス実装から除去されず、しかし単にコンパイルされないことを保証する。

例えば、ｇｅｔＣａｔａｌｏｇ操作が自動的にコメントアウトされるとすると、以下の修正が起こり得る。
第２のウェブサービスコントラクトに準拠する前：

第２のウェブサービスコントラクトドキュメントに自動的に準拠した後：

いくつかの実施形態において、開発者は、次いで、修正されたウェブサービス実装を調べることができ、追加的な修正を行うことができる。例えば、修正されたウェブサービスがコンパイルまたは実行されると、１つまたは複数のエラーが発生する可能性がある。エラーを正すために、開発者は上述のように実装を修正することができる。

上述のように、上記のシステムは、修正された実装においてどのメソッドを公開すべきかをさらに定義するために、ユーザまたは他の自動化メカニズムのいずれかからのさらなる入力パラメータを必要とする可能性がある。例えば、上記の特定のシステムは、実装とコントラクトの間のバインディングの単一の特定のマッピングされた対、−すなわち、１対１の相関−を想定した。しかし、コントラクト（例えば、ＷＳＤＬドキュメント）は、コントラクトを実装にマッピングするときに複数のバインディング（各バインディングは、操作の別個のセットを定義する）を含む可能性がある。例えば、コントラクト内で複数のバージョンがサポートされる場合がある可能性があり、したがって、名前または名前空間が、例えばバージョン識別子を含む可能性がある（名前および／または名前空間に対するそのような変更は、バインディング内の任意の操作の振舞いまたはシグネチャに対して何らかの重大な変更が行われるときに典型的なことであることに留意されたい）。

したがって、同じ名前の操作が、異なるバインディングに生じる可能性があり、そのため操作名のマッピングのみでは不十分である可能性があるが、これは、バインディングが、名前および名前空間プロパティ、−これらは、コントラクト内にあり、実装コード内に属性として記録されるので、相関することができる−、によって完全に特定されるためである。操作（バインディング）の複数のセットがコントラクトにおいて定義されるような場合、システムは、これらのセットの名前の一部分のみ（すなわち、名前または名前空間のいずれか）が第１のコントラクトと第２のコントラクトの間で変化していた場合に、追加的な入力を必要とする可能性がある。そのような入力は、マッピングを指定することができる実装の修正の実行中の直接的なユーザ入力、または実行に対するパラメータとしてのいずれかの形態で提供される可能性がある。

換言すると、上述のシステムならびに以下で説明される実施形態は、下記の状況下で実行されることを必要とする可能性がある。すなわち、（１）コントラクトおよび実装が、それぞれ単一のバインディング（すなわち、１対１の相関）を有し、上記コントラクト内の上記バインディングおよびその操作が、名前および／または名前空間に関わりなく上記実装を準拠させるために使用される場合であって、（２）上記コントラクトおよび／または実装が複数のバインディングを有し、上記名前および名前空間が、行うべき準拠（conformance）に厳密に一致しなければならず（上記コントラクトにあり上記実装にはない任意のバインディングを、上記実装に追加することができるか、または、上記実装にあり上記コントラクトにはない任意のバインディングを、例えばコメントアウトすることによって除去すべきであり）、そして（３）上記コントラクトのどのバインディングを、上記実装のどのバインディングにマッピングすべきかを明示的に特定するマッピング命令が、（例えば、ユーザ入力または他の自動的なやり方を通じて）提供されている（マッピングされない任意のバインディングを、無視するか、（２）のように処理することができる）状況において実行されることを必要とする可能性がある。しかし、マッピングされたバインディングおよびマッピングされていないバインディングを処理する方法は、本明細書では例示のみを目的として使用され、明示的に特許請求の範囲に記載されない限りは本明細書に記載の実施形態の範囲を限定あるいは狭めてはならないことに留意されたい。

本明細書に記載の実施形態を、機能的ステップ（functional steps）および／または非機能的動作（non-functional acts）を含む方法に関して説明することもできる。以下のセクションのいくつかは、本発明の実践において実行されることがあるステップおよび／または動作の説明を提供する。通常、機能的ステップは、達成される結果に関して本発明を説明し、一方、非機能的動作は、特定の結果を得るためのより具体的な動作を説明する。機能的ステップおよび／または非機能的動作は、特定の順序で説明または特許請求の範囲に記載される可能性があるが、本発明は、ステップおよび／または動作のいずれかの特定の順序または組合せに必ずしも限定されない。さらに、特許請求の範囲の詳述−および図２に関する流れ図の以下の説明−におけるステップおよび／または動作の使用は、そのような用語についての特定の所望の使用を示すために使用される。

上述のように、図２は、本発明の種々の例示的実施形態に関する流れ図を図示する。図２の以下の説明は、場合によって図１Ａ、図１Ｂ、および図３からの対応する要素を指す。これらの図からの特定の要素に対して言及がなされる可能性があるが、そのような言及は、例示のみを目的として使用され、明示的に特許請求の範囲に記載されない限り、記載の実施形態の範囲を限定するか、あるいは狭めるようには意図されていない。

ここで図２に移ると、ウェブサービスコントラクトに対する変更に準拠するようにウェブサービス実装を自動的に修正するための方法２００の流れ図が図示されている。方法２００は、ウェブサービス実装の一部分を自動的に修正する（２１０）ためのステップを含む。例えば、準拠モジュール１５０を使用して、ウェブサービス実装１３０を自動的に修正することができる。そのような修正は典型的に、ウェブサービス実装１３０に含まれるメソッドの１つまたは複数の部分（例えば、ビジネスロジック）を保存する。さらに、そのような修正には、下記の１つまたは複数を含めることができる。すなわち、ウェブサービス実装のバインディング名または名前空間のいずれか１つが第２のウェブサービスコントラクト１４０と異なる場合に、ウェブサービス実装のバインディング名または名前空間を更新すること（３０４）と、第２のウェブサービスコントラクトドキュメント１４０に含まれない操作に関するウェブメソッドを保存すること（３２４）と、第２のウェブサービスコントラクトに含まれるがウェブサービス実装には含まれない操作に関するメソッドを、メソッドのシグネチャおよび属性とともに追加すること（３２６）と、操作に一致するウェブメソッドに関してメソッドシグネチャを修正すること（３１８）と、方法が操作として公開されるように属性をメソッドに追加することと、ならびに／あるいは、メソッドはもはや操作として公開されないがメソッドの内容は保存されるように、メソッドに対する属性を除去すること、の１つまたは複数を含めることができる。

２１０のためのステップには、第１のウェブサービスコントラクトドキュメントに従って構築されたウェブサービス実装を受け取る動作２０１が含まれる。例えば、ウェブサービス実装１３０を、準拠モジュール１５０によって受け取ることができる。ウェブサービス実装を、第１のサービスコントラクトドキュメント１１０に従って構築することができる。上述のように、第１のコントラクト１１０は典型的に、提供される１つまたは複数のサービスの振舞いを記述することとなる。したがって、第１の記述１１０は特に、提供される操作、交換されるメッセージのフォーマット、ならびにウェブサービス実装１３０がコンピューティングシステム１００の他のサービスとどのように通信すべきかを定義する他のプロパティを記述する。

２１０のためのステップには、第１のウェブサービスコントラクトドキュメントに対する変更を定義する第２のウェブサービスコントラクトドキュメントを受け取る動作２０２がさらに含まれる。例えば、準拠モジュール１５０は、第１のサービスコントラクト１１０の部分に対する変更を含む可能性がある第２のウェブサービスコントラクト１４０を受け取ることができる。そのような変更は、提供される操作、交換されるメッセージのフォーマット、ならびにウェブサービス実装１３０がコンピューティングシステム１００の他のサービスとどのように通信すべきかを定義する他のプロパティを変更することができる。変更は、ウェブサービス実装１３０が第２のサービスコントラクト１４０を実装するサービスを予期するエンドポイント（例えば、クライアント）と通信することができない可能性が高いようなやり方で、ウェブサービス実装１３０の振舞いに影響を与えることに留意されたい。さらに、第１のコントラクト１１０および第２のコントラクト１４０の両方とも、ＷＳＤＬなどの、何らかのＮＰＤＬの形態とすることできることに留意されたい。

２１０のためのステップには、ウェブサービス実装と第２のウェブサービスコントラクトとの間の変更を特定する動作２０３がさらに含まれる。例えば、準拠モジュール１５０、あるいはコンピューティングシステム１００の何らかの他のコンポーネントおよび／またはモジュールは、ウェブサービス実装１３０と第２のウェブサービスコントラクト１４０との間の変更を特定することができる。いくつかの実施形態では、既存のウェブサービス実装（例えば、ウェブサービス実装１３０）の部分に対する変更が、サービス実装を第２のウェブサービスコントラクトドキュメント（例えば、第２のサービスコントラクトドキュメント１４０）の部分と比較することによって特定される。当然、上述のように、変更を特定する他の方法も、本明細書において意図される。例えば、他の実施形態は、第２のウェブサービスコントラクト１４０に基づいて生成されたスケルトンコード１４５を使用して、ウェブサービス実装１３０または第１のウェブサービスコントラクト１１０に対する変更を特定するために、上記スケルトンコード１４５を、ウェブサービス実装１３０または第１のウェブサービスコントラクト１１０と比較することができる。いずれの場合でも、変更が特定されると、上述のように、準拠モジュール１５０は、修正されたウェブサービス実装１６０を生成することができる。

ビジネスロジック入力インターフェースまたはモジュール１６５を使用して、ウェブサービス実装１６０の修正された部分を公開するための他の実施形態が、さらに提供された。これにより、開発者１７０が下記のいくつかを行うことが可能になる。すなわち、第２のウェブサービスコントラクトドキュメント１４０に存在するが、第１のウェブサービスコントラクトドキュメント１１０にはない操作に対応するウェブサービス実装１３０に追加されたメソッドに、適切なビジネスロジックのコードを提供することと、第２のウェブサービスコントラクトドキュメント１４０に準拠するようにシグネチャまたはメッセージの型が修正されたメソッドに関する既存のビジネスロジックのコードを修正することと、第１のウェブサービスコントラクトドキュメント１１０に存在するが、第２のウェブサービスコントラクトドキュメント１４０にはない操作の結果として、もはや操作にマッピングされないウェブメソッドを除去すること、のいくつかを行うことが可能になる。

本発明の精神または本質的特徴から逸脱することなく、本発明を、他の特定の形態で実施することができる。説明された実施形態は、全ての点において例示的なものとしてのみみなされるべきであり、限定的なものとみなされるべきではない。したがって、本発明の範囲は、上記の説明ではなく添付の特許請求の範囲によって示される。特許請求の範囲の均等物の意味および範囲内に入る全ての変更は、特許請求の範囲に包含されるべきである。

実施形態の例にかかる、ウェブサービスコントラクトドキュメントに対する変更に応じてウェブサービス実装を自動的に修正するための分散コンピューティングシステムを示す図である。 サービス実装の例を示す図である。 実施形態の例にかかる、ウェブサービスコントラクトドキュメントに対する変更に応じてサービス実装を自動的に修正するための方法の流れ図である。 実施形態の例にかかる、ウェブサービスコントラクトドキュメントに対する変更に応じてサービス実装を自動的に修正する特定のシステムに関する詳細な流れ図である。

Claims (20)

1. サービス実装が特定のサービスとどのように通信すべきかを定義するウェブサービスコントラクトドキュメントの前記サービス実装を含むコンピューティングシステム内で、前記ウェブサービスコントラクトドキュメントの変更に応じて前記サービス実装の少なくとも一部分を自動的に変更する方法であって、
   ウェブサービス実装が１つまたは複数のサービスとどのように通信すべきかを記述する第１のウェブサービスコントラクトドキュメントに従って構築された前記ウェブサービス実装を受け取る動作と、
   前記ウェブサービス実装が、実装されるべき第２のコントラクトを予期する１つまたは複数のエンドポイントと通信することができないようなやり方で、前記ウェブサービス実装の振舞いに影響を与える前記第１のウェブサービスコントラクトに対する１つまたは複数の変更を定義する第２のウェブサービスコントラクトドキュメントを受け取る動作と、
   前記ウェブサービス実装と前記第２のウェブサービスコントラクトドキュメントとの間の前記１つまたは複数の変更を特定する動作と、
   前記１つまたは複数の特定された変更に基づいて、前記第２のウェブサービスコントラクトドキュメントに少なくとも部分的に準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正するためのステップと
   を含むことを特徴とする方法。
2. 前記ウェブサービス実装に対する前記１つまたは複数の変更を特定する前記動作は、
   前記ウェブサービス実装の１つまたは複数の部分を、前記第２のウェブサービスコントラクトドキュメントの１つまたは複数の部分と比較することを含むことを特徴とする請求項１に記載の方法。
3. 前記ウェブサービス実装の前記少なくとも一部分の前記修正は、前記ウェブサービス実装の前記少なくとも一部分に含まれる１つまたは複数のメソッドの１つまたは複数の部分を保存することを特徴とする請求項１に記載の方法。
4. 前記ウェブサービス実装に含まれる１つまたは複数のメソッドの前記１つまたは複数の部分は、前記ウェブサービス実装に含まれる１つまたは複数のメソッドの前記１つまたは複数の部分を自動的にコメントアウトすることによって保存されることを特徴とする請求項３に記載の方法。
5. 前記第２のウェブサービスコントラクトドキュメントに基づいてスケルトンコードを生成することと、
   前記ウェブサービス実装を前記スケルトンコードと比較することと、
   前記比較に基づいて、前記スケルトンコードに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することと
   をさらに含むことを特徴とする請求項１に記載の方法。
6. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することは、
   前記ウェブサービス実装のバインディング名またはバインディング名前空間のいずれか１つが前記第２ウェブサービスコントラクトと異なる場合、前記ウェブサービス実装のバインディング名またはバインディング名前空間を更新することを含むことを特徴とする請求項１に記載の方法。
7. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することは、
   前記第２のウェブサービスコントラクトドキュメントに含まれない操作に関するウェブメソッドを保存することを含むことを特徴とする請求項１に記載の方法。
8. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することは、
   前記第２のウェブサービスコントラクトには含まれるが前記ウェブサービス実装には含まれない操作に関してメソッドを、メソッドのシグネチャおよび属性とともに追加することをさらに含むことを特徴とする請求項１に記載の方法。
9. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することは、
   操作に一致するウェブメソッドに関するメソッドのシグネチャを修正することを含むことを特徴とする請求項１に記載の方法。
10. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することは、
    メソッドが操作として公開されるように前記メソッドに属性を追加することを含むことを特徴とする請求項１に記載の方法。
11. 前記第１のおよび第２のウェブサービスコントラクトドキュメントは、ウェブサービス記述言語（ＷＳＤＬ）ドキュメントであることを特徴とする請求項１に記載の方法。
12. 前記第２のウェブサービスコントラクトドキュメントには存在するが、前記第１のウェブサービスコントラクトドキュメントにはない操作に対応する、前記ウェブサービス実装に追加されたウェブメソッドに適切なビジネスロジックを提供することと、
    前記第２のウェブサービスコントラクトドキュメントに準拠するようにシグネチャまたはメソッドの型が修正されたウェブメソッドに関するビジネスロジックを修正することと、
    前記第１のウェブサービスコントラクトドキュメントには存在するが、前記第２のウェブサービスコントラクトドキュメントには存在しない操作の結果として、もはや前記操作にマッピングされないウェブメソッドを除去することと
    の少なくとも１つを開発者が行うことを可能にするためにビジネスロジック入力インターフェースを使用して前記ウェブサービス実装の前記修正された少なくとも一部分を公開することをさらに含むことを特徴とする請求項１に記載の方法。
13. ウェブサービス実装が特定のサービスとどのように通信すべきかを定義するウェブサービスコントラクトドキュメントの前記ウェブサービス実装を含むコンピューティングシステムにおいて使用するためのコンピュータプログラム生成物であって、前記ウェブサービスコントラクトドキュメントの変更に応じて前記ウェブサービス実装の少なくとも一部分を自動的に変更する方法の実装に使用され、前記コンピューティングシステムの１つまたは複数のプロセッサによって実行されると、
    ウェブサービス実装が１つまたは複数のサービスとどのように通信すべきかを記述する第１のウェブサービスコントラクトドキュメントに従って構築された前記ウェブサービス実装を受け取ることと、
    前記ウェブサービス実装が実装されるべき第２のコントラクトを予期する１つまたは複数のエンドポイントと通信することができないようなやり方で前記ウェブサービス実装の振舞いに影響を与える、前記第１のウェブサービスコントラクトに対する１つまたは複数の変更を定義する第２のウェブサービスコントラクトドキュメントを受け取ることと、
    前記ウェブサービス実装と前記第２のウェブサービスコントラクトドキュメントとの間の前記１つまたは複数の変更を特定することと、
    前記１つまたは複数の特定された変更に基づいて、前記第２のウェブサービスコントラクトドキュメントに少なくとも部分的に準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することと
    を前記コンピューティングシステムに実行させるコンピュータ実行可能な命令を格納した１つまたは複数のコンピュータ読み取り可能な媒体を含むことを特徴とする、コンピュータプログラム生成物。
14. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正するように構成される前記コンピュータが実行可能な命令は、
    バインディング名またはバインディング名前空間が前記第２のウェブサービスコントラクトと異なる場合は、ウェブサービスのバインディング属性を更新するように構成された命令をさらに含むことを特徴とする請求項１３に記載のコンピュータプログラム生成物。
15. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正するように構成される前記コンピュータが実行可能な命令は、
    前記第２のウェブサービスコントラクトドキュメントに含まれない操作に関するウェブメソッド属性をコメントアウトするように構成された命令をさらに含むことを特徴とする請求項１３に記載のコンピュータプログラム生成物。
16. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正するように構成される前記コンピュータが実行可能な命令は、
    前記第２のウェブサービスコントラクトには含まれるが、前記ウェブサービス実装には含まれない操作に関してウェブメソッドをメソッドのシグネチャおよび属性とともに追加するように構成された命令をさらに含むことを特徴とする請求項１３に記載のコンピュータプログラム生成物。
17. ウェブサービス実装が特定のサービスとどのように通信すべきかを定義するウェブサービスコントラクトドキュメントの前記ウェブサービス実装を含むコンピューティングシステム内で、前記ウェブサービスコントラクトドキュメントの変更に応じて前記サービス実装の少なくとも一部分を自動的に変更するための方法であって、
    前記ウェブサービス実装が１つまたは複数のサービスとどのように通信すべきかを記述する第１のウェブサービスコントラクトドキュメントに対する変更を特定することによって、第２のウェブサービスコントラクトに少なくとも部分的に準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正するためのステップであって、前記変更は、前記ウェブサービス実装が、実装されるべき前記第２のコントラクトを予期する１つまたは複数のエンドポイントと通信することができないようなやり方で、前記ウェブサービス実装の振舞いに影響を与える前記第２のウェブサービスコントラクト内で行われるステップ
    を含むことを特徴とする方法。
18. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することは、
    操作に一致するウェブメソッドに関するメソッドのシグネチャを修正することをさらに含むことを特徴とする請求項１７に記載の方法。
19. 前記第２のウェブサービスコントラクトドキュメントに準拠するように前記ウェブサービス実装の少なくとも一部分を自動的に修正することは、
    メソッドが前記ウェブサービス実装から除去されないが前記メソッドが操作として公開されないように、前記メソッドに対する属性を除去することを含むことを特徴とする請求項１７に記載の方法。
20. 前記第２のウェブサービスコントラクトドキュメントには存在するが前記第１のウェブサービスコントラクトドキュメントにはない操作に対応する、前記ウェブサービス実装に追加されたウェブメソッドに適切なビジネスロジックを提供することと、
    前記第２のウェブサービスコントラクトドキュメントに準拠するようにシグネチャまたはメソッドの型が修正されたウェブメソッドに関するビジネスロジックを修正することと、
    前記第１のウェブサービスコントラクトドキュメントには存在するが前記第２のウェブサービスコントラクトドキュメントには存在しない操作の結果として、前記操作にもはやマッピングされないウェブメソッドを除去することと
    の少なくとも１つを開発者が実行することを可能にするために、ビジネスロジック入力インターフェースを使用して前記ウェブサービス実装の前記修正された少なくとも一部分を公開することをさらに含むことを特徴とする請求項１７に記載の方法。

Images