书摘和采访： jBPM开发者指南

最新推荐文章于 2020-03-10 15:51:35 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2020-03-10 15:51:35 发布

阅读量94

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89153560

版权

Mauricio的新书《jBPM开发者指南》对Java开发者提供了完整的jBPM编程指导，其中包含了大量的现实案例。

这本书为Java开发者提供了非常详细的jBPM导引。Mauricio首先介绍了业务流程，业务流程管理和面向图编程，接着展示了这些概念是如何由jBPM来实现的。这本书展示了许多jBPM 实现的内部细节，并对开发者如何在项目中更好的利用jBPM提供了实际的建议。虽然这本书主要是基于旧的jBPM3版本而不是最新的jBPM4版本而编写的，但其中许多讨论仍是适用于这一新发布的版本的。

对于那些不仅想要理解正式的jBPM语法，并且还想深入了解支撑jBPM的架构与实现的人们来说，这本书是一个很好的起点。而jBPM的开发总监Joram Barrez对该书的书评也值得参考。

Packt Publishing专为InfoQ读者提供了书摘，描述了jPDL语言的基本结构，这篇书摘是取自该书的《第4章：jPDL语言》。

InfoQ对Mauricio Salatino进行了采访，了解该书背后的创作动机以及他个人对于jBPM的使用经验。.

InfoQ：当谈论主流的业务流程管理时，你没有明确的谈到业务活动监控和流程仿真。你是否认为这些是BPM的重要元素之一呢？

MS：是的，对于所有的BPM实现来说，它们都是非常重要的概念和结果。我在这本书中没有包括相关的内容，是因为这本书是专注在当开发者转变到BPM模式这种思维的时候所走出的第一步。我这本书尝试解释一个开发者使用任何一个BPM框架时所要具备的所有概念。而我们运行了业务流程之后所进行的一切信息分析的工作实际上与业务分析和数据挖掘概念紧密的联系在一起。

InfoQ：在描述BPM历史的时候，你写到SOA的引入很大程度上对 BPM造成了混淆。你如何定义SOA与BPM之间的关系？

MS：我们可以将公共的BPM框架看作是编配面向对象架构内所有服务的一种粘合剂。我知道这种角度对于技术讨论来说是非常适合的。但如果我们将BPM作为一门学科来探讨，SOA与BPM毫无关联。我们必须明智的选择词汇，而不把术语与业务上下文混淆在一起。而这正是我这本书的一个根基之一：澄清BPM这一学科可用于任何地方，不管是使用不同的框架，或者仅仅使用纸和笔。

InfoQ：在你的书里你将BPEL定义为\"一种支持异构系统以Web服务标准进行通信的集成语言。\"这是否意味着你不认为BPEL是与jPDL类似的一种流程定义语言？此外，BPEL/SCA的绑定能简化了非Web服务部件的BPEL应用。你是否仍认为 BPEL是纯粹面向Web服务的呢？

MS：我认为BPEL是一种编配语言。它原本被理解为一种系统编配语言。BPEL是一种纯粹的技术语言，用于构建BPEL语言的语义与定义业务流程情况下的语义并不匹配。在这些业务情境中我们需要表达人们是如何进行日常工作的；它如何实现没有关系，不管选用什么语言或者是否使用Web服务。

InfoQ：你的书中描述GOP与OO的区别，你提到了开发流程，三层架构等等。你认为最主要的区别是什么？

MS：再次强调，从技术层面来比较的，也许你不觉得两种范式有什么区别。但如果你想要使用流程图来表示人员的工作，你就会发现流程将能更准确地描述活动顺序。在书中我还提到，当我们使用OO范式的时候，要在任何时间图形化地表示出我们的应用程序在哪里并不容易。而使用GOP，你可以明确的看到活动是如何地实时被执行的。当你需要向经理层报告所有的工作完成时，这一点非常重要。

InfoQ：在你的书中描述了几种实现决策句柄（decision handlers）的方案，包括决策句柄（decision handlers），表达式，等等。开发者在什么样的场合使用它们你有什么建议吗?

MS：在复杂的场景中我总是推荐使用决策句柄（decision handler）实现。这可让我们使用诸如JBoss Drools（一个接口引擎）这样的复杂工具来将传播流程执行的责任委派下去。责任的外部化将会使你的流程更容易维护并且保持其焦点。

InfoQ：你在书中写到“记住jBPM是一个框架，而不是BPM引擎。它工作的方式与这一概念相去甚远”，但只给出了一个例子——持久化（它工作的方式又正好跟 BPM引擎相似）。你能不能说明一下jBPM与BPM引擎的不同？

MS：jBPM，如同其它的BPM框架一样（OSWorkflow，Drools Flow等等），是无状态的框架。我们不需要有一个庞大的机器和重量级的服务器运行在它们里面。每个想要使用业务流程的应用会在其自己所掌控的内存片段里执行。对于长时间运行的流程，唯一的要求是一个可维护所有中间状态的数据库。通常，刚接触这一类框架的用户会认为他们将要在专门的机器上安装一个中心化的业务流程引擎，但对于jBPM而言恰恰相反。我们只需要一个数据库来处理长时间运行的流程。

InfoQ：尽管jBPM为用户表格定义提供了基本的支持，你在书中没有提及这一点。你是否不建议使用它？

MS：我通常建议定义和使用你自己创建的屏幕。这将提升用户交互和你的开发流程。基本上可以说这是因为你的UI开发者不需要去学习一种新技术，他们可以运用所熟知的东西，然后使用jBPM API来填充UI层所需要的所有信息。

InfoQ：你的书中也没有提及jBPM管理控制台。你觉得它是有用吗？

MS：我认为它仅对那些想要测试他们定义的流程的开发者而言有用。对于业务样例和生产环境我则一点也不推荐。如同我在前一个问题里所提到的那样，我认为创建你自己的管理工具和为你的终端用户开发定制的UI才是良好的选择。

InfoQ：在人工任务（human task）里，你没有讨论用户指派（assignment）的泳道（swimlane），这样做的原因是什么?

MS：并非如此，我不得不删减一部分内容，否则这本书可能有上千页。泳道是一个重要的概念，但随着BPMN2这样的标准出现，解释jBPM3当中的泳道这样的概念可能会对采用新标准的人们带来误导。我试图只阐释会被应用到这一框架新版本当中的概念。这也是我在初始的章节宣扬创建你自己的BPM框架的原因之一。

InfoQ：你描述了在jBPM中处理信息的2种方式——对象变量和基本变量。对于什么时候两者之间某个更适用，你能提供一点帮助决策的参考吗？

MS：解释这两种处理信息的方式，其目的是给予用户其在特定情况解决问题提供决策的灵活性。以我个人经验，我注意到人们在已经有现有的使用JPA或Hibernate进行持久化的实体定义的数据模型时，通常会选择使用对象。所有的流程控制变量（通常是布尔标识）都会以普通的基本变量类型来保存。从高层次的规则来看，我通常会说：