Plugin Architecture
Architecture about plugin system,such as eclipse、maven,always can use Osgi to impl this architecture.
摘要: 這篇blog是繼之前的一篇提升C/S結構軟件的管理性的延續，在這篇blog中會更加的實際的去介紹基于Eclipse Equinox實現的一個插件框架，而不再是象上篇中那樣的提及的想法而已了，通過這篇blog來展現目前一個這樣的插件框架的實際應用的情況，為了更加形象的表達，在文中會貼出一些目前這個系統的截圖。
閱讀全文
摘要: 插件開發框架其實和目前開源界流行的MVC框架之類的相同，都決定了基于這個框架的開發方式，如基于MVC框架，就會按照MVC思想來進行開發，而插件開發框架呢，也是同樣如此，就要求基于插件的方式來進行開發，不過插件開發框架和MVC框架又有不同，插件開發框架是一個可以成為系統基礎架構的框架，而MVC框架通常來講不足以成為，如在目前的MVC框架Webwork、Struts上我們通常都需要加上Spring、Hibernate來構成系統完整的基礎架構，這個時候由于MVC框架的實現是沒有標準可參照的，就造成了在各種系統中形成了不同的但很類似的基礎架構，但卻造成了無法復用的現象；插件開發框架則是作為統一系統基礎架構的一種開發方式，它使得系統的復用成為了可能，而同時由于插件開發框架對于動態性的支持，使得系統更加的靈活和可擴展。
來看看一個插件開發框架，應該提供些什么東西，作為改變系統架構思想的框架，插件框架需要考慮很多方面，如開發、測試、部署等，總結下來一個插件框架應提供插件的開發規范；插件開發、調試的IDE；插件的測試方法；插件的部署策略以及插件的管理端。
閱讀全文
摘要: 繼續以OSGI R4的Declarative Services(DS)來講講Service-Oriented Component Model(SOCM)，SOCM對于現有的Component-Oriented Model或者是Service-Oriented Model來說到底有什么不同的地方，到底DS能給我們帶來什么樣的好處呢？
閱讀全文
摘要: Jeff在EclipseCon 2006那篇介紹Equinox的PPT中提到的Declarative Services(文中全部采用DS簡稱)的用法讓人極度被吸引，但同時又產生懷疑，想起以前自己看過DS好像不是這樣的，沒這么強，便再次翻閱了OSGI R4中的DS的章節，以驗證Jeff的說法，^_^，仔細看過DS章節后，確實為Declarative Services的強大而感到高興，DS是一個面向服務的組件模型，從組件模型層次上去看，它超越了傳統的組件模型，在組件模型描述的完備性上有了很大的進步，例如在組件服務的依賴上、組件服務的延遲加載上、組件服務的多樣性控制上、組件服務的配置上以及組件服務的生命周期管理上，不過DS只能在OSGI容器中使用，這盡管看上去可能是個弱點，但作為OSGI規范中的一部分，這無可厚非，其思想值得很多目前Component Model的開源框架值得思考和學習，如感興趣，請閱讀OSGI R4中DS章節。
閱讀全文
摘要: Equinox，我不想多做介紹，相信很多人都有所了解了，不了解的可具體去www.eclipse.org/equinox看看。
最近基于equinox做了一個系統，還是碰到了一些問題，當然也得到了在插件體系架構下的不少優點，在這里也做個總結。
總體而言，基于equinox做開發對于大多數java開發人員來說應該不會有太多改變的感覺，最多改變的感覺應該是帶給設計師，設計師需要有發揮插件體系架構優點以及減少其帶來的缺點的能力，^_^
閱讀全文
摘要: 插件架構體系是我一直就非常關注的內容，其實插件架構體系的發展已經有很久的背景了，插件架構體系的優點我們也是能看的非常明顯，象硬件一樣的即插即用、無論對于公司還是業界而言的良好的積累方式、為公司或業界提供統一而規范的開發方式以及穩定的內核架構等等，這些優點無論對于公司還是業界來說都是非常重要的。
插件架構體系基本的一個概念就是基于松散的模塊積累方式，通過新增插件以及擴展原有插件的方法來完成系統的實現，凡事有利必有弊，在看到插件架構體系的這些優點的同時，在實現和使用插件架構體系的時候仍然會碰到不少的問題，在本文中大概的整理了一些也相應的提出了一些自己的看法。
閱讀全文
摘要: 大家都知道Eclipse是一個典型的插件系統，而從3.0起其插件體系架構就重構為基于OSGI規范來實現的，從這也可以看出osgi必然與Plugin Architecture是有很多的關聯性的，在這里就來說說自己對Osgi R3與Plugin Architecture的關聯。
閱讀全文
摘要: 通過對Eclipse啟動過程的分析，可清晰的看到Eclipse Kernel+Core Plugins+Application Plugins的方式，在代碼中分別對應為loadBasicBundles和registerApplicationServices，loadBasicBundles通過加載config.ini中的osgi.bundles完成基本的bundles的加載，去看看這個配置會發現是org.eclipse.core.runtime還有一個update，core.runtime又會通過IDEApplication來完成整個Eclipse的啟動，同時會注冊所有與workbench相關的plugin。Eclipse由于以前版本的Plugin Framework是沒有采用OSGI的，所以通過EclipseAdaptor的方式來實現與以往的兼容，目前新的Plugin采用的方式基本就是manifest.mf描述Plugin OSGI部分的信息，Plugin.xml描述擴展點的信息。Eclipse中有非常多優秀的設計，這個在看它的代碼時會有很深的感觸，比如Contributing to
閱讀全文
摘要: 通過對上面兩種實現Plugin Architecture的簡介，分別都實現了需求中的內容，但都有提升的余地，個
人認為Osgi的方式需提升對于Plugin管理的關注(不僅是生命周期管理)、而JMX+IoC方式則需提高對于
Plugin內部結構的關注(就象Osgi將Plugin分解為了Bundle和Service)，至于Plugin的擴展方面覺得
Eclipse的Extension Point是非常不錯的一個設計，不過同時也看出在Plugin Architecture的實現上基
本都采用了管理和靜態結構分離的方法，其實這個好處是非常明顯的，可以快速的將系統原有的模塊通過
編寫一個管理類的方法就可作為plugin放入系統中，這提升了簡便性，當然最大的作用還是分清了職責，
說一句題外話，職責單一一直是軟件設計的重中之重，此文純屬拋磚引玉，希望能聽到更多關于Plugin
Architecture的聲音，也希望大家都關注Plugin Architecture，最近也出了一個JPF，不知道大家是否有
所了解。
閱讀全文
摘要: Plugin System現在的流行程度已經勿庸置疑了，在N多的白皮書、解決方案中都可以看到即插即用這樣的詞語，而市場上面向構件、插件的軟件也是越來越多，其實插件式的組裝系統或者說”搭積木”式的組裝系統一直就是軟件界的追求，但對于Plugin System還是有些迷惑的地方，還望大家一起討論討論，^_^，目前的Plugin Framework基本都是一種Kernel+Core Plugins組成的結構體系，說出來就是all are plugins，^_^，典型的就如Eclipse，其實Maven也算的上的
閱讀全文