私のグループは初めて Web サービスに参入します。Web サービスとクライアントのバージョン管理の問題を制御する通常の方法は何ですか? IBM の RAD で提供されるウィザードを使用して、サービスとクライアントを生成しています。サービスとクライアントは十分に機能しますが、これらの管理がどのように今後の課題になるのか疑問に思っています.
-サービスが変更され、そのインターフェイスが変更されない場合、古いクライアントは違いを認識せず、正常に動作すると思います。
- 新しいプロパティをパラメーターに追加するためにサービスが変更された場合、その値を設定する必要がなければ、古いクライアントはそれで動作しますか?
- Web サービスの数が増え、クライアントを使用するアプリの数が増えるにつれて、人々は Web サービスのバージョン管理をどのように処理しますか? この種のベストプラクティスは何ですか?
私たちが使用するバージョン管理には 2 つのタイプがあります。クライアントに表示されるもの (パブリック) と表示されないもの (プライベート)。これは、クライアントが影響を受けているかどうかに関係なく (既に触れたこと) から生じます。
クライアントが影響を受ける場合、たとえば XSD スキーマ定義の変更や WS の機能の変更により、クライアントもエンドを変更する必要がある場合は、パブリック バージョンを変更します。WS コンテキスト ルートのバージョン番号をインクリメントします。これは、以前のバージョンとは異なる URL を持つことを意味します。また、以前の展開を上書きしないように、コード アーカイブ (この場合は war) にも公開バージョンがあることを確認してください。
たとえば、foo という名前の WS は公開バージョン 2 です。その URL はhttp://ourserver:8000/foo_2で、war ファイルは foo_2 と呼ばれます。XSD スキーマを変更したため、クライアントは変更に対応する必要があります。バージョンを更新し、URL はhttp://ourserver:8000/foo_3で、war ファイルは foo_3 と呼ばれるようになりました。以前のバージョンは引き続き存在しますが、クライアントはゆっくりと新しいバージョンに移行できます。
変更によってクライアントからのアクションが強制されない場合、これをプライベート バージョニングと呼びます。これは通常、公開バージョンと組み合わせて、プロジェクト名の一部として表示されます。前の例を使用すると、プライベート バージョン 5 とパブリック バージョン 2 の WS foo があります。このサービスのプロジェクトは WS_foo_2_5 と呼ばれます。ここで、受信データを保存する順序を変更します。これはクライアントには影響しないため、プライベート バージョンを変更します。実際には、プロジェクト WS_foo_2_6 があります。そこから foo_2 というコード アーカイブを作成し、URL を に設定してデプロイしますhttp://ourserver:8000/foo_2。このようにして、クライアント POV から何も変更せずにバージョンを変更しました。