UML软件工程组织

使用JAVA技术实现新一代OSS/BSS
SUN中国工程研究院 软件技术中心 王刚
出处 sun-cn   
摘要:本文着眼于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解决方案也在这一过程中趋于完善,同时也暴露出越来越多的难以克服的问题





width="480" height="280">
图1、OSS/BSS的“集成的噩梦”

OSS/BSS的软件系统相对复杂,从而使得网管系统、计费系统、营账系统、客服系统等都是各成体系,

要想把它们有机地整合在一起,几乎是不可能的,对于这种“杂乱无章”的系统结构(参见图1),简

直可以称之为系统集成的噩梦(Integration Nightmare)。
很多OSS/BSS开发商都有同感——缺少训练有素的工程师,这也是由前一条所决定的,需要工程师同时

精通电信的专业知识,又能熟悉各类软件,的确要求比较苛刻。
行业标准问题。尽管在近几年来国际国内都陆续推出了一些标准规范,但大多是停留在纸面上,同时也

缺少更直观的技术指导和成功案例。 l 一个OSS/BSS,往往会涉及若干个分离的系统,除了集成,对系

统进行测试、维护都是十分耗时的。
以上各方面的问题,OSS/J就可以解决,原因在于:

采用符合OSS/J规范而开发的软件接口相对简单,OSS/BSS内部的各个子系统是可以互换的(

Interchangable )。
OSS/J是基于J2EE技术的,开发人员只要熟悉J2EE的开发(甚至仅仅熟悉JAVA的开发)就足够了,他们

就能够与设计人员合作,完成系统开发。
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),“杂乱无章”的系统结构将

成为过去。


height="240">


图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开发人员总数已经达到了几百万,这个群体还在迅速膨胀。



width="480" height="300">

图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简介


height="300">

图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中主要涉及到以下要点:

OSS中的功能都是采用EJB组件的形式实现的
这些EJB提供了面向业务逻辑的粗略的接口
应用服务器为OSS/BSS系统提供了集群、扩展和故障处理等功能
采用消息(Messaging)交换机制来减小组件之间的耦合程度
结合消息机制和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来完成。



height="360">


图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的网站)。




height="300">

图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)。



height="300">

图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的认证。



width="480" height="300">

图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的技

术标准。

参考资料


Operations Support Systems, http://www.iec.org
OSS through Java Initiative, By Philippe Lalande
OSS through Java Initiative, Simplifying Integration with Common APIs,

http://java.sun.com/products/oss
OSS/J API Roadmap
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
OSS through Java Design Guidelines, http://java.sun.com/products/oss/apis.html
OSS Trouble Ticket API
OSS Service Activation API
OSS Common API
OSS IP Billing API
OSS Quality of Service API
OSS Inventory API

 
 

版权所有:UML软件工程组织