解析在SOA中实现语义互操作性(1)

引言

语义学 关注的是含义的研究。语义互操作性 表示数据的含义可以明确地被人类和计算机程序理解，而且可以通过有意义的方式来处理该信息。语义集成 是指实现语义互操作性的方式，它可以被认为是信息集成的子集，其中包括数据访问、聚合、关联和转换等。

在面向服务的体系结构 (SOA) 中，语义互操作性可确保服务使用者和提供者可以通过一致、灵活的方式交换数据，这种方式能满足许多非功能性的要求 (Non-Functional Requirement，NFR)，如性能和伸缩性等，而不受所涉及的各种信息的限制。例如，帐单编制应用服务请求者需要获知客户余额“BALANCE”。同时，会计应用服务提供者提供名为“REMAINDER”的客户余额。实现语义互操作性的方法是，将帐单编制应用中的“BALANCE”映射到会计应用中的“REMAINDER”。

语义互操作性是 SOA 中的一个重要体系结构特性，因为它使服务的使用者和提供者能够交换有意义的信息，然后遵照这些信息进行操作。它是 SOA 的基础。没有了语义，数据只是一串串没有任何意义的二进制字节。如果没有语义互操作性，服务使用者和提供者可能误解和破坏数据，最终给 SOA 和业务带来负面影响。

广而言之，大多数信息集成都是对语义互操作性进行处理。问题在于，人们认为语义互操作性是理所当然的，并且很少在语义互操作性方面进行理性而明智的体系结构决策，因为语义解释、映射和转换通常与自主开发应用程序、企业应用程序集成 (Enterprise Application Integration，EAI) 和企业信息集成 (Enterprise Information Integration，EII) 联系在一起。因此，语义互操作性通常会在 SOA 的开发过程中被忽略。

本文的目标是使应用程序架构师和数据架构师认识到语义和语义互操作性的重要性，以便在构建新的基于 SOA 的解决方案或者将现有系统迁移到 SOA 时能够进行合理的决策。要想理解语义互操作性，我们首先必须了解其背后的各种技术和方法，这些技术和方法统称为语义谱。此外，反模式可提醒我们避免犯错。模式和最佳实践则为我们指明了正确的方向。.我们将首先讨论语义谱，然后讨论语义互操作性的模式、反模式和最佳实践。

语义谱

语义谱 描述了用于创建越来越精确的数据定义的一系列技术和方法。需要在精确度与模糊度之间求得平衡——并非总是精确度越高越好——还需要考虑很多因素，如时间、成本和工作量等。

为了定义数据元素，我们不仅需要考虑事物本身(数据实例)，还需要考虑事物的定义和描述(元数据)。因此，语义谱同时覆盖了数据和元数据。它包括词汇表、控制词汇、数据词典、数据模型、分类法和维基百科中的本体。例如，“数据词典”和“数据模型”与元数据相关;而词汇表、控制词汇和分类法则与数据实例相关。本体描述则同时覆盖了这两方面。不过，有些人认为词汇表和分类法也属于元数据的范畴。本文将不讨论数据与元数据的具体区分。

词汇表 是带有定义的术语列表。许多文档和书籍都在末尾列出了词汇表，以方便读者阅读相关内容。控制词汇 是特定方面的组织和团体人遵守的标准化术语列表。控制词汇的遵守可能是自愿的，也可能是强制性的。地区代码列表就是控制词汇。词汇表和控制词汇从开始出现书面语言就有了，通常被用作大众传播和语言框架的组成部分。

20 世纪实现数据数字化后，关系数据库被用作主要的数据持久性机制。数据词典 用于捕获不同数据元素的含义和表示形式，并就此进行交流，最常用于关系数据库。数据词典是一个重要的构件，它支持业务和 IT 社区之间进行有意义的交流。

数据模型 描述数据元素的结构。从 20 世纪 70 年代开始，早在发明统一建模语言(Universal Modeling Language，UML)之前，关系数据库社区就已经使用实体关系(Entity-Relationship，ER)图表来改进交流和简化开发工作。

为了应对日益复杂的异类数据库环境，人们意识到需要创建企业数据模型(Enterprise Data Model，EDM)。流行的观点认为 EDM 需要海量数据库来存储组织所处理的所有数据，但是事实上并非如此，EDM 仅仅是一个公共逻辑数据模型。它通常位于第二或第三范式。其他逻辑或物理数据模型(如 ESB、应用和数据仓库)都可以映射到这个公共逻辑数据模型。EDM 通常用作信息集成的参考模型，或者用作持久性数据库和数据仓库的基础。例如，IBM Insurance Information Warehouse (IIW) 中的企业模型就是一个 EDM 实现。EDM 允许支持数据企业视图，用以帮助降低数据冗余、提高数据质量以及加速项目的集成和新项目的开发。它还可以简化业务需求与数据模型之间的映射。

企业分类法 用于组织一套标准化的术语、概念、目录和关键词。它被组织成一个层次结构，以表示术语和概念的隶属关系，通常与内容管理、知识管理和搜索技术关联。

最后，根据 World Wide Web Consortium (W3C) 的说明，本体 定义用于描述和表示知识领域的术语。它指定有关领域的类(一般事物)的说明以及事物与属性(或特性)之间的关系。IEEE 下属的 Standard Upper Ontology Working Group 正在进行制定上层本体方面的工作，以支持数据互操作性、信息搜索和检索、自动推理和自然语言处理等计算机应用。

反模式

反模式一:无控制语义混乱

由于各种原因，语义互操作性很难实现。之所以出现此情况的原因示例如下:

• 我们不能简单地“拆除”和更换遗留资产。无论任何时候，组织在创建新的应用或者集成现有应用时，都不可避免地需要对遗留资产进行集成。许多企业的关键业务应用仍然运行的是 COBOL 或 CICS。通过查看 COBOL Copybook 来确定语义不是一项简单的任务。
• 由于合并、收购、法律法规、市场竞争和客户需求等各种原因，业务在不断发生变化。信息和应用集成永远不会百分之百的完整。
• 由于职务、经验和知识基础等方面的差异，人们不可避免地发现很难达成一致。 参与者数量越多，就越难达成一致。EDM 涉及各种业务单位和开发团队。人们发现采用竖井 (Silo) 方式构建应用和数据比较容易，而在多个团队参加的情况下则很难达成一致。
• 有些情况下，人们似乎表面上对某件事达成了一致，但是解释方法却各不相同。以采用行业标准的数据模型为例，很多模型十分模糊，而且可以套用不同的语义解释。人们可能将它们用于不同的目的，以此来维护行业标准的作用，而实际上则是违背了标准的初衷。
• 直接来自于开发人员的普及 XML 和 XSD 没有经过协调，因而只会导致语义混乱。

到目前为止，我们可能显得比较悲观，但是我们真正的主张是对语义混乱加以控制。语义混乱意味着所有人都定义自己的方案和词汇，而不遵守任何信息标准，也不考虑与系统的其他部分之间的语义互操作性。人们使用自己的术语，相互之间难以理解。系统是在竖井中构建的。

反模式二:目标过大

无控制语义混乱的另一个反面极端是目标过大。项目涉及许多参与者，而参与者之间很难达成一致。范围过于扩大，时间安排过长。由于计划过于雄心勃勃，强制应用和数据库仅遵从一个数据模型，这在过去造成了很多 EDM 失败。

反模式三:缺乏信息集成逻辑重用

有三种主要的信息集成模式可用于实现语义互操作性:数据联合、数据整合和企业应用集成(EAI)。

在实际中，企业内不同的部门通常擅长使用其中一种模式。例如，数据仓库和业务智能(Business Intelligence，BI)部门通常擅于使用数据整合模式，而业务应用部门则擅长使用 EAI 模式。如果没有跨团队协调和企业级长期战略，将很容易产生一个新的集成竖井集——业务应用程序组为了实现跨越异类数据源的语义互操作性而进行重复工作，而 BI 部门却早已经解决了这个数据仓库难题。由于采用了竖井工作方法，每个组的语义集成和数据处理逻辑可能略有不同。

反模式四:业务术语和定义混乱

通常情况下，业务用户将请求信息技术专业人员提供数据，以帮助他们利用业务术语和定义对业务进行分析，而这些业务术语和定义在不同的部门可能差别很大。例如，一个部门定义的“客户”可能与另一个部门的定义存在很大的差异。IT 专业人员必须将这些业务术语逐一转换成为已知的 ER 或 UML 用语。在会计系统中，“客户”可能被定义为组织已经向其销售了产品的对象，而在市场营销系统中，可能被定义为组织想要向其销售产品的对象。这种混乱的核心在于确定使用哪一种“客户”定义。