[论文解读] Cloud Process Execution Engine: Architecture and Interfaces
本文介绍了云流程执行引擎(CPEE.org),这是一种高度分布式的开源流程执行引擎,通过使用转译(transpilation)和基于REST/SSE的事件流技术,实现了在云、边缘和物联网环境中的可扩展、低代码BPMN执行。其模块化、面向服务的架构支持实时监控、动态实例自适应以及通过最小接口与外部服务的无缝集成。
Process Execution Engines are a vital part of Business Process Management (BPM) and Manufacturing Orchestration Management (MOM), as they allow the business or manufacturing logic (expressed in a graphical notation such as BPMN) to be executed. This execution drives and supervises all interactions between humans, machines, software, and the environment. If done right, this will lead to a highly flexible, low-code, and easy to maintain solution, that allows for ad-hoc changes and functional evolution, as well as delivering a wealth of data for data-science applications. The Cloud Process Execution Engine CPEE.org implements a radically distributed scale-out architecture, together with a minimal set of interfaces, to allow for the simplest possible integration with existing services, machines, and existing data-analysis tools. Its open-source components can serve as a blueprint for future development of commercial solutions, and serves as a proven testbed for academic research, teaching, and industrial application since 2008. In this paper we present the architecture, interfaces that make CPEE.org possible, as well as discuss different lifecycle models utilized during execution to provide overarching support for a wide range of data-analysis tasks.
研究动机与目标
- 设计一种高度可扩展、分布式的流程执行引擎,支持实时监控、动态实例自适应以及与外部服务的无缝集成。
- 通过BPMN实现低代码、基于模型的流程执行,同时保持模块化和可扩展性,以满足研究和工业应用需求。
- 提供一个生产就绪的开源平台,支持边缘和物联网工作负载的集中式和联邦化部署。
- 通过标准化的REST和SSE接口暴露所有内部组件,以支持教学、研究和系统检查。
- 通过与外部服务的集成实现生命周期管理、版本控制和自愈机制,而无需修改核心引擎。
提出的方法
- CPEE.org引擎采用基于转译的架构,将BPMN模型转换为低级可执行代码,以避免每个实例的解释器开销。
- 它使用Redis作为内存数据库的发布/订阅机制,实现跨分布式组件的事件、生命周期状态和投票的流式传输。
- 内部服务——持久化实现(PI)、事件分发(EDI)、投票分发(VDI)、回调终点(CEI)和REST服务(RS)——彼此解耦,并通过事件流进行通信。
- REST服务(RS)作为中央控制接口,将所有命令转发至发布/订阅系统,并同时支持HTTP推送和服务器发送事件(SSE),以实现实时UI更新。
- 系统支持两种部署模式:分布式(集群Redis,负载均衡实例)和联邦化(多个独立PE通过操作接口通信)。
- 所有组件均通过标准化的REST和SSE接口暴露,使外部服务能够扩展功能而无需修改引擎核心。
实验结果
研究问题
- RQ1如何设计一个流程执行引擎,以支持横向扩展、分布式执行,同时保持低延迟和高可用性?
- RQ2哪些架构模式能够实现在不需深度修改引擎的前提下,与外部服务(如数据分析、人工任务)的无缝集成?
- RQ3在去中心化、事件驱动的系统中,如何实现对流程实例的实时监控和生命周期管理?
- RQ4通过外部服务组合,流程引擎在多大程度上能够支持临时实例更改、模型版本控制和自愈机制?
- RQ5与解释执行相比,使用转译在大规模流程执行中对性能和内存效率有何影响?
主要发现
- 基于转译的架构消除了每个实例的解释器开销,与传统基于解释器的引擎相比,显著降低了内存消耗。
- 使用Redis作为共享内存数据库,实现了跨分布式节点的高效、低延迟事件分发和状态同步。
- 事件驱动、面向服务的设计允许通过SSE驱动的UI实现实时、动态的流程实例监控,更新随事件发布即时推送。
- 该系统支持集中式和联邦化部署,使边缘和物联网环境中的多个独立流程引擎能够通过标准化操作接口互操作。
- 模块化、接口驱动的设计实现了完全可扩展性:所有BPMN语义均可通过外部REST服务自定义,而无需修改引擎核心。
- 该平台自2008年以来持续维护,并被广泛应用于学术研究和工业场景,证明了其长期稳定性和实际可扩展性。
更好的研究,从现在开始
从阅读论文到最终审阅,大幅缩短您的研究时间。
无需绑定信用卡
本解读由 AI 生成,并经人工编辑审核。