基本上以后設計腳本自定義支持、組件自定義支持時，可以偷懶的參考OSWorkflow的所使用的各種組件類型、設計、代碼。

類似于Apache Camel，學到很多Endpoint的使用。

?

1.條件(Condition)可擴展。條件用于權限類、Join是否滿足等。

?

Condition包括常見的BSF\BeanShell腳本、也可以與人員執(zhí)行上下文關聯(lián)、也可以是一個注冊為JNDI的Condtion實現(xiàn)、EJB等。

Condition接口定義傳入了必要的上下文信息，上下文信息比較優(yōu)雅的將信息封裝在transientVars、args、propertySet 中，考慮的較為周到，以更方便的在自定義腳本或?qū)崿F(xiàn)中判斷條件：

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

?

在流程定義使用這些Condition時，對“如何簡化Condition類型定義”與“應用自定義”之間做了較好的平衡。

系統(tǒng)自帶的：

    <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.其他可擴展的設置：
存儲可以自定義為內(nèi)存存儲、Hibernate存儲、SQL存儲等若干方式，原則上可擴展。

?

?

4.與spring的結(jié)合。

目前OSWorkflow做到的是配置如何結(jié)合，采用Hibernate存儲時如何結(jié)合。
感覺不愉快的地方是，若基于Spring實現(xiàn)一致性事務、強制應用也使用Spring+Hibernate。
可以將Condition Type、Function Type的名字類型的匹配做成SpringTypeResolver，感覺用處不大。

?

5.由于可擴展，可基于OSWorkflow實現(xiàn)與JBoss Drools做業(yè)務規(guī)則管理、與ESPer做企業(yè)復雜事件管理（CEP）、與Quartz做計劃管理、與Penhato做企業(yè)儀表盤、做到Mule企業(yè)服務總線之上。

OSWorkflow與可擴展性設計