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

在新发布的文章《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