松耦合并不只是使用一个公共的语法和一些协议，它还涉及一组共享语义的创建和管理。本周，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所指出的）。可追溯的人工实物，如服务接口定义或数据库模式，是成功开发本体的关键。