John Evdemon 在其最新的一篇帖子展示了针对 SOA，业界进行定义、重定义和自相矛盾的尝试。这些定义五花八门，无章可循。
首先是关于松耦合的大体定义：
随着 Web 服务和 SOA 的来临，我们正试图创建耦合更松的架构和系统。松耦合系统提供了许多好处，包括：支持运行时迟绑定或动态绑定到其它组件，可以化解组件结构中的差异，安全模型、协议和语义，从而对易变性进行了抽象。
接着，重用占据了舞台中央：
软件重用的核心思想并不是什么新东西，即从最初已经创建出的组件中获取更多价值。在 SOA 之前，由于组织内业务单位之间缺乏集中控制和沟通，导致相同的解决方案一再重复发明。为了确保组织内各业务单位不创建重复服务，SOA 干系人，如业务分析师和架构师，应该能够以一种广为人知和系统的方法来寻找现有服务并评估它们是否能够重用。
业界最后发现真正的重用实在是太复杂了并且并不是总能实现：
创建可重用服务要求对未来进行预测……服务创建者怎么可能准确地猜到未来应用的需求？“车到山前必有路”的想法非常难以实现真正的重用。加上，鼓励所创建组件可被其他小组重用的组织，即使有，也不多。
接着，它谈到了业务流程的松耦合：
硬连接流程应该是一种罪恶，我们要坚决地抵制它……松耦合将迫使我们反思业务活动的方方面面……它将对我们管理业务操作的方式产生深远影响。厚重的流程手册留下了对我们硬连接业务操作方式的遗嘱。预先指定全部活动的详细细节，然后监测所有活动来清除任何不符合标准的变化。尽可能地加固操作。松耦合业务流程的运转方式完全不同。
当 SOA 无能为力之时，事件驱动架构（EDA）成了（一个更流行的）SOA 替补。：
EDA 交付了 SOA 只是承诺却没有做到的松耦合。它并非同步的“命令并控制”类型的模式，而是其反面：异步的“发布并订阅”类型的模式。发布者和订阅者完全不知道对方的存在；在某种程度上，组件是松耦合的：它们只共享了消息的语义。
接下来，它谈到了业务 /IT 的对齐：
自从发迹于面向对象设计和基于组件的软件开发方法论，SOA 已经进入了理想的崇高领域。随着故事的发展，SOA 不单单是为重振 IT 而设计的了；它还成了能改变 IT 所服务于的业务的魔弹。
并且，最终它发现 SOA 跟技术没有任何瓜葛：
太令人震惊了；SOA 似乎是第一个对技术没要求的技术。大厂商们告诫说，只要你坚持走有 SOA 特色的架构基本路线不动摇，在技术上不管你做什么都没关系。
这些定义明显的不一致似乎是来自于以下几个因素：
- 和任何架构一样，SOA 相当复杂且涉及多个关注点。随着 SOA 实现经验的增加，架构师和开发者都发现，他们在实现中需要开始考虑更多的事情。这并非真的移动了门柱，而是意识到“操场”的真正尺寸。
- 相比起正确定义他们确实要做的东西，人们往往更关心变得“时髦”。考虑当前的 SOA 流行程度，许多东西被人为的拉入 SOA 领域并非是因为它们真的就属于那儿，而是因为术语引起了 CEO/CIO 的注意。这并非真的移动了门柱，而是使用流行词汇来引起管理层的更多注意。
- 人们往往把 SOA 架构和 SOA 平台 / 实现混为一谈。尽管 SOA 架构没有改变，但是平台 / 实现的门柱却总是在往更好地支持客户需求的方向移动。
查看英文原文： Moving the SOA Goalposts
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论