使用JAVA技术实现新一代OSS/BSS

　　OSS/BSS概述
　　OSS（Operations Support Systems）是指“运营支持系统”，BSS（Business Support Systems）为“业务支持系统”，OSS/BSS是这两类系统的结合在一起形成的综合的电信业务运营和管理平台，在国内OSS/BSS有时也被称为BOSS。
　　
　　标准化组织电信管理论坛（TMF）对OSS/BSS提出了被业界广泛接受的功能模型。在这个模型中，OSS/BSS包括三大功能：业务开通、业务保障和计费（或称业务计量）。业务开通是指电信运营商接受客户订购电信服务的订单，通过对电信资源的分配、配置、安装和部署为客户提供所需的服务，并能够对服务进行计费。业务保障要提供量牟饬恐副辏繁７衲艽锏娇突У囊蟆Ｒ滴窦屏吭蚴遣饬康缧磐缰懈髦忠滴竦氖褂们榭觯扑阌κ辗延茫⒍允辗压烫峁┲С帧?lt;/P>
　　
　　作为一种高效的信息管理系统，OSS/BSS已在国外电信运营商中得到广泛的运用，并在实践中积累了大量的成功案例。OSS/BSS解决方案也在这一过程中趋于完善，同时也暴露出越来越多的难以克服的问题：
　　　
　　图1、OSS/BSS的“集成的噩梦”
　　OSS/BSS的软件系统相对复杂，从而使得网管系统、计费系统、营账系统、客服系统等都是各成体系，要想把它们有机地整合在一起，几乎是不可能的，对于这种“杂乱无章”的系统结构（参见图1），简直可以称之为系统集成的噩梦（Integration Nightmare）。
　　
　　很多OSS/BSS开发商都有同感——缺少训练有素的工程师，这也是由前一条所决定的，需要工程师同时精通电信的专业知识，又能熟悉各类软件，的确要求比较苛刻。
　　
　　行业标准问题。尽管在近几年来国际国内都陆续推出了一些标准规范，但大多是停留在纸面上，同时也缺少更直观的技术指导和成功案例。
　　
　　一个OSS/BSS，往往会涉及若干个分离的系统，除了集成，对系统进行测试、维护都是十分耗时的。
　　
　　以上各方面的问题，OSS/J就可以解决，原因在于：
　　
　　采用符合OSS/J规范而开发的软件接口相对简单，OSS/BSS内部的各个子系统是可以互换的（ Interchangable ）。
　　
　　OSS/J是基于J2EE技术的，开发人员只要熟悉J2EE的开发（甚至仅仅熟悉JAVA的开发）就足够了，他们就能够与设计人员合作，完成系统开发。
　　
　　OSS/J不仅包括了技术规范，而且有真实的代码实现以及测试工具。这能够帮助开发人员很快的上手。
　　
　　因为各个子系统都符合标准的接口，所以系统的后期测试和维护工作会比较简单。
　　
　　什么是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中主要涉及到以下要点：
　　
　　OSS中的功能都是采用EJB组件的形式实现的
　　
　　这些EJB提供了面向业务逻辑的粗略的接口
　　
　　用服务器为OSS/BSS系统提