Spring framework 市場持續擴大

SpringSource (以前為 Interface21) 接二連三在市場上有大動作。

首先是推出認證機制，通常能夠推出認證的都應該是市場上比較主流的技術，而且能夠被多數人所學習的。而且認證對於教育的市場有非常大的相關，也代表了將會有更多更多的人學會 Spring framework。

第二是在 SpringSource Team Blog 上公佈了 Spring framework 與 EJB 工作職缺的比較，內容發現了：

1. EJB 職缺需求持平
2. Spring framework 需求大幅提升
3. EJB 與 Spring framework 總需求有一定幅度的成長

這點正好呼應了為什麼 SpringSource 敢推出認證機制。

最後就是今天的新聞，SpringSource 買下 Covalent，Covalent 是一家做 Apache HTTP server 或 Tomcat 等等的技術顧問公司，也有在推 Terracotta。技術顧問公司本身沒有產品，SpringSource 買下來主要一定是看重它在市場上推廣技術的資源，而且有顧問公司，也可以更有力的深入企業客戶。

以往 JBoss 也是走顧問導向的方式，SpringSource 也走向這一步，是否能夠比 JBoss 的顧問方式做得更成功呢？ 如果 SpringSource 真的能夠再把市場擴大的話，就很有可能成為 Java enterprise development 的必要條件了。也許真的有那麼一天，所有的 Java developer 幾乎都會使用 Spring。當然到時會 Spring 也就不是什麼了不起的事情了。不管是不是真的有那麼一天，Spring 在市場上繼續擴大是沒有問題的，就技術而言，Spring 有很多替代品跟競爭者，但就市場面去看，Spring 目前是沒有什麼對手呀！

Unitils — 一次滿足所有 unit test 的需求

談到 unit test，大家馬上想到的應該會是 JUnit；又或許是比較新一點的 TestNG。有些比較有經驗的人可能就會提出，那 servlet 如何測試？Spring bean 又如何測試？DAO 又如何測試，怎麼去建立 DB 的資料？如何去 mock 一個物件？

這些問題早就出現了，也早就有解法了，只是每一個問題可能都會對應到一個  library 或小型的 framework。 一直都沒有一個一次把問題解決的方案，直到 Unitils 的出現。Unitils 發源於 Ordina J-Technologies 的一個 unit test discussion group，會中他們討論出一份 Unit testing 的 Guidelines，而 Unitils 正是這份 guideline 的實作。

在 unit testing framework 的部份，Unitils 是 JUnit3, JUnit4, TestNG 三種都支援，所以不管你最熟悉的是哪一個都可以順利的使用 Unitils。在功能方面，Unitils 主要 support 以下幾項功能：

• Assertion utilities
• Database testing
• Unit test database maintenance
• Testing with Hibernate
• Testing with Spring
• Testing with mock object

這些功能的文件都寫得很簡單易懂，其實觀念也很簡單，歸納一下只有幾個：

• 使用 Java 的 equals 去 compare 通常不會是我們真的要的狀況，所以提供了比較寬鬆的比較
• Unit Testing Database 必需要能夠自動的維護 (建立與更新版本)
• DB 的資料必需要能夠在測試中自動加入
• Test fixture 像是 Spring bean, mock object 等等盡量使用 annotation 標註，由 framework 自動產生

另外，Unitils 本身是由一堆 module 所組成的，如果它所提供的 module 還是無法滿足你的需求的話，要擴充其實很簡單。有興趣的人看一下 Unitils 的 source code 以及 unitils-default.properties 這個設定檔應該就知道怎麼做了。其實很難得一個小小的 unit testing framework 居然在模組化上做得這麼精美。

以前在這裡討論過 full stack application framework 的興起，同樣的 Unitils 這個可以滿足所有 unit test 需求的 framework 也很有可能慢慢會變成主流。只要一種技術成熟到一個程度之後，將會有整合的環境出現。在 JUnit、TestNG 都沒有太多的突破之後，Unitils 補足了這個空缺的需求。 如果你還在煩惱要怎麼開始做 unit test，那就用看看 Unitils 吧！

雜記

已經好久沒時間長篇大論了，不寫下一點東西又覺得很可惜：

• 在 Google Code 上開一個 project 比在 SourceForge.net 要簡單，不用慢慢審查。Subversion repository 的空間是 100MB，不過這種無政府狀態的環境會變成怎樣呢？雖然 SourceForge.net 也是一堆死掉的 project 沒人跟進。
• http://devshots.com/ 是一個 for developer 的 search engine，底下還是使用 Google，不過查出來的東西有差嗎？畢竟 developer 是世界上搜尋能力最強的一群人吧，或許對別的領域做點專用的搜尋引擎會比較有用。
• http://softwarecreation.org/ 這個 blog 的作者 Andriy Solovey 雖然我不知道是誰，不過他的文章都是引經據典，只要在做跟 software 相關的我想多少都有點幫助。
• ZK 己經推出 version 2.4 雖然我沒有很仔細看有什麼功能改進，不過我倒覺得功能已經不是最重要的一環了，ZK 如果要做得更好，需要有使用的 best practice。Framework 部份是很強大，不管是寫到像只有 JSP 沒有 Servlet 的 zscript 還是弄到像 Echo2 的做法，ZK 都可以 support，回到根本，Spring 跟 Hibernate 有很多人做出 best practice，後來官方也會提供指引，這是成功的 open source project 必需要走的路。再來就是整合性的 component，一堆強大的 UI 終究還是需要跟後端取得資料，這個地方會是關鍵。

Openkapow – 夢幻 mashup 工具

自從 Web 2.0 興起，國外網站的 mashup 大行其道。不過要自己去做 mashup 一直以來都不是件簡單的事，除非 service provider 本身就有提供夠強的 api 才會比較簡單一點。這也是我一直認為 Web 2.0 的網站應該要主動的提供 api，讓別人有機會去 mashup 你的 service。但國內各種 service provider 自然是不會想得這麼開了，幾乎全都是以鎖國政策以保護自己的廣告收入。歷史的教訓尤在眼前，鎖國政策可以長久嗎？自由與創意無限的網路世界，又怎麼會止於鎖國政策之前？只有提供使用者真正需要的內容與資訊才是長遠之計。接下來介紹一個可以把網站做成 mashup api 的工具。

TechCrunch 最近有一篇文章：5 Ways to Mix , Rip, and Mash Your Data，比較了幾個做 mashup 的工具，包括了剛剛推出很有名的 Yahoo! Pipes。而其中最強大的，就是 Openkapow，它的 mashup service 由一個 robot 的製作工具以及一個 hosting service site 所組成。使用者下載以及安裝它的工具之後，可以在本機開發出 mashup robot，再把 robot publish 到 service site 上分享給大家使用。雖然 robot 只有 publish 出來才能使用，但是對於 Web 2.0 的精神來說已經很足夠，不一定需要能在自己的控管範圍之內。Mashup robot 的型態分為：RSS/Atom、REST service 以及 Web clip，RSS/Atom 的 mashup 應不該不用多說了，把沒有 RSS 的網站做出 RSS。REST service 就是常見的 web services 模式，簡單的開發工具可以吃進一個網頁、輸入資料、頡取輸取。完全破解了沒有 mashup api 的網站，鎖國政策至此被強逼開關。而 web clip 的功能應該是 kapow 的老本行，把網站的一部份取出並存下來留作後用。雖然要下載工具，但工具簡單易用，加上 REST service 這個觀念正常的做法，讓 openkapow 發展出很多的可能性。

在mashup 工具日漸成熟之後，鎖國政策愈來愈不切實際，畢竟在資訊爆炸的時代，每個人都只想關心自己想關心的事情。使用 Openkapow 時快速上手的感覺讓我覺得 mashup 界的夢幻工具已經出現，破解鎖國政策的工具也已經出現，不管 service provider 是否願意，接下來 mashup 會愈來愈多，使用者為了單一事件到單一網站的情況會降低，個人化、而且可以由使用者群的意志去加強功能的系統，應該會愈來愈常見。或許不久之後，國內的 service provider 會對 Web 2.0 有新的定義。

technorati tags:Openkapow, RSS, Atom, REST, webclip

Blogged with Flock

The Role of the Enterprise Service Bus

InfoQ: Presentation: The Role of the Enterprise Service Bus

這是一個很讚的 ESB (Enterprise Service Bus) Presentation，演講者 Mark Richards 對 ESB 有非常深入的研究。演講回答了一個很多人會問的問題，為什麼要用 ESB？

根據 Mark 所說的，ESB 能夠把 business service 跟 implementation service 分開來，business service 是指該 domain 的一些服務，例如下單等等專業的語言；而 implementation service 只是一些 CRUD 一類的程式操作，來實作出像下單樣的功能。把這兩個部份分開完全合符了 SOA 的架構跟概念，也把 business process 跟 technical 切開。ESB 其中兩個重要的能力，process choreography 負責 business process 的管理；而 service orchestration 處理 implementation service 的串接。這是一個很重要的觀念。

演講最後提到了 open source 的 ESB，包括了 Mule 跟 ServiceMix。比較之下，Mule 比較像是一個 lightweight 的框架，讓你以 POJO 實作任何型式的 service。而 ServiceMix 則是已經把該有的都整合好，能以各種各樣的方式去實作出 ESB 的 end point。

ESB 雖然仍很少在實際上看到運用的機會，但它建基於 XML、Web Services、BPEL 以及 SOA 等等的概念與技術之上，成為一個實現學術界論文描繪的 Web Services 烏托邦不可或缺的架構。也是至今真正能把 BPEL 等技術串接起來比較讓人信服的方式。ESB 會不會就是以後資訊系統的樣子，則還要慢慢去觀察。

technorati tags:ESB, ServiceMix, Mule, InfoQ

Blogged with Flock

Client/Server? Client=Server? Ajax 的影響

登揚大在 Pixnet的新後台 中提到 client server application 之爭，我也就來寫寫故事吧。

Client/Server 架構，一般教科書上好像是這樣寫的，沒什麼特別，大概資訊人每個都知道是什麼。最早的 mainframe 跟 terminal 就可以算成 client/server 架構。那時 client 沒有什麼運算能力。後來 client 的能力慢慢提升，很多工作會落到 client 的頭上，一些程式也在 client 上跑，變成了 fat client。跟人一樣，過胖毛病總是多了些，fat client 要安裝程式，更新不易等等的問題。隨著 web 的興起，大家又要讓 client 瘦回來，提倡 thin client。這一瘦下來，就肥了 server，用 www 的人那麼多，什麼事都叫 server 做，不要命才怪。再說網路本身就是一個很大的瓶頸，速度當然就快不起來。現在的 Ajax，其實有點回去 fat client 的意味，把很多事丟回給 client 去做，server 要服務一群什麼都不會做的 thin client 真的很累，如果 client 好歹幫忙做點事，有一點頭腦其實就快很多。

Client=Server，當 client 就是 server，server 就是 client，P2P、Grid computing 等等，都是這個方式，想法就是把所有的運算能力、儲存能力視為一體，然後分配運用。每一個 node 是 client 也是 server。在教科書上，client/server 跟 P2P 被視為很不一樣的東西，不一樣嗎？或許吧，還不就都是程式 (廢話！)。Ajax 的出現，讓 browser 上也有可能做出類似 P2P 的效果，線上共同作業不是什麼大問題。

故事沒有結束，正在繼續發展，不管 thin client、fat client、P2P 還是 Grid computing 都有人在做，都有它的應用。潮流會在可能的選項中流竄，就 Web 而言，Ajax 的興起、Google 的野心，Web 正在走往 fat client 的方式，但這個新式的 fat client 少了下載安裝等等的缺點，Google 用以全力火拼 M$。M$ 兩面押寶，一方面推出 Vista、Office 2007 等等，一方面在 Windows Live!、Office Live 等等也下了不少功夫，似乎是有其市場佈局。Yahoo 夾在中間失了一點先機，但 Yahoo Widget 以及最近一波波上線的服務，其實也不是沒有機會，走中間路線的 Yahoo 沒有直接對上 M$ 也不全面跟 Google 開火，也許也是一個機會。

Mobile 方面，有很多人要把 Ajax 弄到 mobile 上，可見 browser 已經成為一個通用的平台，假以時日相信 mobile 上看網站也不會有任何不一樣了，包括 Ajax 的互動也可以實現 (3G 不要再用封包計費啦！ 不然有些 Ajax 的網站可能會把錢像倒水一樣倒出去的)。

戰爭不會結束，而 Web 2.0 以及 Ajax 也不只是表面上看到的而已，背後有更多更多不為人知的事情。網站流量也不是一切，搜尋準確度也只是眼前，能讓使用者在網站上留下有用的資料，再加以運用的，將會是最後的贏家！

Blogged with Flock

Full Stack Framework 的流行 – 從單點變套餐

我們去餐廳的時候，很常會點套餐。套餐省略了一一挑選的麻煩；對不了解菜色的人而言，套餐會從前菜到點心配好好的；通常也有一些折扣或是附餐。雖然失去了單點的自由度，但還是有很多人都會選用套餐。

Java，尤其是用在 web development 上，有各式各樣的 framework 跟技術。如果要一一選用跟搭配起來，往往是一種痛苦。畢竟能享受從挑選零件再組出一台跑車的人是極少數的人。每個元件都要弄懂也是一種很大的學習負擔。自從 Ruby on Rails 問世以來，很多人都喜歡上它的簡化跟整套 full stack 的 framework。或許是接受到 Ruby on Rails 的刺激，Java community 有很多類似的想法出現，如果你覺得慢慢把 Struts、Spring、Hibernate 等等全都學會再組裝起來很難的話，或許選用一個 full stack framework 也可以達到類似的效果。

以下點名一部份的 full stack framework，有些其實在 Ruby on Rails 之前已經出現了：

AppFuse：或許他不該叫 framework，它是一個把 Struts, Spring, Hibernate 等等 framework 預先組裝好的環境。其組裝的方式可以作為學習對象。Presentation Tier 可以選用 Struts/WebWork/JSF/Tapestry/SpringMVC；Persistence Tier 可以選用 Hibernate/iBATIS。AppFuse 已經在蠻成熟的一個階段了，我本身也在實際的 project 上運用過它，節省了不少開發時間。缺點是所用的 framework 也許不是在最新的版本。

JBoss Seam：這是 Hibernate 的作者 Gavin King 的力作。我個人非常喜歡這個 framework，原因不在它使用了 JSF+EJB3 這些 JCP 的標準，說真的如果不好用標準早是華而不實的東西。我喜歡它是因為大量運用了 annotation 減少了要開發的 code，而且那些 annotation 看得出來是在多次的經驗中提煉出來的，非常切合開發者真正的需求。而 JSF 跟 EJB3 的無間結合讓所要開發的 number of class 大量減少。如果沒有任何負擔的情況之下，我覺得 JBoss Seam 是最佳選擇。只是它目前還有些許的不成熟。

RIFE：一個很成熟的 framework，不過它的概念有點特立獨行，也沒有用到一些主流的 framework。看過它的 demo 我覺得它的想法有達到目的，但因為離主流有點差距，能得到的資源較少。它也可以跟 Spring 等等做整合。

Grails：由 groovy 為主軸的 full stack framework，目前還在很早期的階段。不過 groovy 這種 scripting language 的簡便，讓 Java 也有機會跟 Ruby on Rails 一拼。後端是以 Spring+Hibernate 為基礎。我覺得這個 framework 潛力很大。

其他如 Trails、Project Able 等等因為我沒有太多的研究，不一一詳列，事實上一定還有很多我沒看過或是已經忘記名字的 framework 存在。所能看到的是 full stack framework 的興起，如果是你要追求快速開發，也許要改為注意 full stack framework 的動向，而不單單是個別 framework。在以上的 framework 裡，幾乎都用到了 Spring，也就是說 Spring 這種 middle tier 的 framework 佔有重要的角色。當然 JBoss Seam 是用了 EJB3，不過功能上類似。而 middle tier 的能力就決定了 full stack framework 整合的能力。所以未來 Spring 或是 EJB3 的角色會更重要而使用更廣泛。

如果你還在煩惱用哪些 framework 作為你的 baseline，在學習怎麼把不用 tier 的 framework 組裝在一起的話，那麼何不看看以上幾個 full stack framework 呢？或許你單點的菜色其實跟套餐差不多，而套餐還送你附餐飲料呢！

technorati tags:Appfuse, RIFE, JBossSeam, Grails, Trails, ProjectAble, Struts, Spring, Hibernate, EJB, EJB3

Blogged with Flock

你用哪個 Ajax framework? – Ajaxian 的調查 (2006/09)

Ajaxian » Ajaxian.com 2006 Survey Results

Ajaxian 做了一個關於 Ajax framework 使用調查，在 865 個有效的受訪者中，Prototype 一支獨秀，有 43% 的人開發 Ajax 是用它。見圖：

<<From Ajaxian.com>>

而選用的 server side 語言，不意外的，PHP 佔了 50%：

<< From Ajaxian.com >>

另外，居然有 25% 的人不是用 framework 而用 XMLHttpRequest 手工打造。

我個人觀察以上的結果，有幾點想跟大家分享：

• 在 Ajaxian 這篇的 comment 裡，有人在討論到底 Prototype、Script.aculo.us 等等到底算不算 framework，在我的眼裡那些不是 framework，充其量是 js library 而已。
• 把 Dojo 拿去跟 DWR 比沒什麼意義，畢竟這些東西用法不同。應該先把 framework 分成好幾組，同一類的放一起比才會有意義。我看不出 Dojo 19% 跟 DWR 12% 背後代表什麼。所以第一張圖我只能把它當作品牌知名度投票了。而因為 Prototype 跟 Script.aculo.us 屬於底層的東西，會吃到比較多票數可想而知。
• 第二張圖對 Ajax 而言其實是附屬的投票，不過卻發人深省。PHP 佔了 50%，比起兩大陣營的 Java 37%、.NET 16% 多出很多。代表了其實 PHP developer 對於使用像 Ajax 這類的新的技術接受度跟進入的快速程度都比 Java / .NET developer 來得快。同時也許也表現了 Java / .NET 在 Ajax 的支援上並不夠強，影響了 developer 進場。
• Java 37% 遠比 .NET 16% 高，而 Rails 的 14% 只比 .NET 少一點點，反映了 .NET 在這塊雖然宣稱有 Atlas 強大的支援，不過由於相關的資源還不太夠，我想 .NET developer 會去用它的機會也不是很高。

最後一個感想是，如果你是開發 public 的 web site 的話，還是用 open source 吧。畢竟當三流的 PHP developer 也在用 Ajax 時，一流的 .NET developer 可能還沒有足夠的 support 去大量發展 Ajax。

Blogged with Flock

Validation with Annotations — 驗證新趨勢

Validation 是每個像樣一點的系統必備的功能，不過做法就有很多了。以 Java Web AP 為例，從 JavaScript 的 Validation 到使用 Java Code 去做，或是使用 Jarkata Commons Validator 都是很常見的方法，也各有優缺點。

最近在網路上出現了一些跟 Validation 相關的文章，包括有 Hibernate can meet your validation needs 和 Spring Validation with Java Annotations。或許你會奇怪，Hibernate 跟 Spring 並不是在處理 Validation 的事情的。到底是怎麼回事呢？原來現在最流行的 Validation 方法是使用 Annotation！在 domain model class 的 getter/setter 上加上 Annotation Tag，例如：@Required 就代表這個值是必需填入的。@Length(max = 10) 代表最長不能起過 10 個字元等等。在 domain model 宣告完成後，在需要時再由 Java 程式去執行驗證，而驗證是自動依據 Annotation 的設定所做的。

不管用 Hibernate 或是 Spring 做，概念上都大同小異。把 Validation 資訊放在 domain model 的好處是，不管在哪個 level 想做驗證，都會用到同樣的資訊。否則很有可能會變成在 User Input 寫一段，存取 DB 時又寫一段。而事實上驗證的資訊放在 domain model 事實上是最適合的了，因為驗證限制可以說是 domain model 的一項註解。

Annotation 在 Java 5 出現以來，有很多範例應用。但相對實戰上使用，而且必需要使用 Annotation 才能達成的任務一直都不是很多。直到最近，不少 Annotation 應用都已經成熟。不久的將來，Annotation 就會變成常用的 Java 語法，而系統中出現 Annotation 就跟出現平常的 code 一樣自然。

technorati tags:Annotation, Validation, Spring, Hibernate

Blogged with Flock

JBoss Rules (Drools) 的發現 – 以大廠手法玩 open source?

前幾天剛好有談到 JBoss Rules，才在想說 JBoss 哪時候也這麼先進，連 rule engine 都有了。之前的印象 Java open source 最有名的 rule engine 應該是 Drools 才對呀。結果，原來 JBoss Rules 就是 Drools … 很顯然在場的人功課都做不夠，外人不清楚就算了，做介紹的人也不清楚就讓人笑話啦。

話說回來，JBoss 已經從主打 AP server 完全換了一個樣子，上面應有盡有，連 Enterprise Service Bus (ESB) 的 solution 都快要推出了。只是這一下子推那麼多產品線，除了 JBoss Rules 這種買下市場上最強產品的做法，其他的要應付那麼多本身已經很專業的產品 (像 JBoss Portal vs Liferay)，JBoss community 是不是有這樣的 power 呢？

其實這又引出 open source commmunity 怎麼玩，是要用大廠的併購手法把自家的產品線變廣，還是沒必要做這種事呢？這個其實我沒有什麼答案，但如果是一個 business lead 的 open source，那也許已經失去了 open source community 的正真意義了。即使是 business product，很少有 user 是全部只買一家公司的產品的，因為大家都想說不要把蛋全放在同一個藍子。Open source 的 user 大部份都會有能力去判斷一個產品的好壞，而 open source 也沒有價格的問題，所以選擇的時候幾乎是產品的成熟度、技術的合適度以及 Community 的大小來做決定。這樣的情況下，何不把一兩個產品做好，而突然大開戰線呢？

套句五洲製藥的廣告詞：「有好的產品才有好的商標，有好的商標才有百年企業」，Apache 底下其實一堆 project，但不少人一聽到 Apache 就只知道是 HTTP Server，一個十年來無人能敵的產品。JBoss 就是 open source J2EE AP Server 的代號，如同大家順口說”寫 JSP 要灌 Tomcat“，”寫 EJB 就要灌 JBoss”。產品多元化是好事，但 open source 畢竟是貴精不貴多。再說 JBoss 在 AP Server 中永遠是被大廠拿來當炮灰或對照組用的，地位跟 Apache HTTP Server 可差多了。

technorati tags:JBoss, Drools, J2EE

Blogged with Flock