從寫單個類的打印Hello World小程序到OSGi模塊化開發(fā)，確實存在較大的難度，本文將從模塊化、OSGI模型以及OSGI在OpenDaylight中的應(yīng)用等方面進行介紹。

一、模塊化

我們學(xué)習(xí)Java語言時，最初寫的程序便是在控制臺打印Hello World，此時，我們寫的代碼放在一個類中；慢慢地，我們編寫的代碼需要放在幾個的類時，我們就要考慮如何設(shè)計類與類之間的關(guān)系，你需要面向?qū)ο蟮脑O(shè)計原則和模式；工作中我們要做一個小項目，就可能涉及到數(shù)百個類了，我們會根據(jù)不同的業(yè)務(wù)職責(zé)將這些類進行邏輯上的劃分，分隔不同的小模塊，每個小模塊賦予相應(yīng)的職責(zé)，也就是將一個系統(tǒng)分解為多個較小的互相協(xié)作的單元，并設(shè)定單元之間的邊界來改善系統(tǒng)的維護性和封裝性。大致過程如下圖①②③所示：

至目前為止，我們所做的事情是對類進行了邏輯的包裝，而實質(zhì)上并沒有對類進行物理隔離。通常情況下，軟件在初始構(gòu)建時，并不是很復(fù)雜，但隨著時間的推移、業(yè)務(wù)特性的增加、不規(guī)范的代碼調(diào)用以及為趕進度而忽略架構(gòu)的設(shè)計，就使得軟件變得復(fù)雜起來，甚至極難維護。如同雙11爆倉時凌亂不勘的場景：

圖片來自互聯(lián)網(wǎng)

那么如何降低軟件的復(fù)雜性呢？生活中的貨物運輸或許是一個很好的借鑒例子，我們將零散的貨物打包在一起，形成封閉的空間；然后，通過標準的接口裝載到集裝箱運輸船。

事實上，早在1972年國際軟件工程大師David Parnas在《On the Criteria To Be Used in Decomposing Systems into Modules》一文中就提出了模塊化編程的思想：“每項任務(wù)構(gòu)成一個獨立的、特有的程序模塊。實現(xiàn)時，每個模塊及其輸入/輸出都有確定含義的......系統(tǒng)以模塊化的方式進行維護”，其實質(zhì)就是軟件模塊劃分應(yīng)該以基于信息隱藏為目的，以職責(zé)劃分為手段，從而封裝變化。聯(lián)想到集裝箱的例子，軟件的模塊可以類比為集裝箱，如下圖所示：

我們現(xiàn)在正式介紹軟件模塊，在《Java應(yīng)用架構(gòu)設(shè)計 模式與OSGI》一書中進行了描述：軟件模塊是可部署的、可管理的、原生可重用的、可組合的、無狀態(tài)的軟件單元，它為用戶提供了簡潔的接口。

①可部署：模塊是一個獨立的部署單元，它能夠與其他軟件模塊共處。EAR、WAR以及JAR文件。

②可管理：在運行時，模塊可以進行安裝、卸載以及更新。實體樣例：EAR、WAR以及JAR文件。

③原生可調(diào)用：模塊總是原生可調(diào)用的。也就是說，模塊暴露的操作是通過直接調(diào)用方法觸發(fā)的。

④可組合：一般指的是粗粒度的模塊是由細粒度的模塊組成的。

⑤無狀態(tài)：特定版本的模塊只會存在一個實例。

由前面的分析可知，Java模塊化支持局限于細粒度的面向?qū)ο笾С郑枰懈叱橄罅６鹊哪K。OSGi便是Java模塊化需求其中一個解決方案。

一、OSGi

1. 什么是OSGi?

OSGi(Open Services Gateway initiative,開放服務(wù)網(wǎng)關(guān)協(xié)議)是由 1999 年成立的 OSGi 聯(lián)盟提出的一個開放的服務(wù)規(guī)范，最早用于嵌入式設(shè)備。在2004年，Eclipse發(fā)布于基于OSGi的運行時模型，把 Equinox 作為底層運行平臺。借助于Eclipse,OSGi在商業(yè)化軟件企業(yè)中得到廣泛的關(guān)注?，F(xiàn)已廣泛應(yīng)用于移動設(shè)備、桌面應(yīng)用以及企業(yè)應(yīng)用服務(wù)器。

2. OSGi框架

OSGi框架是應(yīng)用的執(zhí)行環(huán)境。OSGi框架規(guī)范定義了OSGi的行為，現(xiàn)已有Apache Felix、Eclipse Equinox以及Knopflerfish等多個開源實現(xiàn)。OSGi的分層架構(gòu)如下：

模塊層定義了模塊，稱為Bundle，體現(xiàn)為一個JAR文件，由類文件、資源文件和MANIFEST.MF組成。和普通的jar文件唯一不同的就是MANIFEST.MF文件的內(nèi)容，基本上都是標識Bundle的屬性，Import-Package聲明了請求JAR文件中的代碼所需要的外部包。其文件樣例為：

生命周期層定義了動態(tài)安裝和管理Bundle，即可以在框架中安裝和卸載bundle，而不需要重啟應(yīng)用進程。

服務(wù)層定義了面向服務(wù)的應(yīng)用編程模型，涉及面向服務(wù)的發(fā)布、查找和綁定交互模式：服務(wù)提供者將服務(wù)發(fā)布到服務(wù)注冊中心，然后服務(wù)請求者通過搜索服務(wù)注冊中心，查找可供使用的服務(wù)。這種機制稱為VM中的SOA。事實上，服務(wù)就是Java接口。

3.OSGi生態(tài)

4.Bundle交互

了解了OSGi基礎(chǔ)知識后，我們來看下Bundle交互的實現(xiàn)方式：

(1) Export和Import：即通過Package的Export和Import來進行。服務(wù)提供者Bundle對外Export自己的package，而服務(wù)請求者則根據(jù)業(yè)務(wù)需要Import外部的Package；

(2) service：服務(wù)提供者Bundle對外提供Service，而服務(wù)請求者查找Service。而提供Service的方式又有：

①通過BundleContext(Bundle上下文)來提供和獲??；

②通過Declarative Service來實現(xiàn)；

③通過Blueprint來實現(xiàn)；

在這里，我們重點介紹第3種方式--Blueprint。Blueprint提供一個依賴注入框架來實現(xiàn)OSGI，并在OSGI Compendium R4.2里被OSGI組織標準化。Blueprint的強大之處在于即具有Spring強大且非侵入性的企業(yè)級編程模型又具有OSGi的動態(tài)性、模塊化的特性。

Bundle間的交互使用類似Spring Bean的方式配置定義，Blueprint的XML文件定義和描述不同Bundle的組裝。一個簡單的Blueprint示例如下：

XML文件的命名空間標識blueprint 1.0.0版本。頂級的blueprint元素標識XML文件作為一個blueprint模塊來定義；reference元素標識從OSGi服務(wù)注冊中心為組件獲得一個服務(wù)；bean元素標識與Spring Bean相同的含義。

一、OSGi在OpenDaylight中的應(yīng)用

Java模塊化的局限和OSGi框架的模塊化標簽，使得Java和OSGi走在了一起，進而增加了Java模塊化開發(fā)的能力。

作為SDN控制器，OpenDaylight使用了Java語言編寫，SDN控制器本身的功能與協(xié)議繁多導(dǎo)致了其子項目眾多，如何更好地按需動態(tài)加載所需的項目成為技術(shù)選型的一個重要因素。而OSGi的如下特性也使得其在OpenDaylight中發(fā)揮很大的作用：

①將一個程序打包成邏輯上獨立的JAR文件，并且只部署那些某個安裝所需要的部分。

②將一個程序打包成邏輯中獨立的JAR文件，聲明哪些代碼可以被其他JAR文件訪問，并且強調(diào)可見性。

③為程序提供一個插件式的擴展機制。OSGi模塊化特別適合提供強大的擴展機制，包括支持執(zhí)行時的動態(tài)性。

OpenDaylight采用了OSGi框架之后，那開發(fā)一個應(yīng)用程序的流程又是怎樣的呢？下面給出一般方法：

①根據(jù)應(yīng)用的業(yè)務(wù)場景設(shè)計Bundle，并設(shè)計Bundle的服務(wù)；

②使用IDE實現(xiàn)Bundle，配置Blueprint容器XML文件；

③打包和部署B(yǎng)undle的JAR文件；

④啟動類似Karaf之類的部署環(huán)境，并根據(jù)業(yè)務(wù)需要安裝Bundle。

事實上，OpenDaylight不僅采用了OSGi框架，而且還使用了Apache Karaf這個企業(yè)級容器，下篇文章我們將探討Apache Karaf的基礎(chǔ)知識。