1 运维支撑系统的现状概述

    经过十几年的发展，目前国内各大电信运营商都拥有了一个规模极其庞大的通信网络，为了保证这个网络的正常运行同时又不断地新建了大量的运维支撑系统（OSS，Operation Support System），诸如厂家网管（OMC）、专业网管、（数据网管、话务网管、传输网管等）和综合网管（综合分析系统、综合告警系统、综合监控系统等）等数十种运维支撑系统，这些系统基本都相互孤立，只有少量的数据交互和接口调用，随着市场业务的发展对运维支撑工作提出了更高的要求，使得目前运维支撑系统的信息资源管理模式暴露出了很多问题，主要有以下三个方面。

    1）各个系统单兵作战。不同系统的数据及资源没有被有效地整合和集成，严重限制了运维支撑系统信息资源的应用广度和开发深度。

    2）缺乏统一的规划。不同系统通常由不同的集成商开发，所使用的技术、数据结构设计方法和思路、界面风格及操作方式都不尽相同，系统之间存在着很强的互斥性，不同系统之间很难进行信息交换，存在着大量“信息孤岛”。

    3）从外来看，单个系统是个封闭的黑盒子，内部功能只能为自身服务，对外是不可见不可重用的，不能为外部系统或其他应用服务。

    随着市场规模的急剧扩大和全业务运营的紧迫需求，要求能够将现在所有的运维支撑系统进行数据集成、界面集成和应用集成，将所有关于运维支撑系统的告警、信息、报告等内容在一个统一平台上集中展现，以便能够更全面的了解网络运行现状，发现深层次的问题，这个统一的平台就是运维门户系统（OMPS，Operation And Maintenance Portal System）。

    由于各运维支撑系统之间存在着开发语言、开发平台和操作系统的差异，传统的系统集成方法费时费力，而且在各系统之间形成了紧耦合，增加了日后系统扩展的复杂度；本文利用SOA架构的松耦合性和平台无关性特点，较好的解决了通信运营商在建设运维门户系统过程中遇到的问题和困惑。

    2 运维门户系统

    OMPS是指在一个企业内部，通过界面集成、数据集成及功能集成等技术将分散在各个系统中的功能和信息有效地组织起来，给用户提供了统一的信息服务功能入口，实现企业运维信息和知识的共享，提高员工和企业的工作效率。

    运维门户系统自身无任何数据信息，其呈现的信息及功能都是来自被集成系统，门户主要实现的功能主要包括以下三点。

    1）界面集成。即在运维门户系统的一个页面中将用户感兴趣的多个OSS系统页面进行统一呈现，使用户无需在各个系统之间进行登录切换，增加用户查看信息的便利性。

    2）数据集成。运维门户系统需要采集各个OSS系统的业务数据，然后进行归纳、加工和处理，提取出对使用者更有价值的信息并进行展示。

    3）功能集成。运维门户系统还需要对各OSS系统的功能进行集成，使用户在门户中也能够使用各OSS系统中的特定功能。

    由上述三点可以看出，运维门户系统实现的核心就是企业应用集成（EAI，Enterprise Application Integration），EAI是将基于各种不同平台、用不同方案建立的异构应用系统集成的一种方法和技术，将进程、软件、标准和硬件联合起来，在两个或更多的企业系统之间实现无缝集成，使它们就像一个整体一样。

    EAI技术从本质上说是基于消息的集成，实现方式如图1所示。各个OSS系统需要专门开发相应的接口适配器，以便在OSS特有的数据结构与统一标准消息之间进行转换，消息总线负责将各个系统发送的消息按照路由规则发送到目标OSS系统；运维门户系统通过向消息总线发送特定消息，请求其所需要的相关资源，OSS系统在收到消息请求后将门户请求的结果进行反馈。

   
    图1 EAI集成方式

    EAI技术目前存在着三个问题。

    1）接口适配器需要针对特定的系统进行开发，开发工作量大，且系统的业务逻辑变更可能会导致适配器的重新开发。

    2）EAI所使用的协议一般都是企业私有的协议，不能为其他系统所重用。

    3）EAI一般来说主要为这些已有的系统提供一种中间沟通方式，让这些系统之间可以进行数据的共享与交换，不太关注于界面和功能的集成。

    通过引入面向对象服务架构（SOA，Service Oriented Architecture），以SOA架构来设计和实现运维门户系统的建设，可以实现各OSS系统技术与服务的分离以及系统间的松耦合，较好的规避上述问题。

    3 基于SOA架构的运维门户系统建设方案

    SOA（Service Oriented Architecture）即面向服务的架构是一项rr策略，它将企业应用程序中包含的分散功能组织到可互操作的基于标准的服务中，可以快速组合和重用这些服务来满足业务需要。SOA内部的接口是采用中立的方式进行定义的（一般为WebService），它独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

[page]    SOA与传统的EAI技术比较有着以下四个优势。

    1）松耦合。提供服务的宿主与服务内容之间是相对独立的，即使宿主发生了改变，新的宿主一样可以按照服务的约定对外提供完全相同的服务，宿主与服务之间是松耦合的。

    2）细粒度集成。SOA的集成对象是系统中的每一个服务，而EAI的集成对象则是整个系统，SOA的集成粒度要比EAI细的多。

    3）标准化。在SOA架构中任何一种接口、协议都是遵循相应的国际标准，如：标准描述语言（WSDL）、发现协议（UDDl）和消息协议（SOAP）等；而EAI大多是实施企业内部的所有标准和协议。

    4）服务重用。在SOA架构中，当业务逻辑发生变化时只需要将原有的服务打敖，然后根据新的业务逻辑进行重排即可满足业务要求，而EAI则需要对现有的适配器、中间层消息转换规则与消息路由进行改造，无法重用。

    由上可以看出，在系统集成方面SOA架构具备了得天独厚的优势，特别是在通信运营企业众多OSS系统待有效整合的现状下，基于SOA架构的运维门户系统可以有效地减低企业成本、提供可重复使用、共享且高可用的网管支撑平台，快速满足通信运营企业变化的需求，本文提出的基于SOA架构的运维门户系统结构如图2所示。

   
    图2 通信运营商基于SOA架构的运维门户系统结构

    从图中可以看出基于SOA架构的运维门户系统分为四层。

    1）服务提供层。该层主要是通过对通信运营商现有的各个OSS系统进行改造，根据业务需要梳理和提取各系统中的服务，最后将服务以Web Service方式进行封装以对外提供，例如电子运维系统可以提取出代办工单服务、工单状态查询服务、作业计划查询服务、工单统计报表服务等，其他应用就可以通过调用上述服务实现电子运维系统自身特定的功能。

    2）共享服务层。该层主要是对各OSS系统提供的服务进行组合和编排，将各个独立的服务组合成能提供综合服务的高级服务，以满足更高层次的综合业务需求。共享服务层分成了三层：数据服务层、业务服务层和呈现服务层，其中数据服务层主要是实现底层OSS系统数据提供服务，满足业务服务层及门户系统的数据采集、数据转换、数据加工等需求；业务服务层主要是通过对底层OSS系统的服务进行重新编排、组织，实现更复杂的综合服务，满足更高层次的业务需求，主要包括服务访问和业务流程，即通过流程将底层OSS系统的服务组织起来；呈现服务层主要是为上层门户系统提供特定页面呈现，通过WSRP协议（Web Services for Remote Protocol）门户系统可以将呈现服务嵌入到页面中，而无需进行任何页面代码开发。

    3）ESB层。为了避免门户系统在调用底层服务时出现多点对多点的调用方式，在服务层和门户系统之间增加了ESB（企业服务总线），通过ESB可以确保门户系统的服务调用方式为单点对单点，还可以实现访问服务路由、协议转换、负载均衡、服务发现等功能，保证底层OSS系统服务调用的效率、安全性和可靠性，减低了门户系统服务集成的难度。

    4）服务消费层。该层是底层OSS系统服务的消费使用方，主要为运维门户系统或者其他相关系统，门户系统在实现上只需要关注自身的架构和界面风格，而无需过多考虑OSS系统服务的细节，将相应的服务嵌入到门户Portlet组件中，即可实现应用的集成；同时，如果日后业务发生变化，主需要更换相应Portlet组件中的服务即可。底层OSS系统的服务同样可以提供给其他业务系统使用，且一个服务可以同时在多个服务消费者之间使用。

    除了上述四层外，需要一个专门的服务查询服务器，即UDDI（统一描述、发现和集成协议，Universal Description Discovery and Integration）服务器，UDDI服务器主要是实现服务的注册、查询及发现等功能，类似于网络中的DNS服务器，具体工作模式如图3所示：

   
    图3 UDDI服务器工作模式

    首先，OSS系统中的各个服务需要向UDDI服务器注册，UDDI服务器保存其服务的名称、访问标示、地址、参数等信息，随着在门户系统中访问该服务前向UDDI服务器查询服务地址，UDDI服务器反馈服务的访问地址等信息，门户系统即可通过该地址信息访问OSS系统服务。

    基于SOA的这种架构完全颠覆了传统的门户建设方式，服务消费者（运维门户系统或其他应用）所消费的服务可能是底层单个OSS系统的服务，也可能是多个OSS系统提供的综合服务，服务消费者已经无需关注服务是有谁提供的，通过共享服务层和服务接入层实现了服务消费者和服务提供方松耦合的架构，日后即便是更换了底层的OSS系统，只要旧系统所有服务在新系统中实现或者是由其他系统来实现即可。

    此外在系统建设方式上，基于SOA架构的运维门户系统与传统的门户系统也有很大的不同：传统的方式为通过单点登录（Single Sign On，SSO）方式实现对所有OSS系统的资源、数据、应用的集成圆，被集成的系统基本上无需进行改造；而在基于SOA架构的运维门户系统建设中，首先需要对各个OSS系统的业务逻辑和功能特点进行梳理，规划和提取各个OSS系统的基础服务，然后对OSS系统进行改造使其具备对外提供服务的接口，打破各OSS系统的自我封闭，对于OSS系统来说要进行较大的改造，工作量较大，但这些工作带来的好处就是服务的标准化、可重用化、可管理化，后期新系统的建设和新应用的实现将会更加的快捷和灵活。由于不是本文的重点，所以这里不进行过多的叙述。

    4 案例分析

    该建设方案已经在某省移动公司实施，目前已经集成了话务网管系统、数据网管系统、电子运维系统、传输网管系统及各种厂家OMC等30套网管支撑系统。在经过半年的业务和服务梳理后，定义了若干标准服务，随后该移动公司对现有的支撑系统进行了改造，使其具备了对外提供服务的能力，在此基础上，新建的运维门户系统以SOA理念对服务进行了集成，从而消除了网管支撑系统的数据“孤岛”，极大地促进了该公司的运维门户集成和管理水平的提高。

    5 结束语

    随着通信运营商的市场竞争更加激烈，对支撑系统也将会提出更高的要求，一切都要以市场为导向，快速基于已有的OSS系统应用进行整合和创新将是支撑系统的必然发展趋势。本文提出的基于SOA架构的运维门户系统，将关注点从单个系统转换到了系统中的每个服务，通过对服务的整合来快速实现运维门户系统部署和集成，由于SOA架构具有良好的松耦合性和灵活性，可以有效地支撑运营商的随需而变的能力，降低支撑系统建设成本并加快应用实现速度，在3G时代的竞争中取得先机！

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。