发布时间：2004-02-02 13:57:43
来源：赛迪网
作者：中国电信上海研发中心 马军涛;华中科技大学 宋海纲
上一部分《OSS/J,基于JAVA的OSS体系架构(一)》讲述了OSS/J的由来，以及OSS/J的原则和框架，这一部我们将继续讲解OSS/J的内容和应用等内容。
三 内容与应用
图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映射
1.OSS通用API（OSS Common API）： 和其他OSS/J API不同的是，它本身没有对OSS/BSS在业务逻辑提供支持，而是为开发者使用OSS/J API提供了一个基础框架，同时它也是《OSS/J J2EE 系统设计指导》一个具体实施约束框架。以下的所有OSS/J API均依赖于通用API。
2.OSS/J J2EE系统设计指导（OSS/J J2EE Design Guideline或OSS/J J2EE DG）： 定义了一系列的设计模式（Design Patterns），这些模式非常适合于采用J2EE/EJB搭建网络服务管理系统。
3.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）”的定义完成的。
4.OSS故障单API（OSS Trouble Ticket API或TT API）：定义了生成、更新、查询、关闭故障单的一系列操作。网管系统可以通过调用TT API自动生成故障单，服务提供商也可以利用它产生和处理故障单，客户关怀系统能够调用这些API将故障单发送给服务提供商；如果故障单的管理是在一个工作流程中完成的话，那么开发人员可以使用这些API与工作流引擎进行信息传递。
5.OSS IP计费API（OSS IP Billing API）： 定义了IP计费的数据源和计费系统之间的接口。这部分API适用于针对2.5G和3G网络的OSS/BSS开发。而且API的定义重点放在（但不局限于）无线通信的领域。该规范的定义是为了实现计费系统、计费数据采集系统、计费数据源这些不同的子系统之间能够实现无缝连接，完成各种记录类型（例如CDR、SDR、IPDR等）的交换和传输。
6.OSS服务质量API（OSS Quality of Service API或OSS QOS API）： QOS API使得QOS系统能够从其他系统得到影响服务质量的数据，例如网络性能、极限值以及故障数据等等。QOS API主要涉及到性能和使用情况的数据监测、系统极限值的监测及故障数据的监测三个方面的内容。
7.OSS 库存 API（OSS Inventory API）：OSS/BSS在进行操作的时候，大多需要关于网络可以提供的产品、服务和资源的规划、使用的情况，这些功能要由库存API来提供。这部分API包括了对产品和服务的目录管理，并且有跟踪用户预定和使用产品或服务的功能；同时API中对网络资源管理（例如网络上的设备和网络拓扑结构的管理）的功能对于OSS/BSS来说也是不可或缺的。
当前已经有厂商开发出基于OSS/J的解决方案，并推出了基于OSS/J的产品，如Nortel、Telcordia实现了TT API；Agilent、NEC及Cygent实现了客户关怀；Telcordia实现了SLA API；MetaSolv 、Telcordia实现了SA API；IP Value、iLOG实现了Qos API。
四 与NGOSS的联系
首先，OSS/J的制定参考了ITU，TMF，IETF，3GPP，IPDR等组织的标准规范。由于TMF的NGOSS已经成为OSS设计的典范，因此，符合NGOSS规范是至关重要的。下面将主要分析OSS/J与NGOSS的关联。
1.与eTOM的关系
·OSS/J认证产品间的交互实现了eTOM中定义的业务流程。
·eTOM业务流程在OSS/J API定义的过程中用例的定义中作为参考
·业务流程自动化可以得到，通过工作流引擎 集成OSS/J认证的产品
·OSS/J API没有硬性规定特定的工作流引擎和公共通信设施
2.OSS/J API与SIM的覆盖
·每个OSS/J API映射到一个或多个SIM域/LBC/合约
·以同样的粒度，但是采用不同的分组
·SIM分组按照逻辑域信息
·OSS/J分组按照信息使用
·OSS/J，合约以OSS/J会话组件的形式实现
·在SIM中，业务合约以文本表述
·OSS/J定义 更具体和一致(Java /XML定义,严格限制且可测试的行为,经参考实现验证的)
以“库存API”为例，其中包括了eTOM中不同ABE的内容，如产品中的（产品、产品规约、 产品目录计划），服务（服务、服务规约、服务策略），资源（物理设备、物理设备规约、逻辑构件、资源规约、 网络拓扑、 资源规划策略、资源使用），通用业务实体（组织）。
图5：OSS/J库存API到eTOM映射图
3.OSS/J APIs与SID
·业务实体映射到OSS/J的管理实体值对象(MEV，ManagedEntity Value)
·属性映射到OSS/J MEV的属性
·关联映射到OSS/J中MEV间的关联关系
·实体映射（大多以一对一）到JAVA类
·用于新的OSS/J API（e.g. Inventory, future APIs,…）
以库存API为例，包含产品域(产品规约，产品)，资源域（管理物理构件，物理设备，物理设备所有者，业务实体间的关联，业务实体属性）,服务域(服务,服务规约)。
4.原则对应：
·Workflow + JMS/XML――> 流程控制外部化
·Standardized APIs――> 合约定义接口
·JMS/XML――> 公共通信设施
·JNDI registration――> 合约注册和交易
·JCA, RMI/IIOP…――> 集成遗留系统
·Enterprise Java Beans――> 基于构件的软件
5.与NGOSS的差异：
·OSS/J强调基于API的产品认证（信息模型和行为）
·NGOSS强调整体方案与主要原则的一致性及规范（eTOM，SIM）的覆盖
6.映射
在TMF050A中，定义了第三方框架到NGOSS的映射。可以通过NGOSS的一致性测试项目进行映射，从而将OSS/J方案与NGOSS进行对比衔接。
图6：NGOSS一致性第3方间接测试过程图
五 小结
OSS/J源于无线和数据网络领域，而又不锢于此，它具有非常好的适应性和可扩展性。和NGOSS相比，遵循OSS/J开发的应用更易于集成，它对软件厂商具有更强的指导意义。它还提供了与CORBA应用集成的方法，可以容易地跟基于CORBA的网管系统集成起来。另外，我们可以非常容易地把OSS/J的集成方案映射到NGOSS体系。目前国外已经有很多基于OSS/J的商业产品，相信不久的将来，必将有更多OSS/J的产品推出。
(责任编辑：战莹)
