風雲變幻之JDO2.0

風雲變幻之JDO2.0

JDO2.0一波三折,尤其這一次,遭受重創。JDO2.0立項以後,道路就不平坦,平靜中潛伏殺機,我早已覺得有寫一點東西的必要了。

9月份的被迫的EJB合併,到現在的大打出手,可謂慘不忍睹。而投票結果更是多年來JCP中最具"政治"意味的投票,因爲沒有任何一個反對票是基於技術理由。

經過幾天的心情沉重之後,我終於可以靜下心來反思一下了,爲什麼會這樣,以後會怎樣,現在可以做什麼。。。

我正覺得有寫一點東西的必要了。

1       背景

JDOJava Data Objects,一個小巧玲瓏的輕量級對象存儲標準,從一出生就充滿了坎坷。單立項到第一版規範公佈,就花了三年時間,現世之初,功能還比較侷限,目標定位也比較窄,就是提供輕量級的對象包裝,不依賴任何特殊的中間件或J2EE容器,只要有JDK就夠了,做簡單的應用時,開發過程變得非常簡單,開發者不必再關心底層數據庫的實現細節,只需要以面向對象的觀念去組織、構建自己的數據對象模型,再操縱這個模型即可。在當今流行的“簡單就是美”的概念下,JDO這一點得到了很多人的認同,尤其是在紛亂的對象/關係映射領域,終於有一個統一一點的輕量級標準,實在是不容易。當然,此時的JDO還屬於概念級,很多人只是在觀望,同時提供有限的支持和推廣,象IBM,早期就有一些宣傳JDO的文章。隨着時間的推移,JDO廠商也越來越多,所屬的國家也越來越多(比較令人自豪的是Charles Huang領導的中國人自己的JDO產品:Liberator),慢慢呈現出國際化的趨勢,由於JDO廠商之間相互競爭,JDO產品的質量逐步提高,以廠商擴展(Vendor-Extension)方式提供的功能也越來越實用,JDO開始獲得開發人員的認同和實施,尤其是以前使用過EJB實體Bean的人(包括我本人在內),在經歷EJB的繁瑣的配置、發佈、調試過程和高要求的服務器環境維護以後,慢慢地將目光投向JDO,經過一些初始嘗試之後,大家嚐到了甜頭,加上JDO廠商衆多,免費到高端產品一應俱全,不太會成爲幾家廠商霸佔市場的局面,JDO開始進入實用階段。

JDO開發到底簡單在哪裏?快在哪裏?以筆者本人主管開發的兩個項目作例子可說明一切:

太平洋電腦網二手市場:http://es.pconline.com.cn/ 這是花了5個人天做出來的,包括設計和代碼開發,中途還多次修改或取消已完成的功能,數據庫結構也多次更改。在測試階段出現的BUG多是一些易用性方面的東西,比以前使用JDBC方式引起的數據不一致或關聯問題的錯誤少很多,時間上比以前使用JDBC方式至少節省了1個月時間,或者說60%的時間。

太平洋網站羣評論系統:http://cmt.pconline.com.cn/ 這是最近投入使用的一套讓網友對太平洋各網站文章進行自由評論的系統,雖然簡單,但數據量是很大的,在已有的幾百萬條評論的基礎上,現在平均每日發表的評論六七千篇,並且還在逐日上升,裏面完全是面向對象的設計,在實際性能和速度上比直接的JDBC要好得多。這一點足以說明JDO的伸縮性,應對大數量的數據庫開發也是遊刃有餘。當然,高性能的底層數據庫也是必要的基礎。

 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

好了,書歸正傳,剛纔談到JDO開始獲得普遍認同,各JDO廠商羣雄並起,儲侯爭霸,出現百花齊放的局面。不達,儘管很多廠商擴展功能實際上是一回事,但各家廠商有各家的特點和具體實現方式,特別是實現O/R Mapping映射都屬於廠商的擴展功能,讓開發者難以抉擇。在這樣的局面下,JDO2.0規範也箭在弦上,目標是將開發者常用的那些擴展功能都統一規範,讓開發者做出的JDO應用能在各個廠商產品之間最大程度地兼容,從而可以靈活選擇更合適的產品(考慮因素主要包括地域性、技術支持等),在2003年的JavaOne大會和8月的JDO2.0規範啓動會議上,大家制定了2.0規範的目標,開始緊鑼密鼓地制定新的API和語義標準。

在這段JDO快速發展的同時,Java世界本身也有了很多變化。J2SE1.4J2EE1.4的先後發佈,令開發者的應用開發更容易,JSP2.0的使用,讓Web開發容錯性更好,代碼更簡單。尤其要提的是,EJB3.0規範也開始進入制定過程,各大EJB廠商下決心痛改前非,將EJB不斷瘦身成一個苗條靈活的組件體系,讓開發人員不再爲複雜的配置和接口頭疼,甚至讓EJB不再依賴於J2EE服務器,而是直接提供POJO(簡單的Java對象)支持,不過目前還只是一個構思,還未成爲事實)。不過,EJB3.0是直接定位在JDK5.0的基礎上的,它的量產也依賴於JDK5的廣泛接受,而JDK5從業界的規律來看,估計要到2006年以後,纔會成爲主流。

 

JDO2.0經過專家組(包括我在內)一年多的努力,終於出臺了全新的規範,但好景不長,業界風雲變幻,如今形勢危急,尤其是在中國的傳統佳節—中秋節之後,漣漪變爲波瀾,真可謂是往事不堪回首月明中!

2       分析

這一節我們一起來仔細地琢磨琢磨此次風波的過程,Java世界的人間百態。

先說大氣候,EJB的複雜、O/R Mapping的混亂催生了JDO,而JDO又以簡單、輕量級的特點備受中小軟件開發企業的親睞。而大企業呢?一般決定軟件技術路線的人也是慢慢由中小企業吸收而來,這樣來看,JDO也會逐漸進入大型軟件開發,其靈活多樣的配置選擇能讓比較複雜的大型應用也完全運行在完全免費的體系架構上面,這種靈活性在業界中已經有LinuxApacheAnt等優秀的產品印證過。這個時候,對EJB絕對是一種考驗,一則儘量簡化,讓開發者知道EJB也可以非常簡單,二則突出JDO的弱點,比如生命期還年輕,技術支持不完善等等,三則直接將JDO吸收進EJB。結果這幾方面在實際變幻過程中,都得到了體現。

 

再說小氣候,這將涉及多個廠商或團體態度的逐漸變化

JDO的出現對開源團體是一大鼓舞,在JDO1.0出臺之初,JBoss是非常支持的,它還組織專門的團隊立項開發了JBossDO,作爲一個開源的JDO產品,因爲當時JBoss作爲J2EE平臺提供商,還未得到Sun的正式承認,在J2EE容器方面,JBoss已經做得不錯,而如果要提供企業級應用開發,一個數據庫底層是必要的,JBoss此時選擇了JDO,正是因爲JDO簡單,對開發者有吸引力,符合JBoss一貫的特點。不過在後期JBoss態度開始曖昧,先是JBoss終於得到Sun的正式承認(通過了J2EE TCK檢驗),然後是JBoss高層開始向商業化方向發展,並收購了同樣是有一定用戶基礎的開源O/R映射產品Hibernate,而Hibernate的負責人Gavlin King開始傾向於將Hibernate融合進EJB,成爲其POJO支持的底層,這時,JBoss自然需要向EJB傾斜,因此,作爲JDO2.0專家組的一員,JBoss在規範制定的後期開始逐漸淡出,直至如今投了反對票。

有些類似的是,Apache集團對JDO的態度也經歷了一些變化,只不過與JBoss正相反。最初,Apache旗下的Jakarta開發組有自己的幾套數據庫底層,象Turbine中的Torque,象OJBObject Java Bridge)等等,都是有一定有歷史的。JDO初期,Apache也只是觀望,並未給予很大支持,OJB中增加了一點對JDO API的接口,不過在相當長地時間內這方面都沒有什麼發展。不過作爲JDO2.0專家組的一員,Apache後期的貢獻非常大,它利用自己的開源優勢和實力,主動承擔JDO2.0示範產品(Reference Implementation)的工作,目標是爲廣大開發者提供一個強勁、易用、免費的JDO底層,讓自己在業界的聲譽和地位吸引更多的觀望者加入JDO陣營。這也是我比較崇敬的地方。

現在該Hibernate出場了,它原來也是一個獨立的O/R產品,免費和不斷改進是它最大的特點,可以說,它是原先紛亂的O/R市場中最引人注目的,尤其是在開源社區,它也因此獲得2003年最佳Java產品之一的稱號。很多對EJB不滿的開發者都嘗試並使用了它,成爲它廣大用戶羣的一員。最初Hibernate估計也是想成爲JDO的領導者,不過Hibernate特有的語法和完全針對關係數據庫的特點,不適合JDO的統一規範和麪向不只是關係數據庫的遠大目標,因此,Hibernate仍然是走着自己的路。Galvin King對業界的貢獻和他本身的恆心和毅力確實也是令人折服。不過JDO逐漸成熟起來之後,Hibernate是受到衝擊最大的,很多網上的爭論都是爲了在JDOHibernate之間得到一個明確的選擇。而這一時刻,EJB3.0正好想學習JDO的不依賴J2EE容器的靈活性,需要一個POJO支持的底層,Hibernate似乎是被相中了,之後Hibernate又被JBoss收購,開始唯JBoss馬首是瞻,並且JBoss在JDO2.0規範制定專家組中的代表就換成了Galvin King,那就是後話了。

Oracle一向對JDO不懷好感,它曾收購了Toplink,即在原來的O/R Mapping市場中性能似乎是最好的,但價錢也是最高、API也是最特別的一個產品。Oracle希望通過Toplink彌補EJB的不足,在非EJB的數據庫開發市場也贏得先機,達到全面盈收的目的。所以Oracle一直都是不支持JDO的,儘管如此,Oracle在去年的Toplink新版中,加入了很多類似JDO的元素,換句話說,就是將JDO的一些特點融合進Toplink中。

IBM最初對JDO還是挺支持的,IBM的一些技術專家還寫過文章介紹JDO。不過這兩年,IBM逐漸取代BEA成爲J2EE市場的老大,大型企業的數據庫開發選擇BEAEJB的也不在少數,因此不難理解IBM後期對JDO的強大表現出的擔憂。

HP就比較牆頭草了,在本次JDO2.0規範的最終投票上,在去年5月的JDO2.0早期規範(JCP制定Java規範的一個比較前面的必須過程)的投票中,HP堅定不移地投了贊成票,在前幾天的JDO2.0公衆評審版(JCP制定Java規範的一個比較後期的必須過程)的投票中,HP好象是一開始贊成,但在看了其它幾個巨頭的投票和評論後,也改投了反對票,真是讓人一聲嘆息!

日本富士通倒是冷眼旁觀,只簡單地說了一句希望解釋清楚與EJB的關係,就投了反對票。在這裏,我要感嘆一下,好象也沒看到富士通對Java業界有多大貢獻,但卻是JCP執行委員會的一員,很是令人納悶。如果是換成中國的聯想或方正,或許投票會公正些。

Borland公司一向是代表開發人員的,儘管它自己也是EJB廠商,但百花齊放,鼓勵競爭一向是Borland的原則,就象它同時推出Java.NETIDE一樣。

 

好了,我也不多說了,通過上面的一些簡單分析,我們可以看得出來,此次令人遺憾的JDO2.0投票結果,是Java業界大氣候與O/R Mapping界小氣候共同決定的,是不以人的意志爲轉移的。不過,在風雲變幻的過程中,我個人覺得還是有些地方做得不好,比如在JDO1.0出臺後,David Jordan寫了篇文章《CMP or JDO?》,描述CMPJDO的區別及如何選擇。或許那篇文章容易誤導讀者,將JDOEJB對立起來,進而引起不必要的糾紛。

3       過程與前景

JDO2.0規範從20038月制定願景開始,經過一番爭論地決定,在20044月正式開始了JCP的標準規範制定過程,即JSR2434月底對需不需要開展JDO2.0規範的投票中,IBMOracleBEA三巨頭的反對,就爲JDO2.0埋下了隱憂。不過規範制定專家組沒有理會這些,而是專心工作,逐步將前期討論的結果整理出來,在6月下旬公佈了前期草案(Early Draft)。之後,不斷討論如何讓開發者更方便地使用JDO,如何增加更多實用的功能到標準之中,完全沒有理會外界的風起雲涌。

作爲JDO的用戶之一,我能看到的比較大的很實用的改變就有:對完整的MapCollection框架的正式支持,JDOQL增強(自動識別參數和變量等等),關係數據庫的更完美支持(統計功能、保持數據結構不變的廠商間移植),數據存取細節的控制、二級緩衝的細粒度控制的API等等,都是非常有利於應用系統的擴展的。

直到9月份中秋佳節,我還請了幾天假去九寨溝耍了一把,玩得真是痛快,但回來上網才發現,大事不好,EJB要吞併JDO,合併後的規範還是叫EJB3.0,並且領導者不再是JDO的頭Craig Russell,而是EJB的頭Linda(巾幗不讓鬚眉!)。那幾天專家組裏人人都很是忿忿不平,尤其是大部分成員都是JDO廠商代表,他們的市場顯然會受到影響。這一次,我真是體會到了“月有陰晴圓缺”的道理!

大家緊急商量對策,不過,Craig Russell此時顯然受到了來自各方的壓力,包括他的上司,Sun的高層管理者。最終,一封公開信向公衆展示了JDO的屈服:“JDO2.0將只是JDO1.01的細微改進版,以完善舊版爲主要目的”。本來,我們的目的是先軟化矛盾,緩和衝突,再將已經制定的JDO2.0規範中的功能完善化,取越王勾踐之氣節,臥薪嚐膽,厚積薄發,以圖一出世而主宰市場。不過這一招看來是失敗了,因爲我們只想到了用戶會接受並推崇JDO2.0,而沒有仔細想過最終投票的卻主要是當今雄霸天下的EJB巨頭們。JDO2.09月份時已經是完全超越了1.0的功能範圍,加入了太多的實用功能,已經完全不是簡單的JDO1.0完善版了。正是公開信中的這句話,成爲今天備受攻擊的目標。

之後,JDO2.0專家組中的6位成員被挑選到EJB3.0專家組中,參與EJB3.0的規範制定,而Craig則頂住各方壓力,繼續完善JDO2.0

中國有句古話:是福不是禍,是禍躲不過。現在矛盾已經激化,並且在目前的形勢下,JDO只有繼續屈服。

 

不過,中肯地說,JDOEJB3.0都是面向簡單的POJO支持,如何選擇,很多用戶至今無所適從。這次投票正好將這個問題直接提上臺面,無論誰是誰非,對用戶而言,標準不統一最終會造成困擾。從現在的規範內容看,JDO2.0提供的功能確實要多過EJB3.0的範圍,並且現有的廠商支持已經足以讓用戶馬上開始進行JDO2.0的開發。而EJB3.0的規範定稿到最終的廠商產品大量出現,沒有1年的時間是不太現實的。換個角度,從用戶的角度看,EJB歷史悠久,至少知道EJB這個名詞的人比知道JDO的要多,也許EJB3.0更易被企業用戶接受。最好的辦法是以EJB3.0的名義推出JDO2.0,不過這當然是癡人說夢,一廂情願。此事古難全,還需另尋良方。

現在雙方的意見大概是EJB3.0會提供一套全新的APIEntityManager之類,這套API將支持J2EE環境和非J2EE環境,更直接地說,JDO2.0將會通過這套API得到支持,現有的JDO廠商的產品可以經過不太複雜的改造來支持EJB3.0POJO。從這一點上看,很可能EJB3.0的非容器版會更早上市。

而對JDO本身來說,此次投票並不意味着JDO的消亡,專家組下一步的工作是向EJB3.0看齊,將API、映射方式等細節與EJB3.0統一起來,也許會有一些Proxy API來橋接JDOAPIEJB3.0API,這樣,以後用JDO2.0開發出的東西可以方便地移植到EJB3.0的其它產品中去。

夜正長,路也正長,我們還會繼續走下去。。。

4       行動

我們現在可以爲JDO做點什麼呢?

其實答案並不複雜,讓更多人認同JDO,讓JCP執行委員會知道JDO的重要,就是我們的當務之急。至少我們可以做到以下幾點:

1.            在各網站和論壇發表文章,表達自己的觀點,尤其是熟悉英文的讀者可以去theServerSide.comonjava.comoreilly.com等知名業界媒體網站上去發表自己的意見

2.            說服投反對票的那些公司的人員。當然,這不是一蹴而就的事情,我們周圍如果有朋友在IBMOracleHP、富士通等公司任職並涉及Java開發,可以向他們介紹JDO的作用和重要性,他們可以向公司內的投票代表發郵件轉達意見

3.            最重要的,是開發者的意見,如果是已經在JDO上有投入並有一定積累的用戶,可以直接向JCP執行委員會發郵件質詢,描述自己的情況,爭取保護自己的投資

4.            JDO廠商,可以總結自己的客戶的情況,向JCP表明立場

 

據我所知,一些國外的使用了JDO的企業,就發出了質詢的郵件,希望JCP尊重自己的投入,不要因爲一些無意義的策略方面的調整導致JDO的終結。其中有一封郵件還直接發給了JDO規範組,痛罵規範組成員爲什麼投票反對JDO,當然,他這是搞錯對象了,把受害者當成了兇手。不過多多少少讓大家得到一絲慰藉:JDO後面還有很多用戶的支持!

5       參考

說了這麼多,並不能帶來多少轉機,更多的努力,要靠大家共同付出。

最後,給出一些鏈接,給各位讀者參考:

1.              JDO2.0規範主頁,上面有兩次投票的詳細情況鏈接,還有最新版規範的下載
http://jcp.org/en/jsr/detail?id=243

2.              JDO主要討論區
http://jdocentral.com/forums/index.php

3.              JDO2.0中對JDOQL的改進介紹
http://www.csdn.net/develop/Read_Article.asp?Id=26400

4.              JDO規範專家組組長Craig Russell的介紹
http://www.oreillynet.com/cs/catalog/view/au/1118?x-t=book.view&CMP=IL7015
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章