简介

　　当今的企业都希望将SOA作为一种公开其应用程序和数据以便于用户使用的方法。通过采用SOA，企业资产（例如，业务流程应用程序或后端系统）可以由在这些资产公开的服务上构建的各种解决方案/应用程序使用。在这里，您可以将企业视为一组公开数据集或功能集并在其后封装业务逻辑的服务。

　　现在，使用现有开发工具在这些服务上构建解决方案非常容易。通过使用SOAP或WSDL之类的标准，不同的供应商可以提供在这些服务上进行公开和开发的工具。

　　当企业开发了一些解决方案之后，问题就开始暴露出来。以下是一些最常见的问题：

　　1.解决方案只能使用一次。它们只能与一个或一组预先定义的服务进行通信，并且解决方案本身难以重用。更改服务后需要重新构建/重新部署解决方案。

　　2.对服务所公开的内容的理解取决于人们的想法，而不是服务定义本身。当前的标准只涵盖了如何获得那些服务。

　　3.很难将不同的服务集合在一起。既没有预先定义的聚合机制，也没有关于一个服务如何与另一个服务相联系（服务彼此之间不了解）的定义。

　　4.按照大多数常见的用户标准来说，解决方案 UI 难以实现，而且通常很槽糕（除非进行巨额投资）。这是因为难以在一次性解决方案中模拟当前的应用程序 UI。

　　5.大多数用户都相当熟悉Office套件（Word、Excel、Outlook 等）之类的应用程序，但是当设计出一个新的应用程序/解决方案后，需要对他们进行培训，从而增加了此类部署的成本。

　　由于上述原因，我们需要一个在现有服务之上构建解决方案的更好的机制。

　　元数据方法

　　目前，Web服务公开了许多有关如何使用服务的信息，但在说明提供了哪种类型的信息或功能方面，却提供了非常少的帮助。Web服务通常会公开 WSDL，因此工具可以轻松地查明Web服务公开了哪些方法和参数，但是，至于在那些方法后定义了哪些业务实体、甚至这些方法可能会影响后端系统等方面，却提供了非常少的提示（例如，不会告知某个方法将更新后端系统）。看起来，WSDL 似乎不能充分表示当今服务所公开的内容。

　　我们推荐一组新的元数据，它可以与某个服务相关联，并说明该服务的用户（解决方案开发人员）将需要了解的内容。在这个新的元数据中，我们将公开以下概念：

　　1.实体 — 将封装一组数据或功能的抽象业务或用户定义。例如，我们可以有一个客户实体。

　　2.视图 — 与某个实体相关联的架构，它描述有关该实体的数据子集。例如，对于客户实体，我们可以拥有多个视图，例如，客户联系信息或客户财务信息。每个视图都符合特定的架构，它是给定上下文的实体表示形式。

　　3.关系 — 实体/视图可以与其他内容关联，这些关系应该在此元数据中描述。例如，客户实体可能与定单实体相关联。关系允许实体之间的导航，这只需执行元数据描述即可。然后，关系将描述如何从一个实体进入另一个实体。

　　4.引用 — 引用是指向一组信息的常用方式。它是一个架构，表示检索一段数据所需的最小信息集，例如，用于检索客户的客户ID。您可以用多种方式检索一段信息，例如，可以按名称、ID、SSN等检索客户。

　　5.操作 — 这是给定实体/视图可以操作的方法。您可以将GetCustomer、UpdateCustomer 或 ReleaseOrder 看作此类操作的示例。

　　描述现有服务的元数据只能解决一半问题。另一半（在这些服务上开发的解决方案）还需要元数据描述。我们相信，通过考虑最终用户可以执行的操作，您可以构建大多数解决方案。这些操作是在服务实体/视图上构建的，并在其上提供可操作性。客户操作肯定会有一个显示其数据的操作，可能还有一个更新数据的操作。操作说明应该将从服务检索的数据链接到将使用它的 UI 或解决方案功能。

　　信息桥框架

　　信息桥框架(IBF)就是Microsof对上述挑战和元数据方法作出的回答。IBF允许您通过Office应用程序连接LOB和后端系统，以及通过元数据方法在Web服务上创建解决方案。IBF可以实现以下操作：

　　1.为服务创建元数据描述

　　2.创建用于在服务上构建解决方案/应用程序的元数据基础结构

　　3.跨解决方案的高度可重用性

　　4.解决方案的轻松维护和部署

　　5.与Office应用程序的高度集成

　　6.只需对现有Office用户进行简单的培训

　　信息桥体系结构

　　IBF体系结构（如图1所示）包含以下组件：

　　a) 一个封装了LOB或后端系统并与IBF兼容的Web服务。我们将在下一部分（设计和开发 IBF 解决方案）中讨论兼容问题。

　　b) 一个包含服务和解决方案元数据的元数据库（元数据服务）。该库可将自身导出为提供对元数据的访问的Web服务。还有一个描述所有服务和解决方案的中央库。客户端将基于它们的权限下载该元数据的子集，以将其作为所需的执行基础。

　　c)IBF客户端引擎。这最后一个组件包含两个独特的组件：

　　a. 在需要时从元数据服务下载元数据并保留它的本地缓存的引擎。它还可以理解元数据，并基于当前的上下文执行元数据。它执行所有与UI不相关的操作，例如，SOAP调用、转换等。该组件是 UI 不可知的。

　　b.UI引擎，它是了解应用程序寄宿在何处（Word、Excel等）的部分，而且它将呈现UI，并提供特定于宿主应用程序的服务。它能够在宿主应用程序上创建一个抽象层，因此用IBF构建的解决方案不需要了解宿主应用程序之间的差异。

　　d) 元数据设计器是一个基于Visual Studio的工具，它允许编辑元数据并将其导入元数据服务。