使用 JAVA 技術實現新一代 OSS/BSS

SUN中國工程研究院 軟件技術中心王剛

摘要：本文著眼于OSS/BSS發展的現狀，對于OSS/J的技術架構、API規范以及如何進行基于OSS/J的系統開發做了簡要介紹。

OSS/BSS 概述

OSS（Operations Support Systems）是指“運營支持系統”，BSS（Business Support Systems）為“業務支持系統”，OSS/BSS是這兩類系統的結合在一起形成的綜合的電信業務運營和管理平臺，在國內OSS/BSS有時也被稱為BOSS。

標準化組織電信管理論壇（TMF）對OSS/BSS提出了被業界廣泛接受的功能模型。在這個模型中，OSS/BSS包括三大功能：業務開通、業務保障和計費（或稱業務計量）。業務開通是指電信運營商接受客戶訂購電信服務的訂單，通過對電信資源的分配、配置、安裝和部署為客戶提供所需的服務，并能夠對服務進行計費。 作為一種高效的信息管理系統，OSS/BSS已在國外電信運營商中得到廣泛的運用，并在實踐中積累了大量的成功案例。OSS/BSS解決方案也在這一過程中趨于完善，同時也暴露出越來越多的難以克服的問題：

圖1、OSS/BSS的“集成的噩夢”

l??????? OSS/BSS的軟件系統相對復雜，從而使得網管系統、計費系統、營賬系統、客服系統等都是各成體系，要想把它們有機地整合在一起，幾乎是不可能的，對于這種“雜亂無章”的系統結構（參見圖1），簡直可以稱之為系統集成的噩夢（Integration Nightmare）。

l??????? 很多OSS/BSS開發商都有同感——缺少訓練有素的工程師，這也是由前一條所決定的，需要工程師同時精通電信的專業知識，又能熟悉各類軟件，的確要求比較苛刻。

l??????? 行業標準問題。盡管在近幾年來國際國內都陸續推出了一些標準規范，但大多是停留在紙面上，同時也缺少更直觀的技術指導和成功案例。

l??????? 一個OSS/BSS，往往會涉及若干個分離的系統，除了集成，對系統進行測試、維護都是十分耗時的。

以上各方面的問題，OSS/J就可以解決，原因在于：

l??????? 采用符合OSS/J規范而開發的軟件接口相對簡單，OSS/BSS內部的各個子系統是可以互換的（ Interchangable ）。

l??????? OSS/J是基于J2EE技術的，開發人員只要熟悉J2EE的開發（甚至僅僅熟悉JAVA的開發）就足夠了，他們就能夠與設計人員合作，完成系統開發。

l??????? OSS/J不僅包括了技術規范，而且有真實的代碼實現以及測試工具。這能夠幫助開發人員很快的上手。

l??????? 因為各個子系統都符合標準的接口，所以系統的后期測試和維護工作會比較簡單。

什么是 OSS/J

OSS/J（OSS Through Java）是以JAVA技術為動力的新一代的OSS/BSS解決方案。

說到OSS/J，我們需要提及一個稱為OSS Through Java Initiative的工作組，這個工作組由眾多的業界新技術的倡導者（例如Motorola，Nokia，Sun, BEA, IBM）派出的專家組成。自2000年成立以來，他們一直在為加速OSS/BSS解決方案的開發、簡化其中的系統組件的部署和集成而努力。工作組利用JAVA技術，為OSS/BSS定義實現了一系列的開放的標準API，提供給OSS/BSS的開發者使用。在不久的將來，電信行業的設備制造商、軟件開發商、系統集成商都遵循這些標準API的定義，那么最后建立起來的OSS/BSS將是一個組件化的、有機結合在一起的綜合管理平臺（參見圖2），“雜亂無章”的系統結構將成為過去。

圖2、采用OSS/J構建的系統結構

需要指出的是，OSS/J并不是要定義另一個通用的OSS/BSS集成框架。工作組的成員在定義標準的API之前，已經汲取了眾多標準規范和協議中的精華，例如，OSS/J很好的繼承了來自3rd Generation Partnership Project (3GPP), 3GPP2, Mobile Wireless Internet Forum(MWIF)以及TeleManagement Forum(TMF)等組織或論壇推出的規范和框架體系。因此，工作組將所有的經歷投入到了JAVA API的定義和編碼實現上，而且使用OSS/J規范的的用戶可以免費地獲得這些資料。

TMF在NGOSS 3.0（Next Generation Operations Support Systems下一代運營支持系統）的文檔中，推出了詳細的OSS/BSS的定義。（參見http:// www.tmforum.org ）。OSS/J的API定義遵守了NGOSS eTOM （enhanced Telecom Operations Map）的規定，詳細內容請見“OSS/J API簡介”部分。概括地說，NGOSS為我們提供了獨立于技術實現的普遍適用的框架，而OSS/J則是以該框架為基礎，提出了采用JAVA技術的實現方案。

OSS/J的規范的推出是在JCP（ Java Community Process, http://jcp.org）支持下完成的。通過訪問JCP的網站，或者光臨http://java.sun.com/products/oss，你都可以下載到OSS/J的規范、參考實現和兼容性測試工具，下面逐一簡介：

OSS/J的規范：包括OSS/J API規范和OSS/J J2EE系統設計指導。這些內容將在“OSS/J API簡介”中詳細敘述。

OSS/J 參考實現（ Reference Implementation或 RI）：主要內容是根據OSS/J API規范而完成的系統實現的代碼。推出RI一方面是為了驗證規范的可執行性，所以RI的代碼未曾經過很好的優化。RI的另一個重要的作用是它能夠使得開發者很快的著手進行設計和開發工作，而且，RI中的所有代碼可以被開發人員直接使用到商業系統的開發中去。所以，仔細閱讀分析RI的代碼能大大縮短你用于熟悉OSS/J的時間。

兼容性測試工具（ Test Compatibility Kits或 TCK ）：當一個OSS/BSS（或其中的一個子系統）的開發完成了以后，我們如何才能知道它是否符合OSS/J 規范的規定呢？TCK可以完成這樣的測試，并產生一個測試報告。如果開發的產品符合OSS/J規范的要求，那么它將很容易和其它同樣兼容OSS/J規范的產品集成在一起。

OSS/J的規范推出以后，得到了業界的廣泛認可，許多電信運營商、服務提供商、系統集成商爭相追隨。來自IDC的2002年的報告說，“……隨著SA、TT、Qos API的發布，許多服務提供商和供應商認為,采用JAVA技術實現OSS已經到了實際可行的階段。”

OSS/J 與 J2EE

上文提到，OSS/J可以幫助我們終結“系統集成的噩夢”，因為它為我們定義了一系列的標準API，只要各個廠商都能遵守API中的規定，那么OSS/BSS的集成難的問題將迎刃而解。那么具體的底層實現機制是怎樣的呢？——OSS/J采用了J2EE作為技術平臺。

J2EE（Java 2 Enterprise Edition）即Java 2企業版，是提供給開發者的采用組件技術構建分布式系統的編程框架，需要更深入了解J2EE，請瀏覽http://java.sun.com/j2ee/。總體來說，J2EE使得開發人員無須去考慮分布式系統中的底層技術實現細節，例如線程管理，網絡通信等，而是集中精力開發符合業務邏輯的代碼，這無疑大大加快了應用程序的開發進程，而且簡化了系統的部署和后期維護工作。目前全球的J2EE開發人員總數已經達到了幾百萬，這個群體還在迅速膨脹。

圖3、采用J2EE實現OSS/BSS

作為服務器端的開發技術，企業JavaBean（EJB）、擴展標記語言（XML）以及JAVA Management Extensions（JMX）都在OSS/J中被采納。因為J2EE、XML、JMX已經在很多的大型企業應用（特別是服務器端的應用程序）中獲得了成功，所以OSS/J采用它們定義在組裝、開發和部署OSS/BSS解決方案時所需要的API。

圖3是采用J2EE實現OSS/BSS的示意。以OSS/J API為基礎，我們開發了支持SA、TT等功能的EJB，這些EJB可以根據需要通過JDBC存取數據庫，或通過JNDI訪問目錄服務器。對于已有的遺留系統以及EMS（Element Management Systems），可以采用J2EE連接器的架構（Java Connector Architecture即JCA）通過SNMP、CMIP或其他專有協議實現集成。OSS的客戶端可以是瀏覽器或定制的應用程序，通過HTTP/XML/Java/IIOP和系統相聯。與此同時，JAVA的消息機制為我們提供了更加靈活的“松耦合（loosely-coupled）”的集成方式，利用它可以簡單地實現和Intranet/Internet中的其他系統的連接。

OSS/J API 簡介

圖4將OSS/J中的核心API和TMF的eTOM的各個過程做了映射。從圖中可以看出，OSS/J核心API囊括了客戶管理、訂單管理、服務開通等20個，關于每個API的詳細描述，可參見http://java.sun.com/products/oss/apis.html上的OSS/J API Roadmap。目前，已經完成的API有：OSS服務開通API，OSS故障單API，OSS通用API，OSS IP計費API和OSS服務質量控制API，而OSS 庫存 API不久將發行。除了API，OSS/J工作組還為開發者提供了《OSS/J J2EE 系統設計指導》。

圖4、OSS/J API到eTOM的映射

OSS通用 API（ OSS Common API）：和其他OSS/J API不同的是，它本身沒有對OSS/BSS在業務邏輯提供支持，而是為開發者使用OSS/J API提供了一個基礎框架。可以認為這部分API是《OSS/J J2EE 系統設計指導》一個具體實施。需要強調的是，既然是基礎框架，以下提及的所有OSS/J API都是依賴于通用API的。

OSS/J J2EE系統設計指導（ OSS/J J2EE Design Guideline或 OSS/J J2EE DG）：定義了一系列的設計模式（Design Patterns），這些模式非常適合于采用J2EE/EJB搭建網絡服務管理系統。總體來看，DG中提及的設計模式都是來自于J2EE設計模式，關于J2EE設計模式的詳細信息，請參見http://java.sun.com/blueprints/corej2eepatterns。DG中主要涉及到以下要點：

l??????? OSS中的功能都是采用EJB組件的形式實現的

l??????? 這些EJB提供了面向業務邏輯的粗略的接口

l??????? 應用服務器為OSS/BSS系統提供了集群、擴展和故障處理等功能

l??????? 采用消息（Messaging）交換機制來減小組件之間的耦合程度

l??????? 結合消息機制和JCA架構實現系統的集成和工作流的管理

貫穿DG的一個重要概念就是“軟件構件（Software Building Block）”的概念。一塊軟件積木是若干軟件組件（Component）的集合體，這些軟件組件相互協作，從而滿足系統業務邏輯的需求。需要強調的是，OSS/J API的所有定義和實現方式都是遵從OSS/J J2EE DG的。

OSS服務開通 API（ OSS Service Activation API或 SA API）：主要提供了對訂單的管理功能（例如生成、修改、刪除、查詢訂單等）和服務的管理功能。API中并沒有給出指定的“服務信息模型（Service Information Model）”，而是將這部分工作留給開發者去實現，這樣開發者可以根據自己的業務邏輯的需要定義服務信息模型。SA API中關于訂單管理的定義是根據TMF 603中的“世界訂單信息協定”（World Ordering Information Agreement）以及OMG WMF/WfMC的“訂單狀態模型（Order State Model）”的定義完成的。

OSS故障單 API（ OSS Trouble Ticket API或 TT API）：定義了生成、更新、查詢、關閉故障單的一系列操作。網管系統可以通過調用TT API自動生成故障單，服務提供商也可以利用它產生和處理故障單，客戶關懷系統能夠調用這些API將故障單發送給服務提供商（見圖5）；如果故障單的管理是在一個工作流程中完成的話，那么開發人員可以使用這些API與工作流引擎進行信息傳遞。

OSS IP計費 API（ OSS IP Billing API）：定義了IP計費的數據源和計費系統之間的接口。這部分API適用于針對2.5G和3G網絡的OSS/BSS開發。而且API的定義重點放在（但不不局限于）無線通信的領域。該規范的定義是為了實現計費系統、計費數據采集系統、計費數據源這些不同的子系統之間夠實現無縫連接，流暢地完成各種記錄類型（例如CDR、SDR、IPDR等）的交換和傳輸。

OSS服務質量 API（ OSS Quality of Service API或 OSS QOS API）： QOS API使得QOS系統能夠從其他系統得到影響服務質量的數據，例如網絡性能、極限值以及故障數據等等。QOS API主要涉及到性能和使用情況的數據監測、系統極限值的監測及故障數據的監測三個方面的內容。

OSS 庫存 API （ OSS Inventory API ）： OSS/BSS在進行操作的時候，大多需要關于網絡可以提供的產品、服務和資源的規劃、使用的情況，這些功能要由庫存API來提供。這部分API包括了對產品和服務的目錄管理，并且有跟蹤用戶預定和使用產品或服務的功能；同時API中對網絡資源管理（例如網絡上的設備和網絡拓撲結構的管理）的功能對于OSS/BSS來說也是不可或缺的。

下圖展示了各個OSS/J API之間的關系，其中橢圓形的邊界可以看做是API的定義，矩形的內容是由開發商來實現的，而箭頭代表方法或功能的調用，這些功能調用，尤其是各個子系統之間（例如從Qos調用故障單中的功能）應該使用OSS/J的API來完成。

圖5、OSS/J API的關系

OSS/J 開發指導

了解了OSS/J API的概況以后，可能你已經決定著手進行基于OSS/J的系統開發了。無論你是系統設計人員還是程序員，應該具備J2EE的開發經驗，而且最好了解電信行業知識（特別是關于OSS/BSS方面的知識）。而且，建議你按照以下的步驟來開展工作。

研讀 OSS/J相關的資料

瀏覽OSS/J的網站http://java.sun.com/products/oss，你可以下載到OSS/J的規范和相關技術文章（如圖6所示）。前面提到，試著部署一下RI并研究其代碼能幫助你迅速了解OSS/J。如果你在學習和使用的時候有什么疑問和意見，都可以發表在相應的新聞組里（新聞組的地址參見OSS/J的網站）。

圖6、下載OSS/J規范、RI進行開發

開始 OSS/BSS 的設計與實現

這個過程和標準的軟件開發沒有大的區別，主要經歷從制定計劃、需求分析、系統設計、詳細設計、編碼實現和測試等幾個環節。由于進行OSS/J的開發是基于J2EE技術的，所以選擇穩定高效的應用服務器（Application Server）和集成開發環境（IDE）十分重要，好在由于J2EE的開放性，我們有很多選擇，例如Sun ONE應用服務器、BEA Weblogic、Borland Jbuilder等。在系統設計和詳細設計時，設計人員需要首先熟悉OSS/J J2EE設計指導中內容，按照其中講述的設計模式進行設計。至于編碼實現，和一般的J2EE開發沒什么區別，主要涉及到EJB的編程，同時需要程序員對XML比較熟悉。進入到測試階段，除了完成普通軟件開發需要完成的一系列測試以外，OSS/J規范的兼容性的測試也是必須的，如上文所述，TCK可以幫你完成這一個步驟（參見圖7）。

圖7、使用TCK進行測試

發布自己的產品信息

當你開發的產品成功地通過了TCK的測試以后，就可以獲得OSS/J的認證。OSS/J針對OSS/BSS產品規定了一個靈活的“自我認證流程”，參見圖8。上文中提到，使用TCK測試你的產品，將產生一個測試報告。如果測試成功，可以將報告發布到你的公共網站上，同時通知OSS/J工作組的程序管理小組。經過核實以后，OSS/J程序管理小組將會更新OSS/J的網站，將你發布的產品測試報告的鏈接（URL）加到通過認證的產品列表中去。到現在，整個“自我認證過程”就完成了。獲得了OSS/J的認證，意味著你開發的產品可以很容易地和其它廠商的也獲得認證的產品集成起來，可以作為有機的一部分加入到基于OSS/J API的OSS/BSS中去。參見http://java.sun.com/products/oss/adoption/ossj_certified_products_table.html，在這里，你可以看到IBM、Ilog、Nokia等許多廠商的產品都已經獲得了OSS/J的認證。

圖8、OSS/J的“自我認證”

加入 OSS/J工作組

如果你希望能最及時地了解OSS/J的發展動向，獲得最新的信息，甚至希望參與規范的制訂和修改，那么最有效的方式就是加入到OSS/J的工作組中來。OSS/J工作組中的成員有著不同的級別，分別有不同的權利。請查看http://java.sun.com/products/oss/members.html了解加入OSS/J工作組的細節內容。

總結

OSS/J為我們提供了一個采用Java技術實現OSS/BSS的技術框架，它借鑒了眾多的既定行業規范，以J2EE/XML技術為基礎，為OSS/BSS的開發者提供了一個標準的環境，以解決目前OSS/BSS中存在的集成問題。相信隨著相關技術的進步，OSS/J會擁有越來越多的支持者，從而發展成為用JAVA實施OSS/BSS的技術標準。

參考資料

l??????? Operations Support Systems, http://www.iec.org

l??????? OSS through Java Initiative, By Philippe Lalande

l??????? OSS through Java Initiative, Simplifying Integration with Common APIs, http://java.sun.com/products/oss

l??????? OSS/J API Roadmap

l??????? Case Study: From NGOSS Map to OSS/J Roadwork, http://www.tmforum.org/browse.asp?catID=1483&sNode=1483&Exp=Y&linkID=28103, By Peter Lambert

l??????? OSS through Java Design Guidelines, http://java.sun.com/products/oss/apis.html

l??????? OSS Trouble Ticket API

l??????? OSS Service Activation API

l??????? OSS Common API

l??????? OSS IP Billing API

l??????? OSS Quality of Service API

l??????? OSS Inventory API