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的应用开发。