SOA架构的通信运营商运维门户系统建设方案分析.docxVIP

PAGE 1 PAGE 1 SOA架构的通信运营商运维门户系统建设方案分析  为了满意通信运营商对于运维支撑系统快速变化和响应的要求，在分析运维支撑系统的现状和传统EAI集成方式的不足的基础上，本文提出了基于SOA架构的运维门户系统建设方案。具体阐述了该方案的结构和功能，结合某移动公司的实施状况。表明该架构能够有效的解决企业运维支撑系统的集成问题。  1运维支撑系统的现状概述  经过十几年的发展，目前国内各大电信运营商都拥有了一个规模极其浩大的通信网络，为了保证这个网络的正常运行同时又不断地新建了大量的运维支撑系统(OSS，OperationSupportSystem)，诸如厂家网管(OMC)、专业网管、(数据网管、话务网管、传输网管等)和综合网管(综合分析系统、综合告警系统、综合监控系统等)等数十种运维支撑系统，这些系统基本都相互孤立，只有少量的数据交互和接口调用，随着市场业务的发展对运维支撑工作提出了更高的要求，使得目前运维支撑系统的信息资源管理模式暴露出了许多问题，主要有以下三个方面。  1)各个系统单兵作战。不同系统的数据及资源没有被有效地整合和集成，严重限制了运维支撑系统信息资源的应用广度和开发深度。  2)缺乏统一的规划。不同系统通常由不同的集成商开发，所使用的技术、数据结构设计方法和思路、界面风格及操作方式都不尽相同，系统之间存在着很强的互斥性，不同系统之间很难进行信息交换，存在着大量“信息孤岛”。  3)从外来看，单个系统是个封闭的黑盒子，内部功能只能为自身服务，对外是不可见不可重用的，不能为外部系统或其他应用服务。  随着市场规模的急剧扩大和全业务运营的紧迫需求，要求能够将现在全部的运维支撑系统进行数据集成、界面集成和应用集成，将全部关于运维支撑系统的告警、信息、报告等内容在一个统一平台上集中呈现，以便能够更全面的了解网络运行现状，发觉深层次的问题，这个统一的平台就是运维门户系统(OMPS，OperationAndMaintenancePortalSystem)。  由于各运维支撑系统之间存在着开发语言、开发平台和操作系统的差异，传统的系统集成方法费时费劲，而且在各系统之间形成了紧耦合，增加了日后系统扩展的复杂度；本文利用SOA架构的松耦合性和平台无关性特点，较好的解决了通信运营商在建设运维门户系统过程中遇到的问题和困惑。  2运维门户系统  OMPS是指在一个企业内部，通过界面集成、数据集成及功能集成等技术将分散在各个系统中的功能和信息有效地组织起来，给用户供应了统一的信息服务功能入口，实现企业运维信息和学问的共享，提高员工和企业的工作效率。  运维门户系统自身无任何数据信息，其呈现的信息及功能都是来自被集成系统，门户主要实现的功能主要包括以下三点。  1)界面集成。即在运维门户系统的一个页面中将用户感兴趣的多个OSS系统页面进行统一呈现，使用户无需在各个系统之间进行登录切换，增加用户查看信息的便利性。  2)数据集成。运维门户系统需要采集各个OSS系统的业务数据，然后进行归纳、加工和处理，提取出对使用者更有价值的信息并进行展示。  3)功能集成。运维门户系统还需要对各OSS系统的功能进行集成，使用户在门户中也能够使用各OSS系统中的特定功能。  由上述三点可以看出，运维门户系统实现的核心就是企业应用集成(EAI，EnterpriseApplicationIntegration)，EAI是将基于各种不同平台、用不同方案建立的异构应用系统集成的一种方法和技术，将进程、软件、标准和硬件联合起来，在两个或更多的企业系统之间实现无缝集成，使它们就像一个整体一样。  EAI技术从本质上说是基于消息的集成，实现方式如图1所示。各个OSS系统需要特地开发相应的接口适配器，以便在OSS特有的数据结构与统一标准消息之间进行转换，消息总线负责将各个系统发送的消息根据路由规则发送到目标OSS系统；运维门户系统通过向消息总线发送特定消息，恳求其所需要的相关资源，OSS系统在收到消息恳求后将门户恳求的结果进行反馈。 图1EAI集成方式 EAI技术目前存在着三个问题。  1)接口适配器需要针对特定的系统进行开发，开发工作量大，且系统的业务规律变更可能会导致适配器的重新开发。  2)EAI所使用的协议一般都是企业私有的协议，不能为其他系统所重用。  3)EAI一般来说主要为这些已有的系统供应一种中间沟通方式，让这些系统之间可以进行数据的共享与交换，不太关注于界面和功能的集成。  通过引入面向对象服务架构(SOA，ServiceOrientedArchit