上篇說到,經過分析后決定選用JNDI來實現服務的遠程注冊、查找和路由,在這篇blog中就來詳細分析下基于JNDI怎么和OSGi結合來實現服務的遠程注冊、查找和路由。
1、遠程注冊
目前OSGi DS注冊時是直接在本地注冊服務實例的,要支持遠程注冊的話首先需要修改DS注冊服務部分的代碼,在ds的描述中需要增加一個配置項,以支持將服務注冊到遠程服務中心,例如:
<service>
<provide interface="cn.org.osgi.opendoc.bulletin.service.WebCommand"/>
<server>jnp://10.100.100.100:1099,jnp://10.100.100.101:3099</server>
</service>
在注冊時直接采用InitialContext進行注冊,不過這里要采取個不同的策略,就是通常jndi注冊時綁定的都是實際對象的實例,但要注意,其實在分布式的服務框架體系中,服務是分布式部署的,服務中心僅僅是個注冊、路由的地方而已,那么這種情況下只需要把服務的相關元信息注冊到服務中心即可,所以這個時候我們會提供一個服務元信息對象,然后把這個元信息對象綁定到jndi上去,這里涉及到的一個問題是jndi的名稱怎么取,這個名稱要便于查找服務,同時還得保證唯一性。
可以看出,在這個實現方案中,最重要的就是這個服務元信息對象了,這個元信息對象中應該包含和OSGi服務模型同樣的所有的信息,同時還需要包括服務的狀態信息,由于包含了狀態信息,叫元信息對象的話有點不正確,要么干脆就叫Service或ServiceInfo得了。
2、遠程調用
遠程調用準確來講應該分為引用遠程服務和調用遠程服務兩個環節,因為對于lazy init的服務而言首先是遠程查找服務,但并不發生調用,所以在這里也分為兩步來描述下。
引用遠程服務
引用遠程服務這塊的話JNDI目前的實現肯定是很難滿足需求的,按照OSGi的服務模型,在引用服務是只提供了服務的接口名,頂多就是增加了一些服務的特定屬性來限定服務的范圍,而JNDI在查找綁定的對象時是直接指定名稱查找的,一對一的方式,但在OSGi的服務模型中獲取到的服務有可能會是多個的,來看看怎么樣修改實現這個需求。
首先仍然是修改DS描述,以支持引用遠程服務,例如:
<reference name="CommonDaoService" interface="cn.org.osgi.module.hibernate.service.CommonDaoService" bind="setCommonDaoService" unbind="unsetCommonDaoService" policy="dynamic" server="jnp://10.100.100.100:1099"/>
在查找遠程服務中心的服務時,通過jndi將需要查找的服務的接口、屬性等過濾條件傳遞給服務器端,這個應該可以通過擴展JNDI的lookup來實現,JNDI服務中心接到請求后根據過濾條件從注冊的服務中查找到符合條件的服務元信息對象,并返回服務元信息對象集合至調用端,之后由生命周期管理對象決定后續的動作,關于生命周期管理對象在后一個篇章中來詳細的分析。
調用遠程服務
當遠程服務被調用時,此時應該提供的一個配置是是否可跳過服務中心直接向另一端的服務發起調用(某些情況下可能會有這樣的需求),另外就是同步調用和異步調用的配置的支持。
當調用時,可以走某種通訊機制對請求的服務的接口、方法以及參數傳遞至服務中心或相應的服務提供端,當服務提供端處理完畢后繼續走這個通訊機制把處理的結果返回至調用端。
經過上面的分析后,可以看出,基于JNDI實現服務的注冊、查找不會是難點,在后面一個篇章中開始來分析生命周期的管理的問題,就會比較的復雜了,進入分布式環境后,生命周期的管理就比之前OSGi DS的生命周期管理復雜了很多。
<<
基于OSGi實現分布式服務框架歷程(二)
<<
基于OSGi實現分布式服務框架歷程(一)
>>
基于OSGi實現分布式服務框架歷程(四)