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