大音希聲、大象無形

對你前兩條的要求不是很理解。

1、為什么要自己控制POM和MANIFEST兩個文件呢？為什么不把所有的配置信息都放到POM里面，從而生成MANIFEST而要違背DRY法則呢？

2、我覺得把OSGi工程當作普通java工程來開發也不是什么不可以的事情。

一般說來，我覺得使用maven來開發OSGi程序還是很方便的。

Felix的Bundle插件可以自動計算出你需要import的包。這一點有的時候確實有點兒煩人（比如說，我要在我的bundle里面embed一個hibernate的jar，hibernate所有依賴的東西——JTA、DBDrivers、....所有的支持全都加到import配置中去了，實際上我只是想要hibernate中的幾個類而已），而且我沒有看到什么辦法可以解決，我的方式是對jar做自定制，排除掉所有不用的包。

新的SCA（目前已經是OASIS的規范了）標準的實現應該就是基于OSGi的吧？

好久沒有看這個方面，都有點兒生疏了。呵呵。

最主要是根據自己的需要做好IT規劃。
至于是否需要什么技術，要根據情況決定，不應跟采取跟風、什么流行就用什么的態度。

@BlueDavy

開發人員通常在開發的過程中都不會愿意去學習另外一種思路的東西（他們的項目經理更不愿意）。

由于Web組件還是視圖組件，它還要包括視圖組件的靈活性和用戶友好性。最后還要保證它的重用性。

要是開發企業級應用，還要保證組件的質量。

這些糾結在一塊兒就成了JSF標準。

Brooks說過“沒有銀彈”，所謂的合理的設計不過是在綜合各種方面后作出的最終的妥協方案。

技術本身無所謂好壞，要看它使用的場景。

我也非常推崇簡單化、敏捷化。但是，簡單和敏捷不是教條，過于追求復雜是不對的。同樣，過于追求簡單也是不對的。

@BlueDavy

controller可以薄，但是薄到用一個Hashtable來注冊Sevlet，太兒戲了吧？整個應用連一個基本的Servlet對象緩存池都沒有，怎么實現高可靠性和高可用性？集群支持怎么實現？更不用提復雜的Session處理了。目前的情況，做一個簡單的客戶端還可以，復雜的應用肯定吃不住。

我承認，Equinox的Http項目還是一個新的東西，還會有一條路要走。但是，現在就貿然使用，肯定是不明智的。至少，如果IBM的WebSphere是全面采用OSGI技術的話，用WebSphere的Http Bundle可能還會有一些價值。

我沒說OSGI不好，我說的是就目前的Equinox的Http項目的現狀，根本不適合拿它開發企業應用。只能適用于比較小的應用，或者Demo之類的。

Ruby確實有慢的問題，但是Rails對服務端的處理也不是那么草率的。目前為止，Rails是公認的進行小型Web開發的最好工具。如果真是開發需要RCP的小應用，不妨試試Rails + WebService + RCP的方式。那樣，開發效率也是很高的。

說不定，以后真有可能會出現OSGI Server。這也是一個產品線啊。

值得繼續關注。

OSGI的環境就是一個非常經典的SOA環境，把思路限制在O/R Mapping身上就錯了。

完全可以采用別的方式，我舉兩個：

1、采用ActiveRecord模式，中間需要一個從Domain Object到Active Record的數據遷移。
2、采用AOP的模式，在持久化操作時給Domain Object mixin持久化操作。

有趣的是OSGI只知道你是Service，根本不會管你到底是什么。那么，就可以讓腳本語言出馬啦。

如果再結合Annotation，可以實現腳本動態交織，能達到的效果是不可想象的。更有趣的是，這樣在理論上并不會比Hibernate的動態解析HQL然后生成SQL效率低。而且，我個人覺得用MixIn的方式更面向對象。

我現在就有這樣作的打算，我的初步想法是通過JRuby和OSGI把ActiveRecord這種模式以Service的方式實現，有想法的話可以跟我討論。
Mail: guitarpoet@gmail.com

@BlueDavy

恰恰相反，Equinox的HttpService的源代碼我看過了。那么簡單的設計根本就不可能處理大型的應用。

就它目前的狀態來看，基于Equinox來開發應用，還不如直接去用Rails開發。

Java EE的標準在短時間內是不可能被替換的，無論是從對現有投資的方面考慮還是從各大公司技術支持的方面（還有技術接受程度和技術人員培訓的方面）考慮。

除非，Java EE應用服務器全部放棄JMX而使用OSGI或者至少有至少兩種以上的成熟的OSGI的應用服務器出現。否則，我還是認為與Spring結合才是OSGI進入企業級應用開發的最好道路。

EJB的一個主要的意圖就是實現業務邏輯組件化（不管是實體Bean還是會話Bean），它的最大的優點就是對象生命周期容器管理和透明分布式調用。而OSGI就是實現組件化的一個非常好的實現，如果它能夠融合Spring的對象生命周期管理的話，再結合WebService，我不覺得EJB還有存在的必要了。很明顯EJB3中的實體Bean還是有一些作用的。但是，我個人覺得如果把O/R Mapping和ActiveRecord的方式融入到OSGI的Service中去，效果會更好（不但可以動態替換，還可以非侵入式拓展）。
當然，目前我也沒太看出來怎樣實現OSGI和Spring完美的結合。但是，如果它們能夠實現結合，這肯定對EJB是一個非常大的打擊。
呵呵，技術發展太慢或太快，受苦的都是底層技術人員。

OSGI和Spring結合以后，JavaEE還有多少生存空間呢？既然現在EJB容器都在采用OSGI技術，而OSGI的開發要比EJB簡單一些。那么EJB作為一種標準還有多少價值呢？

看來，并沒有什么短期內可預見的未來。

技術這樣發展下去，未來將是混亂的，不光是在兼容性方面。

看來，企業級應用系統的開發遠遠沒有達到成熟期，還有一段漫長的路要摸索啊。

哈哈

你并沒有仔細的看我的評論。

在目前的OSGI R4標準里面，我提的幾點問題好像并沒有規范。

OSGi + Web Service確實是解決方案，但它不是標準。你也看過SCA的規范吧？它也使用Web Service，但是它把使用Web Service整合到規范中去了。規范本身是可以整合任何技術的。OSGI不是不支持遠程Service調用，但是，說實話，我沒在規范中看到具體的實現方式。

我可以負責任的說：在OSGI R4中“沒有象Maven那樣的透明化獲取依賴的構件的‘標準’”（并不是說沒有實現，而是說沒有具體的標準）。

“標準里面的服務定義和發現功能太弱”不是我說的，是Eclipse的人說的。所以Eclipse才需要發明出自己的plugin.xml格式。Equinox也有自己的服務定義和發現方式。

OSGi作為一種技術確實是非常具有開創性的，正是這一點才如此吸引我。

但是，作為標準，尤其是實現SOA的架構的標準的話，尤其是跟SCA比，它還是有缺陷的。

我為什么要這么比？因為我覺得OSGI在基礎上要比SCA扎實，你不覺得SCA的xml太多了嗎？SCA還是靜態部署的，而且對于依賴版本控制也束手無策。

我期待的是，OSGI的下一個版本能夠成為一個比較完整的SOA標準，而不僅僅是一種動態加載的技術，呵呵。

在OSGI技術的使用上，我應該算是新手。所以，我希望能夠跟你探討在當前標準的基礎上，怎么去在具體的工作中去使用它，獲得它的優點，減少開發和維護的難度。呵呵。

OSGI的規范目前在SOA領域還不夠完整，雖然OSGI能夠解決工程依賴和版本控制黑洞，但是由于規范出發點不同，至少在兩點上我認為還需要加強。

其一、標準里沒有組件服務分布式調用
其二、標準里面的服務定義和發現功能太弱

所以，至少在目前的標準下，它不可能成為象SCA這種標準的SOA架構標準。

另外還有，它雖然有自己統一部署構件格式和相應的Repository，但是沒有象Maven那樣的透明化獲取依賴的構件的標準。

說實話，我非常看好OSGI，它以一個非常完美的方式實現了模塊化部署和構建的想法，如果能夠在下一個版本里面把上述的缺陷處理掉的話，在SOA的重要性越來越強的背景下，有IBM和Eclipse的支持，它的前景是很令人樂觀的。

目前來說，上述問題已經有人覺察到了，也分別實現了一些解決方案，但是，別忘了，它們都不是標準，在標準出臺之前，要充分考慮這方面的投資。

至于怎么整合進現有的應用，我也正在考慮方案，可以討論一下，呵呵。

@BlueDavy

項目經理的職責是跟你們公司的項目開發管理體制有關的。單純的就這個定義而言，沒有太多的可評價的東西。

一般說來，項目經理的職責是協調，尤其是在用戶、銷售部門、業務開發部門、技術支持部門之間對于項目的開發進行協調。

軟件的質量問題，對于比較大的公司而言，是有專門的部門、專門的人員進行管理的，項目經理沒有足夠的發話權（一般說來，項目經理不宜兼顧QA，既是開發者，又是監督者，用戶未必認可）。

是否是需求和開發分開來做（甚至是不同的人），還是采取XP的方式來做對于項目經理的要求是不同的。

團隊協調不利肯定是項目經理的失職。但是，反過來想，也有可能是你們公司的開發規范和開發管理制度不夠健全造成的。

@BlueDavy

Hibernate的二級緩存機制最好還是不要用，因為一個項目不可能保證所有的數據庫訪問全部交由Hibernate進行處理，而越過Hibernate 訪問數據庫的方式很容易就造成了Hibernate的緩存數據不一致的問題。

另外對于Hibernate的內置緩存是不支持集群的，即使采用oscache這種支持集群的Cache，你也會發現，由于緩存本身實現的特殊性，服務器端壓力的增加是很多的，也就是說，如果使用不當，對服務器端是壓力的增大而不是減少。

而使用得當的必須是對Hibernate熟悉的并且對JavaEE技術和服務端技術非常了解的開發人員，對于業務開發人員而言，這種要求過高了。

如同HttpSession的實現也是爭論不休一樣，Hibernate二級緩存能夠給你帶來的優點不多，但是給你的系統帶來的隱患卻不少，我的建議是，盡量不要用。只有在非常需要的情況下慎用。

如果你有項目開發的經驗，那么你就會明白，其實系統的更多的瓶頸是在于基本的編程錯誤的設計和技術的錯誤使用方式，對于二級緩存這種只是需求頻率不足10%的需要考慮的問題，大可在系統出現致命的瓶頸問題時再考慮

至于你說的處理緩存和頁面緩存，他們的最應該出現的地方應該是，耗費資源的幾乎不發生改變對象的構建（比如一些圖形、PDF或者需要通過腳本解析、遠程服務調用而獲得的Java對象），這些東西由于構造它們非常耗費服務器資源，而重復構造更是服務器資源的浪費，那么緩存它們是必不可少的

但是，別忘了，對于緩存而言，集群內部同步和內部對象失效和刷新機制也不是什么好玩的東西。想當然的認為使用它就會減輕系統的負擔的想法是不負責任的。必須在壓力測試的前提下進行試驗。

所以，我認為：除了耗費資源的幾乎不發生改變對象之外，其他所有的緩存（尤其是Hibernate的查詢緩存）都應該經過試驗后慎用，最好是不用，只在出現性能瓶頸的時候通過AOP的形式加入進去，我認為Spring框架就比較推薦這種方式

相輔相成吧，在我的觀點是一半對一半。

每一項技術之所以存在都是有它存在的理由的。

但是，技術是為客戶的業務服務的，軟件是面向服務的，開發企業級應用軟件必須要體現軟件的價值，而企業級應用軟件的價值不在于技術，而在于客戶價值的提升。

我忘了是誰說的了，“如果一個軟件公司的軟件功能不是由營銷部門確定而是由技術部門確定的話，真是一件可悲的事情”。

技術是基礎，不是目的

既然是JavaScript RIA，客戶端的JavaScript的重要性也要體會出來，估計樓主看過Rails的AJAX方案，也許那是個比較好的方案。

但是我還是比較看重直接進行客戶端JavaScript編程，只要實現了JavaScript的完善的包和引入機制（很遺憾，標準的JavaScript里面沒有），那么客戶端的編程完全可以采用JavaScript編程的方式進行開發，說句實話，這樣子學習曲線不會比自己發明一套框架陡，組件和可重用性也不會差而且工作量較低可測試性也比較高。

我非常贊同非侵入式的動態HTML頁面開發，說句不好聽的，模板式的動態HTML（比如JSP）根本不適合JavaScript RIA程序的開發，不但組件寫起來非常復雜，而且使用起來也是非常復雜，還跟容器密切相關，增加調試和測試的難度。

希望樓主能夠細致的講解一下具體的設計方案，尤其是在非侵入式動態HTML頁面開發、怎么與業務邏輯層無縫結合還有怎么進行良好的開發和配置方便的服務端頁面流和頁面導航上（這一點Tapestry做的就很不錯）。

至于頁面風格的變化，CSS就已經很強了，還可以通過SiteMesh進行框架的修飾，這個方面應該是比較成熟的了。

得看你針對的是什么樣子的用戶。他們是怎么用系統的。如果你是給一個大的企業或者政府機關作系統，還會跟它們的內部政治因素有關。這個方面不是界面漂亮、反應迅速、操作方便能解決的。

另外，還跟最終使用用戶的素質有關，總體來說，功能完全、反應迅速、操作方便是最重要的部分，至于漂亮不漂亮關乎他們領導的心情和審美，跟底層使用者關系沒太多的關系。

@mixlee
有趣，有趣，我真心的希望大家能夠看完整篇文章再下結論。

另，文中所說是我個人的想法，難免會有不足之處，希望各位高手不吝賜教。畢竟展現層的開發和設計不是我的專長。呵呵，在此先謝謝了。

我有一個問題，如果是采用velocity的模板技術生成JavaScript的話，JavaScript的調試是不是會非常費事呢？

我覺得采用AJAX的系統前端JavaScript的調試也是一個很重要的部分，如果采用模板生成JavaScript，那么調試JavaScript是不是會很費事呢？怎么解決這個問題呢？

目前我最推薦的方式是采用HTML模板技術（比如Tapestry），直接就可以在web容器外進行JavaScript調試

作學問切忌浮躁。樓主的想法是好的。只是行文中帶了一些浮躁，看起來有點像牢騷。呵呵，若是能讓看客幡然醒悟倒也是未必不是好文。

另，雖然沒有看過你們的開源框架，對你們的奉獻精神表示尊敬。

@fisher

其實我們的想法相似，只是表達方式上有所不同，呵呵。

很高興能跟你討論問題，軟件工程作為一門學科，現在離真正的成熟期還遠，在一定的時間內，概念的爭論是免不了的。

我覺得，在這種條件下，要想真正意義上的進行企業級應用開發，必須腳踏實地的采用注重實效的方法。

而且軟件開發還是要以人（客戶、開發人員）為本的，不管采用什么概念、技術和實現方法。

很多人都喜歡拿企業級應用類比汽車產業，其實可比性沒有想象中那么高，軟件開發畢竟是一個概念上的東西，與現實中的物質相比，它跟人的思想和人分析問題解決問題的方法更近一些。

古希臘的時候，人就開始對自身的概念和思維的邏輯進行探討，但是直到現在，還是沒有什么有突破意義的結果。

軟件開發更接近于哲學，這就是為什么編程高手一般都非常喜歡古典哲學。

其實，技術哲學也是哲學的一種啊。

計算機科學的發展，最后應該是跟人類的哲學的發展相互依存的。

馬克思說的真他媽有道理。

不過你并沒有真正的把Java的Proxy的概念用出來。
首先Broker不應該是Artist。
Broker只應該是InvocationHandler，Artist代理是Proxy的newProxyInstance方法自動構造出來的，Broker自己去找Artist（當然也可以采用IOC讓Artist自己去找Broker），通過InvocationHandler的invoke方法截獲Show方法，找適應的Artist去處理。
這個例子需要改進一下。

有趣，通俗易懂，符合面向對象的概念啊，哈哈哈

還好啦，我覺著用Maven2管理項目還是可以嘗試的。Java的最大缺點就是Lisence千奇百怪，如果SUN的Lisence能夠再“友善”一點、Maven2再成熟點，我想Maven2還是下一代的Java開發項目管理工具的。

@fisher

軟件開發必須以人為本，但是所謂的“團隊特色”是一個偽命題，團隊中的人總會流失（升遷、跳槽、借調），總會有新的人加入，這是業內的常識。如果針對團隊作出良好設計的人或是一個對各種技術十分精通的人被別的公司高薪翹走了，怎么辦？

合格的軟件公司都要有一定的應急機制，這也是對軟件質量保證的手段之一。這樣就不會因為某一個開發人員跳槽而造成手足無措的情況。

怎樣才能 達到這一點？那就是有效的分層，有效的把損失局限在某一個范圍內，就算是臨時拿新人頂，他也可以迅速的接替流失人員的位置。

當然，Brooks說過：“無論怎樣，項目肯定會延期”。但是要要盡最大可能的把損失降到最小。

太多的軟件工程書不顧現實的情況了，完美的人是不存在的，技術全才一般是不愿意只做技術的（這個東西真是有趣啊），我們得面對現實。

分層開發的最重要的特征是層與層之間的松耦合。松耦合所帶來的結果是，各層之間都可以有自己的基礎模塊，可以實現本層內部的重用，在底層發生變化的時候（變化協議、變化技術、甚至變化介質），上面的層是可以花費很小的成本進行適應的（比如操作系統和應用程序層）。

商業開發必須考慮開放成本，而有效的重用是降低成本的方法之一。

模塊化開發，估計每家做企業級應用的公司都必然會采用這個方式。拿用電系統來說，客戶服務模塊和電費管理模塊業務差距非常大，非業務專精人員，很難在短時間內寫出高效和高質量的代碼（光是業內常識就有的學的，而且各處業務還都不大相同）。

fanta的話是有問題的，對于不成熟的團隊，如果沒有成熟的技術框架進行支持和有能力的項目負責人進行管理的話，生產的軟件產品質量和工期就沒有辦法得到有效的保證。

實際工作中不完全遵照低耦合的分層設計其最主要的原因就是現實情況要比理論要復雜一些，如果放在以前的話，真是不太可能。但是目前來看我覺得還是有希望的，在接下來的幾天里，我就把我現在正在使用的技術設計方案貼上來。這樣也可以對這一種方式是否真的合乎生產實踐和能對軟件開發成本的降低起作用進行一下探討。