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

　　

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