现在，使用现有开发工具在这些服务上构建解决方案非常容易。通过使用 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 用户进行简单的培训
1
2
3
下一页>>
