2

SOAPおよびWebサービスを使用したバージョン管理を理解しようとしています。私が見つけたものから、URLでこのようなことをすることは容認できるようです：

www.company.com/service/01-12-10/およびwww.company.com/service/03-08-10/およびwww.company.com/service/は最新バージョンをサポートしています。

このようにSOAP本体/ペイロードをバージョン管理するのではなく、これが進むべき道であることを理解しています。

[client]

someRequest = newRequest(){ ClientVersion = "1.0.0" };
webService.Go(someRequest);

[web service]

if request.ClientVersion == "1.0.0"
  do this code
else
  do this code

変更が加えられると、すべての条件が手に負えなくなることがわかります。また、Webメソッドの署名が削除された場合、これはケースを処理しません。ただし、最も重要なのは、これはサービス全体をバージョン管理するのではなく、本体だけをバージョン管理することです。

だから、私の質問は、バージョンを含めるようにURLを変更するだけで正しく理解できたのでしょうか？これは必要なすべての領域を網羅していますか？名前空間の競合が発生するようですが？名前空間も変更する必要がありますか？サービスをバージョン管理することの意味を理解しようとしています。拡大してください。

4

1 に答える 1

7

クライアントにバージョンパラメータを送信させることは、適切なバージョン番号を送信することをクライアントに期待できないため、通常は好ましくありません（Webサービスの複数のバージョンがある場合、バージョンXのペイロードを受信することになりますが、バージョンパラメータ値Y）。

このため、次のようなコントラクトスキーマの名前空間を使用してバージョンを適用することをお勧めします。

...
<types>
      <xs:schema xmlns="http://tempuri.org/v1"
                targetNamespace="http://tempuri.org/v1">
...

コントラクトに壊れやすい変更を加えると（操作の削除など）、既存のすべてのクライアントが壊れます。これは、基本的にWebサービスを呼び出せないようにして、役に立たないためです。

したがって、メジャーバージョンの変更がある場合は、次のように定義した新しいコントラクトを公開します。

...
<types>
      <xs:schema xmlns="http://tempuri.org/v2"
                targetNamespace="http://tempuri.org/v2">
...

v1今後のすべての新しいクライアントを使用しながら、既存のクライアントを引き続きサポートしv2ます（そして、幸いなことに、時間の経過とともにv1クライアントはに移行できますv2）。

複数のバージョンをサポートする必要がある場合は、基本的にエンドポイントを管理する必要があります。この時点で、2つの方法があります。

www.company.com/service/すべてのメッセージ（v1およびv2）を受信し、メッセージの名前空間に基づいて適切な実装にリダイレクトするファサードとして機能するような1つのエンドポイントを維持するか...

...バージョンを個別のエンドポイントとして直接公開すると、既存のクライアントはv1メッセージを受信する古いエンドポイントを使用し（多分www.company.com/v1/service/）、新しいクライアントはv2メッセージのみを受信する別の新しいエンドポイントを使用します（多分www.company.com/v2/service/）。

上記のセットアップは、Webサービスのさまざまなスケルトン実装を通じてクライアントに公開される（1つだけの）ビジネス実装で簡単です。スケルトンは、特定のペイロードパラメータをビジネスレイヤーの適切なパラメータに変換しますv1。v2このようにして、すべての呼び出しはビジネスレイヤーに収束します。ビジネスレイヤーは、この時点では通常、クライアントがどのバージョンであるかを気にしません。

それが今より明確になることを願っています...

于 2012-11-10T15:14:54.500 に答える