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