Webサービスプロバイダは、新しいサービスバージョンを作成せずに実装の変更をどの程度制限する必要がありますか？ 1つは、契約が維持されている限り、サービスオーナーは必要に応じて実装を自由に更新する必要があるということです。スキーマは常に気密ではなく、契約を守っている間にサービス実装内の変更がサービスの出力に影響を与えることは予見できます。Webサービス実装の変更
実装の変更がコンシューマにどの程度通知されるべきですか？あなたのWebサービス実装への更新を消費者に通知することがその1つです。すべての下流の依存関係に対する実装の変更を追跡することはどれくらい実行可能ですか？変更が消費者に影響を与える可能性があることを知ったサービスオーナーは、新しいバージョンを作成する必要がありますか？そして、良い市民になり、他のすべての変化を消費者に通知してください。
質問がたくさんあり、すべての答えに合った1つのサイズがあるとは思えません。それはちょうど状況に依存する可能性があります。多分、これがSLAの目的です。
良い質問ですが、あなたはすでに回答していると思います。はい、これらの詳細はSLAにあります。なぜなら、契約/ WSDLが同じであれば、なぜサービスがその「消費者」に通知する必要があるのでしょうか？もちろん、サービスへの影響が応答時間とパフォーマンスに影響しない限り。たぶんサービスは、別の契約が導入されたとき（元に加えて）、消費者に通知するだろう。消費者は新しい機能を認識し、必要に応じてクライアントを調整することができます。
私はSLAは内部クライアントのために存在していない環境にいるので、不在のSLA、次は
多くの場合、お客様の状況によって異なります。一般的に言えば、いくつかの最優先事項があります。
サービス契約とスキーマはすべて、サービスとクライアントが共有するものです。契約やスキーマを変更しないサービス実装の変更（実装ロジックのバグ修正など）では、クライアントに通知する必要はなく、新しいバージョンと見なす必要もありません。
OTOHの場合、すべてのデータを1つの大きな文字列として渡したり、クライアントがサービスを消費するために広範な解釈を行わなければならないなど、構成が不適切で過度に緩い契約をしている場合は、契約を変更して（そしてそれを改善するために）それをすべての当事者に借りて、新しいバージョンのサービスとして公開する必要があります。
サービスはサービス間の疎結合を可能にするためによく使用されるため、サービスのすべてのクライアントを識別することは実用的ではなく、場合によっては可能でもありません。このような状況で新しいバージョンのサービスを作成するには、しばしばいくつかのガバナンス体の指示に従って、しばらくの間、複数のバージョンのサービスを維持する必要があります。
サービスの実装、実装の依存関係などの詳細を提供することで、クライアントが依存関係を取る可能性のある非契約関連の詳細を開示することで密接な連携を促します。これにより、クライアントが独立して変更するサービスの能力が制限されることがあります。
書籍「Web Service Contract Design and Versioning for SOA 」（Thomas Erl著）は、トピックに関する優れた資料であり、いくつかの一般的なシナリオについて詳しく説明しています。