【文章內(nèi)容簡介】 MP簡單和易于實現(xiàn)的原理，CMIS/CMIP提供了一整套完成的網(wǎng)絡(luò)管理解決方案功能，包括了訪問控制，認證，安全日志等。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，Ethernet，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ù)器。 分布式通信技術(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)流程大致如下： CORBA通信結(jié)構(gòu)編寫IDL接口定義文件；通過指定的編譯器，將IDL文件編譯為相應(yīng)的語言源代碼文件，在編譯的同時，生成服務(wù)器框架和客戶端存根；在服務(wù)器端，編寫服務(wù)對象實現(xiàn)程序；在客戶端存根，編寫客戶對象程序，通過客戶對象程序調(diào)用服務(wù)端對象；分別編譯服務(wù)對象和客戶對象程序；運行服務(wù)端和客戶端程序。 本章小結(jié)本章介紹了電信管理網(wǎng)TMN的概念以及管理網(wǎng)層次的劃分，描述了管理網(wǎng)網(wǎng)絡(luò)管理的概念和功能劃分，以及網(wǎng)絡(luò)管理中的技術(shù)分析。在下一章中，將會對系統(tǒng)的基礎(chǔ)框架OSGi原理做詳細的分析12浙江大學(xué)碩士學(xué)位論文 第3章OSGi體系架構(gòu)分析第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)盟于2000年發(fā)布了OSGi Service Platform ，但真正對大家熟知，與eclipse有密切的關(guān)系，多年以來，Eclipse一直都是Java開發(fā)者的首選IDE，只要是一個Java開發(fā)者，基本都會知道Eclipse，都是使用自己開發(fā)的一套插件機制，該插件機制設(shè)計非常精巧，受到很多開發(fā)者的推崇，但是，Eclipse基金會作出了一個大膽的嘗試，將Eclipse的插件體系機制逐步遷移到OSGi框架中，并且，Eclipse還自己實現(xiàn)了一個OSGi的開源框架，Equinox，每個Eclipse版本的發(fā)布都會伴隨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)項目的打包、部署和對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主要負責(zé)Java核心Jar文件的加載，其他兩個類加載器也由其來加載，Exension ClassLoader是擴展類加載器，負責(zé)加載存放JRE的ext目錄下的class文件，System ClassLoader負責(zé)加載在Classpath下的class文件，也就是程序所在的位置的類文件，在System ClassLoader的基礎(chǔ)上，開發(fā)人員可以繼承這個類加載器來實現(xiàn)自定義的類加載器[11]。 類加載器結(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ù)。Bundle的啟動一般由Bundle激活器來激活，Bundle激活器由manifest文件中BundleActivator參數(shù)來確定，該接口有一個start和stop方法，開發(fā)人員可以在這兩個方法中添加在啟動或者停止時需要注冊的監(jiān)聽器，啟動、停止的線程等操作[9]。Bundle的狀態(tài)有一下幾種：INSTALLED、RESOLVED、STARTING、ACTIVE、STOPPING、UNINSTALLED。 Bundle狀態(tài)轉(zhuǎn)換圖，框架會根據(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和import方式導(dǎo)出和導(dǎo)入包，另一種是通過Service的方式進行交互。導(dǎo)出、導(dǎo)入Java包就是在manifest文件中直接聲明可以導(dǎo)出給其他Bundle使用的package包，或者是導(dǎo)入需要從其他Bundle獲取方法功能的package包或class類，框架會確定該Java包是通過哪個Bundle導(dǎo)出的。這個方式是OSGi中比較簡單的一種Bundle交互方式，但是，這樣的方式會造成會導(dǎo)出導(dǎo)入包的過多依賴，影響B(tài)undle的動態(tài)更新，每次更新Bundle都需要保留原來的Bundle依賴關(guān)系知道框架更新。使用Service服務(wù)的方式，將依賴關(guān)系集中在服務(wù)接口，講具體實現(xiàn)功能對外隱藏，這樣，改變接口不會直接影響具體的實現(xiàn)[5]。 Bundle交互方式()方法將服務(wù)注冊到服務(wù)注冊中心，使用的時候，這種方式的服務(wù)注冊方法，需要在每次都在代碼中聲明注冊，耦合度較高。另一種目前比較流行的Service注冊方式，Declarative Services（DS），Declarative Services是一個面向服務(wù)的組件模型，通過xml文件定義和引用，而不需要依賴于OSGi平臺。Declarative Services為了方便平臺發(fā)布、查找、綁定服務(wù)而制定的，能夠更方便的對服務(wù)進行動態(tài)管理，將服務(wù)的定義信息從manifest文件中獨立出來，只保留一個服務(wù)文件地址，使用xml能夠更清晰地表達服務(wù)的描述，同時采用組件的延遲加載方式，有效的解決平臺開發(fā)、部署時的反應(yīng)速度[14]。Declarative Services的配置文件在manifest文件中的ServiceComponent屬性中被制定，解析配置文件后，首先，需要判斷Service組件是否可用，這里涉及到一個組件滿足（Component Satisfied）的條件，組件被激活需要滿足兩個條件：首先，Bundle必須處于ACTIVE狀態(tài)，其次，在被解析的組件中，至少有一個不被引用的Service處于可用狀態(tài)，或者組件未配置對其他Service的引用，只有滿足以上兩個條件，組件才能被激活（Enable），處于可以使用狀態(tài)。Declarative Services對Service的定義很簡單，只需定義Service實現(xiàn)的接口和引用的服務(wù)即可，當(dāng)滿足組件激活條件后，框架會將Service注冊到服務(wù)注冊中心，通過調(diào)用接口，就可以查找到具體的實現(xiàn)組件。 OSGi的應(yīng)用OSGi作為基于Java的動態(tài)服務(wù)框架，由于優(yōu)越的性能，在業(yè)界已經(jīng)有了一些典型的產(chǎn)品應(yīng)用。比較經(jīng)典的有兩個，一個就是前文提到的Eclipse的插件體系應(yīng)用，Eclipse組織在eclips版本3以后的插件都采用了OSGi模型，