信息桥体系结构
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 — 这是一个允许您通过更新后端系统来修改实体/视图内容的方法。它接受两个输入：对要更新的实体/视图的引用，以及要更新的数据。
<<上一页
1
2
3
下一页>>
