嘗試給SOFA下的一個定義

OSGI：服務與組件（Components & Services）

關鍵理念是組件與服務（Components & Services），Developing with OSGi technology means developing bundles: the OSGi components.（摘自：http://www.osgi.org/About/WhyOSGi）。

直觀點來理解，我們開發的一個基於OSGI的系統（如settleprod），裏面的每一個工程都是一個component。每一個component實現並註冊自己的services，而這些services將會被其他的component來引用。

最後，這些component在部署的時候都會打成一個jar包，每個jar包裏面都會有描述自己的一個MF文件，比如下面就是sofa-platform-common-1.2.jar這個包的一個MF文件，在META-INF文件夾下：

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: xi.hux
Build-Jdk: 1.5.0_08
Bundle-ManifestVersion: 2
Bundle-Name: Alipay SOFA Platform common
Bundle-SymbolicName: com.alipay.sofa.platform.common;singleton:=true
Bundle-Version: 1.0.0
Bundle-Vendor: Alipay
Eclipse-LazyStart: false
Spring-Parent: org.mule.esb


關鍵的信息是：Bundle-SymbolicName: com.alipay.sofa.platform.common，這個事標示這個組件的名字，其他組件要引用這個組件的服務的話會用到這個名字。

現在業界內對OSGI的實現比較典型的就是Equinox，這個其實就是我們每天正在使用的Eclipse的內核，現在版本Eclipse就是基於實現了OSGI的這個Equinox平臺的。我們現在不需要下載任何第三方jar包就可以在eclipse上開發OSGI組件了。

另附一篇JavaWorld上的 Hello, OSGi, Part 1: Bundles for beginners，算是一個OSGI的“hello world”，手把手教你怎麼樣直接使用Equinox開發OSGI bundle。

Spring：反轉控制IoC

這個沒什麼好說的，看過《spring in action》一遍就能很容易的上手Sping了，沒書的話直接就去看documentation也無所謂。關鍵理念就是IoC，把每一個業務實現的類都管理成bean，再使用反轉控制來控制他們之間的依賴關係，然後就是玩玩bean的生命週期之類的。

Spring Dynamic Module：OSGI服務(Services)的Spring實現

關注OSGI的話都會瞭解到Spring那邊有一個Spring Dynamic Module的東西，Spring動態模塊。Spring Dynamic Module在原來的Spring的基礎上增加了3個重要的jar包（可能由於版本不同，報名也變了）：


org.springframework.osgi.bundle.extender
org.springframework.osgi.bundle.core
org.springframework.osgi.bundle.io
事實上，這三個jar包在OSGI裏面都是一個組件，不同的是org.springframework.osgi.bundle.extender這個組件，他會監聽其他組件的部署，然後在其他組件部署後去到該組件jar下查看是否有名爲”spring”的目錄，如果有的話則這個組件對他而言就是一個 Spring Enabled的組件，然後他就會爲該組件創建一個Spring的應用上下文(Application Context)，讀取在”spring”目錄下面的xml配置文件，並創建xml配置文件裏面定義的所有bean，配置他們之間的依賴。如果他在這些配置文件中發現有<osgi-service ref=”aBean” interface=”aInterface”>的定義，則會在一個Service Repository（服務庫）上註冊這個服務，而且服務的索引key爲interface指定的接口，服務的實現爲ref指定的在組件內的一個bean。如果他在這些配置文件中發現有<osgi-reference id=”name” interface=”bInterface”>的定義，則會去Service Repositry查找以interface標識的服務，查看是否有這個服務的實現，並在組件內的應用上下文註冊成爲一個bean,供組件內的其他 bean使用。

這就是服務的註冊和服務的引入。他與Equinox實現的服務的註冊和服務的引入之間的不同就是，Equinox的實現是通過編程的API來實現的，你要註冊服務需要自己在程序內調用一個context.registerService的API，把自己的服務註冊上去，服務的引入也需要調用一個 getService的API來獲得；而Spring Dynamic Module裏面的實現方式是沿用了Spring的理念，IoC，服務的註冊和獲取不用你在程序裏面來完成，只需要你在XML配置文件中說明就好了，然後 Spring會爲你註冊和引用。

作爲介紹OSGI的同一系列文章，Hello, OSGi, Part 2: Introduction to Spring Dynamic Modules也介紹了OSGI的Spring實現，同樣是手把手的教程。

Nuxeo Runtime：主機適配（Host Adapt：OSGI組件的實現）和擴展（Extension）

我們編寫的一個個工程很容易在Equinox裏面就是一個組件，但是在其他沒有完全實現OSGI技術（比如Jboss）的平臺上面，怎麼讓我們的工程變成組件呢？Nuxeo Runtime就是做的這個功能。比如，我們的一個工程，最後打包成jar包，然後部署到Jboss上面，最後是成爲了一個MBean，而不是一個 OSGI的組件。但是，如果我們通過Nuxeo Runtime的適配器來部署到JBoss上，在Jboss上仍然是一個MBean，但是這個MBean也是一個OSGI組件，那上面介紹的OSGI的技術就可以實現了。換種方式說，就是NXRuntime使用OSGI組件模型，並利用一堆Adapters來把這些組件部署到不同的Java主機平臺上面，比如Jboss，Geronimo（另一種Java EE服務器）。

另外，Nuxeo Runtime除了實現了OSGI組件技術外，還實現了一種擴展機制。事實上，看一下有關OSGI架構的介紹，OSGI 並沒有關於擴展的定義，擴展是Nuxeo Runtime借鑑Eclipse插件技術增加的功能。有接觸過Eclipse插件開發的話，就會知道Eclipse插件開發無非就是爲上面的擴展點（Extension Point）和擴展（Extension），比如你想新增加一個View，用來顯示當前編輯器上面都有哪些TODO標籤，那麼只需開發一個插件，這個插件有一個擴展，該擴展會去擴展Eclipse上面id爲org.eclipse.ui.views的擴展點。那麼Nuxeo Runtime也實現了這種擴展機制，讓你很容易的爲擴展點編寫擴展，比如，在組件名爲Bundle-SymbolicName: com.alipay.sofa.platform.event的一個支付寶組件裏面，定義了一個擴展點serviceExport：

<osgi:extension-point ref=”sofaPlatformServiceExporter” name=”serviceExport”>
<osgi:object />
</osgi:extension-point>

這個擴展點是用於暴露Web Service的，以後我們需要編寫Web Service的時候，只需要擴展這個擴展點，把自己的接口和實現指明就可以了，如下：

<osgi:extension bean=”sofaPlatformServiceExporter” point=”serviceExport”>
<osgi:content>
<serviceExport>
<serviceInterface>com.alipay.settleprod.product.cod.facade.LogisticsResolveService</serviceInterface>
<serviceBean>logisticsResolveService</serviceBean>
</serviceExport>
</osgi:content>
</osgi:extension>

這樣使得我們的組件很靈活，以後要增加web service和修改web service時只需要增加插件，編寫擴展即可。如果想了解多點有關擴展和擴展點，可以直接google下eclipse插件開發，也可以直接查看支付寶裏面擴展和擴展點是如何實現的。

Sofa：Spring Dynamic Module+Nuxeo Runtime實現OSGI的整套技術

現在感覺對Sofa的理解比較清晰了，嘗試給Sofa一個說法就是“使用Nuxeo Runtime實現了OSGI組件模型，利用Spring Dynamic Module實現組件服務機制，並且再利用Nuxeo Runtime實現了擴展機制”的一整套技術組合。其優點：

模塊化，模塊邊界清晰，易於維護。
服務化，服務的註冊和依賴都很方便。
易於擴展，很好的定義擴展點和擴展。
這只是我的一種現在的理解，可能還有很大偏差，但是覺得大概就是這些了。當然，整個貫穿其中的還有Spring的IoC機制，讓我們能很快速的就構建我們的服務，編寫擴展和擴展點。還有很多ESB技術，Web Service技術等等，但是這些技術都是依託於上面所說的那些技術的，比如，使用Mule實現的ESB，在支付寶裏面的地位是就是一個普通組件（記得是在近衛軍時上課時我提的一個問題的答案），但是他不是業務組件，是架構組件。還有Xfire實現的web service，都是一樣的。