将 软件SOA 引入 Office 应用程序桌面

关键字：soa 简介

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

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

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

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

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

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

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

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

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

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

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

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

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

原文转自：http://www.ltesting.net