简介
当今的企业都希望将 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 或解决方案功能。
返回页首
文章来源于领测软件测试网 https://www.ltesting.net/
