OSWorkflow是只是一个workflow engine的内核体。我们都说osworkflow非常的易扩展，但是这也同样说明了，用osworkflow去实现一个能够运行的工作流系统是非常繁琐的事情。繁琐并不是难，因为你要想实现一个流程，不得不自己去实现大量的condition和function。
既然说到工作流，那么肯定会涉及到“任务交给谁做”的问题。但是OSWorkflow压根就没有管这种需求，对于其来说，其提供了c和f，如果再有什么额外的需求和功能，那么就扩展condition或function。于是，你不得不扩展一些function类去处理“角色”“任务分配”“提交任务”等等诸如此类的操作。
在我的标题中提到了workitem，这个概念几乎在其他工作流引擎都有所体现，但是对osworkflow来说，这是一个空白区域。至于workitem的含义，请参考wfmc的《Terminology & Glossary》。
OSWorkflow引擎只负责了“流程的运转”，当然这个运转会根据你所定义的Action和condtion来判断。Funtion对osworkflow来说，只是step、action、result执行过程需要调用的功能，至于这个功能作什么，OSWorkflow并不关心，引擎只是负责提供几个参数接口。
|
public interface FunctionProvider { public void execute(Map transientVars, Map args, PropertySet ps) throws WorkflowException; |
所有的Function实现类都必须实现这个FunctionProvider接口中execute方法，而且能够处理的信息，也全部来自这个方法中的三个参数：
|
transientVars |
这个是最为核心的参数，记录非常重要的一些对象，比如WorkflowContext，WorkflowEntry，输入参数等等。 |
|
args |
这个是function配置中的arg参数，具体请参考osworkflow dtd |
|
ps |
是PropertySet对象，记录了流程实例所需要保存的数据，可以理解成osworkflow所描述的流程相关数据。 |
具体transienVars中包含哪些对象，请参考 FunctionProvider api doc。
下面就说说如何利用Function进行任务的分配。
个人建议你在Step的pre-function中做处理，配置如下：
|
<step id="4" name="Assign"> <pre-functions> <function type="class"> <arg name="class.name">nucleus.assign.AssignmentFunction</arg> <arg name="Participant">A</arg> <arg name="ParticipantType">role</arg> </function> </pre-functions> <actions> ······ </actions> </step> |
看了这个配置形式，我想大家应该明白如何去处理。你可以在function中获取自己所定义的角色、根据角色获取人员、根据人员产生workitem······ 。你在function 所作的这一切操作对osworkflow engine来说都是透明的—— 你所产生的worklist所代表的含义只有你自己知道。
其中我为什么会附加了一个arg属性：actionID？这是因为我需要告诉每一个workitem在其应该处理哪一个动作。 因为外部程序都是通过Workflow.doAction(long, int, java.util.Map) 这个接口来激活流程的运转或改变实例的状态。
总体来说，利用osworkflow去实现一个完整的工作流例子，还是比较麻烦的。主要是要扩展和自己实现的太多。