OSS/J API研究報告

 

OSS/J API研究報告*

 

 

1.      參考文獻

[1] Inventory-API-SPEC_PART1_OVERVIEW.1.0.pdf

 

2.      約定

2.1.名字翻譯

Inventory 目前的翻譯有很多，有翻譯成資產、存量、資源的，這裏統一約定爲庫存

Resource 目前的翻譯也很多，有翻譯成資源、網絡資源等，這裏統一約定爲資源

Service   目前的翻譯也很多，有翻譯成業務、服務的，這裏統一約定爲服務

Business  統一約定爲商業

Specification 統一約定爲規範。

JVT  Java Value Type Session Beans 是一種設計模式，通過值對象作爲參數來訪問後端實體，應用門面模式，通過單一接口訪問系統定義的實體。

3.      引言

OSS/J（OSS Through Java）是以JAVA技術爲動力的新一代的OSS/BSS解決方案。是由OSS Through Java Initiative的工作組提出，這個工作組由衆多的業界新技術的倡導者（例如Motorola，Nokia，Sun, BEA, IBM）派出的專家於2000年組成，工作組利用JAVA技術，爲OSS/BSS定義實現了一系列的開放的標準API，提供給OSS/BSS的開發者使用。同時，OSS/J並不是要定義另一個通用的OSS/BSS集成框架。OSS/J的API定義遵守了NGOSS eTOM （enhanced Telecom Operations Map）的規定，並以該框架爲基礎，提出了採用JAVA技術的實現方案。

4.      OSS/J Inventory API介紹

4.1.概述

庫存信息通常包括產品、服務和資源的一些基本信息，但運營商通常都建有獨立的OSS/BSS系統，BSS系統一般用於處理基於自身提供的庫存之上計劃、計費等，而OSS系統則處理訂單管理、服務影響分析等。因此，這些信息不能位於某些指定的系統組件內部，必須將其作爲企業基本數據在企業內部進行共享，當然部分信息也應可以以可控的方式進行跨企業共享。各種各樣的庫存信息可根據功能歸結如下三類:產品、服務和資源。每個功能有它自身特有的實體、關聯、特定的商業邏輯等，然而，所有的庫存功能共享共同的抽象如實體，關聯和實體規範和共同的交互模型（如一些查詢機制）。

庫存功能通常提供物理資源的存儲和配置、網絡拓撲、邏輯資源、服務、客戶賬號和產品等，同時也可以向其它OSS組件提供查詢、監控、分配和更新的接口操作。三種庫存功能的實體、規範及關聯調用關係圖如下：

4.1.1. 產品庫存

產品庫存主要用來管理產品目錄和跟蹤產品訂單。產品目錄定義了一系列產品規範和從市場角度定義的產品offering. 每和產品規範描述一種產品類型。多個產品規範也可描述同一類型。例如產品目錄中定義了金牌、銀牌和銅牌VPN產品，產品規範同服務規範相關聯的，可以存儲在服務目錄中，並在產品與服務之間建立一定的聯繫。

產品庫存與其它組件的交互圖如下：

上圖中客戶訂單管理功能在產品庫存中存儲客戶詳情、訂單和產品詳情、賬號信息。客戶訂單管理功能可以從產品目錄中查詢到產品實例的產品規範信息並將放入產品訂單中。故障單登記功能可以通過產品庫存將服務與Subscriber（號碼）進行關聯，並取得Subscriber（號碼）的詳情。SLA管理功能通過產品庫存獲取指定產品的subscriber（號碼）和subscriber合約信息。

產品庫存的核心信息模型定義了下列實例和規範：

產品

產品規範

Party

Subsciber Party Role

4.1.2. 服務庫存

服務庫存用來管理服務目錄和跟蹤已計劃、已訂購和已提供的服務。服務目錄由一系列服務規範組成和從工程視角看到的服務提供的offering。服務規範是按工程視角進行定義的服務特徵。同樣服務規範與服務類型也是多對一方式。服務規範可同存儲在資源目錄中的資源規範進行關聯，並建立一定的聯繫。

服務庫存同其他OSS組件的交互圖如下：

上圖中服務計劃功能用來根據服務規範詳情來定義一個新的服務類型，服務規範包含工程信息，注意有些信息並非由服務規範自身提供而由其相關的資源規範來提供。服務開通時，工程管理需要使用服務相關信息。服務激活功能用來更新服務實例的服務規範和它相關聯的用戶、提供資源和subscriber（客戶）信息等。客戶訂單管理功能從服務目錄中查詢到服務規範並將可被激活的一系列服務組成一個產品訂單。這裏的操作需要客戶手工操作。供應控制通過服務上當獲取服務和資源設計分配的信息。故障單登記功能獲取服務並將之與產生的故障單進行關聯。SLA管理功能從服務目錄中獲取服務詳情用來配置正在監控的已激活的服務。服務問題解決功能查詢服務規範確認何處出現問題。服務質量管理處理服務和資源信息及流程測量之間的關係，並判斷服務缺陷。服務影響分析功能根據服務庫存中存儲的信息將網絡告警和受影響的服務關聯起來。過程質量管理功能處理服務和過程信息測量之間的關係。

服務庫存定義的信息模型中的核心實體和規範如下：

服務

服務規範

4.1.3. 資源庫存

資源庫存存儲網絡和計算設備、邏輯資源和拓撲，用於資源分配並跟蹤網絡設計庫存（板卡、端口等）的物理和地理配置和不同網絡存的物理連接、邏輯連接。

資源發現組件呈現和同步各種資源庫存。

資源庫存同其它OSS組件的交互過程：

上圖中Provisioning Control 存儲關於可用性和邏輯資源信息，利用資源庫存中的信息來理解網絡中的設備並來設計網絡配置來支持服務。網絡激活功能獲取來自於網絡庫存中設備和連接信息。網絡影響分析使用資源庫存信息來與邏輯資源進行關聯。性能監控

資源庫存信息模型定義瞭如下核心實體和規範：

資源

資源規範

資源關聯

4.2.架構圖

OSS庫存API定義了JVT Session 門面和基於XML的消息門面，其調用關係如下圖：

4.3.核心概念

4.3.1. 元模型

元模型分三層，每一層代表不同的含義，提供不同的抽象含義。其中實例層由庫存數據組成。模型層由描述庫存信息的元數據組成，這些元數據或稱之爲庫存模型可以用規範Schema來描述。元模型層描述了一些模型的結構和語法的定義。其層次關係如下圖：

庫存API規範使用的是CBE 元模型層和部分的模型層。上圖中的出現的部分名詞概念來源於UML，同時又有所擴展。具體描述如下：

Entity 實體，來源於<<Entity>>，代表值對象，這裏專指庫存實體，如產品、服務和資源。實體作爲值對象的接口，包含很多的get/set方法。如下圖：

Entity Specification ：實體規範，來源於<<Specification>>，代表相同庫存實體類型的共同特徵和約束。舉例說來，“GoldBroadbandAccessServiceSpecification” 描述了寬帶接入服務金牌等級特徵。規範與實體是多對多關係。如下圖所示：

下面是兩個示例:

Associations：關聯 來源於<<Association>>，是在實體和實體規範

4.4.API概述

4.4.1. 主要功能

庫存API定義了庫存系統與其他OSS組件之間進行交互的標準接口。當然這些接口同樣也可適用於庫存信息的集成和庫存組件之間的聯邦。庫存組件基於JVT和XML/JMS技術允許客戶端應用進行查詢、分配、佔有、計劃、監控和更新資源庫顧慮、服務庫存和產品庫存提供下列操作功能：

創建、刪除、更新和查詢庫存實體、實體規範和關聯。

按名查詢調用和更新。

處理元數據查詢。

接收庫存事件通知。

導入和導出庫存數據

覈查庫存數據。

同時對庫存信息的發現、庫存實體狀態的計算和宣告和配置管理不在API範疇之內，然而庫存API提供了基於文件的導入與導出操作，可用於資源發現組件。要注意的是雖然配置信息存儲在庫存信息數據中，但庫存信息數據的變更不會直接去改變網絡現狀態。

4.4.2. 約定及關鍵實現技術

4.4.3. 包概述

庫存API使用“javax.oss.cbe”包，本包定義一系列代表上層OSS域通用信息模型。CBE包定義了一系列與TMF SID共享數據轉換對象，但未直接定義管理庫存的實體，它定義了一系列基本抽象類型，從這些抽象類型中被管理的庫存實體可以導出來的。

CBE核心包類結構圖如下：

4.5.API包簡介

4.5.1. CBE Resource Package

資源包定義了接口:

javax.osss.cbe.resource.ResourceValue

javax.oss.cbe.resource.ResourceSpecificationValue

javax.oss.cbe.resource.ResourceAssociationValue

javax.oss.cbe.resource.ResourceAggregatesResourceAssocValue

4.5.2. CBE Product Package

4.5.3. CBE Service Package

4.5.4. OSS Inventory Package

4.6.API使用示例

 

 

4.7.API實現

5.      附錄

5.1.Tigerstripe Workbench產品

Tigerstripe 公司開發的基於eclipse 的模型驅動產品，可用來簡化基於庫存API的應用開發。