基于契约的SOA如何比定义的（远程访问）API更灵活？

我正在阅读一篇关于未来IT开发的策略，其中强调SOA的使用。我知道已经收集了一些关于SOA的文章，认为SOA是一个过时的流行词

作为程序员，我想理解为什么SOA应该比其他分布式计算架构更灵活

• SOA基于在总线上发布的服务。然而，每个服务消费者必须知道服务的重要性/语义，才能使用它。因此，必须修改客户端才能使用新服务
  例如，如果谷歌地图发布交通信息，我的应用程序会知道发布了什么，以什么格式等，但它不会让我的路线规划器神奇地获得利用这些数据的功能

• SOA是基于契约的。合同是否不仅仅是定义明确的（预先的、事后的）条件，可以由计算机自动检查
  （就像一个函数检查它的输入，并在用户文档中记录它期望的内容一样，只是将验证移到函数之外。）
  如果双方都必须再次履行合同，这将如何提高灵活性？数据不会仅仅因为发布就自动完成。如果合同发生变化，客户也必须进行修改

---

我不同意你问题中表达的许多观点
我不认为SOA是一个过时的时髦词。曾经有一段时间，很多人被小贩收买，然后卖了一张货物清单。这段时间结束了。如果你是这个意思，那我就接受。但是SOA是活的并且很好
我不同意SOA需要总线。重要的是将业务问题分解为服务，而不是总线
您关于客户必须了解服务语义才能使用它们的声明适用于所有分布式组件
每个分布式组件都基于契约。一个接口，无论如何表达，都是一个契约：“将这些参数传递给我，我保证我将返回这个值或执行这个函数。”如果契约发生了变化，那么客户端也必须这样做。在您自己的代码和分布式组件中也是如此
我认为SOA是一个赢家，因为它基于使用HTTP（互联网的有线协议）的分布式组件。它简单且开放，这是相对于其他技术（如CORBA、RMI或COM）的巨大优势
它代表了更高层次的抽象，这对开发人员来说总是一件好事。如果API定义良好且稳定，他们就不必担心复杂性。他们可以专注于从一系列服务中进行选择，这些服务很好地映射到他们的业务问题，并协调它们来设计新的解决方案
但这并没有什么魔力。API设计很难。选择SOA和使用契约并不能保证你能做好它

---

与开发SOAP服务的其他方法相比，“契约优先”的一个优点是它使“鸭子类型”成为可能。如果您从一个模式生成WSDL，那么您将用户与服务在幕后使用的对象模型的更改分离。如果您从对象模型生成模式和WSDL，那么这两者是紧密耦合的。在这个主题上，作者进行了很好的讨论。
SOA与XML-RPC（例如，也通过http）有什么不同？SOA是技术上分布式系统体系结构的商业术语吗？我认为XML-RPC可以被视为实现SOA的一种方法。我认为SOA是使用HTTP作为有线协议的分布式组件。REST使用直接HTTP；SOAP通过HTTP使用其特殊的XML；XML-RCP通过HTTP使用定制设计的XML。主题上的所有变化。