J++ = Java + ?

workflow接口劃分

1。應(yīng)用接口 Application Interface
－－interface1 工作流自身提供的服務(wù)接口
－－interface2 工作流與應(yīng)用之間的接口（主要是提供相關(guān)數(shù)據(jù)的調(diào)用接口）

2。擴(kuò)展接口 PlugIn Interface
－－interface3 工作流與組織機(jī)構(gòu)之間的接口
－－interface4 工作流與其他工作流之間的接口

將接口劃分成應(yīng)用接口與擴(kuò)展接口主要是依據(jù)工作流與相關(guān)應(yīng)用的調(diào)用關(guān)系，比如工作流與組織機(jī)構(gòu)之間，是工作流調(diào)用組織機(jī)構(gòu)中的人員信息，所以主動(dòng)者是WORKFLOW、被動(dòng)方是組織機(jī)構(gòu)，所以應(yīng)該采用擴(kuò)展接口來實(shí)現(xiàn)

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

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

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

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

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

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


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

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