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

一、模塊化

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

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

圖片來自互聯網

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

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

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

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

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

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

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

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

由前面的分析可知，Java模塊化支持局限于細粒度的面向對象支持，需要有更高抽象粒度的模塊。OSGi便是Java模塊化需求其中一個解決方案。

一、OSGi

1. 什么是OSGi?

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

2. OSGi框架

OSGi框架是應用的執行環境。OSGi框架規范定義了OSGi的行為，現已有Apache Felix、Eclipse Equinox以及Knopflerfish等多個開源實現。OSGi的分層架構如下：

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

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

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

3.OSGi生態

4.Bundle交互

了解了OSGi基礎知識后，我們來看下Bundle交互的實現方式：

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

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

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

②通過Declarative Service來實現；

③通過Blueprint來實現；

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

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

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

一、OSGi在OpenDaylight中的應用

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

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

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

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

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

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

①根據應用的業務場景設計Bundle，并設計Bundle的服務；

②使用IDE實現Bundle，配置Blueprint容器XML文件；

③打包和部署Bundle的JAR文件；

④啟動類似Karaf之類的部署環境，并根據業務需要安裝Bundle。

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