2006年4月24日
摘要: 這本書就是之前blog上寫的《構建高性能的大型分布式Java應用》一書，書稿完成后，覺得本書更多的仍然是偏向講解分布式Java應用的基礎知識，以及我個人工作經(jīng)驗的一些分享，于是改名成了《分布式Java應用：基礎與實踐》，本書目前已送往印刷廠印刷，下面是目前的一些關于本書的信息：
1、封面和目錄
http://bluedavy.com/?p=55
2、序
http://bluedavy.com/?p=60
3、豆瓣上書的信息
http://book.douban.com/subject/4848587/
閱讀全文
摘要: 本PPT只介紹了在Sun Hotspot V 1.6.0中：
1、內(nèi)存結構；
2、內(nèi)存分代，如何控制代大小；
3、可用的GC，每種GC對于參數(shù)的不同使用，例如SurvivorRatio、MaxTenuringThreshold等；每種GC不同的內(nèi)存分配策略和回收策略，但不涉及具體算法是如何實現(xiàn)的；
4、GC是怎么觸發(fā)的，日志是什么含義；
5、怎么使用上面的GC；
6、GC Tuning，簡單介紹了一些常見的GC調(diào)優(yōu)的目標時的瓶頸、可采用的方法等。
閱讀全文
摘要: 網(wǎng)絡訪問時，通常要做超時控制，要實現(xiàn)的好其實還是有些挑戰(zhàn)的，歡迎大家圍觀code show，并提供你的改進代碼，:)：http://bluedavy.com/?p=39
閱讀全文
摘要: 本次交流在4月24日圓滿完成，主題為關于JVM的那些事，撒迦@rednaxelafx給大家做了一個長達四小時的精彩分享，涵蓋了javac、解釋執(zhí)行、c1、c2編譯執(zhí)行方面的知識點。
由于視頻太大，感興趣的同學請從以下地址下載，自行觀看，:)，也歡迎看完后在twitter上，或在這里來進行討論，blog遷移到了bluedavy.com，地址在此：http://bluedavy.com/?p=36
閱讀全文
摘要: 摘自我那本6月份要上市的，但目前名字還沒完全確定的書，由于書中涵蓋的更多的為構建高性能分布式Java應用所需要的基礎知識，也許改成了《通往高性能分布式Java應用之路》，主要是闡述下為什么大型應用需要SOA，以及eBay的例子，blog全文請見：http://bluedavy.com/?p=30
閱讀全文
摘要: blog已轉移至bluedavy.com，感興趣的同學可以移步至此：http://bluedavy.com/?p=27
閱讀全文
摘要: 3月30日Twitter在其engineering blog上寫了一篇Unicorn Power的blog：http://engineering.twitter.com/2010/03/unicorn-power.html，寫的挺經(jīng)典的，按我的理解來講下這篇blog吧，如有錯誤，請幫忙糾正，:)，blog已遷移至bluedavy.com，感興趣的同學可以訪問這個地址來查看全文：http://bluedavy.com/?p=25
閱讀全文
摘要: 由于blog開始轉移到bluedavy.com，感興趣的同學可到此圍觀：http://bluedavy.com/?p=23，本篇blog從看一個超市發(fā)展的過程中，收銀碰到的問題以及解決方案來闡述互聯(lián)網(wǎng)的技術。
閱讀全文
摘要: blog開始轉移到www.bluedavy.com，因此感興趣的同學請訪問http://bluedavy.com/?p=18
閱讀全文
摘要: 由阿里云龍浩同學牽頭的杭州程序員圓桌交流，第一期主題為并發(fā)編程，把自己的經(jīng)驗也分享下，在活動結束后會公開此次交流的資料，具體PPT請見文中。
閱讀全文
摘要: 在QCon SF 2009的SOA分會場上，eBay的架構師講了一個SOA @ eBay的PPT，正好和我的工作有很多的交叉點，于是比較認真的看了下這個PPT，感興趣的同學可以從這里下載：http://qconsf.com/sf2009/file?path=/qcon-sanfran-2009/slides/SastryMalladi_SOAEBayHowIsItAHit.pdf，在這個PPT中可以看到eBay對于SOA的看法以及他們目前的做法，自己也是做這方面工作的，就在這篇blog中介紹下這個PPT以及自己對于SOA的一些看法。
閱讀全文
摘要: 本篇blog將講述coroutine的一些背景知識，以及在Java中如何使用Coroutine，包括一個簡單的benchmark對比，希望能借助這篇blog讓大家了解到更多在java中使用coroutine的方法，本篇blog的PDF版本可從此下載：http://www.bluedavy.com/open/UseCoroutineInJava.pdf
閱讀全文
摘要: 公歷的2009已經(jīng)過去，2010來臨，不免俗的也對自己個人2009做一次回顧，同時對自己的2010做一次展望，希望自己的2010能過的更加精彩。
閱讀全文
摘要: In product env,we always need to monitor gc trend or tunning gc based on gc trend,before sun jdk 1.6+,we can use GCViewer to visualize gc log to see gc trend,but it not support jdk 1.6+,so I write a free open source tool to visualize gc log produced by sun jdk 1.6+,now V 0.2 release,If you need,pls download from http://code.google.com/p/gclogviewer/.
閱讀全文
摘要: In this blog,I'll test the coroutine supported on jvm,now famous is scala actor & kilim,this blog show the program reliazed with scala actor/kilim/java,let's compare these three program performance.
閱讀全文
摘要: 在HPTS大會上，Randy Shoup放出的eBay的PPT有所改變，在原有的5個Architectural Lessons上又增加了5個lesson，從這也可以一定程度的看出當訪問量、數(shù)據(jù)量、功能不斷上漲后，碰到的技術問題也將繼續(xù)發(fā)展，想必這也是eBay增加5個lessons的原因，eBay在技術方面的發(fā)展對很多互聯(lián)網(wǎng)公司都有一些參考意義，畢竟它已經(jīng)經(jīng)歷過了國內(nèi)很多網(wǎng)站目前的階段甚至是幾年后的階段，在本篇blog中就完整的來看看eBay的這10個lessons、eBay的應對策略以及我個人的一些推測。
閱讀全文
摘要: 本書預計共八章，目前完成五章，由于本書需要涵蓋Java分布式應用、高性能java應用、可伸縮的java應用以及高可用java應用四方面的知識點，編寫的難度不小，因此在此先行放出目錄和樣章，希望能夠得到大家的一些反饋，以保證本書的質(zhì)量，目錄&樣章下載地址為：http://www.bluedavy.com/opendoc/bookpreview.pdf
閱讀全文
摘要: 非常強烈的推薦下BTrace這個工具，用了后不得不說太強大了，BTrace簡單來說，就是能在不改動當前程序的情況下，運行時的去監(jiān)控Java程序的執(zhí)行狀況，例如可以做到內(nèi)存狀況的監(jiān)控、方法調(diào)用的監(jiān)控等等，官方網(wǎng)站上有非常多詳細的例子，我不說太多，只在下面舉一個簡單的例子來說明它的作用，BTrace的User Guide請見：http://kenai.com/projects/btrace/pages/UserGuide。
閱讀全文
摘要: 摘自《構建高性能的大型分布式Java應用》第六章，感興趣的同學們可以看看。
GC策略在G1還沒成熟的情況下，目前主要有串行、并行和并發(fā)三種，對于大內(nèi)存的應用而言，串行的性能太低，因此使用到的主要是并行和并發(fā)兩種，具體這兩種GC的策略在深入JVM章節(jié)中已講解， 并行和并發(fā)GC的策略通過-XX:+UseParallelGC和-XX:+UseConcMarkSweepGC來指定，還有一些細節(jié)的配置參數(shù)用來配置策略的執(zhí)行方式，例如：-XX:ParallelGCThreads、-XX:CMSInitiatingOccupancyFraction等，新生代對象回收只可選擇并行，在此就舉例來看看兩種GC策略在Full GC時的具體表現(xiàn)狀況。
閱讀全文
摘要: 和清華學子做了一次關于OSGi的交流，在此公開下這個PPT，:)，這個PPT是我寫的最長的一個OSGi PPT,涵蓋的內(nèi)容主要是OSGi標準方面的知識以及Equinox使用的一些知識，感興趣的同學可以下載下: http://www.bluedavy.com/opentopic/OSGi20094qh.pptx
閱讀全文
摘要: 架構師接龍是《程序員》雜志最近推出的一個活動，活動方式為：每期一個提問嘉賓，一個回答嘉賓，并由回答嘉賓提出新的問題給下期的架構師，形成接龍，之前第一期是支付寶的馮大輝提問，騰訊的研發(fā)總監(jiān)王速瑜回答，我參與的是第二期，這期會登在《程序員》0909期上，內(nèi)容轉帖如下，原帖為程序員官方上的：http://www.programmer.com.cn/727/，呵呵，都只是個人的片面理解做出的回答，也歡迎大家在此帖中繼續(xù)討論，:)
閱讀全文
摘要: 這篇文章中總結了一些構建可伸縮性系統(tǒng)的最佳實踐，總結的不錯，于是翻譯了下，原文在此：http://akfpartners.com/techblog/2009/08/11/scalability-best-practices/，翻譯內(nèi)容如下。
閱讀全文
摘要: 在將Hessian從3.0.13升級到3.2.0時碰到兩個bug和一個ClassLoader處理策略的改變的問題，在此記錄下，希望能為使用Hessian 3.2.0的同學們提供點幫助，避免再走同樣的彎路。
閱讀全文
摘要: 幾年以來，eBay在幾個不同的大會上先后分享過幾次關于eBay技術的PPT，在這篇blog中，就以這些PPT來以旁觀者的角度分析下eBay的技術發(fā)展歷程，不論eBay現(xiàn)在的業(yè)績?nèi)绾危豢煞裾J，他們的技術還是挺強的，因此還是值得學習，eBay的整個技術發(fā)展歷程從一定程度上來說可以認為是互聯(lián)網(wǎng)公司的典型技術發(fā)展歷程，基本上各家互聯(lián)網(wǎng)公司都在走著類似的路線，只是各家選擇的語言不同、具體的實現(xiàn)方案不同、細節(jié)不同，當然，思路是一方面，實現(xiàn)又是另外一方面，只有兩者結合才能實現(xiàn)一個高可用、高性能和高并發(fā)的有海量數(shù)據(jù)的系統(tǒng)。
閱讀全文
摘要: 這本書的名號有：國內(nèi)第一本OSGi中文書，全球第二本OSGi技術書，少數(shù)的能夠領先于英文技術原創(chuàng)書出版的中文書籍，這些都乃虛名，最重要的是希望這本書能真正的為希望了解、學習或深入掌握OSGi；希望了解、學習如何編寫模塊化、動態(tài)化的Java應用的Java技術人員提供一些幫助，那么也就不枉這本書的出版了，很榮幸能參與這本書的編寫，圓了自己兩年前出一本OSGi書的夢，下面放上一些本書的封面的圖片show下。
閱讀全文
摘要: Equinox的設計非常經(jīng)典，其在擴展方面提供了很多的支持，同樣包括類加載方面的控制，除了通過標準的org.osgi.framework.bootdelegation以及equinox提供的osgi.parentClassLoader這兩個屬性來簡單的控制類加載之外，還可通過實現(xiàn)ClassLoaderDelegateHook來更為靈活的控制類加載。
閱讀全文
摘要: 很不容易，經(jīng)過兩個多月兩個人的努力，終于完成了《OSGi原理與最佳實踐》一書的草稿，目前正在review過程，預計將在7月底上市，而由于國外的那本《OSGi in action》將出版時間推遲到11月了，《OSGi原理與最佳實踐》這本書也將成為全球第二本OSGi的書籍（很遺憾，德國之前出版了第一本），:)，現(xiàn)將本書的目錄公布如下，上市的書也許會稍有改動，但應該會大體一致。
閱讀全文
摘要: 這是Lifecycle Layer中的最大改進，在之前的規(guī)范中只是簡單的描述了下框架的啟動和關閉，在制定了這個規(guī)范后，以后無論是啟動equinox還是felix，都可采用同樣的方式啟動，詳細的來看看，本文摘自《OSGi原理與最佳實踐》。
閱讀全文
摘要: 本文內(nèi)容同樣摘自《OSGi原理與最佳實踐》，在之前的blog中也摘選了部分內(nèi)容分析了Equinox的動態(tài)化，在這里再試驗下Felix的動態(tài)化，關注點為：“即插即用”、“熱部署”、“即刪即無”，看下Felix在這幾方面的表現(xiàn)和Equinox有什么不同。
閱讀全文
摘要: 對于采用OSGi來做系統(tǒng)的人而言，ClassLoader的問題必然是頭號需要解決的問題，如果又是個需要遠程通訊的OSGi應用的話，那么反序列化的classloader問題幾乎可以肯定是會碰到的，來看看在如今流行的兩種序列化、反序列化協(xié)議：java/hessian中如何使用自定義的classloader。
java/hessian并不提供直接的傳入ClassLoader類來改變反序列化時采用的ClassLoader，hessian采用的為使用當前線程的上下文ClassLoader來加載反序列化的類，java則采用堆棧上最近的一個ClassLoader類來加載，可以認為就是調(diào)用類所在的ClassLoader來加載，但在OSGi應用中，通常采用以上默認的行為來反序列化加載類是會出問題的，因此需要采用自定義的。
閱讀全文
摘要: 對于想使用Equinox來構建OSGi應用的同學們而言，掌握Equinox是如何加載Bundle中的Class無疑是相當重要的，這樣在碰到各類ClassNotFoundException的時候也就有底了，否則可能出現(xiàn)的ClassNotFoundException會多的讓你非常的頭疼，本文提取自《OSGi原理與最佳實踐》，介紹下equinox是如何來加載Bundle中的class的。
閱讀全文
摘要: OSGi最吸引人的特性除了模塊化之外，就是動態(tài)化了，在我之前寫的OSGi實戰(zhàn)以及進階兩篇Opendoc中，都有相關的示例，但不知道大家有沒有注意，在兩篇Opendoc中都未提及到bundle本身的更新，而基本都是以新增服務實現(xiàn)的bundle以及停止服務時限的bundle為例，并且相對而言是個比較簡單的例子，動態(tài)化在java界更明確的詞也許是hot deployment，而hot deployment的實現(xiàn)并不容易，同樣，即使你采用OSGi，但也不代表你的應用就具備了hot deployment的能力，在hot deployment上，完美的結果就是當更新完成后，新的執(zhí)行請求就在新的代碼邏輯上正確的執(zhí)行，就像沒發(fā)生過更新這回事樣，但實際要做到這樣的效果，遠沒這么容易，即使是基于OSGi也同樣如此，No magic & no silver bullet，在本篇blog中我們就來具體的看看。
閱讀全文
摘要: 在這篇blog中放置了我收集的一些網(wǎng)站架構相關的PPT和文章，提供給大家下載，如果大家有相關的好的PPT、文章的話，也歡迎推薦給我，非常感謝，:)，這篇blog的內(nèi)容也會隨著我收集的東西增加而變化，同時也會增加我對于這些PPT、文章的看法和評價。
閱讀全文
摘要: 把自己寫的兩篇opendoc和Book統(tǒng)一放入此blog中提供下載，避免占據(jù)我blog的兩個置頂位，:)
閱讀全文
摘要: 在使用OSGi時，有些時候會需要在OSGi容器外獲取OSGi服務，加載OSGi容器加載的class，或者說需要內(nèi)嵌OSGi容器，本篇blog以一個簡單的例子來說明如何基于equinox實現(xiàn)OSGi容器的內(nèi)嵌，或者說通過程序來啟動equinox，同時也通過此例子展示下如何在容器外來獲取OSGi服務以及加載OSGi容器里面其他插件的class，同時還會附送一個如何讓OSGi容器里的插件能加載到OSGi容器外的類的方法。
閱讀全文
摘要: 此次QCon北京大會為期三天，總體而言，精彩紛呈，尤其是第二天，完全將大會的精彩推至了高潮，讓大家覺得值回票價，總結而言，這次大會是相當成功的，一次成功的大會不能缺少的有兩個要素：知名的嘉賓和精彩的Topic，無疑QCon北京大會很好的把握了這兩個要素。
知名的嘉賓，此次大會出現(xiàn)的嘉賓絕對足夠重量級，看看Title就嚇人了：Spring老大、ThoughtWorks首席科學家、Dojo creator、eBay搜索核心架構師、Amazon云計算戰(zhàn)略師、淘寶首席架構師、支付寶首席架構師、豆瓣技術總監(jiān)、優(yōu)酷首席架構師、網(wǎng)易有道技術總監(jiān)等等。
精彩的Topic，不是說嘉賓知名Topic就一定精彩的，不能不說，這次大會還是有些爆冷門的，嘉賓不是很知名，但演講的Topic確實還不錯，而且也不是說知名的嘉賓就一定能給出精彩的Topic，就像Martin Fowler這次的Topic，實在稱不上精彩，總體而言，這次大會并不缺少精彩的Topic，來分享下我的收獲。
閱讀全文
摘要: JVM是Java程序的運行環(huán)境，因此對于JVM的掌握有助于理解Java程序的執(zhí)行以及編寫，尤其是運行時碰到的一些詭異問題，那么怎么樣能考察自己對于JVM關鍵知識點的掌握情況，幫助學習JVM機制呢，在這篇blog中來探討下。
閱讀全文
摘要: 在產(chǎn)品中有碰到過使用LinkedBlockingQueue.poll時超時很不準的現(xiàn)象，關鍵是這不是一般的不準，如果只是一點點不準的話也就勉強接受了，例如指定poll的超時時間為100ms，但最終執(zhí)行.poll這段代碼就花費了8000ms的現(xiàn)象，這篇blog就是展示下通過一段小小的代碼來重現(xiàn)這樣的現(xiàn)象，畢竟沒有重現(xiàn)是無法證明為什么會出現(xiàn)這樣的現(xiàn)象的。
閱讀全文
摘要: 本文摘自《構建高性能的大型分布式Java應用》一書，Garbage First簡稱G1，它的目標是要做到盡量減少GC所導致的應用暫停的時間，讓應用達到準實時的效果，同時保持JVM堆空間的利用率，將作為CMS的替代者在JDK 7中閃亮登場，其最大的特色在于允許指定在某個時間段內(nèi)GC所導致的應用暫停的時間最大為多少，例如在100秒內(nèi)最多允許GC導致的應用暫停時間為1秒，這個特性對于準實時響應的系統(tǒng)而言非常的吸引人，這樣就再也不用擔心系統(tǒng)突然會暫停個兩三秒了。
閱讀全文
摘要: 記得自己在沒有進入互聯(lián)網(wǎng)行業(yè)之前，對于互聯(lián)網(wǎng)行業(yè)并不怎么感冒，總覺得互聯(lián)網(wǎng)行業(yè)的技術含量不高，沒什么意思，值得進入互聯(lián)網(wǎng)行業(yè)了，才明白，原來互聯(lián)網(wǎng)行業(yè)的技術是這么的復雜，這么的困難，而構建一個擁有巨大用戶量的系統(tǒng)無疑也會給自己帶來更多的成就感，記得自己剛進入互聯(lián)網(wǎng)行業(yè)的時候，才發(fā)現(xiàn)構建一個高并發(fā)、高性能、承受高壓力、高度可伸縮以及高可用性的系統(tǒng)要掌握的知識體系是在太多了，而且這些知識體系根本就不是在學校或是google、網(wǎng)絡中能夠?qū)W習到的，于是當時就想，如果能有一本書全面的介紹構建這”五高“特性的系統(tǒng)需要掌握的知識體系，那將是多么的美好呀，畢竟很多的知識體系都是靠經(jīng)驗積累出來的，甚至可是說，是痛苦的教訓等得出來的，但當然，要在一本書中完全講清楚所有的知識體系，自然是不靠譜的，但我想我會盡量在書中表達出自己的一些觀點、看法以及少少的經(jīng)驗吧，希望能夠讓更多的同學即使沒有大型系統(tǒng)的實際經(jīng)驗，也能掌握到一些大型系統(tǒng)所需的知識體系，那么我心甚慰了，由于本書需要寫的東西非常的多，預計在9月底完成寫作，估計要到明年春節(jié)后上市，:)，以下先揭秘下本書的大概內(nèi)容，也請大家多多提出意見。
閱讀全文
摘要: 之前的Opendoc中沒有涉及過此部分的內(nèi)容，maven又是現(xiàn)在非常流行的java的工具，再加上到目前為止搭建OSGi Maven開發(fā)和部署的環(huán)境還是比較的麻煩，覺得有必要寫篇這樣的blog，:)，在這篇blog中來看下如何搭建一個比較好用的OSGi Maven開發(fā)和部署環(huán)境，看看我在搭建一個這樣的環(huán)境中的痛苦歷程。
閱讀全文
摘要: 記得Martin大叔在《企業(yè)應用架構模式》中特別強調(diào)：“能夠不分布式的應用就不要分布式”，這句話沒什么問題，尤其對于做過分布式應用的人而言，就更會有深刻的體會了，但這個世界偏偏就沒有那么簡單，大多數(shù)人都會碰到分布式應用的場景，尤其是對于大型應用而言，從集中式步入分布式是不可避免的，只是也許是小型分布式的，也許是大型分布式的；也許是有高性能要求的，也許是沒有的，在這篇blog中我們來看看java應用從集中式步入分布式后到底會帶來些什么挑戰(zhàn)。
閱讀全文
摘要: XSS漏洞是網(wǎng)站漏洞中最容易出現(xiàn)的一種，至少現(xiàn)在的各大網(wǎng)站中基本都存在，傳聞只有gmail是唯一一個完全不存在的，或者說攻擊者沒找出漏洞的，也許是因為XSS漏洞看起來危害并不是那么的大吧，所以基本上沒有得到過太大的重視，從而也就造成了這么多的網(wǎng)站存在著一些很簡單就能發(fā)現(xiàn)的XSS漏洞，在這篇blog中以我這個網(wǎng)站安全的外行人的角度來侃侃XSS漏洞攻擊以及防范的措施。
閱讀全文
摘要: 近來連續(xù)調(diào)試了好幾天的代碼，樂趣無窮，:)，在純凈的人和機器對話的時間中，充分的和機器不斷的交流，最終共同實現(xiàn)功能，和同事說：“我喜愛調(diào)試代碼勝過了寫代碼”，怎么說呢，我覺得調(diào)試代碼能夠充分讓你將所掌握的知識發(fā)揮出來，考察自己解決問題的能力以及學習知識的能力，在這篇blog中來閑聊下調(diào)試代碼。
閱讀全文
摘要: 近期參與了幾個大學的校園招聘，總體下來感覺還行，由于校園招聘需要面的人很多，差不多面試流程都形成模式了，在面試的過程中，有不少學生問過我，到底面試的標準是什么，不過每個面試官的標準都是不同的，所以也就注定了面試是會有些不公平的，是否對面試官的胃口會起到很大的決定性因素，當然，最重要的還是實力，很多學生會認為面試不公平，但我覺得這也算是從學校進入社會的第一課吧，工作后學生們會發(fā)現(xiàn)更多不公平的事，對于學生而言，無論是應屆畢業(yè)的本科、碩士，我的面試標準都差不多，考察的為Java基礎、Java框架、設計模式、互聯(lián)網(wǎng)架構的了解，當然，在最后會問一些其他的問題，例如大學學習情況呀、一兩年后對自己的期望呀、優(yōu)勢和不足、最近看過的技術新聞等等，在這些所有的問題的背后，考察的最重要的是基礎掌握的是否扎實、學習能力、反應速度、抗壓能力以及技術興趣。
閱讀全文
摘要: 在面試中，經(jīng)常要評估面試者的java基礎知識和其他知識的掌握情況，包括public/private/protected/默認修飾符、static/final修飾符、集合、字符串操作、對象比較、異常、設計模式和面試者經(jīng)常使用的框架等，整理一下自己經(jīng)常使用的評估方法，:)，拋磚中，希望能看到一些好的建議，讓大家更好的學習java知識，同時也更好的判斷人才，挖出真正的“金子”。
閱讀全文
摘要: 隨著OSGi近兩年的迅猛發(fā)展，尤其是Java企業(yè)應用領域廠商對OSGi的認同，大家對于OSGi的新版規(guī)范的關注遠遠超過了之前的幾個版本，近來OSGi終于是放出了傳聞已久的R 4.2的Early Draft，其實從Early Draft來看，我覺得完全可以認為不僅僅是一個小版本的升級了，甚至可以認為是R5了，因為R 4.2增強的東西還是非常多的，其中就包括了大家期待已久的RFC119，不過沒看到傳說中的RFC66，有一丁點的失望，不過相信后面的Draft中應該會加上，:)，這樣看來，R5更是值得期待了，讓我們先來一起品嘗一下4.2 Early Draft這道大餐。
閱讀全文
摘要: 之前也有一些介紹大型網(wǎng)站架構演變的文章，例如LiveJournal的、ebay的，都是非常值得參考的，不過感覺他們講的更多的是每次演變的結果，而沒有很詳細的講為什么需要做這樣的演變，再加上近來感覺有不少同學都很難明白為什么一個網(wǎng)站需要那么復雜的技術，于是有了寫這篇文章的想法，在這篇文章中 將闡述一個普通的網(wǎng)站發(fā)展成大型網(wǎng)站過程中的一種較為典型的架構演變歷程和所需掌握的知識體系，希望能給想從事互聯(lián)網(wǎng)行業(yè)的同學一點初步的概念，:)，文中的不對之處也請各位多給點建議，讓本文真正起到拋磚引玉的效果。
閱讀全文
摘要: 應該是差不多兩個月前收到了這本書，一直到最近才抽出時間來看了下，這本書的開篇的第一題現(xiàn)在基本已經(jīng)成了經(jīng)典中的經(jīng)典了，相信很多人都因為這個控制 CPU使用率的題從而買了這本書的，在我自己看過這本書后我同時相信買了這本書的人應該會覺得非常的值得，要寫出合理實現(xiàn)需求、高性能以及大數(shù)據(jù)量的程序，數(shù)據(jù)結構和算法就成為關鍵要素了，這本書用簡短的題目給大家回顧了一些經(jīng)典的算法。
閱讀全文
摘要: 不是專職做壓力測試這行當?shù)模荒苁且宰约旱慕?jīng)驗來以外行人的眼光來說說壓力測試，壓力測試并不僅僅是個壓力測試的過程，而是一個相當系統(tǒng)的工程，我認為壓力測試是為了讓系統(tǒng)達到所期望的運行效果以及承受所期望的壓力，這也就要求壓力測試應該幫助性能調(diào)優(yōu)團隊，為其提供一定程度的指導，在這里我不將壓力測試和性能調(diào)優(yōu)分的那么清楚了，在我看來，壓力測試過程包括了：明確壓力測試的目標、構建壓力測試案例、進行壓力測試、分析壓力測試結果、尋找瓶頸并進行調(diào)優(yōu)以達到目標，在這篇blog中來細看下這幾個過程以及常用的方法。
閱讀全文
摘要: 這篇文章的第二部分在昨天也發(fā)布出來了，于是抓緊時間把它給翻譯了。在這篇文章的第一部分中，作者結合自己的經(jīng)驗對如何構建具備良好的垂直擴展能力的Java EE應用做了講解，在這第二部分的文章中，作者則對如何構建具備良好水平擴展能力的Java EE應用來進行了詳細的講述，常見的session復制問題，水平擴展中經(jīng)常需要涉及的分布式文件系統(tǒng)、分布式緩存、分布式并行計算，全文讀下來，作者基本指出了構建可擴展的Java EE應用需要了解的知識體系（如需深入的話還有必要進一步的學習，例如集群技術、通訊協(xié)議、線程、并發(fā)等）和平時實踐中的一些注意事項，應該說是篇十分難得的好文章，值得推薦。
閱讀全文
摘要: 這是一篇從TheServerSide上翻譯過來的文章，很自豪這篇這么好的文章是一個中國人（從作者名字上猜想應該是中國人吧，:)）寫的，原文地址為：http://www.theserverside.com/tt/articles/article.tss?l=ScalingYourJavaEEApplications，可以說，這篇文章寫的是非常的不錯的，這是文章的第一部分，探討了如何構建可垂直擴展的Java EE應用，文中談論到的讓所編寫的Java EE應用具備垂直擴展能力的幾個關鍵要素，例如熱鎖問題、盡可能的縮短同步塊、不要在static方法上加鎖、多使用Atomic包、jvm內(nèi)存不能設置的太大等，文中除了列了這幾個關鍵要素外，還詳細的解釋了為什么不能做以及如何避免出現(xiàn)這樣的現(xiàn)象，可以很明顯的看出作者在這些方面是具備了非常豐富的經(jīng)驗的，因此這篇文章不僅僅講述了可擴展性理論方面的知識，同時也很好的從實戰(zhàn)角度進行了分析，之后我也會結合這篇文章來說說自己曾經(jīng)碰到的垂直擴展場景的反例，同時也很期待這篇文章的第二部分，第二部分將探討如何構建可水平擴展的Java EE應用，翻譯的不好的地方還請大家多
閱讀全文
摘要: 之前寫了個簡單的jsp做壓力測試，沒想到出現(xiàn)的一個問題是當壓力比較大的情況，運行比較久的話會出現(xiàn)一個現(xiàn)象，就是jvm的內(nèi)存幾乎被耗盡，用 jprofiler查看會發(fā)現(xiàn)是有一個ConcurrentHashMap對象的內(nèi)存一直在增長，而且沒有釋放的跡象，隨后進入Debug模式，跟蹤查找都有誰new了ConcurrentHashMap，因為測試場景中是個非常簡單的jsp頁面，發(fā)現(xiàn)只有jsp的Request session會創(chuàng)建這個ConcurrentHashMap，很久沒寫jsp了，猜測是request session的默認超時時間太長，所以導致高壓力下(200并發(fā)，總共連續(xù)訪問50萬次，jvm內(nèi)存1G)會出現(xiàn)內(nèi)存一直沒有回收的問題，后來打印了一下request session的默認超時(AS是jboss 4.2.2)，是半小時，如果這樣的話確實是會有造成上面內(nèi)存一直被占用的現(xiàn)象。
閱讀全文
摘要: 在JBoss Remoting 2.2.2中存在這么一個bug，如果剛好客戶端的timeout比服務器端處理時間短的話，就會出現(xiàn)客戶端連接池中的連接被無故用掉一個的狀況，而且是沒法回收的，最終就會導致很快客戶端的連接池被占滿的現(xiàn)象，在分析JBoss Remoting 2.2.2的代碼后發(fā)現(xiàn)了問題的所在，同時查看了下JBoss Remoting 2.4的代碼，發(fā)現(xiàn)在2.4中此bug已被修復。
閱讀全文
摘要: 性能調(diào)優(yōu)無疑是個龐大的話題，也是很多項目中非常重要的一環(huán)，性能調(diào)優(yōu)的難做是眾所周知的，畢竟性能調(diào)優(yōu)涵蓋的面實在是太多了，在這篇blog中我們蜻蜓點水般的來看看性能調(diào)優(yōu)這項龐大的工程都有些什么過程，同時也看看這些過程中常見的一些做法。
閱讀全文
摘要: Java 5并發(fā)包的加入，給Java的并發(fā)程序的開發(fā)帶來了很多的好處，在此列舉一些并發(fā)編程中應該掌握的一些基礎知識片斷，這些片斷基本都是由一些問題組成，在片段中沒有直接寫出答案，由于可用來解決這些片段的方法還是很多的，因此只是提到了解決問題可選方案的關鍵字，如果有需要進一步了解的話，基本上 google一下應該就能查出來了，不過就像之前有朋友說的，如果不是經(jīng)常用的話，其實就算現(xiàn)在知道了也是會忘記的，這很正常，:)，不過我更認為那是因為知其然而不知其所以然造成的，很多東西如果知道原理的話，基本上還是可以記得很長一段時間的。
閱讀全文
摘要: 精通這個詞估計是在簡歷中最常見到的詞了，簡歷上通常都充斥著精通struts2、精通java、精通hibernate等等詞語，近來經(jīng)常看些比較底層的書，越來越體會到精通這個詞應該具備的份量了，也越來越理解以前朋友和我說的在國外工程和研究是分的很清楚的原因了，在這篇blog里來扯扯自己對精通這個詞的看法。
先來看幾個面試的片段，從中也許能看出些端倪，:)
閱讀全文
摘要: 由于Topic的時間有限，因此此篇PPT只是簡單的對OSGi進行了介紹和演示，而沒有做詳細的OSGi使用的講解，可能讓參與這次Topic的同學們失望了，不過還是在此把PPT公開出來了，如感興趣的話，可以從以下地址下載：
http://www.riawork.org/opentopic/Simple.Introduction.For.OSGi.ppt
閱讀全文
摘要: JavaOne的第二天Sun正式官方宣布在Java 7中將支持OSGi：This will allow developers who create applications that use OSGi bundles will be able to run them unmodified in JDK 7.這消息對于知悉OSGi Vs JSR 277的一系列歷史戰(zhàn)爭的人而言絕對是非常的振奮人心，盡管不是說Java 7直接納用OSGi來實現(xiàn)模塊化這一塊（這個呢，其實如果JDK做的話，確實可以做的更好，至少可以更高效什么的），但就支持這一點也可看出Sun已經(jīng)看到了OSGi是事實性的模塊化標準，這對于OSGi來說也是里程碑的一天。
閱讀全文
摘要: Java領域中的分布式框架比較的多，分析一個已有的遠程調(diào)用框架無論是對于打算采用已有成果還是自己做分布式框架，都是很必要的事情，JBoss Remoting是其中很好很強大的一個框架，在此來對JBoss Remoting進行深入的分析，看看JBoss Remoting是如何基于java.net提供的包去解決這些問題的，本文所分析的JBoss Remoting源碼的版本為2.2.2_SP2，本來以為會是篇不怎么長的文檔，沒想到還沒寫的詳細和深入的時候就已經(jīng)有三十多頁了，也不好在這里直接貼出來，就把文檔目錄和最后的總結部分貼在這了，感興趣的同學們可以從這個地址下載PDF版本的文檔：http://www.riawork.org/opendoc/JBoss.Remoting.Opendoc.pdf
閱讀全文
摘要: 非常感謝Kane的工作，其實在差不多兩個月前就完成了和OSGi官方聯(lián)盟的協(xié)議的簽訂，使得OSGi China User Forum成為了繼法國、日本、韓國、西班牙以及瑞典后的第六個官方授權和認可的組織，并且拿到了OSGi聯(lián)盟官方提供的空間，其實就是個簡單的wiki了，只是一直沒抽出時間去建設網(wǎng)站，Kane在百忙之中抽出時間把站點的基本頁面進行了搭建，使得這個官方站至少看上去有點內(nèi)容了，官方站的地址為：http://china.osgiusers.org。
閱讀全文
摘要: OSGi DevCon2008已經(jīng)閉幕，迫不及待、非常迫不及待的希望能了解更多此次大會的盛況，不過目前相關的新聞報道等還是比較少的，除了osgi.org/blog上有三四篇報道，根據(jù)日程找到目前公開的OSGi DevCon 2008中Topic的PPT，共11個，在此根據(jù)自己看這些PPT的情況做個簡單的介紹和評價。
閱讀全文
摘要: 期待已久的OSGi DevCon 2008將會在下周（3月17日---3月20日）和EclipseCon 2008共同召開，今年OSGi的Topic比去年更多，也占據(jù)了更重要的位置，來看看本次大會即將開講的Topic，暢想暢想，看看哪些Topic將會成為熱題。
本屆Topic仍然和往年一年，分為Long Talks、Tutorials、Short Talks、Panel和Additional OSGi Talks，本屆OSGi DevCon可謂是眾星云集，世界級的OSGi大師們共聚一堂，毫無疑問將給我們這些OSGi Fans們貢獻一場盛宴。
閱讀全文
摘要: 在分布式服務框架中，一個最基礎的問題就是遠程服務是怎么通訊的，在Java領域中有很多可實現(xiàn)遠程通訊的技術，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等，這些名詞之間到底是些什么關系呢，它們背后到底是基于什么原理實現(xiàn)的呢，了解這些是實現(xiàn)分布式服務框架的基礎知識，而如果在性能上有高的要求的話，那深入了解這些技術背后的機制就是必須的了，在這篇blog中我們將來一探究竟，拋磚引玉，歡迎大家提供更多的實現(xiàn)遠程通訊的技術和原理的介紹。
閱讀全文
摘要: 在使用Spring的時候，我們習慣于用bean的名稱作為注冊、查找的條件，這也就意味著bean的引用是唯一的了，而不能來查找、注入一系列具備相同功能但不同實現(xiàn)的bean，這種應用的場景其實還是很多的，尤其在擴展的場景中，在這篇blog中以一個應用場景來說明下這種需求，順便也宣傳下OSGi的服務接口+版本+屬性的注冊和查找機制。
閱讀全文
摘要: 在上篇分析完了在V 0.7需要干的活后，開始細化其中的實現(xiàn)細節(jié)，由于技術細節(jié)和之前想的有點不同，在細化的同時也稍做了調(diào)整，系統(tǒng)的架構仍然保持不變，在這篇blog中來看看實現(xiàn)每項任務的技術細節(jié)，之后就可以進入編碼實現(xiàn)階段了。
閱讀全文
摘要: 經(jīng)過上篇分析分布式服務框架的blog后，正式對之前的基于OSGi實現(xiàn)分布式服務框架的系列改名(順便把分布式服務框架改為使用DSF縮寫)，因為已經(jīng)決定基于Spring-DM來實現(xiàn)，為什么呢，而且為什么一定要是Spring-DM，而不直接說Spring呢？
在講完這個原因后，在這篇blog中你還會看到基于Spring-DM后的DSF V0.7是什么樣子，以及要干些什么活來完成V 0.7。
閱讀全文
摘要: 昨天剛分析完分布式服務框架，今天便看到Spring Integration 1.0 M1發(fā)布的消息，這也為Spring進軍SOA領域拉開了序幕。
閱讀全文
摘要: 技術是為需求而服務的，分布式服務框架也同樣如此，它不是憑空誕生的，也是因為有這樣的需求才會有分布式服務框架這樣的東西誕生，在這篇blog中來詳細的分析分布式服務框架誕生的原因(其實也是需要用分布式服務框架的應用場景，這里隱含的意思就是并不是什么應用都需要分布式服務框架的)、分布式服務框架需要提供的feature以及實現(xiàn)這些feature可選的技術方案。
閱讀全文
摘要: 在這個篇幅中將來分析下這個分布式服務框架的服務的生命周期的管理的問題，在分布式服務框架中，支持服務的動態(tài)部署、卸載、升級是很關鍵的，至于服務的生命周期是否需要做到像OSGi那樣的動態(tài)通知，在這個篇幅中會進行分析，并最終形成這個分布式服務框架的生命周期模型以及到目前為止的服務架構模型。
閱讀全文
摘要: 上篇說到，經(jīng)過分析后決定選用JNDI來實現(xiàn)服務的遠程注冊、查找和路由，在這篇blog中就來詳細分析下基于JNDI怎么和OSGi結合來實現(xiàn)服務的遠程注冊、查找和路由。
閱讀全文
摘要: 在這篇歷程中來完成對于JINI的Spike，目標仍然是判斷基于JINI實現(xiàn)服務的路由、查找需求的滿足度。
JINI是由Sun研究院制定的，其目標就是為了實現(xiàn)分布式的服務，所以在很多地方可以看到它和分布式服務框架是有不少重疊之處的，來先看看它對于需求的滿足度，最后再來分析做個總結。
閱讀全文
摘要: 寫完之前的那篇基于OSGi實現(xiàn)服務框架的分析后，決定動手來實現(xiàn)一個基于OSGi的分布式服務框架，而其feature呢，就會遵照之前寫的服務框架的要素來實現(xiàn)，根據(jù)之前的分析，將這個實現(xiàn)過程分為了三個大的步驟來完成：Spike階段、實現(xiàn)階段和測試階段，Spike階段用于完成幾個關鍵問題的技術的研究和選型；實現(xiàn)階段用于完成基于OSGi的分布式服務框架；測試階段用于判斷實現(xiàn)的分布式框架對于應用場景的符合程度、性能的情況。
首先進入Spike階段，在Spike階段需要完成服務注冊、創(chuàng)建以及服務的proxy管理的技術研究和選型，這主要是因為我對這兩部分的技術并不怎么熟悉，對于服務的注冊和查找，可選的技術有兩種：JNDI和JINI；對于服務的proxy的管理，可選的技術應該就是cglib這一種了，不過需要研究具體怎么用，在這篇blog中將介紹對于JNDI的Spike。
閱讀全文
摘要: 根據(jù)上一篇服務框架的要素的blog，來分析下基于OSGi實現(xiàn)一個這樣的適合分布式場景的服務框架時需要對目前的OSGi框架做出哪些方面的修改，以及預估一下實現(xiàn)的難度。
根據(jù)分析可以看出要基于OSGi實現(xiàn)一個這種適合分布式場景的服務框架還是比較麻煩的，需要重寫的部分是非常的多，以此來看的話，目前OSGi最適合的場景應該還是如下幾種：
1、不需要分布式部署的應用場景；
2、需要分布式部署，但僅僅是分層的分布式部署，例如業(yè)務層在一臺機器上，數(shù)據(jù)層在另外的機器上。
不過基于OSGi實現(xiàn)一個這樣的服務框架也是一件很不錯的事，估計這也是EEG目前正在做的事，希望以后能在自己有空的時候動手做做這個基于OSGi的服務框架。
閱讀全文
摘要: 服務框架，這個名詞已經(jīng)出現(xiàn)了很多年了，很早以前系統(tǒng)的架構就希望是以基于服務框架的方式來搭建的，turbine、phoenix、avalon等都是朝著實現(xiàn)服務框架的目標而去，如今的SCA，也可以說就是為了提供一個可用的服務框架，服務框架在系統(tǒng)中到底承擔什么角色呢，為什么它會顯得那么重要呢，如果要實現(xiàn)一個服務框架，不太可能從最底層做起，那么我們又需要怎么樣去選擇呢？
服務本身是個挺形象的名詞，在系統(tǒng)設計中我們非常強調(diào)輸入和輸出，服務呢，可以說是更形象的去強調(diào)了這一點，每個模塊都會對外提供一定的功能，而這些對外提供的功能我們就可以作為服務了，細到模塊內(nèi)，我們也會發(fā)現(xiàn)模塊內(nèi)各個類其實也是以服務的方式來交互的，在這樣的情況下，服務框架自然就成了整個系統(tǒng)的核心基礎框架，那么服務框架能幫我們來提供哪些功能呢，如果我們要實現(xiàn)一個服務框架，有哪些要素是需要考慮的呢，歡迎大家拍磚，多多交流！
閱讀全文
摘要: 07年的最后一天了，回顧當年、展望來年已經(jīng)是每年最后一天的慣例了，就像往年一樣，07年對于業(yè)界而言仍然是高速發(fā)展的一年，新技術、新框架、新名詞不斷的在冒，不過對于自己而言，07年在新東西方面接觸的不多，也許是現(xiàn)在更加的專注了吧，沒有以前那么博了，:)，回顧的關鍵字自然也就鎖定在自己感興趣的領域：OSGi、SCA、Erlang、互聯(lián)網(wǎng)應用、認識架構。
對于08年，有很多的期待：OSGi、互聯(lián)網(wǎng)應用和深入架構。
閱讀全文
摘要: 之前發(fā)布了一篇Introduction OSGi的PPT，Introduce OSGi PPT主要是用于介紹OSGi，更多的是在講解OSGi的一些基礎概念，OSGi in action PPT則主要是針對有一定OSGi使用經(jīng)驗的用戶而編寫的，此篇PPT更加專題性質(zhì)和細致的講解了OSGi如何在實際的項目中進行使用，如何和流行的java框架進行集成，以及在實際的OSGi應用設計和開發(fā)時的一些最佳實踐的介紹和講解，對此PPT感興趣的同學可從以下地址下載：
http://www.riawork.org/opentopic/OSGi.in.action.ppt
閱讀全文
摘要: 這篇文檔是erlang創(chuàng)始者之一的Joe Armstrong所編寫的博士論文，由段先德翻譯、鄧輝審校，感興趣的同學可以從以下地址下載：
http://erlang-china.org/study/joe-armstrong_thesis_cn.html
Erlang在業(yè)界已經(jīng)引起了不小的轟動，通讀了下這篇博士論文，翻譯的質(zhì)量很高，:)，所以讀起來非常的順暢，論文的內(nèi)容對于erlang初學者而言絕對是堪稱經(jīng)典，寫的非常的不錯，點出了erlang的強項并詳細的進行了解釋，感謝翻譯論文的段先德和鄧輝的工作。
Erlang以天生的支持并發(fā)、分布式和容錯而聞名，由于erlang的誕生是為交換機而服務的，因此在并發(fā)、分布式、容錯、動態(tài)代碼升級等方面是實現(xiàn)的非常好的，其目前主要是應用在erission的交換機上，這對于erlang的那些天生的特性也是個很好的證明。
通過閱讀這篇博士論文，讓我對了erlang有了部分的認識，由于目前尚未實踐過，只能根據(jù)論文本身對自己理解的erlang做個闡述。
Erlang采用的是虛擬機的方式，這個虛擬機和java的虛擬機類似
閱讀全文
摘要: SQLUnit是一個用于對存儲過程進行單元測試的工具，其實也可以用于做針對數(shù)據(jù)庫數(shù)據(jù)、性能的測試等，延續(xù)了xUnit家族的一貫特性和風格，只不過它的測試是以xml的方式來編寫，但原則仍然和xUnit家族其他產(chǎn)品一樣，強調(diào)的是輸出和預期的比較，SQLUnit的文檔比較的少，由于官方站上并沒有提供類似其他開源工具的quick start guide，就寫了這篇quick start guide以便大家快速的使用sqlunit，至于SQLUnit的高級用法還是得去多看看sqlunit.sf.net官方站上的文檔。
為了讓大家能快速的開始入門使用SQLUnit，將介紹SQLUnit環(huán)境的搭建、如何編寫一個單元測試、如何運行。
閱讀全文
摘要: 上次發(fā)布OSGi in action的PPT后，得到了flyisland的反饋意見，:)，在此也謝謝他，正是從他的意見中看到了之前PPT的一些問題，之前PPT的問題應該是目標聽眾不明確，講的內(nèi)容多但卻都不詳細，很有可能最后講完了無論是對于OSGi Newer還是OSGi熟悉的人都沒有什么任何的幫助，為了解決這個PPT，決定把PPT分為兩篇來完成，一篇為OSGi Newer編寫的關于OSGi介紹方面的PPT，將名字定為了Introduce OSGi，重點的介紹OSGi的基礎概念和基本的使用方法；而另外一篇則是為較為OSGi的同學們編寫的，名字仍然保持為OSGi in action，會重點和較為詳細的講解OSGi在實際項目的使用，目前先發(fā)布Introduce OSGi的PPT，希望能繼續(xù)得到大家的反饋意見，感興趣的同學們可以從這下載這篇PPT：
http://www.riawork.org/opentopic/Introduce.OSGi.ppt
閱讀全文
摘要: 在我現(xiàn)在的項目中出現(xiàn)了這么兩個問題，大家可以來探討下這樣的兩個問題的解決方法，:)
1、從開發(fā)環(huán)境到正式環(huán)境的部署/校驗非常麻煩；
2、數(shù)據(jù)庫的頻繁移植/校驗非常麻煩。
我的解決方法：
對于上面兩個問題，我自己想到的解決方法是：
1、建立持續(xù)集成機制，編寫環(huán)境部署腳本和文檔，采用這兩種方法可保證從開發(fā)環(huán)境到正式環(huán)境的部署是非常簡單的；
編寫自動驗收測試腳本，可以基于Selenium進行編寫，這樣每次在升級版本的時候就不需要再人工的進行回歸測試了，這里面的問題是如何在測試完畢完畢后清除這些測試數(shù)據(jù)，因為這些測試數(shù)據(jù)是不能和正式數(shù)據(jù)共存的。
2、建立數(shù)據(jù)庫升級移植機制，每次升級時做增量的升級，不過這需要建立在對原庫建立版本記錄，這個方法對于我們的項目而言不太可行；
第二種方案就只能每次進行全面的重新移植了，但這個帶來的一個巨大問題就是存儲過程的重復修改，目前我還沒想到什么解決方法，而且；
至于如何校驗數(shù)據(jù)庫移植是否成功，我覺得可以建立數(shù)據(jù)庫移植校驗的Checkpoint，除了保證數(shù)據(jù)庫結構、數(shù)據(jù)量等的
閱讀全文
摘要: 這個PPT將會用于最近的一些OSGi活動作為Topic來講講，不過是英文版的，:)，一方面是鍛煉自己的英文，另一方面也準備把這PPT再雕磨雕磨，提交到OSGiDevCon 2008的Topic中試試。
感興趣的朋友請從以下地址下載此PPT：
http://www.osgi.org.cn/opentopic/OSGi.in.action.ppt
不過俗話說，PPT嘛，靠的主要是講，但同時也希望得到大家對此PPT的反饋意見，以便我進行進一步的修改，希望在之后的公開的活動中不會把這Topic講砸了，此PPT會不斷的進行修改，我會在此篇blog中公布目前ppt的版本號，大家就可以確認手頭的PPT是否是最新的了，:)。
version info:
1.0 2007-10-21
閱讀全文
摘要: 在歷時兩個多月后，OSGi進階的編寫已完畢，感謝N多朋友一直以來的關注和支持，現(xiàn)將正式版對外發(fā)布，下載地址為：
http://www.riawork.org/opendoc/osgiopendoc2.pdf
隨文的代碼的下載地址為：
http://www.riawork.org/opendoc/osgiopendoc2-source.zip
隨文的例子的可運行版本的下載地址為：
http://www.riawork.org/opendoc/osgiopendoc2-dist.zip
隨后將會相繼在Redsaga上發(fā)布Redsaga Opendoc版本，以及在InfoQ中國站上發(fā)布InfoQ miniBook版本，這兩個版本在精美程度上都會超過我現(xiàn)在發(fā)布的版本，到時再給予大家通知，:)
閱讀全文
摘要: 軟件架構的選擇和設計并不是很容易做出的，一個成功的軟件架構取決于N多的因素，軟件架構這個詞向來就是最為模糊的一個詞，個人認為軟件架構實在是個很大的話題，業(yè)界一直采用的形象比喻就是建設房子時的房屋結構圖，以軟件的角度來說，軟件架構應至少包括軟件開發(fā)時使用什么語言、形成軟件開發(fā)時可運行的核心基礎框架、軟件應用模塊的設計（包括模塊內(nèi)聚的功能、對外提供的服務等）、軟件測試的方法、軟件部署的方法以及團隊開發(fā)的方法，那么怎么來選擇和設計軟件架構呢，其衡量的因素是什么呢，個人認為其中質(zhì)量和快速是衡量軟件架構的選擇和設計是否成功的兩個最重要的因素。
閱讀全文
摘要: OSGi在應用時具備了典型的微核系統(tǒng)的特點，但對于實際項目/產(chǎn)品型的應用而言，這個微核有些過于底層了，為什么這么說呢？
對于實際項目/產(chǎn)品型的應用而言，何謂其微核呢，應該說其腳手架或開發(fā)平臺才是它的微核，而并非僅僅是OSGi框架，當然，也可以將自己的腳手架或開發(fā)平臺以Fragment-Host的方式綁定到OSGi的System Bundle上去，但這樣的做法無疑有些evil了，TPF誕生的最主要的目的就是形成一個應用級的微核的概念，使得我們在管理實際的項目和產(chǎn)品時，能夠?qū)⒛_手架和實際的業(yè)務應用模塊分離管理，讓腳手架也變成微核，這樣在管理時就可以做到對應用系統(tǒng)的統(tǒng)一管理，而同時保持一個含應用意義的微核（也可以認為是開發(fā)平臺）的穩(wěn)定運行，在具備了TPF的情況下，就可以將應用系統(tǒng)從部署上分為腳手架和應用系統(tǒng)，而在管理上也可以單獨對應用系統(tǒng)進行管理，如啟動應用系統(tǒng)、停止應用系統(tǒng)，同時避免應用開發(fā)人員對腳手架無意的修改。
在本篇文檔中將介紹TPF提供的功能、TPF實現(xiàn)的方法以及TPF的下載地址。
閱讀全文
摘要: 本來目前這篇Opendoc還沒有達到發(fā)布的條件，不過正逢國慶佳節(jié)，希望各位感興趣的同學能夠在國慶期間抽出時間看看這篇Opendoc，而國慶期間我也會對Opendoc進行潤色和內(nèi)容的充實、完善，國慶后希望能獲取到各位看過預覽版的同學的意見，我會根據(jù)各位的意見對Opendoc進行適度的修改，爭取在10月中旬發(fā)布正式版。
至于隨Opendoc的代碼等到正式版的時候我再發(fā)布，如有需要的同學可以直接mail給我，我可先mail給需要的同學。
另外由于預覽版還有不少需要潤色、完善的地方，請各位收到預覽版的同學不要傳播這個版本，:)，多謝！
閱讀全文
摘要: 《OSGi實戰(zhàn)》Opendoc推出已一年有余，該篇Opendoc主要是為了介紹OSGi而編寫的，相對而言知識點較淺，很多朋友在看過那篇Opendoc后也許會對OSGi產(chǎn)生興趣，但未必會在商業(yè)的項目/產(chǎn)品中去使用它，為了能夠讓更多的朋友能夠在商業(yè)的項目/產(chǎn)品中使用OSGi，根據(jù)自己的經(jīng)驗以及這一年多來OSGi界的發(fā)展情況，從8月初開始了《OSGi進階—模式與最佳實踐》Opendoc的編寫，爭取在國慶前推出一個預覽的版本，希望《OSGi實戰(zhàn)》能吸引大家關注OSGi，而《OSGi進階》能推動大家在商業(yè)項目/產(chǎn)品中使用OSGi，如對預覽版有興趣，請發(fā)郵件聯(lián)系我，在完成后的第一時間我將mail給你，謝謝關注！
閱讀全文
摘要: OSGi.org.cn將做為OSGi.org的官方中文網(wǎng)站推出，整個項目預計分為兩期完成。
一期的目標為翻譯OSGi.org的所有內(nèi)容，至于blog部分則能盡量翻譯，暫定為先翻譯近三個月的blog，一期的計劃為一個月內(nèi)完成，也就是說在國慶前正式的推出OSGi.org.cn，到時會在國內(nèi)的幾個大網(wǎng)站上(InfoQ-CN、JavaEye、EclipseWorld、CSDN等)做一定的宣傳和推廣；
二期的目標為翻譯OSGi.org中的所有blog，同時翻譯www2.osgi.org中的所有內(nèi)容。
在一二期工作完成后，進入OSGi.org.cn的維護期，到時就是跟隨著OSGi.org做更新的翻譯，同時OSGi.org.cn會考慮做一些本地化的blog、新聞、論壇、開源項目等工作，目標是讓OSGi.org.cn做到中國頂尖的OSGi網(wǎng)站，并為推廣OSGi和發(fā)展OSGi做出貢獻。
閱讀全文
摘要: 此次需要完成的目標是將庫從SQLServer 2005完整的移植到Oracle10g中，包括表結構、數(shù)據(jù)、視圖、函數(shù)以及存儲過程的移植，移植主要基于Oracle的OMWB（Oracle Migration Workbench）來完成，盡管OMWB能幫助完成大部分具備難度的工作，但還是有很多工作量的事情需要在OMWB完成后來手工進行，所以整個移植過程工作量看起來會非常大，但是不是僅僅只有工作量的問題呢？我覺得不是，寫下這篇blog以便需要進行此項操作的同學以及給自己做個備忘。
閱讀全文
摘要: 《Oracle9i&10g編程藝術》即為《Expert one to one oracle》的升級版本，不過升級后可能會變?yōu)槿緯@本書強調(diào)的是深入數(shù)據(jù)庫體系結構的講解，本書的作者Thomas Kyte(即Tom)無疑是Oracle界最為知名的人物，而這本書可以說基本是專為開發(fā)人員而寫的，因為我個人覺得書中講的東西大部分DBA都是懂的，但對于開發(fā)人員來講估計大部分都不懂，Thomas Kyte抓住了怎么給開發(fā)人員講才能講清的方法，對于書中的每項內(nèi)容Thomas會講解什么時候這么做、為什么要這么做、什么時候不能這么做以及為什么不這么做，要說服開發(fā)人員，很多時候除了告訴怎么做以外，還必須得告訴為什么要這么做，否則很難說服，而Tom在書中則很好的做到了這點，Tom會告訴你Oracle是怎么去實現(xiàn)的，所以你要這么做或者不能這么做，這本書除了讓我學習到了更多的Oracle知識外，還讓我更加明白了數(shù)據(jù)庫在系統(tǒng)中的重要性以及充分發(fā)揮數(shù)據(jù)庫的功能是多么重要的一件事，還有一個附加的好處就是讓我們可以窺探到部分Oracle的設計，對于自己實現(xiàn)應用系統(tǒng)也是會找到一些可參考的地方，這本書寫的實在是太好了，強
閱讀全文
摘要: 向Peter Kriens問了一些自己比較關心的OSGi進展情況的問題，總結而言：
從Peter Kriens的答復來看，R5和EEG的工作成果生效還得等待較長的時間，好消息是SCA采用OSGi作為基礎架構看來是非常的有希望了，這對于OSGi的推廣是件非常好的事。
閱讀全文
摘要: 說書評實在是沒什么資格，:)，已經(jīng)有將近半年的時間都沒使用Ajax做產(chǎn)品或項目了，不過一直都在關注Ajax的發(fā)展和動態(tài)，應該說Ajax的發(fā)展在這兩年以來非常的可喜，Ajax帶來的web友好性的改變在各大網(wǎng)站已經(jīng)開始顯現(xiàn)出來了，這一切都是很值得高興的，說回正題，記得是當時在做一個Ajax方面的框架，做的過程中開始看《Ajax patterns and best practice》，英文版本，碰巧從dlee那了解到他們正在翻譯這本非常不錯的書，后來從dlee那拿到了翻譯后的草稿版，先睹為快了，記得當時看了翻譯稿后就在我的blog上寫了一些關于書中介紹的模式，主要是看書后的激動之情，順便也為了大家先了解下這本書的內(nèi)容，在《Ajax模式與最佳實踐》上市后拿到博文的贈書，不過由于工作原因，一直沒時間好好的翻看，最近才拿出書來仔細的看了看。
很久都沒看技術方面的書了，大部分技術相關的東西都是要用的時候才從網(wǎng)上臨時的翻閱，基本就是看些小文章，再加上自己是個典型的實戰(zhàn)主義者，所以對書應該也是較為挑剔的，《Ajax模式與最佳實踐》是本典型的實戰(zhàn)書籍，而且無疑是ajax實戰(zhàn)類書籍中的佼佼者，為什么
閱讀全文
摘要: 在Play OSGi中提及到了Bnd是個非常有用的東西，既然是個好東西，就介紹給大家用，在得到了Peter的授權下，我把這篇使用手冊翻譯成了中文，大家感興趣的話可以到這里看看：http://www.aqute.biz/Code/BndCn，同時也會提供一個PDF的版本供大家下載，PDF版本下載地址為：http://www.aygfsteel.com/Files/BlueDavy/Bnd.zip。
有了Bnd后，傳統(tǒng)的java工程非常容易打包成標準的OSGi R4的bundle，同時Bnd也為校驗Bundle是否符合OSGi R4規(guī)范提供了支持，而且Bnd有命令行、Eclipse插件、Ant Task和Maven插件，拿過來非常的好用，強烈推薦大家用用看。
見文中的例子...
基于Bnd我們非常容易就把一個傳統(tǒng)的java工程打包成了兩個有效的OSGi R4的Bundle，從這可以看出這對于要把傳統(tǒng)的java系統(tǒng)重構為基于OSGi的系統(tǒng)會有很大的幫助，除了打包生成Bundle外，Bnd本身還具備了校驗bundle是否符合OSGi R4規(guī)范、把新的文件或jar文件添加到
閱讀全文
摘要: Peter(OSGi主席)在7月3日的一篇blog上展示了一個很有趣的演示，相信可以給公眾很好的展示下使用OSGi是一件很好玩的事，很簡單的快速的基于OSGi搭建出各種各樣不同的系統(tǒng)，我知道也許你會說你們的系統(tǒng)也可以，但你覺得真的能做到和基于OSGi所做出的系統(tǒng)的效果一樣嗎，really？如果可以的話，非常恭喜你，你對模塊化、動態(tài)化都有很強很深的認識，如果不可以但又想做到這種效果的話，我覺得不妨和Peter所做的一樣試著Play OSGi。
閱讀全文
摘要: 很久以前寫過一篇關于產(chǎn)品規(guī)劃的blog，結合最近在做產(chǎn)品規(guī)劃時的一些感想再來寫一些想法，產(chǎn)品規(guī)劃涵蓋的面非常的大，宏觀上來講涉及到技術部門、銷售部門、售前部門等，細節(jié)上來講涉及到產(chǎn)品每個版本的功能特性、銷售、推廣策略、銷售對象、售后支持、產(chǎn)品定價甚至是產(chǎn)品包裝的細節(jié)，所以在做產(chǎn)品規(guī)劃時要考慮的較為全面，需要做到宏觀以及細節(jié)層面的共同把握，本篇blog主要是對產(chǎn)品規(guī)劃中的藍圖規(guī)劃和版本規(guī)劃做一些概述。
閱讀全文
摘要: 在之前的一篇blog中提及到實現(xiàn)系統(tǒng)整合的方式有兩種，其中一種就是通過建設綜合系統(tǒng)來實現(xiàn)系統(tǒng)整合，近期經(jīng)歷了好幾個這樣的項目，來說說這種方式的項目的幾個難點的地方，我是以整合廠商的身份進入此類項目，所以blog中更多的可能代表了整合廠商的心聲。
在這類項目中，集成商的能力非常的關鍵，集成商的能力主要包括了技術能力、業(yè)務能力以及協(xié)調(diào)能力，這三種能力缺一不可，分別來看看這三種能力在此類項目中的重要性。
閱讀全文
摘要: 整合項目難做，做過的人都是很容易知道的，這也是為什么整合項目通常要規(guī)劃很久、實施很久，而且還要花費很大的財力的原因，在之前的blog中曾經(jīng)寫過整合項目難做的一些地方，像數(shù)據(jù)分析、客戶的不夠理解等。
隨著對于整合項目實施的逐步深入，碰到的難點在逐步的增多，目前手頭的一個整合項目接近完成了，對于這種類型而言的整合項目中的難點估計該出現(xiàn)的都已經(jīng)出現(xiàn)了，總結下來除了數(shù)據(jù)分析這個大難點之外，還有的難點就是業(yè)務理解的不一致、系統(tǒng)設計的不一致和協(xié)調(diào)這三個，其實業(yè)務理解的不一致和系統(tǒng)設計的不一致可以列入數(shù)據(jù)分析這個范圍，但由于這兩點對于整合項目的影響較大，會很大程度影響整合項目實現(xiàn)的難度，所以還是單獨列出來講講。
閱讀全文
摘要: 在信息化建設上企業(yè)以及政府都投入了很多年了，多年的信息化建設使得企業(yè)以及政府擁有了很多套獨立的專業(yè)的信息/業(yè)務系統(tǒng)，隨著系統(tǒng)建設的完畢以及應用的深入，企業(yè)以及政府對于系統(tǒng)的依賴性在逐步的加大，企業(yè)以及政府慢慢的意識到多套系統(tǒng)造成了各套系統(tǒng)中的信息無法分享，也就是形成了常說的“信息孤島”，企業(yè)以及政府對于信息的整合的需求已經(jīng)越來越迫切也越來越突出了，盡管整合“信息孤島”這樣的概念各大公司(IBM、BEA等)在幾年前就已經(jīng)提出了，但應該說在幾年前仍然是洗腦甚于實際，不過現(xiàn)在整合已經(jīng)步入了實際階段，也可以說是整合時代已經(jīng)來臨。
閱讀全文
摘要: 這是一篇對于從事數(shù)據(jù)集成的實施、銷售和售前人員的培訓的PPT,較為簡單，主要是講解了數(shù)據(jù)集成類項目的概念、實現(xiàn)方法和通常采用的實施步驟。
感興趣的朋友們可以到這里下載：
http://www.aygfsteel.com/Files/BlueDavy/數(shù)據(jù)集成項目培訓.rar
閱讀全文
摘要: 在數(shù)據(jù)集成類的項目中，最難的過程就是數(shù)據(jù)分析了，數(shù)據(jù)分析過程位于數(shù)據(jù)集成類項目整個過程(前期準備調(diào)研-----數(shù)據(jù)分析-----接口實現(xiàn))的第二步，它為第三步接口實現(xiàn)提供了充分的準備，因此數(shù)據(jù)分析的正確與否很大程度上決定了數(shù)據(jù)集成能否成功的實現(xiàn)和完成。
怎么樣有效的進行數(shù)據(jù)分析呢，怎么樣提前在數(shù)據(jù)分析中盡量避免問題等到實現(xiàn)時才出現(xiàn)呢？這是一個行之有效的數(shù)據(jù)分析方法論的評判的關鍵。
經(jīng)過幾個項目的經(jīng)歷，反思了一下在做這些項目時比較有效的方法和失妥的方法，總結了一套目前個人覺得可行的數(shù)據(jù)分析方法，此套數(shù)據(jù)分析方法只適用于數(shù)據(jù)庫---文件---數(shù)據(jù)庫或數(shù)據(jù)庫---數(shù)據(jù)庫的分析，對于接口式的集成(例如調(diào)用對方的webservice、EJB接口等)并不適用，在這樣的一套數(shù)據(jù)分析的方法中，為數(shù)據(jù)分析的步驟以及需要注意的問題事項提出了指導，編寫此blog以希望有同行的同學們多多交流。
閱讀全文
摘要: 話說上篇blog談到了數(shù)據(jù)集成類項目的難點，在這篇blog中再根據(jù)數(shù)據(jù)集成項目/產(chǎn)品的特點來侃侃所需的人才，對于做數(shù)據(jù)集成產(chǎn)品的公司而言，通常都是走專業(yè)性質(zhì)的產(chǎn)品公司的發(fā)展路線，在這樣的公司中技術方向的組織架構多數(shù)為產(chǎn)品實施人員、產(chǎn)品技術支持人員和產(chǎn)品研發(fā)人員，那么根據(jù)數(shù)據(jù)集成類項目的情況來說，這些人才都需要具備些什么樣的能力呢，產(chǎn)品公司又應該給這些人才提供些什么方面的培訓呢，借此篇blog做個總結，同行的同學們多多交流。
閱讀全文
摘要: 經(jīng)過之前幾年各大廠商對于應用整合的概念的大肆推廣、吹噓，近兩年來隨著各企業(yè)/單位的基礎系統(tǒng)的建設完善，應用整合類項目開始步入實質(zhì)階段，而數(shù)據(jù)集成就是目前應用集成類項目中一個重要的部分，那么數(shù)據(jù)集成類的項目它的難點通常會有哪一些呢，根據(jù)自己的經(jīng)驗稍微的進行了些總結，希望從事相關工作的同學們多多交流。
閱讀全文
摘要: 不知道很多正在創(chuàng)業(yè)、已經(jīng)起步或者想做中間件廠商的同學們會怎么看待這個問題，中間件廠商到底有多難呢，它的難處到底又在哪里呢，為什么中國一直以來就很難誕生一家比較好的中間件產(chǎn)品的廠商呢，在這篇blog中想談談自己的一些感受。
閱讀全文
摘要: 由于當時匆忙的發(fā)布，沒有進行仔細的校對，發(fā)布的EventAdmin部分的代碼中缺少了使用DS實現(xiàn)的示例，但同時在其中又提供了OSGI-INF/component.xml，導致了如果大家直接使用該Component.xml切換為使用DS來實現(xiàn)EventHandler的時候會出現(xiàn)運行時事件未通知到EventHandler的現(xiàn)象。
閱讀全文
摘要: 在本屆EclipseCon 2007大會上，OSGi占據(jù)了不少的Topic，下面就對本次EclipseCon 2007大會上OSGi相關的主要的一些Topic簡單的介紹下，最后總結下通過本次大會形成的反饋(信息來源于OSGi官方網(wǎng)站blog和EclipseCon 2007官方網(wǎng)站)，關于EclipseCon其他方面的精品Topic在后續(xù)的blog中也將相繼介紹。
閱讀全文
摘要: Peter在2月23的時候在OSGi的官方網(wǎng)站上貼了這么一篇blog，挺經(jīng)典，至少讓我學到了一些東西，建議關注OSGi或者關心系統(tǒng)設計中資源管理的人都看看，在這篇blog中我簡單的將peter寫的blog的意思大概寫一下，也不全部翻譯了，另外說一下自己的看法。
如果感興趣的話，請同學們?nèi)ゲ榭碢eter的這兩個帖子：
http://www.osgi.org/blog/2007/02/osgi-extender-model.html
http://www.aqute.biz/Snippets/Extender
這個OSGi Extender Model給了我們什么啟示呢：
1、Declarative方式的使用
Declarative無非是現(xiàn)在一種非常非常流行的軟件設計理念，在這樣的理念中，可以盡量的保證當前組件的簡單，而通過Declarative的方式去增強的描述該組件，其實在spring中最重要的也是這個思想，而在OSGi的DS中也是這么一個思想，聲明式的編程自然讓整個系統(tǒng)的體系變得非常的簡單和靈活，并且大大提升系統(tǒng)組件的可
閱讀全文
摘要: 去年帶了幾個新人，越來越覺得軟件開發(fā)這行還是需要一定的"天份"的，其實每行都需要一定的"天份"，每個人都有自己最為適合的行業(yè)，特別是技術行當而言，如果真的希望在軟件的技術領域有所發(fā)展的話，勤奮、吃苦的精神固然是必須的，但以下的幾點素質(zhì)卻是基本的，而有些我覺得完全是靠天生的，或者后天小時候的努力才能培養(yǎng)出來的，如果不具備的話，我覺得這樣的人就不是很適合從事軟件技術行業(yè)：
1、邏輯思維能力
2、舉一反三能力
3、自學、獨立解決問題的能力
4、對軟件開發(fā)的興趣
閱讀全文
摘要: 搭建動態(tài)化的系統(tǒng)是作為java開發(fā)人員一直就非常追求的目標，一個系統(tǒng)能夠動態(tài)化就意味著：
★ 添加新功能時不需要重啟系統(tǒng)；
★ 修改已存在的功能時不需要重啟系統(tǒng)；
★ 刪除一些不需要的功能時不需要重啟系統(tǒng)；
★ 修改系統(tǒng)中的配置時可以不需要重啟系統(tǒng)即刻生效；
★ 系統(tǒng)的業(yè)務行為可動態(tài)的改變。
也許習慣了傳統(tǒng)java開發(fā)方式的人而言，沒有這些動態(tài)化也沒什么，但不可否認，這些動態(tài)化的特征還是非常吸引人的，尤其是如果能很容易就獲得這些好處，那么自然就不會錯過這些好處了，基于OSGi可以很容易的讓我們獲取到這些好處。
閱讀全文
摘要: 作為一個桌面應用的開發(fā)者，向RCP致敬的理由會是RCP提供了豐富的界面控件，使得基于Java開發(fā)桌面應用也變得容易了很多，盡管仍然不能和基于VB、Delphi去相比；對于我而言，盡管使用RCP也是為了開發(fā)桌面應用，但RCP給我?guī)淼母嗟母杏X是在它充分發(fā)揮插件化系統(tǒng)的優(yōu)勢方面，RCP可以視為基于OSGi構建插件化系統(tǒng)的最佳實踐的指導，從RCP的設計中，可以學習到如何讓應用做到模塊化、讓應用做到動態(tài)化，甚至還可以學習到象如何自動生成界面這樣的細節(jié)設計思想，盡管我自己基于OSGi做應用型的產(chǎn)品也做了一段時間了，但自己仍然一直感覺到在發(fā)揮插件化系統(tǒng)的優(yōu)勢方面還有不小差距，RCP可以看做是基于OSGi做插件化應用系統(tǒng)的最佳實踐，其中的不少設計方法甚至都可以整理成為基于OSGi做插件化應用系統(tǒng)的設計模式，讓我們進入RCP之旅，揭開面紗，一探其本質(zhì)吧，相信大家在了解了RCP的設計思想，看過其代碼后，不得不對RCP表示崇高的敬意，大師之作，不同凡響。
閱讀全文
摘要: 上午在普元的網(wǎng)上培訓的地方和業(yè)界的朋友們進行了OSGi的交流，PPT在我之前的blog中已經(jīng)提供，大家可以通過以下網(wǎng)址來下載今天演講時的全程錄像(帶聲音)，PPT：
http://www.osgi.org.cn/opentopic/OSGiInAction.rar
其中的會議全程錄像就是帶聲音和演示的東西，感興趣的同學們可以下去聽聽、看看，歡迎大家多交流。
這次的演講主要就是一個介紹，講的都比較粗，沒有細致的去講其中的東西。
閱讀全文
摘要: 新年即將來臨，Peter在OSGi的官方blog上對OSGi 06年的發(fā)展進行了回顧，同時也就07年OSGi進行了展望，在這篇blog中我也對一年以來OSGi的發(fā)展、自己在OSGi方面的工作以及對于明年OSGi的期望也做些闡述。
閱讀全文
摘要: 12月30日下午13:00--15:00我將在普元goCom社區(qū)舉行一次OSGi Topic，歡迎感興趣的O粉(OSGi Fans)到時前往交流和討論，由于這是在網(wǎng)上首次進行的公開Topic，鑒于對聽眾群不了解的情況，本次Topic主要仍然是宣傳和推廣OSGi，所以基本上只是OSGi的一些簡介，以下列出了大綱和PPT的下載地址。
閱讀全文
摘要: 之前也寫過關于Service-Oriented Component Model的blog了，Service-Oriented Component Model(以下簡稱SOCM)是OSGi R4中最為重要的改進，SOCM也是切實體現(xiàn)OSGi的動態(tài)性的模型，大家在使用SOCM的時候可能會因為受到原有思想的影響而一時無法理解，在這篇blog中將再次的對SOCM進行講解，以便大家能夠更好的理解和進行運用。
閱讀全文
摘要: EclipseCon2007中OSGi主題部分的Long Talks均已提交，雖然尚未確定最終哪些Topic將會入選，我們可以先一睹為快，此次總共提交了16個Topic，讓我們來看看這些Topic：
閱讀全文
摘要: 置換模式，引用即將出版的《ajax模式和最佳實踐》(也就是《ajax patterns and best practice》)中對于它的意圖的描述：
“置換模式(Permutations pattern) 被服務器用來分離資源(URL)與表現(xiàn)(例如HTML或XML)。分離資源與表現(xiàn)使得終端用戶只需要關心資源，不需要擔心URL所關聯(lián)的內(nèi)容。例如，假如一個客戶的銀行帳號是URL http://mydomain.com/accounts/user，那么相同的 URL 能夠被各種各樣的設備 (電話，PC等等)來使用。”
閱讀全文
摘要: 一眼看過去相信大家都知道用Runtime.getRuntime().exec來調(diào)用，我的需求就是：
調(diào)用Oracle EXP命令完成備份，并返回生成的備份文件名，這個備份文件會很快在其他的地方被使用。
采用Runtime.getRuntime().exec我們都知道，需要處理它的InputStream，以避免出現(xiàn)執(zhí)行的命令輸出的信息過多使得進程被堵死，OK，按照這樣的方法寫出來的代碼執(zhí)行后卻碰到了問題.....
閱讀全文
摘要: 在之前的一篇blog中我曾經(jīng)寫到過CM對于application level的configuration的不適用，提到的主要是兩點：
1、無法在外部統(tǒng)一的對Bundle中service所需要的屬性進行管理；
當時基于這個約束，只好在各自的bundle下編寫一個管理當前bundle屬性的服務，當外部需要管理此bundle的屬性時，必須通過這個服務來管理，否則的話改變是不會起到效果的。
2、無法共享屬性的配置。
每個bundle都保存自己獨立的一份屬性配置，這就導致了當出現(xiàn)共享屬性時，在管理端也不得不同時去重復的更新多個bundle。
經(jīng)過對于Equinox的CM實現(xiàn)代碼的查看，發(fā)現(xiàn)我冤枉CM了，現(xiàn)在給它平反，:)
閱讀全文
摘要: 此模式出自《Ajax patterns and best practice》，這個模式非常具備實際意義，為客戶端的緩存實現(xiàn)做出了指導，和以往在使用傳統(tǒng)B/S結構進行開發(fā)時所做緩存的思路有一個改進點，:)。
閱讀全文
摘要: 界面設計，一個在軟件行業(yè)非常尷尬地位的東西，但是絕對離不開的東西，不過在軟件行業(yè)的技術發(fā)展一直是為程序員們提供更佳的方式，而在界面設計方面則是在近些年來才逐漸的重視，但這并不意味著在界面設計上一直就做的很好，反倒在界面設計方面一直就是軟件設計中最薄弱的環(huán)節(jié)，如果從軟件設計的層面去看界面設計，N多的設計師都會看到其中犯的N多設計錯誤的基本常識，可以去想想為什么每次系統(tǒng)改界面總會是件那么痛苦的事，很多時候都是因為在項目/產(chǎn)品中缺乏專業(yè)的界面設計師而造成的。
在你的項目/產(chǎn)品中，是否有專業(yè)的界面設計師呢？
閱讀全文
摘要: EclipseCon 2007中將會有關于OSGi的專題Topic，經(jīng)過一段時間的Topic征求后，目前公布出來了一些Topic供大家投票，以確定到底哪幾個Topic會在明年的EclipseCon上登場，稍微看了一下，基本上都屬于初級的介紹，沒有什么深入性質(zhì)的探討，畢竟OSGi在國外目前也只是處于開始流行階段，順便提一下最近OSGi EEG倒是有不少的動作，相信近期會有一些他們活動的結果公告出來。
在這篇blog中將介紹下這些參加海選的Topic....
總體而言，無論這里面哪些Topic會成為EclipseCon 2007的正式Topic，它們的講述必將為OSGi的推廣做出貢獻，支持誰，就趕緊為它投上一票吧，移動、聯(lián)通、小靈通用戶均發(fā)送至OSGi，哈哈
回到正題，給Topic投票必須是EclipseCon網(wǎng)站的注冊會員，或者你可以直接發(fā)郵件給peter，:)，具體投票的地址請見：
http://bundles.osgi.org/Conference/Tutorials
閱讀全文
摘要: 每個面試官隨著面試經(jīng)驗的積累，都會逐漸的積累自己的一套面試標準，當然，這套面試標準也會隨著公司的需求、業(yè)界的發(fā)展而不斷的變化和發(fā)展，面試標準反應了面試官對于各種級別技術人員的技術要求，在以前的一篇blog中曾經(jīng)提及過面試官應營造好的面試氛圍，而這篇blog則會談及自己面試時采用的標準來衡量面試者的技術能力，拋磚引玉，大家多交流.....
個人覺得面試標準主要由純技術方面的標準和符合公司產(chǎn)品/項目技術要求的標準兩部分組成，當然，還有一些是性格方面的要求，這篇blog主要談及下技術方面的面試標準，由于面試多和公司要求、面試官的判斷標準有關，所以通常來說不能因為沒通過面試就認為自己沒有這方面的能力，需要多嘗試。
面試時對于面試者我會根據(jù)程序員和設計師兩種大的標準來問問題。
閱讀全文
摘要: Peter對于JSR 277是極度的關注，畢竟JSR 277和OSGi在實現(xiàn)的目標上具備了那么多的共同性，從98年JSR 277開始，Peter就希望能加入JSR 277 JCP Group，但是被拒了，JSR 277基本完全是SUN在主導的，經(jīng)過這么多年了，JSR 277的草稿終于是發(fā)布出來了，Peter在對JSR 277做了Review后特意寫了篇Blog做了評價，總結而言，Peter認為JSR 277 just like a toy,JSR 277并沒有吸取OSGi在這8年模塊化方面的教訓和經(jīng)驗，在模塊的一致性校驗、可選性、分離包機制等等方面都缺少足夠的考慮，原文見：
http://www.osgi.org/blog/2006/10/jsr-277-review.html
閱讀全文
摘要: 關于OSGi、SCA的最新的一些消息。
閱讀全文
摘要: POJO這個詞無疑是這幾年來Java界最為熱門的詞，各類框架都是以支持POJO形式作為其關鍵的特性之一，確實，POJO方式降低了開發(fā)的難度和門檻，讓開發(fā)人員能夠得以更加的關注和實現(xiàn)業(yè)務，而Spring也同樣是依靠著"POJO Enhanced"獲得了大家的認可。
閱讀全文
摘要: 發(fā)了封關于SCA和OSGi的mail給OSGi-dev的郵件列表，收到了Peter的回應，Peter的回信如下：
"What the EEG will do depends on its members ...
I think there is a lot of excitement about SCA and OSGi. I also just
read it and agree that it seems very complementary. But we need people
that can drive the work."
目前還沒收到EEG成員的回應，估計他們可能不在這個maillist里吧......
閱讀全文
摘要: OSGi和SCA到底能有什么關系呢，確實，至少從現(xiàn)有的OSGi規(guī)范以及SCA規(guī)范分別來看，兩者沒有直接的關聯(lián)，由于OSGi規(guī)范是對于嵌入式領域的軟件而制定的，其特別注重軟件的動態(tài)性的支持，而SCA規(guī)范是對于企業(yè)應用領域的軟件而制定的，并且是基于SOA的，其特別注重對于企業(yè)應用而言的基礎設施的實現(xiàn)，同時又盡量的去屏蔽對于SCA容器使用者而言SOA帶來的技術實現(xiàn)細節(jié)的難度；但根據(jù)OSGi規(guī)范以及SCA規(guī)范，同時又能發(fā)現(xiàn)兩者有個共同希望解決的問題，那就是規(guī)范的模塊化，這是OSGi規(guī)范和SCA規(guī)范中的一個共同目標。
閱讀全文
摘要: IBM認為一個完整的EAI的解決方案應當包括五個方面：用戶交互、應用連接、業(yè)務流程整合、構建整合和信息集成。
在這篇blog中來探討下EAI的應用連接，IBM對于應用連接的定義：通過 HUB 或總線架構，實現(xiàn)應用與應用之間的連接，完成相關的數(shù)據(jù)路由與數(shù)據(jù)格式轉換，對于IBM的這個定義，非常的認可，在實際的EAI類的項目中，這也確實是個很實際的需要解決的問題，可能很多人仍然會認為EAI是一種炒作，好象也是沒有什么做的成功的EAI項目，但EAI項目現(xiàn)在確實是存在的，而且在這塊的技術、實施經(jīng)驗也是不斷的成熟，EAI項目帶來的意義更是不可否認，在這篇blog中將從應用連接所應對的應用場景、技術實現(xiàn)兩個方面來探討下：
閱讀全文
摘要: SCA無疑是目前業(yè)界最為火熱的詞語之一，粗略的翻閱了一下SCA V0.9的規(guī)范，先不論SCA的商業(yè)因素，不得不感嘆于SCA確實可以稱為企業(yè)應用開發(fā)的利器，而SCA的野心也是從目前的規(guī)范中可見一斑。
閱讀全文
摘要: OSGi的CM就是Configuration Admin Service，是用于管理Bundle屬性、并在屬性發(fā)生變更時通知相應的Service，但在實際的使用中發(fā)現(xiàn)OSGi的CM規(guī)范缺少對于共享屬性配置管理的支撐。
關于模塊的耦合上只有個小小的想法討論下，就是做為設計師你能否很快的告訴別人搭建你其中的一個模塊的工程需要哪幾個模塊的支撐，或者最好就是運行檢驗你其中的一個模塊的功能需要哪幾個模塊來支撐，當然，這個在基于OSGi的系統(tǒng)更容易來做到，不過這個確實是設計時很關鍵的一個地方，這既反映了系統(tǒng)中模塊的耦合性，更體現(xiàn)了系統(tǒng)的擴展性以及系統(tǒng)的組裝耦合上是否合理。
閱讀全文
摘要: OSGi聯(lián)盟的主席Peter做了這么個小東西，原理非常的簡單，在現(xiàn)在傳統(tǒng)的使用ajax的方式多為通過js直接調(diào)用Spring中的bean，那么peter做的這個小東西就變成了js直接調(diào)用OSGi中的service，基本上沒有什么難度，只是玩了一把ajax的東西，估計是peter以前對這塊接觸的少，peter把他做的這個東西放到他的Nokia E70上跑.....
閱讀全文
摘要: 模塊的可擴展性是模塊設計時需要重點考慮的非功能特性，對于框架而言，擴展性的設計則更加的重要，框架需要通過不斷的擴展來充實其基礎設施，構成真正的應用系統(tǒng)。
模塊的擴展主要有兩種，一種為擴充功能的擴展，另一種為覆蓋性質(zhì)的擴展，當然，本質(zhì)上而言是可以把這兩者進行合并的。
在模塊的擴展上Eclipse的擴展點的設計方式無疑是支撐模塊可擴展的經(jīng)典設計方法，到現(xiàn)在為止仍然是如此，基于Eclipse的擴展點的設計無論是對于擴充功能的擴展還是覆蓋性質(zhì)的擴展都支持的非常好，這個經(jīng)典的設計也是RCP得到那么多client side app的原因之一，盡管OSGi中并沒有定義這方面的規(guī)范，但做為OSGi R4的RI的Equinox考慮到更好的支撐Bundle的擴展就引入了Eclipse的擴展點的設計，在現(xiàn)在的Equinox中我們?nèi)匀豢梢曰贓clipse的擴展點的方式來支撐模塊的可擴展性。
但是否有別的方法呢？一定需要Eclipse的擴展點的方式嗎？其實個人覺得基于OSGi的Service就已經(jīng)天然的構成了一種可擴展的設計，為什么這么說呢？
閱讀全文
摘要: 在企業(yè)應用中，持久化無疑是其中非常重要的一環(huán)，盡管OSGi的規(guī)范中也有負責持久數(shù)據(jù)、屬性的服務規(guī)范，但對于企業(yè)應用而言那些顯然是不夠的，這里就以目前Java界流行的Hibernate為例來看看如何集成Hibernate到OSGi中，使得我們能夠很簡單在OSGi中使用Hibernate進行持久化。
閱讀全文
摘要: OSGi越來越風行了，得到的關注越來越多，這本來是好事，但聽到的越來越多的聲音都是認為OSGi對于B/S、企業(yè)應用支持的太不夠，怎么說呢，這些聲音挺好，至少說明發(fā)出這些聲音的人肯定是想過將OSGi應用到自己的項目/產(chǎn)品中去，雖然這是好的，但我覺得更多的原因還是很多的人都習慣的以一種框架的觀點去看OSGi，這對于OSGi而言或多或少有些不公平，為什么這么說呢？
閱讀全文
摘要: 最近一段時間，OSGi這個詞在業(yè)界出現(xiàn)的頻率已經(jīng)越來越高，其受關注的程度也已經(jīng)在大幅度的增長，當然，這其中不可否認OSGi聯(lián)盟、Eclipse、IBM等的推廣，但這主要當然還是得益于OSGi在規(guī)范的模塊化以及動態(tài)化的管理的領先優(yōu)勢，但也會發(fā)現(xiàn)，很多廠商以及很多人對于OSGi仍然處于觀望階段，這主要還是因為OSGi在企業(yè)應用上目前尚無太多案例的原因，但OSGi就真的不適合企業(yè)應用了嗎，還是別的原因讓這么多的廠商、這么多的人對OSGi只是處于觀望的階段呢，應該說，主要原因應該是OSGi目前對于企業(yè)應用缺少足夠的基礎設施，OSGi聯(lián)盟顯然認識到了OSGi在企業(yè)應用上的不足，9月11日OSGi聯(lián)盟對外正式宣布了EEG(EEG的成員包含了IBM、BEA等各大廠商)的成立；而Spring與OSGi的結合更是很好的推動OSGi進入企業(yè)應用。那么，就現(xiàn)在的OSGi規(guī)范來看，它離企業(yè)應用到底還有多遠呢：
閱讀全文
摘要: 個人覺得設計人員可以分為四種類型：模塊設計人員、框架設計人員、專業(yè)領域設計人員、系統(tǒng)設計人員，這四種類型的設計人員并沒有什么絕對的誰強誰弱，只能說各有千秋吧，但一定程度上來講，四種類型之間還是存在著一些關聯(lián)，來看看這四類設計人員的專注點和關聯(lián)吧：
閱讀全文
摘要: 規(guī)范的模塊化開發(fā)是需要OSGi的重要理由之一，模塊化的開發(fā)方式一直就是現(xiàn)在的主流開發(fā)方式，但業(yè)界卻一直缺乏這樣的標準，當然，如果java本身具備這樣的標準自然就更好了，那么大家就會很自然的以同樣的方式去設計、開發(fā)和部署模塊，但目前java暫時還沒有這樣的標準，雖然之前的JSR 277(Java Module System)的目標是制定這樣的標準，但由于該標準制定完后并沒有得到業(yè)界和各大廠商的認可，所以基本上沒起到什么作用，而現(xiàn)在JSR 291的認可則更是觸動了它，目前的情況看下去，OSGi成為下一個版本的Java Module System JSR只是時間的問題而已，整個業(yè)界能夠采取統(tǒng)一的方式進行模塊的設計、開發(fā)是非常重要和有意義的事，這也是OSGi得到IBM等大公司支持的重要原因之一，說了這么多背景性質(zhì)的話后開始來看看OSGi是如何規(guī)范化模塊的開發(fā)的：
閱讀全文
摘要: 在OSGi的官方網(wǎng)站的blog上Peter Kriens(OSGi主席)貼了一篇關于Spring and OSGi的blog，呵呵，peter在blog里寫的還真不客氣，直接說以前只是聽說過spring而已，但基本上沒任何了解，不過peter畢竟是高人，稍微看了后便準確的點出了spring的兩個核心：解決依賴和組裝的配置方式以及POJO的動態(tài)增強，Peter在blog里提及到在OSGi R5中將考慮如何讓現(xiàn)有系統(tǒng)無需改動移植至OSGi平臺中，這點非常令人興奮，不過R5估計還早，最近OSGi R4.1倒是準備release了，目前還沒得到關于4.1對比4的改進的信息，在blog中，peter也提及他認為目前Spring and OSGi的很多實現(xiàn)過于繁瑣，于是之前他和spring-osgi的幾個人員碰面重新考慮了這塊的設計，這可是非常好的事，OSGi的開發(fā)人員的視角和企業(yè)應用的開發(fā)人員的視角確實會有很大的不同，兩者的碰撞還是能產(chǎn)生不少火花的，通過那次討論，Peter認為OSGi的服務注冊/尋找機制可以很好的和spring的applicationContext機制做結合，他覺得現(xiàn)在這樣的改
閱讀全文
摘要: 盡管這只是一個小項目，耗時也很短，但個人覺得這個項目的整個過程還是值得回顧的，項目雖小，五臟俱全，項目經(jīng)歷了兩個小的迭代，迭代過程中經(jīng)歷了典型的需求調(diào)研、設計、開發(fā)&重構、集成測試過程，采用了現(xiàn)場客戶、TDD等實踐，這里就以第一迭代來對這個項目的過程做些總結：
1、迭代版本的頻繁發(fā)布能很好的建立客戶方對于系統(tǒng)的信心；
2、結合真實系統(tǒng)的調(diào)研能夠更加準確的挖掘(引導)客戶的需求；
3、簡單而完整的設計過程和TDD能保證開發(fā)較好的完成；
4、把握設計的尺度，依靠重構來不斷的提升設計。
5、提升系統(tǒng)的交互對于客戶是直接而明顯的幫助。
閱讀全文
摘要: 表單是我們在實現(xiàn)應用時常用的，通常情況下多數(shù)的應用系統(tǒng)對于用戶而言就是在于表單打交道，所以提升表單的交互能力是非常重要的一個環(huán)節(jié)，當然，交互其實很多時候和業(yè)務都是有關系的，就如很多業(yè)務表單需要的是快速錄入的方式，這個時候如回車添加行、Tab快速切換到相應的域上都是非常重要的，在網(wǎng)上查了一下，沒找到一個完整的交互性質(zhì)的表單的Demo，非常的希望css高手們能動手搞一個這樣的東西，這樣以后大家就方便了，由于在現(xiàn)在的一個項目中用到了，就把自己做的一個具備了一定能力的交互表單放到網(wǎng)上，希望有高手能基于這個或者自己做一個能作為以后做表單時可參考的對象，在這個交互表單中，對于交互性主要提供了這么一些：
1、表單進入域時的即時提醒
2、回車增加行
3、星級評分
4、域值非法的提示
下載地址：http://www.aygfsteel.com/Files/BlueDavy/richform.rar
閱讀全文
摘要: 簡單的談談交互中重要菜單和工具欄按鈕；
備忘javascript清空表格中行的問題；
備注動態(tài)創(chuàng)建的radio按鈕無法選中的問題。
閱讀全文
摘要: 在交互設計方面完全就是個外行，看About face那本書也是挺難看懂的，不過自己還是想在這里寫寫自己對于交互方面的一些想法，由于目前做項目/產(chǎn)品時還沒有專業(yè)的交互設計師，現(xiàn)在自己在做項目/產(chǎn)品的時候根據(jù)自己的想法開始對系統(tǒng)的以下幾個方面有所要求：
閱讀全文
摘要: JSR 291：Dynamic Component Support for JSR291，這個消息雖然有點舊了，不過還是同樣非常的令人振奮，OSGi成功的進入了JAVA SE領域，在Java新版本中必然會越來越多的看到OSGi的影子，JSR 291的final版本將在9月1日發(fā)布，其實它的內(nèi)容基本就是OSGi Core的內(nèi)容。
OSGi對于Spring產(chǎn)生了重大的影響，這個從Rod Johnson本人的一段話以及之前Equinox中的"Declarative Services Vs Spring"郵件中可以看出很多：
閱讀全文
摘要: 最近有好幾個人都問了我這個問題，問的挺好的，在軟件業(yè)界新技術層出不窮，做技術的人每天都要不斷的學習新技術，在學習每樣技術之前，自然是要知道為什么要學習它，說白點，就是得給自己一個理由，對于一個對OSGi完全陌生的人而言，學習OSGi能帶給什么呢，給大家?guī)讉€可選的理由：
閱讀全文
摘要: 這個東西其實在以前的OSCAR項目中是有的，而現(xiàn)在處于Apache沙箱中OSGi R4的實現(xiàn)Felix也準備構建這個了，構建OBR其實和構建Maven 2、Ivy這些的Repository沒什么區(qū)別，解決的都是方便其他的使用者通過倉庫直接下到所需要的東西(OBR中提供的是Bundle、Maven2、Ivy中是jar)，最大的好處在于下載的Bundle或jar會根據(jù)其元數(shù)據(jù)信息去下載其所依賴的其他的Bundle或jar，這就大大方便了使用者了。
閱讀全文
摘要: 正式版的下載地址為：
http://www.bluedavy.com/opendoc/OSGI_Opendoc.rar
壓縮包中包含了OSGi Opendoc的PDF、隨文發(fā)布的代碼以及可運行包。
閱讀全文
摘要: 每個系統(tǒng)中都會有需要配置的屬性，而通常這些屬性的配置都會是分散式的管理，而且很多時候都是不支持動態(tài)，在實現(xiàn)這些屬性的管理(新增、編輯、刪除、保存等)時總是要不斷的做重復的工作，如果框架中能提供一個這樣的基礎設施那么對于系統(tǒng)的配置屬性管理來說就會比較好了，這樣的話系統(tǒng)中所有的屬性配置就可以采用統(tǒng)一的方式進行配置、獲取、管理和動態(tài)的更新了，如果能動態(tài)的管理系統(tǒng)配置屬性的話，簡單的動態(tài)改變系統(tǒng)行為也就自然的可以實現(xiàn)了。
閱讀全文
摘要: 聽說過OSGI的人基本都知道OSGI最早是為了移動設備、制造業(yè)生產(chǎn)線等嵌入式系統(tǒng)而制定的規(guī)范，而現(xiàn)在隨著OSGI在桌面式軟件、服務器端應用逐漸的被接受，OSGI組織也決定開始進軍服務器端應用和企業(yè)應用領域，OSGI成立的EEG(Enterprise Expert Group)的關注領域主要是企業(yè)級應用的配置管理、類級別生命周期管理、分布式部署、國際化以及異構軟件集成，在技術領域的目標是為企業(yè)級應用平臺提供包括技術需求、功能規(guī)范、數(shù)據(jù)和元數(shù)據(jù)以及通訊協(xié)議在內(nèi)的服務平臺。
閱讀全文
摘要: 是否能夠真正做面向接口的開發(fā)，和系統(tǒng)所采用的容器或框架具有很大的關系，面向接口的開發(fā)最重要的就是解決系統(tǒng)的依賴問題，在這點上目前最成熟的解決方案莫過于IoC，IoC容器而言最成功的莫過于Spring，那么基于OSGI的話是不是會帶來不同的視角呢，來看看這幾個方面的例子：
閱讀全文
摘要: 這篇blog是繼之前的一篇提升C/S結構軟件的管理性的延續(xù)，在這篇blog中會更加的實際的去介紹基于Eclipse Equinox實現(xiàn)的一個插件框架，而不再是象上篇中那樣的提及的想法而已了，通過這篇blog來展現(xiàn)目前一個這樣的插件框架的實際應用的情況，為了更加形象的表達，在文中會貼出一些目前這個系統(tǒng)的截圖。
閱讀全文
摘要: C/S結構的軟件的可維護性一直就認為是較大的問題，當然，在引入了自動升級這樣的小功能就好很多了，這里談談C/S結構軟件的可管理性，意思就是指Server對Client端的管理，在大多數(shù)C/S結構的軟件中，并沒有很強的管理性的概念，更多的面都是關注Server的業(yè)務處理、數(shù)據(jù)存儲這些功能，當然，不一定所有的C/S結構軟件都強調(diào)Server對Client的管理功能，來說說自己看法中的Server對Client的管理功能吧。
閱讀全文
摘要: 大家都知道，xmlhttp在通信時采用的是utf編碼，而國內(nèi)很多網(wǎng)頁的信息都是采用gbk編碼，所以當直接通過ajax去連接網(wǎng)頁，并將獲取到的信息直接顯示的話就會出現(xiàn)亂碼的現(xiàn)象，有些時候無法改變服務器端網(wǎng)頁的編碼(例如獲取別的網(wǎng)站的天氣預報信息)，在這種時候就只能在客戶端通過js做編碼的工作了，下面這段js就是用于將服務器端返回的gbk編碼字符串轉換為utf編碼字符串：
閱讀全文
摘要: 對于搜索技術基本是完全不懂，在這里也只是談談自己的一些想法，歡迎大家討論.........
閱讀全文
摘要: 這篇新聞令人振奮，OSGI被越來越多的商業(yè)產(chǎn)品認同和采用，在這篇新聞中提到了之前OSGI是被象Eclipse這樣的重量級的開源產(chǎn)品而采用，而現(xiàn)在Apache的Tuscany工程也開始采用，還有之前提及的IBM的重量級的商業(yè)產(chǎn)品--WAS V6.1，現(xiàn)在Adobe大名鼎鼎的CS2產(chǎn)品中也開始使用Equinox，同時這篇新聞也提及到了部分這些商用產(chǎn)品之所以要采用OSGI的原因，最后提及到OSGI對JSR 294、JSR 277可能會產(chǎn)生的影響。
閱讀全文
摘要: 代碼參見code.rar，其中的classic目錄放置了基于Equinox的實戰(zhàn)部分的代碼，其中的ds目錄放置了基于ds重構后的代碼，請從這下載：
http://www.riawork.org/opendoc/code.rar
同時還發(fā)布了一個可直接運行的環(huán)境dist.rar，解壓后直接運行其中的run.bat，就可通過http://localhost:8080/demo/page/login.htm來訪問用戶登錄驗證模塊，請從這下載：
http://www.riawork.org/opendoc/dist.rar
同時在收集到大家的一些意見以及自己對Opendoc的重新瀏覽后，做了少量的改動，都發(fā)布到了新的pdf中了，新的PDF仍然是通過以前的這個地址下載：
http://www.riawork.org/opendoc/OSGI_Opendoc_Preview.pdf
閱讀全文
摘要: 這里的Equinox不是Appfuse的那個Equinox，而是Eclipse的Project(www.eclipse.org/equinox)，是OSGI R4的RI，具體大家可參考我之前發(fā)布的OSGI Opendoc預覽版中對于Equinox的描述和講解，而現(xiàn)在又有一個重量級的產(chǎn)品基于Equinox而構建，那就是WAS V6.1，這也就足以說明在IBM這樣的大廠商心目中對于OSGI的認同。
WAS V6.1之所以要改為基于Equinox而搭建，它認為主要是為了提升WAS的組件化、靈活性、松耦合和簡潔性，具體大家可參見此篇PPT：
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/advanced/help.jsp?topic=/com.ibm.iea.was_v6/was/6.1/Architecture/WASv61_Componentization/player.html
閱讀全文
摘要: 本篇Opendoc按照學習開源框架的基本流程進行編寫，從體驗OSGI到基于OSGI框架的實戰(zhàn)，到深入OSGI，完成對于OSGI從入門到深入學習的過程，最后對于OSGI的現(xiàn)狀和發(fā)展發(fā)表些自己的看法和思考，限于筆者的水平以及時間，文內(nèi)難免有些錯誤，還請大家不吝指正，也希望本文能作為國內(nèi)OSGI的拋磚之作，引出更多的關于OSGI的Opendoc。
由于個人時間的關系，這篇Opendoc歷經(jīng)一個半月左右的時間才基本完成，在此先發(fā)布預覽版，希望能夠得到感興趣的朋友們的指點，先謝了....
請從這下載：http://www.riawork.org/opendoc/OSGI_Opendoc_Preview.pdf
隨本文的代碼將在隨后發(fā)布，請大家關注......
閱讀全文
摘要: 在進行系統(tǒng)設計時，采取的通常都是逐級分解的策略，無論是分層、分模塊都是典型的分而治之的策略，而系統(tǒng)在通過逐步分解形成架構、詳細設計時，輸入、輸出以及擴展都是考慮的重點。
閱讀全文
摘要: 發(fā)送動作是流程中的關鍵動作，程序或用戶通過觸發(fā)發(fā)送動作來進行流程的流轉，對于人工干預的發(fā)送動作來說，通常會顯得很復雜，做過類似辦公系統(tǒng)的人都會體會到這點，發(fā)送為什么會變得復雜呢，首先發(fā)送是由多個步驟構成的，其次就是各個步驟都有一些用戶可通過配置來改變發(fā)送步驟的行為的點，在人工干預要求很強的發(fā)送動作中，就變得更為復雜了。
請見正文......
在實際的流程發(fā)送動作中，還有更為復雜的情況，象抄送、傳閱辦理、跳轉、會簽等這些特殊類型的發(fā)送動作，實現(xiàn)起來就比上述的發(fā)送動作更為復雜，但其實現(xiàn)原理仍然類似上面所述。
閱讀全文
摘要: 昨天重裝系統(tǒng)，突然想到一個問題，如果以后機器本身只要裝個微核，然后所有的東西都可以通過網(wǎng)絡直接安裝就好了，那樣重裝系統(tǒng)就不是件什么痛苦的事了，只要連接到網(wǎng)絡上選自己需要的windows、office等等，平時在用這些軟件的時候隨時可以把個人的偏好上傳到服務器，那是多么爽的一件事呀，^_^，也許可以做個這樣的網(wǎng)站，提供這樣的服務，和一站式的框架類似.....
閱讀全文
摘要: 所思、所悟：
建立客戶、領導的信心；
模塊的擴展設計；
界面設計的重要性。
閱讀全文
摘要: 本來是不想寫這種blog了的，反正自己現(xiàn)在也不準備做項目經(jīng)理了，但在近來項目中碰到的一些事情讓自己產(chǎn)生了些想法，還是要寫寫。
閱讀全文
摘要: 已經(jīng)看完，覺得這本書是越看到后面越精彩，Joel的很多觀點引發(fā)我的思考，覺得這本書對于技術人員而言絕對是本好書，會很大程度的調(diào)整看軟件、做軟件的觀點，不廢話了，繼續(xù)寫最后看的這部分的讀書筆記。
閱讀全文
摘要: 盡管抽象機制就象Joel說的一樣，都是帶有漏洞性質(zhì)的，但是對于軟件行業(yè)總體而言，應該說仍然是有利的，盡管它使得高手越來越強，而新手則越來越弱，抽象機制給業(yè)界帶來的好處是很明顯的，象Webwork、Struts、Hibernate等等，但這些東西同時也會帶來一個問題，就是維護問題，特別是當整個業(yè)界的思想還沒有同步的時候，就會變得比較麻煩了，不知道大家怎么看呢？
Internet時代的軟件來臨了？
覺得我們這代java軟件從業(yè)人員是很幸運的，高度的抽象機制還在建立的過程中，有望參與到其中；軟件的建設思想在改革中，web 2.0、OSGI；軟件的商業(yè)運作模式在改變中，從傳統(tǒng)的銷售軟件的模式改為internet軟件商業(yè)模式。既然擁有這樣的運氣，我們是不是應該做點什么呢？.........
閱讀全文
摘要: 繼續(xù)讀Joel on software，^_^，除了繼續(xù)忍受中文版翻譯的不佳外，還是享受著Joel的一些想法，痛并快樂著吧，好了，不廢話了，這幾天主要讀了冰川下的密碼到動機激勵機制的幾章，這幾章引起的共鳴更強。
閱讀全文
摘要: 緩存是在提升系統(tǒng)響應時常用的一種技術，在我之前的blog中也提及過好幾次這部分的技術，今天還是想從緩存涉及的一些方面再次的去談談，在系統(tǒng)緩存上通常采用的是有頁面緩存、處理緩存和數(shù)據(jù)緩存這三種具體的類別，應該說這三種緩存在實現(xiàn)上還是稍有不同，盡管底層的緩存實現(xiàn)是一樣的。
閱讀全文
摘要: 本來想等讀完之后再來寫讀后感的，不過由于引起的共鳴或者說帶來的感想確實不少，還是決定先寫寫，免得以后有所忘記，^_^
Joel on software不愧是jolt的得獎書籍之一，寫的非常的不錯，不過建議大家直接看E文版，不要看中文版，中文版翻譯的實在不怎么樣，給人的感覺根本就是直譯的方法，象其中體現(xiàn)出不夠?qū)I(yè)的翻譯的詞到處都是，象連編、內(nèi)用軟件等等詞，里面翻譯的很多話都翻譯的很晦澀，估計如果對joel講的那個方面不懂的話，看中文版反而會完全看不懂...
Joel on software是本很薄的書，講的主要是joel在軟件方面的一些經(jīng)驗、想法、實踐，joel是以前Microsoft Excel團隊的領導之一。
目前看了大概一半，流水帳式的記錄下讀書的筆記.....
閱讀全文
摘要: 插件開發(fā)框架其實和目前開源界流行的MVC框架之類的相同，都決定了基于這個框架的開發(fā)方式，如基于MVC框架，就會按照MVC思想來進行開發(fā)，而插件開發(fā)框架呢，也是同樣如此，就要求基于插件的方式來進行開發(fā)，不過插件開發(fā)框架和MVC框架又有不同，插件開發(fā)框架是一個可以成為系統(tǒng)基礎架構的框架，而MVC框架通常來講不足以成為，如在目前的MVC框架Webwork、Struts上我們通常都需要加上Spring、Hibernate來構成系統(tǒng)完整的基礎架構，這個時候由于MVC框架的實現(xiàn)是沒有標準可參照的，就造成了在各種系統(tǒng)中形成了不同的但很類似的基礎架構，但卻造成了無法復用的現(xiàn)象；插件開發(fā)框架則是作為統(tǒng)一系統(tǒng)基礎架構的一種開發(fā)方式，它使得系統(tǒng)的復用成為了可能，而同時由于插件開發(fā)框架對于動態(tài)性的支持，使得系統(tǒng)更加的靈活和可擴展。
來看看一個插件開發(fā)框架，應該提供些什么東西，作為改變系統(tǒng)架構思想的框架，插件框架需要考慮很多方面，如開發(fā)、測試、部署等，總結下來一個插件框架應提供插件的開發(fā)規(guī)范；插件開發(fā)、調(diào)試的IDE；插件的測試方法；插件的部署策略以及插件的管理端。
閱讀全文
摘要: Ajax在帶給我們提供良好的用戶體驗的情況下，還給我們帶來了什么呢？
閱讀全文
摘要: 最近用了下在php業(yè)界中非常出名的wordpress和mambo，使用下來的感覺就是這兩個東西易用性真的太好了，功能方面同樣非常的強大，實在想不出java界的CMS哪個能和它們進行對比的，引發(fā)自己的一些思考，java界的技術人員特別容易以技術觀點去評價一個東西的好壞，覺得這就是為什么java界的論壇、CMS這種東西總是無法和其他語言體系的相比的原因，并不是說java界就真的做不出象mambo這樣易用的CMS。
閱讀全文
摘要: Foundations Of Ajax，Ajax領域中的經(jīng)典書籍，還是決定看看，今天趁有些時間便翻閱了一下，總體而言，這本書寫的還是不錯的，在douban上我寫了這么一段評價：“對于ajax新手而言，這絕對是本好書，可以快速的讓你了解ajax涉及的技術，如何去使用ajax以及ajax的一些缺點；對于ajax老手來說，這本書固然有些簡單，但我相信會帶給你更加系統(tǒng)化的ajax知識。”
閱讀全文
摘要: 之前公司招高程，估計面試了不下30個人，覺得面試別人其實也是一種樂趣，和各種不同的人聊天會讓自己也學到很多，而且由于還是面試階段，會更容易進行沒有隔閡的技術交流，每次面試其實我都覺得是一次很好的技術交流機會，所以我很樂意面試，同時我也希望被我面試的人能夠享受著這種感覺.....
閱讀全文
摘要: 先簡單的做了一個，結合TrimPath提供的JavascriptTemplate實現(xiàn)，目前的解決方案比較丑陋，通過xmlHttpRequest從服務器端獲取模板文件，然后交由JavascriptTemplate結合數(shù)據(jù)解析形成最后的html。
閱讀全文
摘要: 以前的自己一直認為做技術化性質(zhì)的框架、產(chǎn)品是自己的職業(yè)發(fā)展之路，逐漸的慢慢而改變，發(fā)現(xiàn)以前的自己很陷入技術，不斷的追求技術，而忽略了軟件的本質(zhì)，軟件的本質(zhì)是為了提高在某種工作上的效率，其實就是讓業(yè)務能夠更高效的完成，而要做到這一點，依賴的重點并不是技術，而是對業(yè)務的理解以及將業(yè)務轉化為電腦化操作的能力，而這點是非技術能解決的，在業(yè)界可以看到很多公司，象浪潮，它在煙草行業(yè)的成功讓人嘆服，從技術人員的角度去看它的系統(tǒng)可能會覺得不過爾爾，技術人員往往會認為自己要做出一套這樣的系統(tǒng)來不過是小菜而已，但事實是如果讓你現(xiàn)在進入煙草行業(yè)，也許你做出來的系統(tǒng)從技術上是超越了浪潮，但從業(yè)務的理解上以及轉化為電腦化操作的能力上能超越浪潮嗎？這個不是一兩年的業(yè)務積累就夠的，^_^，從現(xiàn)在國內(nèi)的軟件業(yè)界的情況來看，我覺得大部分技術人員的最佳發(fā)展方式還是深入理解業(yè)務，這才是自己的優(yōu)勢，同時掌握將業(yè)務轉化為技術的能力，這樣的技術人員必將是強勢的，這樣做出來的東西才是有足夠的競爭力的，軟件是面向服務的，^_^，不要忘記了這一本質(zhì)。
技術只是一種輔助而已，切勿反客為主.......
閱讀全文
摘要: 為什么界面集成這么的麻煩呢，要做界面集成就是為了將動態(tài)性質(zhì)的實現(xiàn)增加到靜態(tài)的html上去，而這個步驟在現(xiàn)在還沒有什么好的框架或者說好的IDE來支撐，導致了現(xiàn)在的這個步驟很麻煩，這也是為什么在做系統(tǒng)的時候很多時候最怕的不是用戶所要的功能的變化，而往往是界面的變化，界面集成的這個步驟是這么的索然無味而且工作量奇大，怎么來提高這塊的效率呢？
閱讀全文
摘要: 在上篇RIAWork的簡要介紹篇中，已經(jīng)提及RIAWork的重要目標之一就是為界面和交互的靈活變化提供支撐，在這里來看看界面和交互在實際項目中的變化情況以及RIAWork是如何提供對于其變化的支撐。
閱讀全文
摘要: 早上上班，就聽聞用戶評價系統(tǒng)代碼寫的很爛，作為programmer，聽到這句話估計都有很不服的心理，但從用戶評價系統(tǒng)的觀點去看，就可以表示理解，在這個項目中尤其突出，用戶最為看重的是系統(tǒng)漂不漂亮，操作起來是否方便，最后才是系統(tǒng)功能實現(xiàn)是否和需求一樣，而事實證明，很多時候其實系統(tǒng)功能是已經(jīng)實現(xiàn)了的，為什么他們還覺得和他們的需求不一樣呢，問題出現(xiàn)在交互上，操作上他們按照他們的想法去進行，發(fā)現(xiàn)沒法用，在這種情況下，他們就認為系統(tǒng)是不可用的，在系統(tǒng)設計的可用性上要引起足夠的重視，這種看起來的小事往往容易造成客戶對于系統(tǒng)的不信任和抵觸。
閱讀全文
摘要: 在現(xiàn)在的軟件業(yè)界，我認為很大的問題是開發(fā)人員甚至是公司從來都沒有真正的把用戶當成上帝，當然，這和目前業(yè)界的項目有很大的關系，例如項目通常都是時間非常的緊張，N多開發(fā)人員投入只能盡量去保證功能、需求的實現(xiàn)，在界面以及交互上往往不是那么的重視，但其實業(yè)界很多成功的產(chǎn)品都證明，功能往往不是決定性的因素，界面和交互才是用戶最為重視的，而且通常也是打敗對手的重要地方，為什么項目中不在重視功能的同時去重視界面和交互呢，大都是因為現(xiàn)在的框架在界面和交互變化的支撐上都不是很好，導致了每次界面的改動都要花費很大的成本，而交互上則一方面是現(xiàn)在交互設計師急為的缺少，另一方面是還沒引起企業(yè)足夠的重視，所以其實我覺得在web應用開發(fā)框架上最大的目標就是為“把用戶當上帝”提供足夠的支持。
閱讀全文
摘要: 動態(tài)產(chǎn)生的持久模型和數(shù)據(jù)存儲，這個詞語感覺挺晦澀的，不過估計在實際的項目中或者研發(fā)的產(chǎn)品中大家都碰到過這樣的場景：
例如在一個簡單的考試系統(tǒng)中，出題人在系統(tǒng)中出題，答題人進行相應的答題。
希望能發(fā)起討論，總結出一個這樣的設計模式，^_^，順便還發(fā)起對于另外一個場景的設計模式的討論，需要動態(tài)的擴展目前已有的PO或表，不知道在這個場景中大家會采用什么樣的解決方案，預留字段？動態(tài)修改表？關聯(lián)屬性擴展表？抑或別的..........
閱讀全文
摘要: 再次做項目，感覺頗多，項目和產(chǎn)品其實都有應對變化的部分，項目更在乎功能的實現(xiàn)以及對于需求的應變能力，產(chǎn)品更在乎的是通用性的高度抽象、開放性以及基礎設施的建設上，產(chǎn)品比項目更依賴規(guī)劃人員對于通用性需求的挖掘上，而項目則更依賴需求人員對于客戶的需求的挖掘上。
閱讀全文