为工作流系统建议一个持久的策略 [英] Suggest a persistent strategy for a workflow system
问题描述
我正在为我的宠物项目创建 UI 配置工具.该工具的一个方面是让最终用户定义其编排.然后我需要将此编排定义保存到数据库中.在运行的系统中会有这个定义的可执行版本.可执行版本是按需动态创建的.
I am in the process of creating a UI configuration tool for my pet project. One aspect of this tool lets the end user DEFINE his orchestration. I then need to save this orchestration definition into a database. There will be a executable version of this definition in a running system. The executable version is created dynamically on-demand.
想法是将 DEFINITION 与 EXECUTABLE 版本分开，以便我可以灵活地在 BPMN 或 JPDL 或基于 POJO 的工作流解决方案 (BeanFlow) 中选择运行时版本.
Idea is to separate the DEFINITION from EXECUTABLE version so that I have the flexibility to choose the runtime version among BPMN or JPDL or a POJO based workflow solution (BeanFlow).
限制:我不能使用 jBPM、Activiti 等框架附带的 BPMN 编辑器，因为我不想使用我自己的特定于我的域的 UI.
Limitation: I can't use the BPMN editors that come with frameworks like jBPM, Activiti etc as I wan't to use my own UI that is specific to my domain.
我需要关于如何坚持定义的建议.
I need suggestions on HOW to PERSIST the definition.
我应该使用 rdbms 表吗?如果是这样，我可以借用接近编排概念的数据库模式吗?
Should I use rdbms tables? If so, is there a db schema I can borrow that is close to orchestration concepts?
我应该将我的定义序列化为 BPMN/JPDL XML 实例文档吗?
Should I serialize my definition to BPMN/JPDL XML instance document?
还有其他简单的格式可以使用吗?
Are there any other simple formats that I can use?
推荐答案
编排"我假设您指的是 有限状态机.当前状态决定了可以遵循哪些转换到其他状态的位置.将状态和转换表示为边和顶点通常会产生 有向无环图，但是有时图表何时循环(例如，草稿 -- 提交批准 --> 待批准 -- 拒绝 --> 草稿).
By "orchestration" I'm assuming you mean a finite state machine. Where the current state dictates what transitions can be followed to other states. The representation of states and transitions as edges and vertices often produces a directed acyclic graph, however there are times when the graph will cycle (e.g. draft -- submit for approval --> pending approval -- reject --> draft).
在实践中，将定义与执行分开需要一种可以轻松适应自定义的持久性格式.随着您的系统的发展，您会发现许多意料之外的边缘情况，其解决方案不需要更改持久性架构，只需更改代码.这意味着 XML 或 NoSQL 解决方案 - 其架构很容易更改或不存在的东西.
In practice, separating the definition from execution calls for a persistence format that can easily accommodate customization. As your system evolves you will find a number of unanticipated edge cases whose solution should not require altering a persistence schema, only code. This implies XML or a NoSQL solution - something whose schema is easily changed or non existent.
现在，为此目的编写了我自己的 XML 定义(出于无趣的原因，我将排除)，我的建议是使用 JPDL(或 BPMN).原因是它们的定义可能包含您现在正在考虑的，将来会考虑的任何内容，并启用自定义 - 例如在给定点悬挂任意数据或行为.您还可以利用已构建的工具(不仅仅是 UI)来处理循环检测并确保有完成路径等.
Now, having written my own XML definition for this purpose (for uninteresting reasons I'll exclude), my suggestion is using JPDL (or BPMN). Reason is their definitions likely incorporate whatever you're considering now, will in the future, and enable customization - such as hanging arbitrary data or behavior off them at a given point. You also get the advantage of tools already built - not just UI - for dealing with cycle detection and ensuring there is a path to completion for example.
我知道 JPDL 拥有的一些有趣的特性是能够帮助合并分叉进程、定时任务(包括那些定期重复的任务)和发送通知的工具.最后一项 - 通知 - 需要进一步说明.我在自己的系统中发现的一件事是需要发送可配置的电子邮件，其内容基于流过的数据.这些现有引擎通过提供一种方法将变量插入到文本中，然后在传输之前在运行时动态评估，从而使这变得相对容易.此外，它们还提供引擎和任何用户存储之间的桥梁，以便向人群发送通知、分配任务并执行安全策略.
Some of the interesting features I know JPDL possesses are an ability to help merge forked processes, timed tasks (including those that repeat periodically), and facilities for sending notification. This last item - notification - bears some further exposition. One of the things I've found with my own system is the need for sending out configurable email whose content is based on the data flowing through. These existing engines make that relatively easy by providing a way to plugin variables for instance into text that's then dynamically evaluated at run time before transmission. Also they provide bridges between the engine and whatever user store for the purpose of sending notifications to groups of people, tasking them and enforcing security policy.
最后，根据您系统的范围，您可能仍会使用数据库.我的建议是以序列化格式将 XML 和编排到数据库中的数据存储起来.然后，如果数据在执行过程中被更改，则将数据的序列化(如果数据也发生更改，可能还有工作流)写入历史/审计日志表.
Finally, depending on the scope of your system, you will probably still be using a database as well. What I suggest is storing off the XML and data being orchestrated into the database in a serialized format. Then, if the data is being altered as it travels through the execution, write out serializations of the data - and perhaps workflow if it is also changed - into a history/audit log table as well.
这篇关于为工作流系统建议一个持久的策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
