J++ = Java + ?

workflow接口劃分

1。應用接口 Application Interface
－－interface1 工作流自身提供的服務接口
－－interface2 工作流與應用之間的接口（主要是提供相關數(shù)據的調用接口）

2。擴展接口 PlugIn Interface
－－interface3 工作流與組織機構之間的接口
－－interface4 工作流與其他工作流之間的接口

將接口劃分成應用接口與擴展接口主要是依據工作流與相關應用的調用關系，比如工作流與組織機構之間，是工作流調用組織機構中的人員信息，所以主動者是WORKFLOW、被動方是組織機構，所以應該采用擴展接口來實現(xiàn)

在擴展接口上應該采用Adapter模式，從而使工作流不局限于某個特定的實現(xiàn)

目前的進展
0。Application Interface接口已經基本實現(xiàn)了
PlugIn Interface接口目前基本完工，但OSWorkflow的實現(xiàn)實在是非常的丑陋，需要更改的地方太多，而且對于Interface3不可以使用它采用的User / Group模型（而且它使用了OSUser這個框架，對于多數(shù)的應用程序基本可以說不適合，而且它的User類竟然是Final ?!而且我發(fā)現(xiàn)它的很多類的屬性都是Protected！也就是說除了他們自己根本沒有辦法擴展，即使擴展也是很丑陋的方式）

1。現(xiàn)在最大的問題是它的WorkStore接口的擴展，我采用DB2的方式實現(xiàn)了它的接口，但這樣的方式會與DB2綁定在一起，如果自己寫實現(xiàn)就要根據不同的DB采用不同的SQL語言－也就是不同的方言策略？！而且考慮到性能估計不是什么好主意，看來明天需要更換成HibernateWorkStore的形式，這樣工作流的持久層接口將工作在Hibernate之上，看來很完美的解決了這個問題。

2。而且我擴展了它的PropertySet，使其不再依靠JNDI尋找DataSource，而是通過嵌入在程序內部采用JDBC的形式尋找數(shù)據庫連接，這樣我就不必為了驗證一個問題去建立那該死的數(shù)據庫緩沖池了（而且JNDI的形式也就不可避免的要用到容器，太重了！）

3。我編寫了UserGroupCondition的實現(xiàn)類，這個類的作用就是調用Interface3的方法，從而判斷某個用戶是否屬于某個組（現(xiàn)在的做法是讓WorkStore實現(xiàn)Interface3的偷懶辦法，但很亂，看來還是要寫一個Adapter去實現(xiàn)interface3才對！）

4。目前工作流引擎的工廠類已經實現(xiàn)完工并測試通過。


用了近一個月的時間完成了這些工作，看起來很少但是基本上大量的時間花費在熟悉工作流規(guī)范、WFMC標準、以及學習和擴展OSWorkflow接口上，不過對OSWorkflow的實現(xiàn)基本上掌握了，如果拋開OSWorkflow自己也可以采用自己的方式去實現(xiàn)，或者會考慮使用Spring的方式（Interface3的Adapter不行就采用Spring實現(xiàn)）。

BTW:
OSWorkflow的實現(xiàn)其實比較的丑陋！而且編碼根本沒有什么規(guī)范，接口的定義也是天馬行空，看來Heni除了他的大嘴外應該好好的提高自己的技術修養(yǎng)。－實在不敢恭維這位"大師"的編碼水平！