为工作流系统提出持久策略
我正在为我的宠物项目创建一个 UI 配置工具。该工具的一方面可以让最终用户定义他的编排。然后我需要将此编排定义保存到数据库中。在运行的系统中将有该定义的可执行版本。可执行版本是按需动态创建的。
想法是将 DEFINITION 与 EXECUTABLE 版本分开，以便我可以灵活地在 BPMN 或 JPDL 或基于 POJO 的工作流解决方案 (BeanFlow) 之间选择运行时版本。
限制：我无法使用 jBPM、Activiti 等框架附带的 BPMN 编辑器，因为我不想使用特定于我的域的自己的 UI。
我需要有关如何保留该定义的建议。
我应该使用 RDBMS 表吗？如果是这样，我是否可以借用一个接近编排概念的数据库模式？
我应该将我的定义序列化为 BPMN/JPDL XML 实例文档吗？
还有其他我可以使用的简单格式吗？
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.
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).
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.
Should I use rdbms tables? If so, is there a db schema I can borrow that is close to orchestration concepts?
Should I serialize my definition to BPMN/JPDL XML instance document?
Are there any other simple formats that I can use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我假设您所说的“编排”是指有限状态机。当前状态决定了可以遵循哪些转换到其他状态。将状态和转换表示为边和顶点通常会生成有向无环图，但是有时图表何时循环（例如草稿--提交审批-->待批准--拒绝-->草稿）。
在实践中，将定义与执行分离需要一种可以轻松适应定制的持久格式。随着系统的发展，您会发现许多意想不到的边缘情况，其解决方案不需要更改持久性模式，只需要更改代码。这意味着 XML 或 NoSQL 解决方案 - 其模式很容易更改或不存在。
现在，我已经为此目的编写了我自己的 XML 定义（由于无趣的原因我将排除），我的建议是使用 JPDL（或 BPMN）。原因是它们的定义可能包含您现在和将来考虑的任何内容，并支持自定义 - 例如在给定点挂起任意数据或行为。您还可以利用已构建的工具（而不仅仅是 UI）来处理周期检测并确保有一条完成路径等。
我知道 JPDL 拥有的一些有趣功能包括帮助合并分叉进程、定时任务（包括定期重复的任务）以及发送通知的功能。最后一项——通知——需要进一步说明。我在自己的系统中发现的一件事是需要发送可配置的电子邮件，其内容基于流经的数据。这些现有的引擎通过提供一种将变量插入文本的方法，然后在传输之前在运行时动态评估，从而使这一过程变得相对容易。此外，它们还在引擎和任何用户存储之间提供桥梁，以便向人群发送通知、分配任务并执行安全策略。
最后，根据系统的范围，您可能仍然会使用数据库。我的建议是将 XML 和数据以序列化格式存储到数据库中。然后，如果数据在执行过程中发生更改，请将数据的序列化（如果也发生更改，可能还包括工作流程）写入历史/审核日志表。
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).
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.
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.
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.
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.
我不会使用 RDBMS 表，或者如果使用，请将定义存储为文本 blob。尝试为定义进行记录是一个坏主意，因为随着时间的推移，更改定义会更加不灵活且困难。许多人会使用不同的方法，但我会使用 JSON 或 YAML，并避免使用 XML。这样做的动机是使其尽可能简单。尝试使用 XML，尤其是 XML 的形式化特定格式，将使您花费更多时间来满足精确的规范，而该规范实际上对您想要完成的任务没有任何帮助。从代码角度来看，JSON 和 YAML 都非常易于使用。 YAML 更容易被人类阅读和编辑，并且标点符号和转义不像 JSON 那样棘手。 JSON 使用更广泛，并且比 YAML 更小。如果考虑文档大小的话，JSON 也有一个对应的二进制文件 BSON。
一旦您有一个导入器/导出器可以将您的内部对象转换为您的数据格式，那么使用 RDBMS 或其他机制进行持久化将变得很简单。您甚至可以使用 CouchDB，它可以为您的应用程序提供其他好处，并且可能非常适合。
I would NOT use rdbms tables, or if you do, store the definitions as text blobs. Trying to make records for the definition is a bad idea because it's much more inflexible and difficult to change your definition over time. Many people would use different approaches, but I'd use JSON or YAML, and avoid XML. The motivation for that is to make it as simple as possible. Trying to use XML, especially a formalized specific format of XML is going to make you spend much more time meeting an exact specification that doesn't actually do anything to help what you're trying to accomplish. JSON and YAML are both very easy to work with from a code perspective. YAML is more easily readable by humans and easier to edit, and isn't as tricky for punctuation and escaping as JSON. JSON is more widely used, and is smaller than YAML. JSON also has a binary counterpart, BSON, if document size is a concern.
Once you have an importer/exporter that goes to/from your internal objects to your data format, then persisting using RDBMS, or other mechanisms, will be straightforward. You could even use CouchDB, which could offer other benefits to your application and may be a great fit.
非常好的问题！这是我的两点意见：
Very good question! Here is my two cents:
如何使用 XStream 对组合 UI 进行简单序列化，然后将序列化位存储在数据库作为二进制列？然后当用户登录时，获取关联数据，反序列化，如果需要则初始化，并显示。
How about a simple serialization of the composed UI using for example XStream and then storing the serialized bits in the database as a binary column? Then when the user logs in, get the associated data, deserialize, initialize if required, and display.