下载文档原格式
系统工作流程调度方案系统工作流程调度方案是指在系统中一系列的任务流程和工作流程按照一定的顺序和时间要求进行调度和执行的方法和策略。
下面将介绍一个具体的系统工作流程调度方案。
首先，需要确定系统中所有任务的执行顺序和时间要求。
根据任务的依赖关系和优先级，确定任务的先后顺序。
对于需要并行执行的任务，需要保证它们的执行时间不冲突。
同时，需要了解任务的执行时间，以确定任务的开始时间和截止时间。
其次，根据任务的执行顺序和时间要求，生成任务调度表。
任务调度表可以是一个二维数组，每一行代表一个任务，每一列代表任务的开始时间、结束时间、执行状态等信息。
可以使用图论算法，如拓扑排序算法，来生成任务调度表。
然后，根据任务调度表，分配任务的执行资源。
根据任务的执行时间，确定需要的计算资源和存储资源。
如果任务需要的资源超过系统的资源限制，需要进行资源调度和分配，以满足任务的执行需求。
接下来，根据任务调度表，执行任务并监控任务的执行状态。
根据任务的开始时间和执行时间，安排任务的执行顺序，并监控任务的执行情况。
如果任务的执行时间超过了截止时间，或者任务的执行结果不符合要求，需要及时采取措施，如重新分配任务资源、调整任务执行顺序等，保证任务的正常执行。
最后，进行任务的结果分析和优化。
根据任务的执行结果，分析任务的执行效率和资源利用率。
如果任务的执行效率低下或者资源利用率不高，可以进行任务的优化，如优化算法、调整资源分配策略等。
综上所述，一个系统工作流程调度方案包括确定任务的执行顺序和时间要求、生成任务调度表、分配任务执行资源、执行任务并监控任务的执行状态，以及进行结果分析和优化。
这个方案可以提高系统的工作效率和资源利用率，保证任务按照一定的顺序和时间要求进行调度和执行。
基于逆向分层的网格工作流调度改进算法近年来，工作流算法得到了越来越多的关注，因为它可以有效地调度网格环境中分布式作业。
随着网格技术的发展，网格工作流调度技术逐渐增强，为实现高效的工作流执行提供了更多可能性。
提出了一种基于逆向分层的网格工作流调度改进算法。
这种算法可以有效地处理网格环境中的大规模复杂作业集，优化作业的执行时间，减少网络传输的开销，并改善目标函数的性能。
首先，基于逆向分层的网格工作流调度改进算法旨在改善常规网格宽带调度算法（RBSA）的性能。
主要思想是，将工作流任务模型转换为一种称为“逆向树”的数据结构，并将复杂的网格工作流任务拆分为一系列的以小型宽带作业为基础的逆向树结构。
之后，算法按照任务定量模型计算出作业所需的带宽，从而帮助决策者按照网格环境的特点进行高性能的作业调度。
此外，基于逆向分层的网格工作流调度改进算法还能够有效地处理大规模复杂作业集和减少网络传输时间。
因此，它可以改善两个基本优化问题，即作业执行时间优化和带宽优化问题，以实现高性能的工作流执行。
最后，基于逆向分层的网格工作流调度改进算法还可以通过优化目标函数来帮助决策者实现最优的工作流调度。
针对网格环境中的大规模复杂工作流任务，基于逆向分层的网格工作流调度改进算法可以有效地优化工作流执行过程。
通过将大规模复杂作业拆分为小型宽带作业，算法不仅可以减少网络传输时间，还可以优化作业执行时间和带宽优化。
其次，基于逆向分层的网格工作流调度改进算法可以实现最优的工作流调度，优化目标函数的性能，以期实现最优的工作流执行。
因此，基于逆向分层的网格工作流调度改进算法是一种非常有效的算法，具有良好的性能和可塑性。
它可以帮助决策者有效地调度网格环境中的大规模复杂作业集，优化作业的执行时间，减少网络传输的开销，提高目标函数的性能，以及实现最优的工作流调度。
由此可见，基于逆向分层的网格工作流调度改进算法是实现高性能工作流执行的一种有效技术。
综上所述，基于逆向分层的网格工作流调度改进算法是网格环境中有效调度大规模复杂作业集的一种技术。
收稿日期:2008-12-30;修回日期:2009-02-19 基金项目:江西省教育厅科技资助项目(G J J 08417);吉安市科技局科研项目(吉市科计字[2008]21号) 作者简介:李金忠(1977-),男,江西吉安人,讲师,硕士,主要研究方向为网格计算、网格工作流(l e e z h o n g 2005@126.c o m );夏洁武(1969-),女,江西吉安人,教授,硕士,主要研究方向为软件工程;曾劲涛(1978-),男,江西吉安人,讲师,硕士,主要研究方向为We b 信息抽取和挖掘;朱兵(1975-),男,江西吉安人,副教授,硕士,主要研究方向为嵌入式系统;刘昌鑫(1963-),男,江西吉安人,教授,硕士,主要研究方向为计算机网络.网格工作流调度算法研究综述＊李金忠,夏洁武,曾劲涛,朱 兵,刘昌鑫(井冈山大学信息科学与传媒学院,江西吉安343009)摘 要:作为一个N P 完全问题,通常采用启发式算法来解决网格工作流调度。
首先对网格工作流调度算法进行了分类,然后对其典型算法进行了分析和讨论,并阐述了一些典型网格工作流调度系统,最后指出了现有算法中的一些不足之处,展望了该领域的进一步研究方向。
关键词:网格工作流;调度;算法中图分类号:T P 393 文献标志码:A 文章编号:1001-3695(2009)08-2816-05d o i :10.3969/j .j s s n .1001-3695.2009.08.005S u r v e y o n g r i d w o r k f l o ws c h e d u l i n g a l g o r i t h mL I J i n -z h o n g ,X I AJ i e -w u ,Z E N GJ i n -t a o ,Z H UB i n g ,L I UC h a n g -x i n(S c h o o l o f I n f o r m a t i o nS c i e n c e ＆M e d i a ,J i n g g a n g s h a nU n i v e r s i t y ,J i 'a nJ i a n g x i 343009,C h i n a )A b s t r a c t :A s a n N Pc o m p l e t e p r o b l e m ,g r i d w o r k f l o ws c h e d u l i n g i s u s u a l l ys o l v e db y m e a n s o f h e u r i s t i c s .T h ep a p e r f i r s t l y a s s o r t e d g r i dw o r k f l o ws c h e d u l i n g a l g o r i t h m s ,s e c o n d l y a n a l y z e d a n d d i s c u s s e di t s t y p i c a l a l g o r i t h m s ,t h e ni l l u s t r a t e ds e v e r a l t y p i c a l g r i d w o r k f l o ws c h e d u l i n g s y s t e m s .F i n a l l y ,g a v e t h e s h o r t c o m i n g s a n d t h e f u r t h e r r e s e a r c h t r e n d .K e y w o r d s :g r i dw o r k f l o w ;s c h e d u l i n g ;a l g o r i t h m 引言I .F o s t e r 等人[1]认为网格关心的是在动态的、多机构的虚拟组织中协调资源共享和协同解决问题,核心思想是在一组参与节点(资源提供者和消费者)中协商资源共享管理的能力,利用协商得到的资源池共同解决一些问题。
第３７卷第１１期 计算机应用与软件Ｖｏｌ ３７Ｎｏ．１１２０２０年１１月 ＣｏｍｐｕｔｅｒＡｐｐｌｉｃａｔｉｏｎｓａｎｄＳｏｆｔｗａｒｅＮｏｖ．２０２０云环境中一种多阶段式工作流任务调度算法张 扬１ 马 飞２１（广西工业职业技术学院 广西南宁５３０００３）２（广西大学计算机与电子信息学院 广西南宁５３０００４）收稿日期：２０１９－０５－２１。
国家自然科学基金项目（６１６６１００４）；基于移动互联网的高等院校设备维护管理项目（ＫＹ２０１６ＬＸ５７４）。
张扬，实验师，主研领域：大数据。
马飞，副教授。
摘 要 为了解决云计算环境中工作流调度的代价优化问题，提出一种多阶段式工作流任务调度算法。
以同步优化调度长度和执行代价为目标，将最优化调度方案求解过程划分为工作流分级、确定任务优先级和最优虚拟机选择三个阶段。
第一阶段将任务划分为可并行执行的独立群组；第二阶段计算任务秩值得到任务调度次序；第三阶段基于时间和代价的均衡考虑为任务调度选择最优虚拟机，从而求得代价与时间均衡的工作流调度方案。
仿真实验表明，该算法在不同的任务规模和任务类型（计算密集型与通信密集型）比例下，在调度长度和执行代价两个性能指标上，较同类型的调度方法表现出更好的性能，可以有效实现调度效率与执行代价间的均衡优化。
关键词 云环境 工作流调度 任务优先级 代价优化 代价因子中图分类号 ＴＰ３９３ 文献标志码 Ａ ＤＯＩ：１０．３９６９／ｊ．ｉｓｓｎ．１０００ ３８６ｘ．２０２０．１１．０３０ＡＭＵＬＴＩ ＳＴＡＧＥＷＯＲＫＦＬＯＷＴＡＳＫＳＣＨＥＤＵＬＩＮＧＡＬＧＯＲＩＴＨＭＩＮＣＬＯＵＤＥＮＶＩＲＯＮＭＥＮＴＺｈａｎｇＹａｎｇ１ ＭａＦｅｉ２１（ＧｕａｎｇｘｉＶｏｃａｔｉｏｎａｌａｎｄＴｅｃｈｎｉｃａｌＩｎｓｔｉｔｕｔｅｏｆＩｎｄｕｓｔｒｙ，Ｎａｎｎｉｎｇ５３０００３，Ｇｕａｎｇｘｉ，Ｃｈｉｎａ）２（ＳｃｈｏｏｌｏｆＣｏｍｐｕｔｅｒａｎｄＥｌｅｃｔｒｏｎｉｃｓＩｎｆｏｒｍａｔｉｏｎ，ＧｕａｎｇｘｉＵｎｉｖｅｒｉｓｔｙ，Ｎａｎｎｉｎｇ５３０００４，Ｇｕａｎｇｘｉ，Ｃｈｉｎａ）Ａｂｓｔｒａｃｔ Ｆｏｒｓｏｌｖｉｎｇｔｈｅｃｏｓｔｏｐｔｉｍｉｚａｔｉｏｎｐｒｏｂｌｅｍｏｆｗｏｒｋｆｌｏｗｓｃｈｅｄｕｌｉｎｇｉｎｃｌｏｕｄｃｏｍｐｕｔｉｎｇｅｎｖｉｒｏｎｍｅｎｔ，ｗｅｐｒｏｐｏｓｅａｍｕｌｔｉ ｓｔａｇｅｗｏｒｋｆｌｏｗｔａｓｋｓｃｈｅｄｕｌｉｎｇａｌｇｏｒｉｔｈｍ．Ｗｉｔｈａｎｏｂｊｅｃｔｉｖｅｏｆｏｐｔｉｍｉｚｉｎｇｓｙｎｃｈｒｏｎｏｕｓｌｙｔｈｅｓｃｈｅｄｕｌｉｎｇｍａｋｅｓｐａｎａｎｄｔｈｅｅｘｅｃｕｔｉｏｎｃｏｓｔ，ｏｕｒａｌｇｏｒｉｔｈｍｄｉｖｉｄｅｓｔｈｅｓｏｌｖｉｎｇｐｒｏｃｅｓｓｏｆｏｐｔｉｍｉｚｉｎｇｓｃｈｅｄｕｌｉｎｇｓｃｈｅｍｅｉｎｔｏｔｈｒｅｅｓｔａｔｅｓ：ｔｈｅｗｏｒｋｆｌｏｗｌｅｖｅｌｌｉｎｇ，ｄｅｔｅｒｍｉｎｉｎｇｔｈｅｔａｓｋｓｐｒｉｏｒｉｔｙａｎｄｓｅｌｅｃｔｉｎｇｔｈｅｂｅｓｔｖｉｒｔｕａｌｍａｃｈｉｎｅ．Ｔｈｅｆｉｒｓｔｓｔａｇｅｉｓｔｏｄｉｖｉｄｅｔａｓｋｓｉｎｔｏｔｈｅｉｎｄｅｐｅｎｄｅｎｔｇｒｏｕｐｓｃａｎｂｅｅｘｅｃｕｔｅｄｉｎｐａｒａｌｌｅｌ；ｔｈｅｓｅｃｏｎｄｓｔａｇｅｉｓｔｏｃａｌｃｕｌａｔｅｔｈｅｒａｎｋｓｏｆｔａｓｋｓｆｏｒｇｅｔｔｉｎｇｔｈｅｔａｓｋｓｓｃｈｅｄｕｌｉｎｇｏｒｄｅｒ；ｔｈｅｔｈｉｒｄｓｔａｇｅｉｓｔｏｓｅｌｅｃｔｔｈｅｏｐｔｉｍａｌｖｉｒｔｕａｌｍａｃｈｉｎｅｆｏｒｅｘｅｃｕｔｉｎｇｔａｓｋｓｂａｓｅｄｏｎｔｈｅｔｒａｄｅ ｏｆｆｏｆｔｉｍｅａｎｄｃｏｓｔ，ｗｈｉｃｈｃａｎｏｂｔａｉｎｔｈｅｓｃｈｅｄｕｌｉｎｇｓｃｈｅｍｅｔｒａｄｅ ｏｆｆｔｈｅｃｏｓｔａｎｄｔｈｅｔｉｍｅ．Ｔｈｅｓｉｍｕｌａｔｉｏｎｅｘｐｅｒｉｍｅｎｔｓｓｈｏｗｔｈａｔｕｎｄｅｒｔｈｅｄｉｆｆｅｒｅｎｔｔａｓｋｓｓｃａｌｅａｎｄｔｈｅｄｉｆｆｅｒｅｎｔｔａｓｋｔｙｐｅｓｐｒｏｐｏｒｔｉｏｎ（ｃｏｍｐｕｔｅ ｉｎｔｅｎｓｉｖｅａｎｄｃｏｍｍｕｎｉｃａｔｉｏｎ ｉｎｔｅｎｓｉｖｅ），Ｃｏｍｐａｒｅｄｗｉｔｈｏｔｈｅｒｓａｍｅｔｙｐｅｓｓｃｈｅｄｕｌｉｎｇａｌｇｏｒｉｔｈｍｓ，ｏｕｒａｌｇｏｒｉｔｈｍｈａｓｂｅｔｔｅｒｐｅｒｆｏｒｍａｎｃｅａｄｖａｎｔａｇｅｓｉｎｔｗｏｐｅｒｆｏｒｍａｎｃｅｉｎｄｅｘｓｕｃｈａｓｔｈｅｓｃｈｅｄｕｌｉｎｇｍａｋｅｓｐａｎａｎｄｔｈｅｅｘｅｃｕｔｉｏｎｃｏｓｔ，ｗｈｉｃｈｃａｎｅｆｆｅｃｔｉｖｅｌｙａｃｈｉｅｖｅｔｈｅｔｒａｄｅ ｏｆｆｏｐｔｉｍｉｚａｔｉｏｎｂｅｔｗｅｅｎｔｈｅｓｃｈｅｄｕｌｉｎｇｅｆｆｉｃｉｅｎｃｙａｎｄｔｈｅｅｘｅｃｕｔｉｏｎｃｏｓｔ．Ｋｅｙｗｏｒｄｓ Ｃｌｏｕｄｅｎｖｉｒｏｎｍｅｎｔ Ｗｏｒｋｆｌｏｗｓｃｈｅｄｕｌｉｎｇ Ｔａｓｋｐｒｉｏｒｉｔｙ Ｃｏｓｔｏｐｔｉｍｉｚａｔｉｏｎ Ｃｏｓｔｆａｃｔｏｒ０ 引 言通常，云计算环境中的工作流可表示为有向无循环图ＤＡＧ的形式［１］。
云计算环境中的工作流系统资源调度方法与设计方案一、引言随着云计算技术的发展，越来越多的企业选择将自己的应用程序和数据迁移到云上进行管理和处理。
而云计算环境中的工作流系统资源调度方法与设计方案是保证云计算环境中工作流的高效执行的关键。
本文将介绍云计算环境中工作流系统资源调度的概念、挑战和相关的方法与设计方案。
二、概念与挑战云计算中的工作流系统资源调度涉及到将工作流中的任务分配给合适的资源进行处理。
工作流系统将工作流分解为一系列的任务，并将这些任务分配给云中的虚拟机、容器或其他资源进行处理。
这样可以保证工作流具有较好的并行执行能力和资源利用率。
然而，云计算环境中的工作流系统资源调度面临着一些挑战。
首先，由于云计算环境中的资源是动态变化的，资源的可用性、性能和成本会不断发生变化，因此需要不断调整工作流的资源分配。
其次，工作流系统中任务之间存在依赖关系，资源调度需要满足工作流任务之间的约束。
此外，资源调度算法需要考虑多个目标，如最小的执行时间、最小的成本等。
为了解决云计算环境中工作流系统资源调度的挑战，研究者们提出了许多方法与设计方案。
1.静态资源调度方法静态资源调度方法是在工作流开始执行之前就进行资源的分配和调度。
这种方法通常根据工作流中任务的需求和资源的可用性等静态信息，采用启发式算法或优化算法进行资源的分配。
静态资源调度方法可以在一定程度上优化资源的利用率和执行时间，但是对资源变化的适应性较差。
2.动态资源调度方法动态资源调度方法是根据实时的资源状况和工作流执行情况进行资源分配和调度。
这种方法可以根据当前资源的可用性和性能来决定任务的调度顺序和资源的分配。
动态资源调度方法可以实时调整资源分配，提高任务的执行效率和整体系统的性能。
3.基于遗传算法的资源调度方法遗传算法是一种模拟生物演化过程的优化算法，可以应用于工作流系统资源调度。
基于遗传算法的资源调度方法通过建立适应度函数、定义编码方式和交叉变异操作等步骤，对资源的分配和任务的调度进行优化。
can请求检索工作流任务调度算法在现代信息化时代，大规模数据的处理和任务的调度成为一项重要的挑战。
作为一种高效的任务调度算法，CAN （Content Addressable Network）请求检索工作流任务调度算法在分布式系统中得到广泛应用。
本文将对CAN请求检索工作流任务调度算法的原理、优势以及应用进行详细介绍和分析。
CAN请求检索工作流任务调度算法是一种基于P2P（Peer-to-Peer）网络结构的任务调度算法。
其基本原理是通过将整个任务空间划分为多个区域，并将这些区域映射到P2P网络中的不同节点上，从而实现任务的分布式调度和处理。
优势一：高效的任务调度CAN请求检索工作流任务调度算法通过将任务空间划分为多个区域，并将这些区域映射到P2P网络节点上，实现任务的精确调度和定位。
这种基于区域划分的方式使得任务能够更加均衡地分布在整个网络中，避免了任务的重复处理和负载不均衡的问题。
同时，CAN算法充分利用了P2P网络的优势，通过节点之间的相互协作和通信，实现了高效的任务调度和处理。
优势二：灵活的任务处理和分配CAN请求检索工作流任务调度算法允许任务在节点之间进行迁移和重新分配，从而在保证任务负载均衡的同时，还能够应对节点故障或者网络拓扑变化等情况。
当某个节点发生故障时，系统可以自动将该节点上的任务迁移到其他节点上进行处理，避免任务的中断。
同时，当新的节点加入系统时，已有的任务可以根据新节点的性能和可用资源进行重新分配和调度，实现系统的动态伸缩和扩展。
优势三：良好的健壮性和伸缩性CAN请求检索工作流任务调度算法具有良好的健壮性和伸缩性。
由于任务空间的划分和节点的动态调度，系统能够有效地应对节点故障和网络拓扑变化等不可预知因素。
当节点发生故障或者网络发生变化时，系统可以自动调整任务的分配和调度，保证整个系统的稳定运行。
同时，CAN请求检索工作流任务调度算法支持系统的动态伸缩，即随着任务量和节点数的增加，可以自动扩展和调整系统的规模和容量，提高了系统的吞吐量和性能。
工作流调度算法作者:qwerty | 源自:原创 | 发表日期:2007-4-14 | 阅读次数:242 | 【保存文章至硬盘】【打印文章】主要比较：OBE，Shark，OSWorkflow，jBpm。
分析一下他们的调度算法，就基本上可以知道其能力有多强。
OBE 的引擎调度机制说到开源引擎，首先就要说一下OBE，这是最早一款支持XPDL 的开源工作流引擎。
可惜由于没有良好的持续维护，到如今，虽然Adrian 依然还在对其进行一些补充和修改，但已经掩饰不出其“落寞”的容颜了（/james999/category/57982.aspx）。
OBE 的引擎运转调度算法是很简单的，其所有的调度规则都是依据于WorkflowRunner 类的run 方法。
采用遍历循环的方式，这个遍历机制就是：/***** 摘自WorkflowRunner 类的run 方法****/while (!_activityStack.isEmpty()) {//_activityStack 中暂存着需要被激活的活动实例ActivityContext ap = (ActivityContext)_activityStack.pop();_ctx.setActivityContext(ap.activity, ap.instance);//虽然叫execute，但是其实际上是一个激活活动实例的行为executeActivityInstance(ap.activity, ap.instance);}/*在初始化任何一个活动实例后，将这个活动实例放入_activityStack 这个堆栈中。
然后调用WorkflowRunner 的run 方法。
在这个方法中，遍历_activityStack 堆栈中的活动实例，进行运行。
*/但是什么情况下会激活WorkflowRunner 的run 呢？StartProcess，startActivity，completeActivity，executeTransition 这些情况下，都会造成run 的运行。
OBE 的调度算法是很简单，但是执行这个调度过程，是比较绕的。
想弄清楚到底如何运行的，大家有必要去仔细阅读阅读WorkflowRunner 类。
从StartProcess 方法开始，跟踪起startActivity，completeActivity，executeTransition 这几个方法之间的调用关系。
这样的引擎调度机制是比较单一的。
将一些控制判断交给了外围的过程。
引擎本身并没有多少实际的调度，只是一个执行体：获取需要执行（激活）的活动实例，然后执行（激活）。
工作流引擎核心调度算法与PetriNet by 胡长城（银狐999）补充一下，OBE 有个非常值得参考和吸收的地方，就是其Listener 的应用。
虽然Listener对引擎来说只是一个外设，但是却为其跟踪整个引擎得调度留下了很多可扩展接口。
当然OBE 内核主要是两个类：WorkflowRunner（负责引擎调度）和EngineContext （运行环境）。
Shark 的引擎调度机制和OBE 同样支持XPDL 的模型描绘语言的还有一个引擎Shark，Shark 是目前体系结构最为庞大和完善的开源工作流引擎。
不光提供了对分布式的支持（基于Corba），而且提供了多线程的事务安全控制。
Shark 的内部调度机制也比较简单，与OBE 类似。
Shark 的整个调度方法也基本上是基于WfProcessImpl 内的run 方法，也采用的是遍历循环的方式。
只是OBE 是遍历待激活的活动实例，而Shark 是遍历已经完成的活动实例，然后往下推进。
——估计Shark 是故意为了避免。
与OBE 类似，所以选择了这么一种算法。
因为你会发现，他们的执行推进机制是较为相像的。
Shark 遍历循环的机制是：/***** 摘自WfProcessImpl 类的run 方法****/protected void run (SharkTransaction t, WfActivityInternal lastFinishedActivity){//如说是启动流程，启动流程实例的时候，不指定lastFinishedActivityif (lastFinishedActivity==null) {Set starts=getProcessDefinition(t).getStartingActivities();for (Iterator it=starts.iterator(); it.hasNext();) {startActivity(t,asDefId,actDef,null);}}//开始遍历已经结束的活动实例while (lastFinishedActivities.size()>0) {if(!state.equals(SharkConstants.STATE_OPEN_NOT_RUNNING_SUSPENDE D)) {//执行当前活动实例后续的行为queueNext(t, (WfActivityInternal)lastFinishedActivities.get(0));lastFinishedActivities.remove(0);} else {return;}}}/*任何一个活动点完成之后（不论是Complete 还是Terminate），会将自身放入lastFinishedActivities 列表中，然后调用run 方法，促发对这个列表的循环遍历。
*/有兴趣对这方面研究的，可以看看WfProcessImpl 内的start、run、activity_complete、activity_terminate 这几个方法。
工作流引擎核心调度算法与PetriNet by 胡长城（银狐999）从调度机制上说，shark 和obe 基本雷同。
甚至可以看到，其两个运行类都基本上有些类似：shark 是WfProcessImpl 类，obe 是WorkflowRunner 类。
两个类都是即包含了调度的前推因素（比如起动流程实例、活动实例结束等方法），也包含了调度的规则运算（run 方法）。
唯一不同的就是，shark 是对已经完成的活动实例进行遍历，然后前推；而OBE 则是对需要激活的活动实例进行遍历，进行前推。
点评：OBE 和Shark 的run 调度方法，是比较常用的调度机制。
首先效率上比较还是可以，其实比较直观，也容易理解。
而且连个引擎的执行机制有一定的雷同，这可能是由于两者都采用XPDL 的缘故。
但是，受他们调度机制的影响。
OBE 和Shark 是很难支持复杂的运转模型，比如“抢占模式（Workflow Pattern 中叫延迟选择）”。
OSWorkflow 的引擎执行机制OSWorkflow 与其说是一个工作流引擎，不如说是一个“可嵌入式状态机”。
其机制并不类似于我们通常所说的“流程”。
其是以“动作（Action）”作为驱动的。
所以OSWorkflow 用在如“bug 跟踪”等处理流程中，是非常适合的。
从狭义上说，OSWorkflow 是不存在什么调度机制的。
如果硬要说的话，那么就可以从AbstractWorkflow 这个类的两个方法来看：doAction 和transitionWorkflow。
—— OSWorkflow应该说是一个执行机制：执行某一个Action，并将状态从A 转变为B。
这个状态的转变，可能是从一个step 的某一个status 变为另一status；也可能是从一个step 的某一个status 变为另一个step 的某一个status。
（注：对osworkflow 来说，step+status 表现为一个state）。
在这种状态变迁过程中，会执行一系列的Function。
当然，OSWorkflow 有很大的灵活性取决于其Function 机制。
这种Function 机制，有兴趣的可以参考参考。
最近很多人询问我，是否可以将OSWorkflow 用于他们的办公自动化系统中。
其实这方面OSWorkflow 处理起来并不是很适合，通常一个OA 的审批流程是很难用OSWorkflow 做的完美的。
JBpm 的引擎执行机制如果大家对UML 的Activity Diagram 很熟悉的话，理解jBpm 就易如反掌了。
在jBpm中也应用了Token。
但是这个Token 和PetriNet 的概念和语义是不同的。
jBpm 的token 是用于表示“任务分配给某一个actor（执行者，可以是人、系统等等）的依据”，也就是说，只有某一个actor 拿到token，才有可能去执行任务。
——当然，由于jBpm 这一块的算法，也局限了jBpm 的复杂逻辑处理。
从狭义上说，jBpm 这个也不能算是什么调度机制，也只能说是执行机制。
只是这个执行工作流引擎核心调度算法与PetriNet by 胡长城（银狐999）机制要比OSWorkflow 复杂很多。
OSWorkflow 的推进执行机制是Action 的执行，而jBpm 的推进机制则是Token 的转移。
在往下阅读阅读的时候，大家有必要把jBpm 的一些基本元素和理念搞懂。
可以参考：/james999/category/57982.aspx。
首先需要说明的是，jBpm 在将任务分配给某一个Actor（也就是jBpm 所描述得执行者）的时候，也会将一个Token 对象分配给这个Actor。
不论这个Actor 是执行“接受任务”还是“提交任务”，其首选都必须获取一个ExecutionService 对象（当然，每一个Actor 在获取其所需要执行的任务的时候，也就是获取一个token 对象标识，那么这个时候，token 的作用又似乎类似于我们通常所理解的WorkItem 意图）。
/***** jBpm 如何开发调用****/ExecutionService executionService =JbpmServiceFactory.getInstance().openExecutionService(actorId);InvocationLog invocationLog = null;//如果是启动流程实例invocationLog =executionService.startProcessInstance( definitionId,variables,transitionName ) ;//如果是结束任务State（State 是jBpm 的任务点，不要理解成了状态）invocationLog =executionService.endOfState( tokenId,variables,transitionName );当然，看到这儿，大家一定很关心，这个Token 到底是如何产生的？jBpm 引擎会在start of Process Instance 的时候，产生一个root-token。
