松耦合并不只是使用一个公共的语法和一些协议，它还涉及一组共享语义的创建和管理。本周， Dave Linthicum 提供了关于服务建设的一组推荐，它们集中于抽象层 VS. 公共模式的想法：
1）你应该首先面对数据，定义一个公共数据或抽象层，这样服务就不会与特定的模式绑定在一起，而且还能享受数据使用的乐趣。我不会象推动抽象层那样力推公共模式。
2）抽象或公共模型应该象其它组件一样被测试。
3）不要将过多的把精力放在努力适应数据模型上，而应把精力放在跨越各服务领域的协议上，利用模式映射层为将来提供选择，以及向下面的数据层提供机动性。
David 的经验显示，在设计服务接口时，依赖一组公共模式可能被证明是僵化的，因为“它阻碍了这些服务分别地演变”。
SOA 就是要创建能在不同的环境中被重用的资产，在设计时环境往往是未知的，最大化 SOA 的好处就是让尽可能多的消费者最大化重用你的服务。但是，认为消费者总是处于采纳提供者观点的位置，或提供者与消费者总是采纳相同观点，都是天真的。即使今天是真的，但是随着时间变化，消费者和提供者可能不会处于同时向新版本接口演变立场。
即使仲裁没有明确的出现在 W3C 的 Web 服务架构中，SOA 的实践者很早就系统地使用它来取得更高层次的松耦合，使消费者和提供者之间分别地演变。不论你使用哪一种仲裁机制：发布 / 订阅，编制、多态接口…它将总是导致从消费者模式到提供者模式的转换，以及反向转换。这些转换可能由协调器来执行，或假定在消费者或提供者服务容器内发生。
既然这些转换是不可避免的，那么问题来了，你如何使这种转换从设计和运行角度来看都尽可能没有痛苦？顺便提一句，如果你打算使用独立于提供者和消费者接口的公共信息模型，并仍想要得到松耦合，那么这将导致两次转换，还不算你仍需将消息格式转换成被提供者和消费者实现所能消费的数据集合。
迈向更具管理性转换的第一步，是捕获包含在你消息中的信息语义，并从这些语义派生消费者和提供者接口。Dave 称之为“抽象层”，其他人则称之为标准数据模型（canonical data model）或本体（ontology）。在这个抽象层中，结构比起语义的正规化来说是次要的。这不是个新问题，David Webber，早在1998 就引入了业务编码的概念，用来正规化分级命名XML 格式并优雅地处理本地化。更近一些时候，UN/CEFACT 开发出了一套标准，帮助管理语义和数据格式：核心组件技术规范（Core Component Technical Specification）；其中一个概念是“上下文（context）”，它可让你管理跨越8 维的模式公共部分（如，它可以帮助管理德国汽车工业中的购买订单和美国半导体工业中的购买订单间的共同体）。
语义必须在严格的治理过程下被精确地管理，并被测试（正如Dave 所指出的）。可追溯的人工实物，如服务接口定义或数据库模式，是成功开发本体的关键。
以下是在面向服务架构中关于使用本体的细节：
a) 服务接口需要从本体设计（使用它们自己的结构，但是利用并仅利用本体语义）
b) 对于反复无常的消费者和提供者，在服务接口和本体间尽早建立可追溯性，对于转换的设计和实现是非常有用的，并且如果它们是从相同的本体设计，一些转换可以是自动的或直接被推断。
如果你打算开始摆弄这些概念，那么可以试试斯坦福大学开发的 protégé本体编辑器。
查看英文原文： Opinion: SOA doesn’t need a Common Information Model
评论