当今的企业都希望将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) 就是 Microsoft 对上述挑战和元数据方法作出的回答。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 的工具，它允许编辑元数据并将其导入元数据服务。
设计和开发信息桥解决方案
在设计 IBF(信息桥框架)解决方案时，您必须将它分为三个截然不同的块(如图 2 所示)。一方面，您需要描述与 IBF 兼容的 Web 服务，该服务封装了您要提供给最终用户的后端应用程序功能。另一方面，您需要设计要提供给解决方案用户的 UI 和体验。最后一步是链接您使用 IBF 元数据构建的服务和 UI 解决方案。通过分开这三个阶段，您可以为其中的每个阶段分配不同的资源，然后以单独的方式操作，只需在它们共享的界面(或公共架构)上保持一致即可。
创建与 IBF 兼容的服务
IBF 需要可以提供数据以及与您的解决方案所需的数据进行交互的服务。IBF 目前支持两种类型的服务：Web 服务和 CLR 组件。Web 服务是公开后端数据最常用的方法，大多数 IBF 示例都将它们用于服务描述。如果您需要使数据脱机或者缓存(出于性能原因)CLR 实现，也是可以的。
在为 IBF 设计服务时，您应该记住，您是在构建用户使用的服务，因此您希望公开对用户有意义的数据和方法。
在构建这些服务时，您还需要知道几个概念：
实体 — 您可以将实体视为一个对用户有特殊意义并且可供用户操作的业务对象。实体的示例可以是客户、定单或机会。它们都有一些数据与之相关联，并且从用户的角度来看，它们是可以操作的。例如，客户实体可能包含与特定客户(名称、地址、位置等)相关联的数据，以及允许用户操作实体的方法，例如，UpdateCustomerInformation 或 SendEmailToCustomer。它可能还是一个通过关系(例如，CustomerOrders 或 CustomerOpportunities)到其他实体的起始点。
视图 — IBF 可以用不同的视图来分割实体。视图是与实体有关的信息子集。对于一个客户，您可能有客户联系信息视图和客户财务视图。
引用 — IBF 中的引用是唯一标识一个实体/视图实例的一段信息。对于前面的示例，引用可以是客户 ID 或客户名称(如果它允许您唯一标识客户)。
关系 — 某些实体/视图之间具有关系，我们构建的元数据应该描述这些关系。一个示例是客户与定单，因为您可以将客户与其定单相关联，以及将定单与其客户相关联。
基于前面的概念，在您构建服务时，您应该识别三种不同的方法：
Get — get 方法允许您通过传递 Reference 来为实体/视图检索数据。一个示例是名为 GetCustomerContactInformation 的方法，它将接受客户 ID Reference 参数。
Put — 这是一个允许您通过更新后端系统来修改实体/视图内容的方法。它接受两个输入：对要更新的实体/视图的引用，以及要更新的数据。
Act — 该方法允许执行与获得/更新实体/视图无关的操作，或者跨多个实体执行操作。
如果您理解了这些概念，就可以围绕它们来构建服务。服务将公开一组类型为 Get/Put/Act 的方法，为此还将为引用和视图(由 Get 操作返回的数据)定义架构。
为了完成服务，还必须公开描述前面解释的概念的 IBF 元数据。IBF 提供了可以从 Web 服务自动生成元数据的工具，这样您就可以通过标注围绕实体/视图公开的方法来增加元数据，并将它们映射到正确的引用。
内容导航
创建 UI 组件
IBF 允许您的文档包含指向后端数据的活动链接。这些文档通过智能标记或者获得文档的附加架构，来包含有关要获得哪些后端数据的信息。智能标记或架构中的元素节点将存储有关要指向哪些后端信息的信息。根据前面有关如何创建 IBF 服务的主题中的讨论，这些就是引用。例如，智能标记将包含对后端信息的引用。您的解决方案必须定义它希望这些智能标记如何插入文档，对此 IBF 提供/推荐了几种方法。您可以自动生成嵌入了智能标记的文档(如果电子邮件/文档由某些进程动态生成，这将十分有用);您可以使用智能标记识别器基于正则表达式来检测文本，或者在其中查找并动态插入智能标记;您还可以使用 IBF 中的内置搜索功能，让用户查找他们感兴趣的信息实例，并允许用户将它们粘贴到文档中。
剩下的 UI 部分就是要显示给用户的部分。IBF 提供了一个窗格方法，该方法可以宿主可由解决方案提供程序完全定义的区域。IBF 支持 .NET CLR 控件和 HTML 区域(以及这些区域的菜单)。创建一个 UI 实际上就是创建一个控件，以及实现一个将数据插入控件的界面。控件本身不需要知道如何获得数据，以及数据来自哪里。控件只需要知道所提供的数据类型。IBF 将在运行时动态实例化控件，并将正确的数据传递给控件。这就允许将数据的显示与获取数据的方式分离开来。根据前面的示例，您可以创建一个知道如何呈现客户信息的控件(它理解客户的架构，并且包含其名称、地址等)。
创建解决方案元数据
创建 IBF 解决方案的最后一步就是，创建将服务描述与为其定义的 UI 元素相链接的元数据。为了让您轻松地创建这些基于元数据的解决方案，IBF 提供了以下几个概念：
操作 — 从用户的观点来看，这些是可执行单元，并且可以包含服务和 UI 方法/操作。在前面的示例中，您应该有一个 DisplayInformation 操作，它使用 CustomerContactInformation 上的服务实体/视图，并将其链接到我们创建的、用于显示客户信息的用户控件。
转换 — 由于来自服务的数据和 UI 元素所需的数据可能不同，因此 IBF 允许您转换数据。XSL 转换、正则表达式或调用 CLR 组件都是受支持的数据转换方式。
关系 — 您的解决方案可以具有除该服务提供的关系之外的关系，还可以跨服务了解关系。例如，我可以将一个旧式应用程序中的客户与 CRM 系统中的客户相关联。
部署和安全
您可以将 IBF 视为元数据的中央库，作为解决方案动态部署的服务描述和 UI 元素将由 IBF 客户端组件使用。除了 IBF 客户端以外，不需要在客户端机器上安装其他任何代码/元数据。IBF 客户端组件可以连接到相应的元数据服务，以获得给定上下文所需的所有元数据和 UI 元素。在获得元数据描述和 UI 元素后，IBF 客户端组件将它们与服务方法调用一起执行，并根据需要来构建 UI 和用户体验。
由于 IBF 使用 CLR 组件进行 UI 呈现，因此它构建在 .NET 安全性之上，所有组件都动态下载并在本地缓存，并且在沙箱环境中执行，因而不会危害客户端机器。如果您需要让控件拥有更高级别的控制权，可以使用标准的 .NET 安全策略对这些控件进行签名，并提升它们的权限。
它为您的企业解决方案提供了一个健壮且无需部署的环境。
小结
通过将服务层与 UI 层分开，并经由元数据将它们链接在一起，IBF 可以允许高度抽象和重用您的服务和 UI 组件。它提供了一个功能非常强大的平台，用于指定企业中的后端资产，以及根据这些资产创建无需编码即可链接或组合的解决方案。在元数据驱动的方法中，该元数据方法添加了许多灵活性，并允许根据客户的情况进一步改进解决方案。IBF 提供了功能强大的 UI 结构，以帮助构建完整的 UI 体验以及与 Office 应用程序的集成。通过在 .NET 技术之上构建，它还为新的解决方案提供了一个安全且无需部署的环境。
网友评论