介绍：业务实体和业务实体定义语言

在新发布的文章《Data4BPM》中，IBM 的 Prabir Nandi、Dieter König、Simon Moser、Richard Hull、 Vlad Klicnik、 Shane Claussen、 Matthias Kloppmann 以及 John Vergo 引入了业务实体的概念，它是展现数据的业务视图的一种方法。 他们提出了两种新标准，一种是业务实体定义语言（BEDL），另一种是 BPEL4Data ，它们是针对带有业务实体的过程的整体设计和执行的标准。

据作者们所说：

在大多数业务过程管理工具套件中，数据多会被认为是后来添加的东西。 活动和它们的流程才是主要的抽象，而过程所操作的数据本质上是隐藏在过程变量中的。 数据的表现和聚合是在过程定义之外处理的，并通过一般的服务调用来实现。 这种只重视过程的方法忽略了业务操作分析中重要的数据视图，通常这会隐藏操作的关键因素，并导致在解决方案的生命周期中一直要进行昂贵的重构工作。

在文章中，他们推荐将数据实体作为过程设计中的“一等公民”，并且引入了业务实体：

… 它是关键的与业务相关的动态概念对象，当它们在企业的操作中传递时，就会被创建、发展，并且（一般会）归档。 在业务实体中，既包括针对数据的信息模型，这些数据是与处于生命周期中的业务对象相关的，还包括一个生命周期模型，它描述了在这些对象上启动和执行任务可能的方式和时间点。

文章提出了业务实体定义语言（BEDL），它会定义 BEDL 元模型和语法，并且还讨论了能够支持 BEDL 规范的运行时架构。 它还概述了 BPEL4Data——这是扩展 BPEL 标准的一种方法，这样就可以支持带有 BEDL 组件的明确的互操作。

文中提出 BEDL 是建立在业务实体（BE）概念之上的，而业务实体拥有四种主要的组件： 信息模型、生命周期模型、访问策略以及通知。 BE 类型的信息模型被指定为一组属性 / 值对，其中的 XML 模式会与每个属性相关联，它会决定相关值的结构。 并非所有属性都需要在 BE 中出现。 BE 的生命周期模型被指定为一种有穷状态机。 生命周期规范本身既不会提供可能会在指定的 BE 实例处于特定状态的时候执行的活动的相关细节，也不提供可能作为将 BE 实例从一种状态转换为另一种时执行的活动。 我们通常会用 BPEL 来说明它们，而 BPEL 是用来补充说明 BE 的定义的。 BE 访问策略关注两个方面： 针对修改 BE 的信息模型（或者该模型的一部分）的 CRUD 定义策略；针对生命周期模型转换的执行、定义策略。 BE 规范的最后部分是一些通知，它定义了可能与外部组织——例如其他过程——有关的 BE 活动（变化）。

支持 BEDL 的软件组件提供了一个接口，它使得外部组件能够触发下列功能：

• 请求 BE 类型的元数据——这是一个请求接口，允许获取它所支持的 BE 类型的模式。
• 访问业务实体实例的数据——这是一个 CRUD 接口，允许对 BE 的属性进行操作。 这个接口是 CRUD 权限的主体。
• 在 BE 实例上的查询——这是一个查询接口，允许获取所有满足查询的 BE 实例的引用。
• BE 的执行状态转换——这是一个控制接口，命令 BE 转移到不同的状态。 这个接口还包含了对 BE 实例的创建。 状态转换会受到 BE 生命周期和执行权限的影响。
• 加锁 / 解锁 BE 实例（的一部分）——这是支持对 BE 实例的并发控制的接口。
• 订阅 BE 实例类的数据和状态改变——这是一个接口，使我们可以订阅 BE 的数据和状态改变的通知。 这个接口会受 CRUD 权限的影响，同时会试图读取 BE 的变化。

文中还提供了一个实例，它是关于对 Courier Shipment 的 BE 类型的设计。

文章的作者设想了一个特定的 BE 运行时，它会负责管理与多个 BE 类型相关联的实例。 他们讨论了这样的运行时的两种形式：

• 在“绿色区域”案例中，BE 运行时会管理位于特定的数据存储中的实际的 BE 实例数据（既包含属性值，也包含实例状态）——BE 内容存储。 这种情况下的 BE 运行时负责执行数据访问策略，并且向 BE 订阅者发送通知。
• 在“棕色区域”案例中，他们假设大多数 BE 数据已经存储在遗留的应用程序中。 在这种情况下，BE 运行时不会复制数据，而是可以增加持久的存储，其中会保存可以被用来链接和关联数据的 BE 信息视图和数据的遗留应用程序视图。

尽管 BE 运行时为操作 BE 数据和状态提供了支持，但是它并没有为定义状态转换的执行提供任何支持。为了做到这一点，它会依赖外部过程——例如：基于 BPEL/BPMN 的过程、两层的 Web 应用程序、可以购买的应用程序，或者主数据管理的维护工作流，或者是基于 XPDL 的应用程序。

文中概述了使用 BE 的优势，如下：

• 用户满意 > - BE 方法填补了传统的自顶向下、以过程为中心的分解业务操作领域的方法的空白，对于带有大型端对端范围的业务过程，在开始进行设计活动的时候就拥有少量关键的业务实体，会为我们提供洞察力和清晰度，这在多级过程分解的复杂过程中是很难得的。

  • BE 方法使企业中不同部门之间的通信得到了本质上的提高，因为在很多情况下，BE 类型会覆盖多个部门，并为那些不同部门的利益关系者提供通用的词汇表。

• 估值的简单性、灵活性，并节省时间 > - 使用 BE 方法，即便是对于大型复杂的系统，我们也可以快速捕获关键的实体、状态以及改变状态的任务。

  • 方法迫使我们拥有简单（但完整）的开始，然后随着逐渐对需求进行建模，会对设计有螺旋上升式的发展，但总是会保持一致性和连贯性。
  • 业务实体的生命周期状态代表过程的里程碑和对业务实物的反应。

• 成本的降低 > - 因为在之前已经对大多数需求建模，之后只会有较少的重构和起伏。 这使得之后在解决方案的开发周期和部署、维护周期中需要更少的变更。

  • 过程是在实体生命周期中分解的。 这会提升过程定义的重用范围。 它还会让我们拥有设计中的敏捷性，因为变更会限制在过程片段中，而不会影响设计的其他部分。

数据建模肯定是过程定义中的重要部分，但是一般它用于企业的语义数据模型级。 正如文中所说，将这个想法扩展到 BE，是否能够真正更好地设计和实现过程，还有待观察。

查看英文原文： Introducing Business Entities and the Business Entity Definition Language