指南:服务数据封装
本指南描述应用于面向对象开发并将其扩展至服务的封装概念。它进一步描述了如何通过执行消息交换来与服务进行通信,介绍服务的隐喻为可能仅直接与已知“使者”交互的“权力机构”,而“使者”反过来又与使用者交互。
关系
主要描述

简介

在面向对象和基于组件的开发中,有一组组件代表驻留在共享数据库中的持久实体是常见的做法。事实上,许多 IT 组织经常都有一个包含企业中所用的所有持久元素的数据库模式。虽然这限制了一些组织取得成功,但对许多组织而言,尚未开发出共用的企业模式。这种方法失败有很多原因,许多是非技术原因,但与多个应用程序有关;跨组织边界访问、锁定和更改同样的共享数据是很难解决的问题。

在本指南中,我们将解决两个关系密切的问题:服务应该完全包含它所需的数据,以及服务之间唯一的信息共享应该通过消息交换来进行。

本指南提供有关“数据驱动的服务确定”这一主题的更多详细信息。

作为权力机构的服务

描述面向对象开发的概念时,最常用的一个术语是包括的概念,即对象应该包括其状态(私有数据)和其实施逻辑。在服务世界中,我们明确地将工件:服务(实施)概念从它的工件:服务规范中分离出来。本部分将满足包括状态的需求。此概念已被记录,最初在 [HELLAND] 中,最近在 [SESSIONS] 中,且侧重于自主开发因而更容易演进的系统。

文本内容中所述的图。

常用的类比 [HELLAND] 指的是申请您要使用代理的新保险。该代理负责帮助您填写申请表,并且通常通过访问策略和费率类型的数据来完成该任务。保险代理代表保险公司的权力机构充当使者。 事实上,保险公司可能只接受已批准的代理的策略应用程序。权力机构负责将最新的策略、费率和表单信息分发给代理和处理应用程序。但是,即使权力机构将策略信息提供给了代理,且代理已经权力机构认证,保险公司对应用程序所做的第一件事仍是彻底验证它,该权力机构仍然不信任使者。

以下部分更详细地概述了两个主要元素的角色。虽然这不是作为具体模式或规定方法提出的,但包含的原则对于考虑面向服务的解决方案还是很重要的。

权力机构的角色

权力机构是一种自主的服务;它只允许通过消息进行通信,一般认为这些消息由代表使用者执行操作的使者创建。权力机构是安全、自主的并完整地定义了数据边界。在权力机构之间或在权力机构和其他软件元素之间未共享任何数据源或其他持久数据。现在,有可能单个数据库服务器可以加强多个服务的持久性,但是每个权力机构的不同表空间或数据库容器确保数据的完整性、安全性等。

该模式的另一个关键方面是确保使者能充当合理的代理、他能用与权力机构的最少通信与使用者交互,以及权力机构会将某些参考数据的副本分发给使者以供他们在本地存储和使用。所以,在以上的保险示例中,会将可用策略、其需求、限制和价格的目录定期分发给代理。当然,重要的是代理能使用该信息,并且他们理解该信息是数据的副本,不一定是权力机构使用的数据,并且该信息可能已过时。它可以每个月更新一次,如果收到更新,使者可能无法处理新的应用程序或者它可以基于较早的数据处理它们。

如以上所述,使者代表权力机构的事实并不意味着在双方之间有任何形式的信任关系。要确保使者尚未被取代,在接受之前,将验证所有消息的语法、语义和策略。

权力机构的详细职责是:

  • 管理参考数据并将其分发给所有使者,明确标识数据的生效日期。
  • 管理事务数据的状态;所有事务都完全在内部管理。
  • 验证与使者的所有通信。

使者的角色

使者充当代理并可作为针对使用者的组件、基于因特网的组件或特别开发的组件查找,但重要的是它有管理参考数据所需的特点来填写权力机构进程发送的消息。它还负责管理针对事务的消息的本地副本。所以,例如,客户可以将自己标识为有现有的策略,这首先可以由使者进行查找以用某些信息预填充表单,现有策略的这个副本可以在应用程序完成事务期间由使者高速缓存。

通常,当权力机构和使用者之间的通信代表某些较复杂的事务时,将使用使者,使者现在能更有效地进行管理,如当前示例中的填写复杂的请求。今天在很多组织中都能看到此模式,其中处理订单和调度订单用于交付的订单履行系统通常多年都是同一系统。这些组织开始在 Web 上以交互方式销售产品时,Web 应用程序将充当使者,使者拥有产品目录的本地副本并帮助客户准备订单。当然,处理订单的不是 Web 应用程序;Web 应用程序将订单提交给现有系统。因为使者基于参考数据完成此订单,所以当订单不正确时期望订单不被拒绝是很合理的。另一方面,如前所述,现有的订单系统在接受订单前将验证该订单。

使者的详细职责是:

  • 充当代理,代表使用者,完成消息并与权力机构交互。
  • 适当时,代表使用者管理逻辑事务查询参考数据、填充消息并提交信息。
  • 管理参考数据的本地副本,按照权力机构的建议进行更新。
  • 按照权力机构的标识,对时间敏感数据管理高速缓存策略。

服务数据边界

通常,许多应用程序均开发为垂直集成的组件集(请参阅面向服务的体系结构概念以获得更多信息)。这往往导致应用程序具有很少的自然集成点。最常用的集成方法是让两个以上的应用程序共享一个公共的数据存储器(这主要是因为它听起来很简单)。因此,当库存和订单共享“产品”的概念时,它们正在访问数据库中相同的表。这导致了一系列关于并发和性能的潜在问题,并且由于现在结合了这些应用程序而形成了一些相互关系,这些问题和关系将影响应用程序各自的演进,并影响企业重新主管、重新开发或者只是更改其中一个应用程序的能力。

文本内容中所述的图。

对于面向服务解决方案的开发,我们建议服务管理特定的、有边界且相干的数据模型。所以,分析以上显示的两个应用程序的用途应该标识它们对数据的使用,以及如何能将数据分为由两个自主服务来管理。这并不是说数据模型分开时在它们之间没有任何相互联系。例如,库存和订单服务都将需要产品的公共定义以及存储库存和提供订单来源的位置。

处理这个问题的方法是为共享概念创建第三个服务(在此情况下,与产品目录服务相关)或者仅在一个新服务中管理概念。例如,位置将由库存进行逻辑管理。现在,发送至这些服务和从这些服务发送的消息将需要包含共享元素的标识,以便需要时可查询或检索它们。例如,在库存的情况下,位置当前管理的产品查询将返回产品标识列表(和一个假定的现有数量);如果需要产品的详细信息,则将从产品目录服务检索此标识。

显然,数据边界分析中的主要工作产品是数据模型。将需要为现有的数据库创建数据模型,并在物理数据模型或者最好是在逻辑数据模型中仔细地将数据模型分开。

作为数据视图的服务消息

如果所有数据都仅存储在服务中,并且拒绝服务以外的所有访问,则所有通信都必须通过在服务规范中标识的消息进行。但是,始终要注意重要的一点:因为这些消息代表查询和从数据库返回到使用者的数据,所以它们是服务拥有的专用数据副本。因此,它们可能实际上代表服务的旧状态。例如,通过查询产品“234”的现有数量,将返回一条消息,该消息标识位置“562”的数量为“12”。可是,如果另一个使用者从库存中取出 8 个项目,而原始使用者尝试获得 12 个项目,则操作将失败。

实际上,这是设计和传统事务管理的问题;由于服务和服务使用者的松散耦合特性,管理事务的范围和边界变得更加复杂或者至少更容易看见。因此,必须将消息同时作为数据视图和数据副本进行考虑。在很多地方(包括 SOA)编写了某些指导信息,用于描述消息如何明确确定自身的生存期和适用性。

此转换对面向服务解决方案所固有的基于消息方法的另一个影响是:我们现在可以重新侧重于将应用程序的一般数据模型集成到一般消息模型的构想。这意味着,只要可能,为服务规范定义的消息都将基于一般结构,很可能被分到可跨服务复用的内聚模式中。这是一个灵活得多的集成方法,它还与服务本身松散的耦合方法匹配。而且,服务实施中使用的大多数技术都包含技术、工具或运行时,它们在消息模式不完全匹配时提供消息转换功能。

有关更多信息(具体而言是关于消息租赁和高速缓存的更多信息),请参阅任务:消息设计

引用

[HELLAND] Fiefdoms and Emissaries,Pat Helland,Microsoft。

[SESSIONS] Software Fortresses: Modeling Enterprise Architectures,Roger Sessions,Addison Wesley,2003。