OSWorkflow与可扩展性设计

基本上以后设计脚本自定义支持、组件自定义支持时，可以偷懒的参考OSWorkflow的所使用的各种组件类型、设计、代码。

类似于Apache Camel，学到很多Endpoint的使用。

 

1.条件(Condition)可扩展。条件用于权限类、Join是否满足等。

 

Condition包括常见的BSF\BeanShell脚本、也可以与人员执行上下文关联、也可以是一个注册为JNDI的Condtion实现、EJB等。

Condition接口定义传入了必要的上下文信息，上下文信息比较优雅的将信息封装在transientVars、args、propertySet 中，考虑的较为周到，以更方便的在自定义脚本或实现中判断条件：

    public boolean passesCondition(Map transientVars, Map args, PropertySet ps) 
  

 

在流程定义使用这些Condition时，对“如何简化Condition类型定义”与“应用自定义”之间做了较好的平衡。

系统自带的：

    <condition type="beanshell">
	<arg name="script"><![CDATA[
					"Finished".equals(jn.getStep(6).getStatus()) && "Finished".equals(jn.getStep(8).getStatus())
					]]></arg>
</condition>
  

 

一个自定义的：

    <condition type="class">
        <arg name="class.name">com.packtpub.osw.TimeCondition
        </arg>
       <arg name="dayNumber">7
       </arg>
</condition>
  

 

2.Function可扩展。

 

 

 

3.其他可扩展的设置：
存储可以自定义为内存存储、Hibernate存储、SQL存储等若干方式，原则上可扩展。

 

 

4.与spring的结合。

目前OSWorkflow做到的是配置如何结合，采用Hibernate存储时如何结合。
感觉不愉快的地方是，若基于Spring实现一致性事务、强制应用也使用Spring+Hibernate。
可以将Condition Type、Function Type的名字类型的匹配做成SpringTypeResolver，感觉用处不大。

 

5.由于可扩展，可基于OSWorkflow实现与JBoss Drools做业务规则管理、与ESPer做企业复杂事件管理（CEP）、与Quartz做计划管理、与Penhato做企业仪表盘、做到Mule企业服务总线之上。

OSWorkflow与可扩展性设计