我正在阅读一份强调 SOA 使用的未来 IT 开发战略。我知道， SOA是网络上一些关于它的文章中的流行词。
作为程序员，我想了解为什么 SOA 应该比其他分布式计算架构更灵活？
SOA 基于在总线上发布的服务。但是，每个服务消费者都必须了解服务的意义/语义才能使用它。因此，必须修改客户端才能使用新服务。
例如，如果谷歌地图发布交通信息，我的应用程序会知道有什么发布，以什么格式等，但它不会让我的路线规划器神奇地获得利用这些数据的功能。
SOA 是基于契约的。合同是否不仅仅是明确定义的（前、后）条件，可以由计算机自动检查？
（就像一个函数检查它的输入，并在用户文档中记录它的期望，只是将验证移到函数之外。）
如果双方都必须再次履行合同，这将如何提高灵活性？数据不会因为发布就自动完成。如果合同发生变化，客户也必须修改。
我不同意你问题中表达的很多想法。
我不认为 SOA 是一个衰落的流行词。曾经有很多人被供应商带走并出售货物清单。那个时候结束了。如果这就是你的意思，那我就接受。但是 SOA 还活着并且很好。
我不同意 SOA 需要总线。重要的是把业务问题分解成服务，而不是总线。
您关于客户必须了解服务语义才能使用它们的陈述对于所有分布式组件都是正确的。
每个分布式组件都基于合约。一个接口，无论如何表达，都是一个契约：“把这些参数传给我，我保证我会返回这个值或者执行这个功能。” 如果合同发生变化，客户也必须如此。在您自己的代码和分布式组件中确实如此。
我认为 SOA 是赢家，因为它基于使用 HTTP（Internet 有线协议）的分布式组件。它简单且开放，与 CORBA、RMI 或 COM 等其他技术相比，这是一个巨大的优势。
它代表了更高层次的抽象，这对开发人员来说总是一件好事。如果 API 定义明确且稳定，他们就不必担心复杂性。他们可以专注于从能够很好地映射到他们的业务问题的服务菜单中进行选择，并协调它们以制定新的解决方案。
但它没有魔法。API 设计很难。选择 SOA 并使用合同并不能保证您会做得很好。
与其他开发 SOAP 服务的方法相比，“契约优先”的一个优势是它使“鸭子类型”成为可能。如果您从一个模式生成 WSDL，您就可以将用户与后台服务使用的对象模型的更改分离开来。如果您从对象模型生成模式和 WSDL，这两者是紧密耦合的。Spring Web 服务站点对此主题进行了很好的讨论。