站内搜索: 商品 资讯 职位 下载

        新闻分类
        您现在的位置:新闻首页 >> 新闻中心 >> 行业资讯 >> 分布式架构在电信业的应用

        字号:   

        分布式架构在电信业的应用

        浏览次数: 日期:2005年4月9日 16:17

        在下一代电信运营支撑系统的实现过程中,分布式架构的部署以及开发平台和开发工具的选择,将是系统升级成败的关键因素之一。分布式计算技术的应用和工具,目前成熟的技术包括J2EE、CORBA和.NET(DCOM)。关于.NET,比尔.盖茨如是说:“简单地说,.NET是以微软的各种产品为开发工具和应用平台,实现基于XML的网络服务。”由此也可以看出,.NET在微软的世界里功能强大,但对于Unix和Linux这些在服务器市场占主要份额的系统,.NET显得束手无策。

        对比之下,J2EE显示了它跨平台的优势,为网络服务商提供了很好的面向前端的开发和应用平台,随着网络服务进一步广泛应用和服务集成度的提高,在网络服务提供商的后台会形成越来越庞大的分布式计算环境,CORBA的模块结构更适合后台的多种服务,例如网络服务的计费程序等。因此可以看出,J2EE和CORBA技术在网络服务这片蓝天下,各自有自己的海洋和陆地。如果在前端使用了.NET开发平台,那么在后端的分布式结构中,DCOM就是理想的选择。

        在大型系统的开发中,对数据库的访问往往需要多线程的支持,否则可能会形成数据库访问的瓶颈。CORBA标准对多线程的支持被认为是安全可靠的;DCOM本身不支持多线程;J2EE/RMI本身也是非多线程,但可以通过“线程复用技术”解决这个问题。

        从系统应用的复杂环境来看,CORBA比J2EE功能更强一些:使用CORBA架构,能够选择更多的开发语言。由于CORBA规范的开放性,不同厂商提供的CORBA产品具有互操作性。但在应用中,OMG组织缺乏对市场上CORBA产品是否严格符合CORBA的标准进行认证,再加上CORBA产品应用环境的复杂性,供应商相互支持不够,更谈不上互通功能在产品级别的测试,因此,应用软件开发商要谨慎使用这个功能。

        另一点要考虑的因素是系统的运行效率。J2EE是纯Java技术,很多测试显示J2EE/RMI服务器的响应速度远远低于非Java的CORBA服务器。因此,在一些对数据处理速度和响应时间要求较高的系统开发中,要对系统的性能进行测试对比后再作选择。在国内的CORBA应用中,一个非常典型的成功案例是时力永联为北京移动开发的OSS运营支持系统,该系统结合了J2EE与CORBA的功能。这个系统的总体构架符合e-TOM(增强的电信运营图)的框架,系统前端采用B/S结构;在后台一些服务器之间以CORBA方式通信,例如计费模块、数据库访问模块等。系统投入运营后,非常稳定,除非是系统扩容或增加功能的需求,针对CORBA服务器的维护工作量,在总体维护工作量中所占的比例相对较低。

        在电信级的eTOM框架中,端到端的业务模式划分出很多功能模块,eTOM的二级流程视图不只反映了运营流程的逻辑关系,实际上,二级流程视图的每个功能模块基本上对应一个软件模块。时力科技在针对NGOSS(下一代运营支撑系统)的研究中体会到,在实现时,这些eTOM中的功能模块形成了复杂的分布式计算环境。模块之间互相调用,比如说功能模块B为功能模块A提供某个服务;同时功能模块B又向C申请某个服务。而在CORBA架构中,对服务器和客户端界定得很清楚,此处B既是A的服务器端,又是C的客户端,A、B、C可能运行在不同的主机上。而每一对服务都是由IDL的“界面”描述的,这样就有诸多的IDL“界面”要定义,这样虽然模块关系比较清晰,便于维护,但初期开发工作量不小。对上述情形,采用J2EE将会缩短开发周期,因为不需要定义大量的IDL及其维护工作。

        对于分布式计算技术的架构,不能绝对地说哪一个更好,只能说哪一个更合适。针对不同的软件项目需求,具体分析才是明智的选择。从宏观市场来看,CORBA产品的销售并没有如想象那样给CORBA产品提供商带来可观的利润;而.NET在工业界的呼声也不如J2EE那么高;随着J2EE与CORBA接口的加强,再加上开发费用相对较低和使用的方便性,J2EE一揽子开放的环境,将会是软件开发商和系统集成商的首选;但CORBA标准具有极好的兼容性,也使它在大型系统开发中会占有一席之地。

        所属类别: 行业资讯

        该资讯的关键词为: