引言

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

　　在面向服务的体系结构 (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 用语。在会计系统中，“客户”可能被定义为组织已经向其销售了产品的对象，而在市场营销系统中，可能被定义为组织想要向其销售产品的对象。这种混乱的核心在于确定使用哪一种“客户”定义。

　　语义互操作性模式

　　可以采用很多模式在 SOA 中实现语义互操作性。可以将其大致分为以下几类:

　　模式一:点对点语义集成

　　在此模式中，每个数据源都有其专有的语义，而且采用点对点的方式进行语义转换。例如，需要集成两个数据源 A 和 B 时，A 组和 B 组分别打印出自己的 ER 关系图，然后分析数据元素的含义，再进行从数据源 A 到数据源 B 的直接映射。我们以前面的示例为例，可以将帐单编制应用中的“BALANCE”列直接映射到会计应用中的“REMAINDER”列。当集成的数据源扩展到 4 个时，需要进行 6 组映射。如果一个数据源中的数据定义被更改，对其他系统的影响就会加倍，而且通常很难预测。无论您选择的技术多么先进，都不起作用，这个语义集成模式是混乱的，而且当数据源增加时，维护工作会变成您的噩梦。因此，它得到一个绰号“毛团”。此外，这也不容易实现对 IT 资产的重用。无论相信与否，许多 ESB 和 EII 项目仍然在 SOA 中进行点对点的语义集成。尽管如此，点对点集成不一定就是坏事。选择性地利用点对点语义集成，不但可以确保高性能，并可以创建一条“捷径”。

　　模式二:轮辐式语义集成

　　每个系统都有其专有的语义，但是被映射到一个逻辑数据模型，可以将此模型实例化为一个物理联合模型或规范消息模型。企业内部的语义互操作性通过轮辐式拓扑来实现，此轮辐式拓扑减少了冗余，并且降低了点对点集成的维护成本。体系结构设计良好的 ESB 通常使用此模式将消息映射到规范消息模型，从而实现语义互操作性。

　　模式三:主数据管理 (MDM) 模式

　　MDM 作为一个语义互操性模式出现，与由部门解决方案产生的数据竖井相对应。今天，典型的企业管理系统内存在多个版本的“事实”。MDM 系统连接各个异类信息源，并产生关键信息的唯一事实版本，例如联机事务处理(Online Transaction Processing，OLTP)和操作数据存储(Operational Data Store，ODS)系统中的客户和产品信息。关键信息可能为数据实例(如特定的客户)，也可能是元数据(如产品的规范)。MDM 系统使数据不再受单个业务应用或软件包供应商的约束，它是基于开放标准的系统。因此，会将数据完全作为公司资产对待并进行重用。MDM 系统的构建通常独立于现有系统，可降低对业务的显著影响;但是，遗留系统可能在经过一段时间后最终迁移到 MDM系统。MDM 模式与前两个模式之间有着明显的区别，因为 MDM 只保留一个版本的事实，而且有效地从逻辑和物理两个方面将各个不同的信息系统集成到了一起。利用 MDM 系统，各个公司可以获得切实的利益，如改善客户关系、减少新产品的上市时间、与遗留系统之间进行数据集成以及实现资产重用等。

　　模式四:行业信息模型

　　为了倡导行业内的语义互操作性，垂直行业标准化组织开发了行业特定的信息模型，其中通常包括 XML 消息和消息模式，也称为域信息模型(Domain Information Model，DIM);不过，也有些组织开发了关系数据模型。DIM 是典型的基于 XML 的模型，用于 B2B 环境中的信息交换。行业标准组织的成员都同意遵守这些规范，经常要求对规范的遵从性进行认证。例如，Association of Retail Technology Standards (ARTS) 针对零售行业，而 Agency Company Organization for Research and Development (ACORD) 则针对保险行业。DIM 提倡更高水平的语义互操作性，鼓励资产重用和公平的竞争环境，以便成员花费更少的时间、成本和精力来解决语义互操性问题。有些组织甚至采用行业标准模型作为其内部的企业逻辑模型和规范消息模型。

　　标准组织倾向于从水平和跨行业的角度来研究信息。例如，开放应用程序组(Open Applications Group，OAGi)是一个开放标准组织，负责构建用于 B2B 和应用程序到应用程序(Application-to-Application，A2A)集成的基于流程的 XML 标准，它的工作重点是如何改进应用集成的状态。另一个例子是 RosettaNet，它帮助各个行业的公司应对当今全球供应链的需求和挑战。它包括 RosettaNet 业务词典 (RosettaNet Business Dictionaries) 和 RosettaNet 技术词典 (RosettaNet Technical Dictionaries)。

　　模式五:语义 Web

　　语义 Web 跨越了应用、企业和行业之间的边界。语义 Web 将数据模型的各个元素链接和关联到一个通用的本体。它使用资源描述框架 (Resource Description Framework) 和 Web 本体语言 (Web Ontology Language)，允许在 Web 上共享和重用数据。

　　模式总结

　　我们已经讨论了用于实现语义互操作性的多个不同模式。语义互操作性的范围可能包括各个业务单位、企业以及同一个行业或跨行业的各个企业。语义互操作性的范围越大，其成果的长远可重用性会越高，但是也更加难以协调和达成一致。此外，单个公司的控制权将会减少，在自定义重用资产来适应其独特的业务需求和确定想要的功能方面会有所羁绊。正是由于这些原因，一些公司使用内部专有的数据模型来进行内部集成，并且将行业标准模型用于 B2B。

　　企业应以平衡的观点来考虑采用不同的语义互操作性模式所带来的利弊。以下是一些需要考虑的重要问题:五年后我们的业务战略将会是什么样的?IT 如何支持我们的业务远景?IT 组织的业务和监管环境是什么样的?IT 如何应对(甚至利用)变更?IT 能否利用各种活动来促进更高水平的资产重用，并尽可能降低维护成本和分担开发成本?哪一个信息集成模式是某种特定情况的最佳方法——数据联合、数据整合还是 EAI?

　　最佳实践

　　最佳实践一:建立一个研究语义互操作性的核心业务部

　　如前面的“无控制语义混乱”反模式中所述，人们对于语义将不可避免地有不同的理解。强制要求对 EDM 或企业分类法达成一致是不可取的，与此相比，促进不同参与者之间的合作并且协调文档的不一致通常是更为有效的方法。许多协作工具，如 Wikis、博客工具和群组软件都是十分优秀的工具，如果出现不能达成一致的情况，人们可以使用这些工具软件公开发表观点，处理差异并加以记录。以一个实际的情况为例，Semantic Interoperability Community of Practice (SICoP) 是由 Federal CIO Council 建立的一个团体组织，目的是为了在美国政府中实现语义互操作性。在一个大型机构中，存在数以万计的数据库、数百万的数据元素和文档。要形成一致通常是不可行的，也是不可能的。SICoP 可帮助人们一起更有效地协作。

　　最佳实践二:胸怀长远目标，以增量方式向战略远景靠近

　　成功的语义集成的关键在于胸怀长远目标，然后以增量方式向战略远景靠近。“胸怀长远目标”表示要制定战略远景，并且尽可能利用各种不同的活动，如 SOA、数据仓库操作和法规遵从。这些活动通常要求多个业务单位之间进行协作，并要求进行企业级的文化变更。一个战略性的、共同认可的远景不仅给各个参与者带来实实在在的好处，而且可以帮助赢得绝对必不可少的支持者。“以增量方式向战略远景靠近”表示要制定增量式的计划以实现远景目标，并且需要制定数据控制流程，以迭代的方式交付切实可见的成果，评估进度和不断地修改执行计划。总而言之，战略远景和良好的执行都是十分关键。

　　当企业迁移到 SOA 时，无论他们是否进行自顶向下或自底向上的服务分析，如果迁移工作还没有开始，此时都是考虑是否包含 EDM 和 MDM 的合适时机。上面的两个模式都提高了语义互操作性和数据质量，可保证数据服务的服务水平协议(Service-Level Agreement，SLA)，而且降低了总体拥有成本 (TCO)。它们可能对于实现 SOA 的承诺具有深远的影响;这个承诺即使用 IT 从长远的角度提高业务灵活性、增加收益和降低 TCO。

　　最佳实践三:重用语义集成资产

　　ESB 的一个主要功能是将消息从一种数据格式转换为另一种数据格式，以确保服务的使用者和服务的提供者能够互相通信。在 XSLT 文档中捕获的转换逻辑可以提供很多的重用好处。不仅可以供其他业务流程重用，ETL 和应用程序也可以对其进行重用。类似地，ETL 工具所使用的语义转换资产还可以公开为 Web 服务，以便由其他应用程序进行重用和调用。

　　最佳实践四:采用和参与行业标准

　　有许多处理语义互操作性的行业标准，其中包含了垂直行业和水平行业的数据和数据模型标准。采用和参与行业标准使公司能够利用整个行业的最佳实践，从而减少了语义互操作性的长期成本。

　　选择软件供应商时，一个重要的标准是确定其是否支持相应行业的 DIM、如何无缝地支持内部数据模型与 DIM 之间的集成以及如何管理后续的变更。为了促进更广泛的语义互操作性，IBM 已经成为各种行业标准的有力支持者。例如，2005 年 9 月，IBM 向 ACORD 无偿提供了 100 多个业务流程模型、模型定义以及其他行业信息。

　　结束语

　　IT 世界在不断地发生变化，因此，语义互操作性也是一个不断发展变化的目标。我们的第一个假设是，变化是不可避免的。业务方面永远不会出现一劳永逸的情况。业务始终需要对客户需求、趋势、经济情况、法律法规和竞争进行适应。我们的第二个假设是，我们处在一个信息时代，语义互操作性的挑战只会增加。除非我们确定了语义互操作性的反模式、模式和最佳实践，否则我们的决策就不能够有效地解决问题。我们的第三个假设是，世界是混乱的。我们力所能力的事情是创建或利用各种工具和方法，在一定范围内对混乱加以控制。语义互操作性实际只是一个秩序形式，我们将它运用于我们的世界，使我们能够控制混乱，并使普遍存在并不断增加的信息有意义。控制混乱还意味着我们需要清楚地理解我们的选项以及每个选项的成本和好处，并减少变更带来的不良后果。

　　希望本文所讨论的反模式、模式和最佳实践将帮助您为您的 SOA 工作选择合适的方法来实现语义互操作性。需要强调的是，使用单个模式、组或标准并不能解决语义互操作性中的所有问题。