【導(dǎo)讀】個非常值得研究的方向。型，網(wǎng)絡(luò)操作工單是一系列網(wǎng)絡(luò)操作任務(wù)的集合。同時，使用OSGi動態(tài)模塊化技術(shù)作為系統(tǒng)模型的基礎(chǔ)架構(gòu)，分析了OSGi. 行了詳細的描述。行以及操作任務(wù)的執(zhí)行狀態(tài)的實時監(jiān)控等系統(tǒng)業(yè)務(wù)流程。

　　

【正文】 套完成的網(wǎng)絡(luò)管理解決方案功能 ，包括了訪問控制，認(rèn)證，安全日志等。 CMIP 的管理模式是通過事件報告的形式，檢測網(wǎng)絡(luò)中設(shè)備的狀態(tài)、參數(shù)、配置等變化，并通過管理進程實現(xiàn)事件 報告 的統(tǒng)一管理 ，管理進程能夠及時對事件做出相應(yīng) 。 MTNM（ Multi Technology Network Management） 是一種多技術(shù)網(wǎng)絡(luò)管理 標(biāo)準(zhǔn)，是由 TMF 針對多技術(shù)設(shè)備，多廠商設(shè)備，提出的一種多技術(shù)并存的網(wǎng)絡(luò)管理標(biāo)準(zhǔn)。 MTNM 是一種基于 CORBA 分布式技術(shù)的網(wǎng)絡(luò)管理系統(tǒng)與網(wǎng)元管理系統(tǒng)接口交互的標(biāo)準(zhǔn)協(xié)議， MTNM 提供的是網(wǎng)絡(luò)端到端的管理，并且能夠?qū)崿F(xiàn)多廠商網(wǎng)絡(luò)設(shè)備并存的預(yù)先配置 ，不同于 MTOSI，它是一種純粹的面向資源層次的。MTNM 使基于多廠商，多技術(shù)的系統(tǒng)能夠快速的發(fā)布新的服務(wù)，并且成本更低，速度更快。 MTNM 提供的服務(wù)包括網(wǎng)絡(luò)資源設(shè)備清單管理，網(wǎng)絡(luò)設(shè)備供應(yīng)，設(shè)備故障管理，設(shè)備運行監(jiān)控等 ，并且支持多種網(wǎng)絡(luò)通信技術(shù)： SONET/SDH， PDH，DWDM， Ether， DSL， ATM 等。 MTNM 對于網(wǎng)絡(luò)管理系統(tǒng)和網(wǎng)元管理系統(tǒng)之間的接口作了統(tǒng)一化的處理，使用統(tǒng)一的接口基礎(chǔ)模型，使各種技術(shù)之間的交互的模式能夠通過相同的方式進行 ，比如，對于面向連接的技術(shù)，從 DWDM 跨越到 ATM， MTNM 會為兩種不同技術(shù)的交互提供相同的基本端點模型和連接模型，使兩種技術(shù)能夠便捷的交互而無需更多的轉(zhuǎn)換操作。 雖然 MTNM 主要的應(yīng)用在于網(wǎng)絡(luò)管理系統(tǒng)與網(wǎng)元管理系統(tǒng)之間的交互，但是，也可以用于多網(wǎng)絡(luò)管理系統(tǒng)之間的交互，比如以Client/Server 客戶端服務(wù)器的模式， 一個管理系統(tǒng)作為客戶端，另一個或多個作為服務(wù)器，通過 MTNM 交互。 對于本文中的網(wǎng)絡(luò)操作工單管理系統(tǒng)與網(wǎng)絡(luò)管理系統(tǒng)的交互，本系統(tǒng)平臺也即是客戶端，網(wǎng)絡(luò)管理系統(tǒng)就是后臺服務(wù)器。 浙江大學(xué)碩士學(xué)位論文 第 2 章 網(wǎng)絡(luò)管理技術(shù)分析 11 分布式通信技術(shù) 分布式技術(shù)是目前比較流行的系統(tǒng)交互技術(shù)，目前使用比較多 的有 Microsoft的 COM/DCOM， CORBA 等， 相比與 COM/DCOM 的平臺局限性和 idl 不支持繼承的缺陷性，在基于 TMN 規(guī)范的管理網(wǎng)絡(luò)系統(tǒng)中，使用并不廣泛的特點， CORBA的多語言 混合使用 以及平臺無關(guān)性的優(yōu)勢，使之在許多分布式網(wǎng)絡(luò)系統(tǒng)中得到了廣泛的研究和應(yīng)用 [3]。 CORBA 定義了一系列的 API 和通信協(xié)議， 并且能夠應(yīng)用于異構(gòu)的應(yīng)用程序平臺之間相互操作，這些應(yīng)用程序平臺可以是使用不同程序語言編寫實現(xiàn)的，運行在不同的平臺上，比如使用 C 語言編寫的網(wǎng)絡(luò)管理系統(tǒng)與使用 Java 語言編寫的網(wǎng)絡(luò)服務(wù)層之間，通 過 CORBA 能夠?qū)崿F(xiàn)平臺間的透明通信。 CORBA 主要包括三個部分：接口定義語言（ IDL），對象請求代理（ ORB），以及 ORB 之間的交互協(xié)議 IIOP。 CORBA 的實現(xiàn)流程大致如下： C l i e n t S e r v e rS t u b T i eO R B O R BI I O P 圖 CORBA 通信結(jié)構(gòu) 編寫 IDL 接口定義文件； 通過指定的編譯器，將 IDL 文件編譯為相應(yīng)的語言源代碼文件，在編譯的同時，生成服務(wù)器框架和客戶端存根 ； 在服務(wù)器端 ，編寫服務(wù)對象實現(xiàn)程序 ； 在客戶端存根，編寫客戶對象 程序，通過客戶對象程序調(diào)用服務(wù)端對象； 分別編譯服務(wù)對象和客戶對象程序； 浙江大學(xué)碩士學(xué)位論文 第 2 章 網(wǎng)絡(luò)管理技術(shù)分析 12 運行服務(wù)端和客戶端程序。 本章小結(jié) 本章介紹了電信管理網(wǎng) TMN 的概念以及管理網(wǎng)層次的劃分， 描述了管理網(wǎng)網(wǎng)絡(luò)管理 的概念和功能 劃分 ，以及網(wǎng)絡(luò)管理中的技術(shù) 分析 。 在下一章中，將會對系統(tǒng)的基礎(chǔ)框架 OSGi原理做詳細 的分析 浙江大學(xué)碩士學(xué)位論文 第 3 章 OSGi 體系架構(gòu)分析 13 第 3章 OSGi 體系架構(gòu)分析 網(wǎng)絡(luò)管理的需求是伴隨著網(wǎng)絡(luò)應(yīng)用的不斷發(fā)展， 網(wǎng)絡(luò)設(shè)備應(yīng)用的快速增長的。 OSGi 的起源在最初也 是希望能夠為家庭嵌入式設(shè)備提供網(wǎng)關(guān)服務(wù)，直至現(xiàn)如今成為了一個熱門的 動態(tài)模型框架。 OSGi 簡介 OSGi是開放 服務(wù)網(wǎng)關(guān)協(xié)議（ Open Services Gateway initiative)的簡稱， OGSi是一個網(wǎng)絡(luò)服務(wù)定義的標(biāo)準(zhǔn)，一個面向服務(wù)的計算環(huán)境，為用戶提供了開放的、面向服務(wù)組件的、易于部署的編程模型，允許用戶將定義好的服務(wù)在運行期間綁定到特定的 Service 服務(wù)接口 。 OSGi 是由 OSGi 聯(lián)盟提出的一個開放的服務(wù)規(guī)范 ， OSGi 聯(lián)盟是由 Sun、MicroSystems、 IBM、愛立信等公司于 1999 共同成立的一個開放的標(biāo)準(zhǔn)化組織，它是一個非盈利性質(zhì)的國際組織，旨在建立一個開放的服務(wù)規(guī)范。該組織成立的目 的原本是為了使服務(wù)提供商通過住宅網(wǎng)關(guān)，向各種家庭智能設(shè)備提供各種服務(wù)，可以看到， OSGi標(biāo)準(zhǔn)最初的目的只是服務(wù)于嵌入式設(shè)備，專注于網(wǎng)管服務(wù)，希望能為通過網(wǎng)絡(luò)訪問的設(shè)備提供一個通用的接口服務(wù)平臺，解決因為系統(tǒng)的不同和環(huán)境的差異而引起的設(shè)備之間不一致性的問題，使軟件能夠動態(tài)的部署和運行。后來，由于 OSGi 的諸多優(yōu)秀特性，比如動態(tài)改變系統(tǒng)行為，熱插拔的插件體系結(jié)構(gòu)，高效性，高復(fù)用性等，被應(yīng)用于許多 PC 上的應(yīng)用，并逐步被開發(fā)者所鐘愛。現(xiàn)在 OSGi 已經(jīng)從單一的應(yīng)用于移動設(shè)備發(fā)展到應(yīng)用于各種開源項目，以及商業(yè)軟件，包括 著名開源項目 Eclipse，到寶馬汽車的智能系統(tǒng)，人們對 OSGi的理解已經(jīng)遠不是它字面和初衷所能夠解釋的了 [7]。 OSGi 最早的版本是由 OSGi 聯(lián)盟于 20xx 年發(fā)布了 OSGi Service Platform ，但真正對大家熟知，與 eclipse 有密切的關(guān)系，多年以來， Eclipse 一直都是Java 開發(fā)者的首選 IDE，只要是一個 Java 開發(fā)者，基本都會知道 Eclipse，而在 版本之前，都是使用自己開發(fā)的一套插件機制，該插件機制設(shè)計非常精巧，受到很多開發(fā)者的推崇，但是，知道 發(fā)布時， Eclipse 基金會作出了一個大膽的嘗試，將 Eclipse 的插件體系機制逐步遷移到 OSGi 框架中，并且，Eclipse 還自己實現(xiàn)了一個 OSGi 的開源框架， Equinox，每個 Eclipse 版本的發(fā)布浙江大學(xué)碩士學(xué)位論文 第 3 章 OSGi 體系架構(gòu)分析 14 都會伴隨 Equinox 的更新。 Eclipse 采用 OSGi 框架使得 OSGi 成功的進入了 Java企業(yè)應(yīng)用領(lǐng)域，并成為其中重要的一員 [16]。 OSGi 框架 及運行機制 OSGi 框架 根據(jù)功能劃分， OSGi框架可以分為以下幾個層次 [13]： 安全層 Security Layer； 模塊層 Module Layer； 生命周期層 Life Cycle Layer； 服務(wù)實現(xiàn)層 Actual Service； 圖 OSGi 模塊結(jié)構(gòu)圖 安全層是 OSGi服務(wù)架構(gòu)中的一個可選的層，它是基于 Java2 的安全體系結(jié)構(gòu)，并且安全層提供了在精密控制的環(huán)境下應(yīng)用程序的部署和管理的基礎(chǔ)架構(gòu)。安全層是貫穿于 OSGi平臺的所有層的，可以說整個框架都在安全層的控制管理之中，實現(xiàn)對 OSGi中 bundle 應(yīng)用的詳細管理控制。 模塊層定義了 bundle 應(yīng)用的加 載策略， Java 平臺只提供了對打包、部署和對Java 應(yīng)用和組件校驗的最小支持，通常，大多數(shù) Java 應(yīng)用中，一個應(yīng)用對應(yīng)一個單獨的 classpath，其中包含了所有的 Java 類文件和資源文件，因此，在很多基于Java 的項目中，都會借助于專用的類加載器，用來創(chuàng)建用戶模塊層，實現(xiàn)項目的浙江大學(xué)碩士學(xué)位論文 第 3 章 OSGi 體系架構(gòu)分析 15 打包、部署和對 Java 應(yīng)用和組件的校驗。 OSGi框架為 Java 的模塊化提供了一個標(biāo)準(zhǔn)的解決方案，框架為每個實現(xiàn)了 BundleActivator 接口的 bundle 應(yīng)用提供一個單獨的類加載器，使得 bundle 應(yīng)用的組織更加模塊化。 在 OSGi框架中，模塊化的單元是 bundle，一個 bundle 由 Java 的類和其他文件組成，提供終端功能，在服務(wù)框架中， bundle 是僅有的需要部署的 Java 應(yīng)用實體， bundle 以 Jar 文件的方式進行部署 ，每個 Bundle 中 包含一個 manifest 文件，用來描述 Jar 文件的內(nèi)容和 bundle 的信息，將 bundle 的信息提供給框架，以用來安裝和激活 bundle。 OSGi支持的 jar 文件和普通的 Java 應(yīng)用程序 Jar 文件類似，卻別主要在于 manifest 文件的內(nèi)容 [15]。 生命周期層提供了對 bundle 的生命周 期管理和安全控制，在模塊層定義了bundle 作為 jar 文件的組織形式，但是，對 bundle 的控制是放在生命周期層來完成的，生命周期成可以動態(tài)的對 bundle 進行安裝、啟動、停止、卸載和升級等，用戶可以通過生命周期層提供的一組 API 來對 bundle 的運行進行操作控制。 服務(wù)層定義了一個動態(tài)的協(xié)作模型，與生命周期緊密結(jié)合，服務(wù)的模型包括服務(wù)發(fā)布、查找和綁定模型。一個服務(wù)是一個 Java 對象，這個對象實現(xiàn)了一個或多個特定的服務(wù)接口，在實現(xiàn)服務(wù)接口的同時，也通過服務(wù)注冊，將服務(wù)與接口進行綁定，通過調(diào)用接口，就可以調(diào)用 到相應(yīng)注冊的服務(wù)。一個 bundle 應(yīng)用可以是服務(wù)的注冊發(fā)布者，同時也可以動態(tài)的綁定服務(wù)，接收服務(wù)注冊動態(tài)改變的信息等 [1]。 OSGi 類加載機制 類加載器 （ ClassLoader） 是 Java 虛擬機 JVM 提出的概念， JVM 本身包含了3 個 類加載器， Bootstrap ClassLoader， Exension ClassLoader， System ClassLoader，這 3 個 類加載器 都 是由系統(tǒng)本地代碼實現(xiàn)的 [10]，加載器的結(jié)構(gòu)如下圖 所示 ，Bootstrap ClassLoader 主要負(fù)責(zé) Java 核心 Jar 文件 的加載，比如 JRE 目錄下 文件 ，其他兩個類加載器也由其來加載， Exension ClassLoader 是擴展類加載器，負(fù)責(zé)加載存放 JRE 的 ext 目錄下的 class 文件 ， System ClassLoader 負(fù)責(zé)加載在Classpath 下的 class 文件， 也就是程序所在的位置的類文件，在 System ClassLoader的基礎(chǔ)上，開發(fā)人員可以繼承這個類加載器來實現(xiàn)自定義的類加載器 [11]。 浙江大學(xué)碩士學(xué)位論文 第 3 章 OSGi 體系架構(gòu)分析 16 圖 類加載器結(jié)構(gòu) 在 OSGi規(guī)范中，定義 每個 Bundle 中包含了一個獨立的類加載器， 并且這個類加載器只用于本 Bundle 范圍內(nèi)，與其他 Bundle 隔離 。在 OSGi 框架啟動后，首先會解析安裝的 Bundle， Bundle 只有在解析后，才能關(guān)聯(lián)到相應(yīng)的類加載器，一般會在 Bundle 解析成功后，由框架創(chuàng)建一個與 Bundle 綁定的類加載器，在一些不需要啟動就加載的 Bundle 中，框架一般會采取延時創(chuàng)建加載器的方式，等到Bundle 實際被使用時才被創(chuàng)建 [2]。 Bundle 生命周期 OSGi框架提供 一些 API 來管理 Bundle 的生命周期 ，一般 Bundle 的安裝需要由 另一個 Bundle 來執(zhí)行，或者由 OSGi框架來執(zhí)行，作為框架啟動的一個命令行參數(shù) 。 OSGi提供了 作為安裝 Bundle 使用。 Bundle 的啟動一般由 Bundle 激活器 來激活， Bundle 激活 器由 manifest 文 件中BundleActivator 參數(shù)來確定，該接口有一個 start 和 stop 方法，開發(fā)人員可以在這兩個方法中添加在啟動或者停止時需要注冊的監(jiān)聽器，啟動、停止的線程等操作 [9]。 浙江大學(xué)碩士學(xué)位論文 第 3 章 OSGi 體系架構(gòu)分析 17 Bundle 的狀態(tài)有一下幾種： INSTALLED、 RESOLVED、 STARTING、 ACTIVE、STOPPING、 UNINSTALLED。 i n s t a l l s t a r t i n gr e s o l v e d a c t i v es t o p p i n gu n i n s t a l l e d 圖 Bundle 狀態(tài)轉(zhuǎn)換圖 在調(diào)用 安裝 Bundle 后，框架會根據(jù) manifest 文件對 Bundle 進行解析，成功解析依賴關(guān)系后， Bundle 進入 RESOLVED 狀態(tài)，這時， Bundle 處于就緒，可以啟動使用了。 啟動 Bundle 會調(diào)用 BundleActivator 的start 方法，成功調(diào)用這個方法以后， Bundle 就進入了 ACTIVE 狀態(tài)，處于使用的Bundle 一直會保持這個狀態(tài)，直到接收到停止信號， Bundle 進入 STOP 狀態(tài)，會首先調(diào)用 stop 函數(shù)，停止由 Bundle 啟動的線程 ，注冊的服務(wù) [22]。 Bundle 交互 Bundle 之間的交互一般有兩種，通過 export 和 i