向 Web 服务添加方法：旧客户端是否需要更新 Web 引用？
ProductA 使用我们唯一的 Web 服务，它是与 ProductA 分开的部署。我们将两者部署到生产中。
后来，我们正在编写 ProductB。在此过程中，我们向我们唯一的网络服务添加了一种新方法。当 ProductA 发布时，这个新方法并不在 WSDL 中。我们在开发过程中不对 ProductA 进行任何更改。
当我们将 ProductB 部署到生产环境时，我们还将唯一 Web 服务的新版本部署（到生产环境）（到 ProductA 期望找到它的同一端点 URL）。我们不会将 ProductA 重新部署到生产环境中。
我们唯一的 Web 服务的 WSDL 在生产中已更改，但 ProductA 使用的方法的签名没有更改。他们仍然在 WSDL 中。
我们这样升级我们唯一的Web服务，ProductA会不会有什么问题呢？
如果 Web 服务的更改导致原始客户端的方法保持不变，您是否必须升级 Web 服务的客户端？
ProductA uses our only web service, which is a separate deployment from ProductA. We deploy both to production.
Later, we're writing ProductB. During that effort, we add a new method to our only web service. That new method wasn't in the WSDL when ProductA shipped. We make no changes to ProductA in development.
When we deploy ProductB to production, we also deploy (to production) the new version of our only web service (to the same endpoint URL where ProductA is expecting to find it). We don't re-deploy ProductA to production.
The WSDL for our only web service has changed in production, but the signatures of the methods being consumed by ProductA have not changed. They're still in the WSDL.
Will ProductA have any problems due to our upgrading our only web service in this way?
Do you have to upgrade a client of a webservice if the webservice changed in such a way that left the original client's methods unchanged?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
不需要。只要您保留产品 A 单独使用的方法，您就不必更新产品 A 的 WebReference 副本。
No. As long as you left the methods that Product A uses alone, you do not have to update Product A's copy of the WebReference.
只是为了向现有答案添加更多细节，需要对客户端代理进行相应更改的 Web 服务的唯一更改是：
添加新方法，或向类型添加新字段/属性，几乎总是非破坏性更改（不过，与客户端进行测试也没有什么坏处）。
当然，请记住，在重建之前，客户端实际上无法使用这些新方法或属性。但它不会破坏现有功能。
Just to add a little more detail to the existing answer, the only changes to a web service that require corresponding changes to the client proxy are:
Adding a new method, or adding new fields/properties to a type, are almost always non-breaking changes (still, it doesn't hurt to test with the client).
Keep in mind, of course, that the client won't actually be able to use those new methods or properties until they rebuild. But it won't break existing functionality.
通常我会说不。然而，我们有十分之一的客户在使用 JAX-WS 时遇到问题。他们收到这样的错误：
我相信它与此相关：
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom。 ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftwbs_devjaxws_exposewebmethod.html
其中表示：“最佳实践：每当收到更新了 WSDL 文件。”
然而，服务器端 WSDL 在运行时在我们的客户端实例中进行检查，因此一旦我们添加新方法，它就会失败。我不知道问题的具体情况或范围，但看来您可以编写一个 SOAP 客户端实现，该实现将破坏服务提供的 WSDL 中的新方法。
Normally I would say no. However, we have one out of 50+ clients that has problems with this using JAX-WS. They get an error like this:
I believe it is related to this:
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftwbs_devjaxws_exposewebmethod.html
Which says: "Best practice: Be sure to regenerate your client side artifacts any time you receive an updated WSDL file."
However, the server-side WSDL is checked at run-time in our clients instance so it fails as soon as we add a new method. I don't know the specifics or scope of the issue, but it appears you can write a SOAP client implementation that will break with new methods in the WSDL served up by the service.
虽然我同意不更新现有客户端的服务引用可能不会有任何问题，但您也应该问一下，如果您更新现有客户端的服务引用，将会出现什么问题。请务必也测试该场景。
尽管我们倾向于认为向服务添加方法只对服务器很重要，但请记住，当更新服务引用时，这实际上是在更改客户端的代码。
一些组织相信当客户端代码更改时测试客户端代码。
While I agree that there probably won't be any problem by not updating the service references of existing clients, you should also ask what problems there will be if you do update the service references of existing clients. Be sure to test that scenario as well.
Although we tend to think about adding method to the service as something that's only important on the server, keep in mind that when a service reference is updated, this is actually changing the code of the client.
Some organizations believe in testing client code when the client code changes.
我不想插话老化的线程，并且已经提出了许多关键点，但我想添加有关迁移框架的注释。从 .Net 2.0 一直迁移到 4.6 后，我有时会出现异常行为。我会详细说明具体错误，但它们是前一段时间的。
我还想补充一点，尽管有大部分评论，但我还是遇到了来自客户的许多问题，即使在进行了此处描述的最小更改之后，他们也没有升级 Web 引用。我可能会补充说，这可能是较新框架的结果。多年来，我在 MSDN 的许多地方读到，WSDL 应该始终重新生成。
实际上我一直在寻找一种自动执行此操作的技术。从而防止 Web 服务更新时客户端崩溃。我在那次搜索中绊倒了这条线索。
不是真正的答案，但这里的评论太长了。
I did not want to chime in on an aging thread, and many key points have been made already, but I wanted to add a note about migrating frameworks. I have had unusual behaviors at times, after migrating from .Net 2.0 up, all the way through 4.6. I would elaborate more on the specific errors, but they were some time ago.
I want to also add that, despite most of these comments, I have had numerous issues from clients that did NOT upgrade web references even after the minimal changes described here in. And I might add that this could be the result of the newer framework. I have read in numerous places in MSDN over the years that the WSDL should always be regenerated.
I've actually been looking for a technique to do this automatically. So as to prevent client side crashes when the web services do get updated. I tripped across this thread in that search.
Not really an answer but too long for a comment here.