基于区块链的业务流程互操作服务框架

唐玄昭，余 阳，吴荆璞，潘茂林

(中山大学 数据科学与计算机学院，广东 广州 510006)

0 引言

业务流程协同，如供应链协同，可以帮助企业充分利用供应商和客户的资源，产生协同优势。借助这种优势，企业可以达到更好的绩效[1]。但当这种协同发生在组织之间时，协同方之间的信任问题将阻碍供应链的创新，从而间接或直接地影响供应链的绩效[2]。解决信任问题的一个重要的方法就是事先对业务流程协同达成共识，但该方法要求在执行过程中有一个可信的第三方来控制跨组织的业务流程协同的进行。因此，这种方式仍然建立在对第三方信任的基础上，并不能很好地解决信任问题。

区块链技术的出现则有助于解决信任问题。无需借助第三方组织，区块链就可以保证协同过程产生的数据不可篡改。这是因为区块链的概念起源于比特币[3]，存储在区块链上的数据被打包成块并通过链的方式组织成一个记账账本或记录序列，从而确保存储在其上的数据很难被修改。而后随着智能合约的出现，用户可以通过编码的方式自动地转移存储在区块链上的资源[4]。因此，可以借助智能合约确保业务流程协同按照事先约定的顺序进行，并使用区块链对协同过程中产生的数据及协同的过程进行存储，从而保证协同的过程信息不可篡改，进而避免企业间的信任对协同效率的影响。

通常情况下，企业内部使用业务流程管理系统(Business Process Management System ，BPMS)对流程进行管理，本文使用工作流管理联盟(Workflow Management Coalition ,WfMC)提出的Wf-XML2.0协议，使得不同组织的BPMS可以通过该协议实现互操作，确保企业间合作可以自动化地进行。但由于该协议采用的是P2P(peer-to-peer)模式，意味着互操作双方直接交互，导致互操作的过程无法被客观地记录，这会在合作发生冲突时产生影响，从而降低企业之间的信任。除此之外，该模式也为多方合作带来了许多复杂性。因此，本文基于区块链对该协议进行了扩充，使得企业间的BPMS可以轻松地完成互操作，并保证可信性，从而提高企业间协同的效率，同时降低协同成本。

本文提出了一个标准的流程互操作服务框架，并使用了区块链技术来保证互操作过程透明可信。具体来说，使用区块链来提供流程互操作服务[5]，使本文提出的框架可以支持可信的流程互操作，为BPMS和区块链提供了操作代理，该代理使用WfMC提出的Wf-XML 2.0协议进行交互，同时屏蔽了区块链和企业内部BPMS的操作细节，以提供标准化的互操作方案，提高企业间协作的自动化水平。

1 相关工作

早期关于业务流程协同的研究中，WfMC提出了各种标准用以支持不同的工作流系统间的互操作。文献[6]中给出了工作流参考模型，其中包含了一个接口(接口四)用以支持互操作。文献[7]对接口四的功能进行了详细说明，随着Web技术的发展，新的互操作标准被提出，包括Wf-XML 2.0[8]，BPEL4WS以及WS-BPEL。这些方法将流程抽象成webservice，使得工作流管理系统的访问变得更加简便和标准，从而促进了互操作。

虽然这些模型和方法为流程互操作提供了可行的方案，但没有考虑到企业间合作可能存在的各种问题，其中包括信任问题，而后针对信任问题又有了一些深入的研究。文献[9-11]通过身份验证和授权、加密等方式来管理企业协同中资源的共享，通过保护隐私的方式来增强信任。文献[10, 12]通过提供信任评估的方法来帮助评估企业间的信任水平，使得企业可以选择更值得信任的合作对象。

区块链技术的出现，吸引了许多研究者来解决合作中可能存在的欺诈问题。文献[5]将业务流程建模标记 (Business Process Modeling Notation，BPMN) 语言编排图转化成智能合约，并使用区块链来记录协同中流程实例状态的变化，同时确保协同的有序执行。文献[13]提出一种基于动态数据结构的BPMN流程模型解释器，该方法不再基于模型生成智能合约，从而使得业务流程的执行更加灵活。区块链的加入使得业务流程协同的过程更加透明，从而增强了协同方之间的信任。但考虑到实际情况，跨组织的流程协同是通过各自BPMS之间的互操作完成的，而以上工作只提供了可信性的方法，却缺乏一个统一的互操作标准，同时并没有将区块链和互操作之间进行对应。因此，本文提供了一套标准化的框架来支持企业的BPMS间的互操作，并使用区块链技术来确保流程协同的可信性。

2 基于区块链的工作流引擎互操作服务框架

基于企业的BPMS，给出了一套完整的互操作框架，框架使用区块链来提供流程互操作服务，并使用Wf-XML 2.0协议进行交互，从而确保跨组织的流程协同的有序进行[5]。同时，本文使用基于区块链的互操作服务对互操作的过程进行记录，以确保流程协同过程不可篡改。本文对一次协同的过程进行了论述，并在该过程中展现了在一组确定的参与方之间合作的场景下，该框架的组成，以及它是如何为各方提供可信的互操作服务的。

2.1 互操作服务框架

本文提出的框架本身不关心企业BPMS对于内部流程支持的能力，只是在此基础上增强参与者之间的流程互操作能力。为提供这种能力，本文的框架需要完成以下任务：

(1)为BPMS提供标准化的交互方式，以提高流程交互的自动化水平，同时降低多组织场景下的复杂性。不同企业使用的BPMS不同，使得企业之间互相沟通的成本变得十分昂贵，因此BPMS需要使用同一套互操作协议，而该协议必须足够通用，使得各个参与者的BPMS无需过多适配即可支持。

(2)为BPMS提供可信的互操作环境。自动化可以提高企业间合作的效率，企业间的信任也对效率具有很大的影响。因此，互操作框架还需要提供可信的互操作环境。

为确保过程可追溯，本文框架使用了Client-Sever架构。过程可追溯意味着互操作过程不可篡改，它是确保可信性的一个重要因素。因此，需要有一个服务来对交互过程进行记录，这可以保证当合作的过程中发生纠纷时，由于互操作过程是不可篡改的，合作方可以快速定位问题所在。在保证交互过程公开的同时，还需要保证参与合作的企业的隐私不被暴露，因此流程的执行应该放在合作方处进行。基于此，本文设计了如图1所示的流程互操作框架。该框架包括工作流互操作服务和企业BPMS两部分。

2.1.1 工作流互操作服务

WfMC提出的接口四标准定义了工作流引擎要实现互操作所需要具备的能力，在此之上，Wf-XML 2.0定义了一个互操作的模型，并提供了用以互操作的接口，但该协议是P2P模型的，意味着互操作的双方直接进行交互，而对于多方合作的场景，则需要每一个参与者都明确自己需要交互的对象是谁，应该如何完成互操作等，这使得互操作变得异常复杂。除此之外，采用这种方式的合作并不利于对互操作的过程进行控制和追溯，因此事先定义的协同模型并不能很好地对互操作过程进行制约，且合作发生问题时，追责变得异常困难。

因此，本文引入的服务需要提供互操作的能力。为解决信任问题，该服务使用智能合约来协调参与方BPMS之间的互操作，基于区块链的互操作服务可以使被记录的交互过程不可篡改，从而确保交互的公开透明，增强合作的可信性；该服务的引入也同样解决了交互的复杂性问题，协同的参与者不再一对一地进行互操作，而是和服务之间进行交互，互操作服务则会根据事先定义的协同流程来推进合作过程的进行。为了使工作流互操作服务实现以上目标，本文设计如下模块，以实现工作流互操作服务：

(1)交互接口 本文的工作流互操作服务旨在提供企业间BPMS互操作的能力，因此服务的调用者是BPMS。考虑到Wf-XML 2.0提出的资源模型仍然符合现有工作流的资源模型，因此本文采用该协议作为框架内的标准化交互协议。该接口屏蔽区块链的实现细节，其内部将区块链的事件和Wf-XML 2.0协议进行了对应，其中关键的互操作资源和事件与区块链操作间的映射关系如表1所示。

(2)流程控制模块 该模块基于区块链，它通过智能合约确保了流程协同的有序进行[5]。协同流程的模型将被事先注册到工作流互操作服务，并翻译成智能合约用以控制流程协同的有序执行。当BPMS通过交互接口进行交互状态的同步时，流程控制模块将首先检查该状态是否符合流程协同的模型定义，并根据检查结果决定是否接受该状态变更。

(3)协同状态记录模块 该模块使用区块链对流程协同中的状态变更进行记录，以便对流程协同的过程进行检查。其本质还是存储在区块链上的交易事件，因此保证了存储在其上的状态信息不会被轻易篡改。

(4)协同数据记录模块 该模块负责记录交互过程中的数据。在实际的互操作过程中，不仅需要确保协同的状态不可被篡改，还需要确保互操作过程中包含的数据记录不可被篡改，因此在必要的情况下，数据同样需要被记录到工作流互操作服务上。由于数据作为企业的隐私，需要对访问权限进行限制，在该模块中只记录数据的摘要，而实际内容的管理交给流程协同的参与方。从而在保证隐私的基础上，确保了互操作包含的数据不可篡改。

2.1.2 企业的BPMS

为保证合作方的隐私，企业内的业务流程在各自的BPMS上执行，同时与工作流互操作服务进行交互来推动协同的进行。Wf-XML 2.0协议被用来与工作流互操作服务进行交互，因此本文框架还提供了一个适配器，用以将BPMS上使用的BPMN模型转化成标准的互操作接口。

借助该框架，可以实现:①不同企业的BPMS间可以自动地完成流程互操作;②企业间流程协同可以按照事先定义的顺序进行;③互操作的过程可以得到记录，且该记录不可被篡改;④企业自己的流程作为隐私不会被外界获取。接下来通过介绍企业间互操作的步骤，来对这两个模块的内容进行详细说明，同时介绍不同的参与者间是如何在该框架下完成协同的。

虽然工作流互操作服务作为各方BPMS互操作的中心，但它仍然是一个分布式的框架。这是由区块链的特性决定的，节点除了运行了区块链相关服务之外，还运行了一个将区块链操作映射成工作流接口的服务。因此，上述提到的工作流互操作服务的各个模块都是分别运行在分布式的节点之上，基于区块链网络提供服务，并依赖区块链保证一致性。因此本文框架中的互操作服务只作为一个理论上的中心，但实际环境则是分布式服务。

表1 Wf-XML 2.0中概念与区块链间的映射

2.2 互操作流程说明

为了帮助读者理解该框架，本文将基于图3的协作模型，按照企业间进行协作的顺序，对该框架的互操作流程进行说明。

(1)构建协同工作流

业务流程协作发生在合作方之间，合作者通过彼此之间信息和资源的交换完成合作，为了对该过程进行约束，需要将协同过程进行建模，同时为了控制合作的顺序按照约定进行，该模型将被部署到工作流互操作服务上，从而作为后续合作的约束。因此有需要建立两种模型：①利用BPMN编排图建模的协同流程，该模型将被用来控制企业间的协同过程;②运行在企业内部工作流引擎上的业务流程，它对企业内部的业务进行建模，这类流程是不要求公开的，它只需要在某些关键点上与协同流程交互即可，从而在确保过程透明的前提下，保护企业的隐私。

合作方在完成对协同流程的商讨和建模后，需要将协同流程的模型注册到工作流互操作服务上，后续合作过程的开展都是基于该模型进行的。除此之外，还需要将内部的业务流程部署到各自的BPMS上，保证合作开始后可以正常地进行流程的执行。

(2)合作开始时的状态同步

在(1)中，参与方已经就流程协同的顺序达成一致，并对协同流程进行了建模。为了提高流程协同的自动化水平，参与方的工作流引擎间需要进行状态同步，从而可以在约定的流程之下高效地完成合作。在(1)中提到，在本文提出的框架下的协同，其本质是参与方的BPMS和工作流互操作服务之间的互操作，通过执行任务来推动协同的进行，因此需要为BPMS提供标准的与工作流互操作服务交互的协议，从而为协同提供自动化的能力。

但正如上面所提到的，工作流互操作服务本身需要与多方进行互操作，且参与方可能需要同时参与多次协同，这也就意味着BPMS间需要在合作开始前就合作过程进行状态同步。本文采用下面描述的流程来完成状态的同步，该过程的一个示例如图2所示。

1)发起一次协同。每一次流程协同都有其起始点，一次业务流程协同是以负责执行起始点任务的参与者向工作流互操作服务发送CreateInstance请求开始的，该请求意味着在工作流互操作服务上创建一个协同流程来控制本次协同。

2)其他参与方创建业务流程。工作流互操作服务收到创建请求后，将根据(1)中注册的协同流程自动部署智能合约来控制一次协同。除此之外，工作流互操作服务还负责将协同同步到其他的参与方。工作流互操作服务将向参与方发送CreateInstance请求，这意味着参与方的本地流程将要被创建。

3)参与方向工作流互操作服务同步状态。流程的创建是一个异步的过程，当工作流互操作服务收到响应时，并不意味着流程已经完成创建。因此，当流程完成创建后，参与方需要向工作流互操作服务发送StateChanged消息，以告知流程创建的完成。

4)工作流互操作服务响应StateChanged。在完成上述过程后，工作流互操作服务的流程创建则正式完成，这意味着参与方之间可以开始合作，此时，工作流互操作服务将发送StateChanged消息给各个参与方以告知流程协同可以开始。

经过上述过程，一次协同流程便得到了同步，同步意味着参与协同的多方之间就合作达成了一致，且经过工作流互操作服务的协调，参与方本地都已经启动了对应的业务流程以共同执行协同任务。与此同时，CreateInstance响应中所包含的唯一ID，则可以帮助参与方关联本次协同的流程实例以及互操作服务的流程实例，使得参与方可以同时进行多项合作任务而不会发生冲突。

(3)合作过程中的互操作

为了使用Wf-XML2.0协议，除了需要在工作流互操作服务的交互接口处和区块链对应，还需要在BPMS一侧进行转化。考虑到现有工作流引擎大多支持BPMN 2.0，因此本文也将BPMN 2.0的概念和Wf-XML 2.0进行了对照，从而方便将现阶段的大部分工作流引擎接入到本文框架内。

由表2可知，本文框架对于互操作的支持是基于BPMN 2.0中的各种事件的，这是由于在BPMS处，主要的行为是企业内部业务流程的执行，而为了不对企业内部流程进行过多的改造，需要通过模型中暴露出的各个事件进行沟通。除此之外，BPMN协作图用于对企业间流程协作建模，而该模型同样采用事件的方式完成流程间的互操作。因此，需要有一个网关将BPMN中的各种事件转换成为接口四的行为，在Wf-XML 2.0的资源模型中，除了异步服务之外，还有一个重要的资源就是Observer，它可以协助完成上述功能。

表2 Wf-XML2.0和BPMN2.0在客户端的关系映射

(4)协同结束后的工作

在上述3个步骤中，企业间的协同经历了协同模型的构建、协同开始前的状态同步以及协同过程中的互操作过程。在协同执行到最后一个任务时，此次合作便接近尾声。但是协同过程的结束并不意味着合作的结束，本文开头提到，可信性是企业间协同的重要前提。为了提供更高的可信性，方法引入了区块链来对过程进行记录，同时为了提高效率，引入了Wf-XML 2.0这一标准化接口来减轻企业间合作中适配的负担。但是这些仍不足以提供足够的信任，本文的场景仅针对事先确定了的合作方，但并未考虑不确定的多方之间的合作场景，例如众包。在这一类场景下，合作的参与方不仅需要在合作过程中保证过程不可篡改，还需要在协同一开始就提供对方信任度的评估。除此之外，工作流服务的能力还需要扩展，从固定的参与方到不固定的参与者需要有额外的支持。由于篇幅限制，将不在本文中进行探讨。

3 实验验证

3.1 实验环境

为了验证本文提出的框架对于WfMC给出的4种互操作场景的支持，基于Activiti工作流引擎实现了一个支持工作流互操作的原型。该原型使用实验性的私有以太坊提供互操作服务，并通过运行在以太坊上的智能合约控制协同的有序进行。由于智能合约的生成是基于BPMN编排图的，在实验开始前，先将该流程转换成BPMN编排图，再将转换后的BPMN编排图注册到工作流互操作服务，由工作流互操作服务将编排图翻译成智能合约。每个参与方本身都拥有一个工作流引擎用以执行各自的业务流程，本实验中采用activiti，因为该引擎目前在业界使用范围更广，所以具有更好的代表性。activiti本身并不支持跨流程协同，因此实现了observer来监听工作流实例执行的过程，并对外部事件进行响应，从而在原有工作流引擎的基础上来支持这种互操作性。

由于区块链本身涉及多方之间的状态同步，性能问题会比传统的协同流程更值得关注。但业务流程协同本身更关注准确性，而并不太关注性能问题，因此本文的性能数据也仅仅是被用来作为一种展示，从而说明本文方法可以满足跨组织协同的基础要求，而并不作为这个工具好坏的评价标准。与之相比更为重要的则是该框架对可信性的支持，因此本实验中加入了一组特殊的案例，用以表现合作中的某一方不按照要求进行协同的场景，并对工作流互操作服务的响应进行展示，从而说明该框架对流程协同顺序的控制能力。

3.2 实验结果

本文在使用以太坊作为工作流互操作服务的具体实现时，对交互过程所花费的时间进行了统计。局域网环境下，采用随机的延时来模拟执行任务的过程，因为本文区块链运行在本地机器上，所以区块链的状态同步时间几乎可以忽略不计。但是基于以太坊公有链的交易的时延会随着交易数量的增多而变长[15]，因此大量互操作的场景下，时延问题仍然是后面需要解决的问题。

为了验证本文框架对流程合法性的要求，设计了一个对照实验，该实验场景下，Supplier在receiverequests之后跳过providedetails这一任务(Task)而直接执行providewaybill。以此验证合作中某一方不遵守约定执行任务时，工作流互操作服务的处理能力。在执行到这一步时，工作流互操作服务并没有继续，而是仍旧等待providedetails这一流程，并且查看交易记录可以发现区块链的账本中新增了对于Supplier这一行为的记录。该记录可以被用来进行追责和信任评级，从而为下一次合作中对合作方的信任度进行考核。

3.3 讨论

3.3.1 通用性

为了验证4种模型，本文对图3[5]所示的协作模型进行了分析，对于Connected Discrete和Hierarchical两种模式都是较为简单的实现，B流程只需要完成A流程在某一点给出的任务即可，区别只在于A是否需要等待返回。在BPMN协同图中，Middleman的forwardorder即满足Connected Discrete模型，Middleman在此处发送消息到Supplier，而后续两者之间不会有任何同步的过程。Manufacturer的placeorder和receiveorder过程则满足Hierarchical模型，在placeorder处将任务交给middleman而之后在receiveorder处，SpecialCarrier完成了任务并返回。对于Parallel Synchronised这种场景，SpecialCarrier的requestdetails和receivedetails则符合描述，通过这两次事件，SpecialCarrier和Supplier实现了同步，完成了对details的协商。最后则是场景Connected Indiscrete，在该场景下，参与协同的多方共同解析并完成同一个流程。这是一种比较特殊的场景，因为在该场景下，参与协作的多方实际上是在执行同一个流程实例，因此Task执行状态的转移发生在各参与方之间。由于本文框架需要对整个协同流程进行建模，可以将该流程作为协同流程，各个参与方内部解析执行同一个流程，从而解决该问题。

3.3.2 信任

文献[15-16]的研究发现，开放的沟通以及更多的规则和程序正义的透明度会带来更多的信任。本文提出的框架在确保企业的隐私不被影响的情况下，为企业间的协同提供更高的透明度。与此同时，区块链的加入，则使得这些被公开的数据变得不可篡改。通过提高合作间的透明度，为企业间的合作提供了一个可信的环境，从而提高了合作的效率。

3.3.3 隐私

本文提出的框架只对协同的顺序进行了控制，而协同顺序则是在协同开始前通过各方商议形成的。运行在企业内部的流程本质上则是一个灰盒，只需要暴露出来的活动满足事先商议的顺序即可，并不需要将整个执行过程暴露出来。以图中给出的协同图为例，Supplier只需要在providedetails前完成receiverequest即可，在这两个活动中间的任务的执行是不受限制的。

另一个值得关注的则是数据问题，由于区块链天生不适合存储大批量数据，而Wf-XML 2.0协议也明确说明该协议并不关心数据。但数据本身也关系着协同的进展，同时又带有一定的隐私性。因此，本文框架在工作流互操作服务中加入了数据存储模块，但这并不意味着合作方之间的数据交换必须通过该框架进行。Wf-XML 2.0协议推荐采用统一资源标识符(Uniform Resource Identifier ，URI)的方式进行数据的传递，但考虑到可信性的要求，推荐使用数据的摘要来代表数据本身进行传递，同时采用非对称加密的方式来确保数据安全。这样不仅可以满足隐私性的要求，还可以确保在发生问题时，可以通过摘要对数据进行审查。

4 结束语

本文旨在为企业间的流程协同提供一个标准化和可信的环境，从而提高企业间协同的效率，降低企业间协同的成本。为了实现该目标，本文基于WEBER[5]的工作，对区块链进行了包装，使其成为一个提供标准化服务的互操作服务，并通过代理对外提供标准化的工作流互操作服务，屏蔽了区块链和企业内BPMS的具体细节。同时，工作流互操作使用星形架构，简化了跨组织的流程互操作的过程，同时确保了协作过程的可信性。最后，通过实现一个SupplyChain的案例，说明了本文提出的框架对于多方的跨组织流程协同的支持。

区块链集群内节点数量的增加，将会带来交易速度的下降。因此，后续将对区块链底层性能进行考虑，来解决区块链系统的效率问题。除此之外，后续的工作将会基于协作模型的类别，通过对交互模式的研究，使得本文的框架可以支持更多的场景。