隨著開源文化的日益普及
參與開源
似乎也變成了一種時尚
一時間
似乎大家都樂於把自己的代碼拿出來分享了
就在新年前夕
我的一位老朋友
一位向來對開源嗤之以鼻的J
EE架構師竟然也發布了一個開源的J
EE應用框架（姑且稱之為
X框架
）
不得不令我驚歎開源文化的影響力之強大
可惜開源並非免費的午餐
把源碼公開就意味著要承受眾目睽睽的審視
僅僅幾天之後
國內幾位資深的J
EE架構師就得出一個結論
細看之下
X框架不管從哪個角度都只能算一個失敗的開源項目
究竟是什麼原因讓一個良好的願望最終只能得到一個失敗的結果？本文便以X框架為例
點評初涉開源的項目領導者常犯的一些錯誤
指出投身開源應當遵循的一些原則
為後來的開源愛好者掃清些許障礙
成熟度 打開X框架在SourceForge的項目站點
我們立刻可以看到
在
Development Status
一欄赫然寫著
? Production/Stable
也就是說
作者認為X框架已經成熟穩定
可以交付用戶使用
那麼
現在對其進行評估便不應該有為時過早之嫌
可是
X框架真的已經做好准備了嗎？
打開從SourceForge下載的X框架的源碼包
筆者不禁大吃一驚
壓縮包裡真的只有源碼??編譯
運行整個項目所需的庫文件全都不在其中
從作者自己的論壇得知
該項目需要依賴JBoss
JDOM
Castor
Hibernate等諸多開源項目
筆者只好自己動手下載了這些項目
好一番折騰總算是在Eclipse中成功編譯了整個項目
不需要對開源文化有多麼深刻的了解
只要曾經用過一些主流的開源產品
你就應該知道
一個開源軟件至少應該同時提供源碼發布包和二進制發布包
源碼包中至少應該有所有必需的依賴庫文件（或者把依賴庫單獨打包發布）
完整的單元測試用例（對於Java項目通常是Junit測試套件）
以及執行編譯構建的腳本（對於Java項目通常是Ant腳本或者Maven腳本）
但這些內容在X框架的發布包中全都不見蹤影
用戶如果想要使用這個框架
就必須像筆者一樣手工下載所有的依賴庫
然後手工完成編譯和構建
而且構建完成之後也無從知曉其中是否有錯誤存在（因為沒有單元測試）
這樣的發布形式
算得上是
Production/Stable
嗎？
開源必讀便捷構建 開源軟件應該提供最便捷的構建方式
讓用戶可以只輸入一條命令就完成整個項目的編譯
構建和測試
並得到可運行的二進制程序
對於Java項目
這通常意味著提供完整的JUnit測試套件和Ant腳本
你的潛在用戶可能會在一天之內試用所有類似的開源軟件
如果一個軟件需要他用半天時間才能完成構建
而且還無從驗證正確性
無從著手編寫他自己的測試用例
這個軟件很可能在第一時間被扔到牆角
從SourceForge的項目頁面可以看到
X框架的授權協議是Apache License V
（APL）
然而在它的發布包中
筆者沒有看到任何形式的正式授權協議文本
眾所周知
SourceForge的項目描述是可以隨時修改的（X框架本身的授權協議就曾經是GPL）
如果發布包中沒有一份正式的授權協議文本
一旦作者修改了SourceForge的項目描述
用戶又該到哪裡去尋找證據支持自己的合法使用呢？
在X框架的源碼中
大部分源文件在開始處加上了APL的授權聲明
但有一部分源碼很是令人擔心
例如UtilCache這個類
開始處沒有任何授權聲明
而JavaDoc中則這樣聲明作者信息
@author <a mailto:
>David E
Jones</a>
也就是說
這個類的源碼來自另一個開源項目Ofbiz
值得一提的是
Ofbiz一直是
商業開源
的倡導者
它的授權協議相當嚴格
凡是使用Ofbiz源碼
必須將它的授權協議一並全文復制
像X框架這樣復制Ofbiz源碼
卻刪掉了授權協議的行為
實際上已經構成了對Ofbiz的侵權
另外
作者打包用的壓縮格式是RAR
而這個壓縮格式對於商業用戶是收費的
對於一個希望在商業項目中應用的框架項目來說
選擇這樣一個壓縮格式實在算不得明智
而且筆者在源碼包中還看到了好幾個
jbx文件
這是JBuilder的項目描述文件
把這些JBuilder專用的文件放在源碼包中
又怎能讓那些買不起或是不想買JBuilder的用戶放心呢？更何況
出於朋友的關心
筆者還不得不擔心X框架的作者是否會收到Borland公司的律師信呢
開源必讀授權先行 在啟動一個開源項目時
第一件大事就是要確定自己的授權協議
並在最醒目的地方用最正式的方式向所有人聲明??當然
在此之前你必須首先了解各種開源授權協議
譬如說
GPL（Linux采用的授權協議）要求在軟件之上的擴展和衍生也必須繼承GPL
因此這種協議對軟件的商業化應用很不友好
相反
APL則允許用戶將軟件的擴展產物私有化
便於商業應用
卻不利於開發者社群的發展
作為一個開源項目的領導者
對於各種授權協議的利弊是不可不知的
除了源碼本身的授權協議之外
軟件需要使用的類庫
IDE
解壓工具等等都需要考慮授權問題
開源絕對不僅僅意味著
免費使用
開源社群的人們有著更加強烈的版權意識和法律意識
如果你的開源軟件會給用戶帶來潛在的法律麻煩
它離著被拋棄的命運也就不遠了
可以看到
不管從法律的角度還是從發布形式的角度
X框架都遠夠不上
Production/Stable
的水准??說實在的
以它的成熟度
頂多只能算是一個尚未計劃周全的開源項目
雖然作者在自己的網站上大肆宣傳
但作為一個潛在的用戶
我不得不冷靜地說
即便X框架的技術真的能夠吸引我
但它遠未成熟的項目形態決定了它根本無法在任何有實際意義的項目中運用
要讓商業用戶對它產生興趣
作者需要做的工作還很多
我剛才說
即便X框架的技術真的能夠吸引我
這算得上是一個合理的假設嗎？下面
就讓我們進入這個被作者寄予厚望的框架內部
看看它的技術水平吧
整體架構 在X框架的宣傳頁面上
我們看到了這樣的宣傳詞
X框架解決了以往J
EE開發存在的諸多問題
EJB難用
J
EE層次復雜
DTO太亂
Struts繞人
緩存難做性能低等
X框架是Aop/Ico[注
應為
IoC
此處疑似筆誤]的實現
優異的緩存性能是其優點
下面是X框架的整體架構圖
educitycn/img_///jpg > 可以看到
在作者推薦的架構中
EJB被作為業務邏輯實現的場所
而POJO被用於實現Fa?ade
這是一個好的技術架構嗎？筆者曾在一篇Blog中這樣評價它[
]
讓我們先回想一下
使用EJB的理由是什麼？常見的答案有
可分布的業務對象
聲明性的基礎設施服務（例如事務管理）
那麼
如果在EJB的上面再加上一 層POJO的Fa?ade
顯然你不能再使用EJB的基礎設施了
因為完整的業務操作（也就是事務邊界）將位於POJO Fa?ade的方法這裡
所以你必須重新??以聲明性的方式??實現事務管理
安全性管理
remoting
緩存等基礎設施服務
換句話說
你失去了 session bean的一半好處
另一方面
可分布的業務對象
也不復存在
因為POJO本身是不能??像EJB那樣??分布的
這樣你又失去了session bean的另一半好處
繼續回想
使用基於POJO的輕量級架構的理由是什麼？常見的答案有
易於測試
便於移植
開發
發布
周期短
而如果僅僅把POJO作為一層Fa?ade
把業務邏輯放在下面的EJB
那麼你仍然無法輕易地測試業務邏輯
移植自然也無從談起了
並且每次修改EJB之後必須忍受漫長的發布周期
即便是僅僅把EJB作為O/R mapping
而不是業務邏輯的居所
你最多只能通過DAO封裝獲得比較好的業務可測性
但
修改
發布
的周期仍然很長
因為仍然有entity bean存在
也就是說
即使是往最好的方面來說
這個架構至少損失了輕量級架構的一半優點
作為一個總結
X框架即便是在使用得最恰當的情況下
它仍然不具備輕量級架構的全部優點
至少會對小步前進的敏捷開發造成損害（因為EJB的存在）
並且沒有Spring框架已經實現的基礎設施（例如事務管理
remoting 等）
必須重新發明這些輪子
另一方面
它也不具備EJB的任何優點
EJB的聲明性基礎設施
可分布業務對象等能力它全都不能利用
因此
可以簡單地總結說
X框架是一個這樣的架構
它結合了EJB和輕量級架構兩者各自的短處
卻拋棄了兩者各自的長處
在不得不使用EJB的時候
一種常見的架構模式是
用session bean作為Fa?ade
用POJO實現可移植
可測試的業務邏輯
這種模式可以結合EJB和POJO兩者的長處
而X框架推薦的架構模式
雖然乍看起來也是依葫蘆畫瓢
效果卻恰恰相反
正可謂是
取其糟粕
去其精華
開源必讀架構必須正確 在開源軟件的初始階段
功能可以不完善
代碼可以不漂亮
但架構思路必須是正確的
即使你沒有完美的實現
參與開源的其他人可以幫助你
但如果架構思路有嚴重失誤
誰都幫不了你
從近兩年容器項目的更迭就可以看出端倪
PicoContainer本身只有
個類
數百行代碼
但它有清晰而優雅的架構
因此有很多人為它貢獻外圍的功能
Avalon容器盡管提供了完備的功能
但架構的落伍迫使Apache基金會只能將其全盤廢棄
所以如果你有志於啟動一個開源項目（尤其是框架性的項目）
務必先把架構思路拿出來給整個社群討論
只要大家都認可你的架構
你就有機會得到很多的幫助
反之
恐怕你就只能得到無盡的嘲諷了
技術細節
既然整體架構已經無甚可取之處
那麼X框架的實現是否又像它所宣稱的那樣
能夠解決諸多問題呢？既然X框架號稱是
AOP/IoC的實現
我們就選中這兩項技術
看看它們在X框架中的實現和應用情況
IoC
X框架宣稱自己是一個
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28779.html
