图文：BEA系统中国公司技术经理郑曙光

图为：BEA系统中国公司技术经理郑曙光(骆磊 摄)

　　2008年1月18日，2008年电信计费和运营支撑大会在北京举办，本次会议由中国通信学会举办，会议主题为“下一代计费和IT发展策略”。

　　图为：BEA系统中国公司技术经理郑曙光(骆磊 摄)

　　以下为其演讲全文：

　　郑曙光：SOA这个名词听到很多了，讨论到现在差不多4年时间，实际上是集成了一些软件的技术，但并不是根本性的改朝换代的变化，我们如何思考或看到大量的名词Web2.0，他们又是讨论什么？我做一个介绍，基本是在概念之上稍微往前进了一步。

　　首先我们从这样一个名词看起来，Mashup，他是来自于哪？首先可以看到不同Mashup的解释，不是从音乐定义的。它来源于音乐层，从音乐角度看到的，叫什么呢？台湾会叫混搭，把不同的音乐混合在一起形成效果。实际上应用在外部或者IT领域，带来的是如何把不同的源提供的数据或者是由应用产生的，把这些应用组合在一起成为新的应用。

　　我们看到Mashup第一强调的是Web应用，第二组合了一些数据，这些数据是从不只一个原来的。不管是企业内部，还是电信内部的企业云也圆，最终大客户是企业用户。

　　为什么从Mashup说起呢？Google的例子应该说是最直观的，后面我从三层的角度去看。如果去看的话，最直接的访问者体会到的应用是展现层的一部分，我们拿Mashup来讲，更直接地感受到的内容。我截的是一个Google的界面，一个是数据的提供或者是应用功能的提供，天气、新闻也好，这些我们都了解，都不是Google提供的，是从不同的源拿过来的，我们组成在一起，不仅仅是基于互联网的应用，在企业内部也大量应用。企业内部应用有可能在一起组成，在这个过程中，有可能使用的业务的能力是从不同的点组成起来的。

　　回到电信行业支撑系统，这个系统跟我们刚才讲的Mashup要求的或者需求的环境有什么相同或者不同？从完整的系统应用来看，一定有底层数据，有中间层和业务层，还有上面的人访问过来。我们看到中间的业务处理过程对不同的数据都要进行访问，当然这些数据有可能不是这种按照线的方式直接访问，上面的人也不是单一的只访问一个系统，对于电信运营商，支撑的系统和营业人员来访问的系统几个啊、几十个。这样的系统对于最终用户而言，访问多个系统也有交叉混合的需求。更不说在运营商内部有大量的内部的管理系统，这些系统实际上跟外部的运营或者营业系统不是剥离开的。

　　我们知道分析拿来的数据是指导运营系统的调整，运营系统要去做分析，这样的过程是一个滚动循环的，中间不是剥离的，所以把里里外外都放在着，从建设角度来讲不可能是混为一谈，我们要考虑如果交互或者融合。这里举个不是太恰当的例子，早期电信行业可能按照垂直的，比如固网有可能是市话、长话、数据业务的建设，逐渐大家在变，在改这个系统。我们这个倾向于可能营业厅有一套系统，呼叫中心有一套系统，大客户合作伙伴也有一套系统，不恰当的地方是合作伙伴系统可能不是垂直单独的系统能剥离出来，跟后来很多计费系统要关联不是自己完成所有功能。

　　我们看到的情况是什么样呢？传统应用是垂直的建设方式，现在大家把它往水平方式走，按照水平的颜色来看，更多的是往大块上画，有很多的系统，可能分的更细一些。前端面向客户提供统一的客户服务能力，当然应该包括营业厅自助服务等等一系列服务。

　　从这样的角度看，如果全企业内看三层，传统上讲中间件或者单独应用的时候，企业应用是典型的三层应用。有数据逻辑层，业务逻辑层也有展现逻辑层，在企业范围内看仍然存在，这时候存在的方式不太一样，在数据逻辑层不仅仅是要求对分布式数据的统一访问，每个系统都有后台的数据，把分散的数据统一起来。传统上如果单一业务独立拿出来看没有这样的需求，如果现在把客户的服务数据，计费项目的数据甚至后面的分析出来拿来的结果拿到这里来，这些数据本身都是统一业务环节中必不可少的所有数据。相同数据的统一存储，电信业中性能是必不可少的，我要用统一的中心的概念，所以从性能的角度折衷一下，对于某些数据大量的不同系统当中频繁的一些访问可能产生，冗余存储。从业务逻辑层看，也不是传统的支撑一个业务建设，我们现在要求的是应用互访，每个应用模块或者系统当中提供出一部分功能，但对于用户、营业人员来讲，完成完整的操作可能靠多个模块来完成。我们在交互过程是不是A和B一个对一个。位置透明，没有强化它的需求，带来的是任意一个系统从IT维护角度做了一些调整，如果访问位置是透明的，这就不对我的系统造成影响。另外从管理角度进一步提升角度也有一部分需求。但第一阶段不是那么迫切。

　　之所以提出这个，是曾经看到一个国外分析资料，在大量企业中做调查，为什么已有的IT投资不能很好的重用，是因为我原来不知道干这件事情。不要说现在还是按部门、角色分工、建设IT系统，即便统一起来，实际上由于庞大的量我们很难每一个人都掌握。当有一个人要来建设新的系统，如果发现企业内已经有了服务可以被我所用，可以大大缩短开发周期，并且重用原来的资产，保证我的投资。实践驱动的流程流转，用户有一个需求进来会驱动你的业务流程在内部的流转过程，这是基于用户有良好的互访之后。

　　从展现逻辑层，不同人要访问不同的系统，是切换还是有什么手段？类似于Google一样，我们希望有一个统一的展现聚合，以前可能都是单独的访问，现在统一放在一个里面，企业内部也可以考虑这样的方式把企业后台应用聚合起来。这个聚合过程针对不同人群定制，普通营业员和客户经理的需求是不一样的，面向合作伙伴他们的需求都是不同的，要有对他们的定制能力。还有融合访问渠道。还有机遇笔记本的方式，打电话、传真等等都是不同的渠道，这些渠道后台访问的是相同的业务能力。

　　在电信行业内部，从业务角度看服务，还有他的支撑系统需求。有几种分类，单元性的业务服务。单独的一个服务，访问量巨大，需求固定，比如说缴费，不管你后面的模型怎么样变，我进来之后要看我缴的费，我的费用是多少？帐单多少？去缴费，我钱进去之后要把我帐单上的欠费抹平。这些往往很少变化，灵活性并不是很高，但性能要求很高。被大量其他业务使用的，本身也是需求固定的，同样有大量的访问，性能要求也比较高。符合业务服务，业务开通过程往往就是这样的过程，是综合了多种基础业务服务，需求多样，访问量相对小。每一个业务地宫了业务开通的访问服务能力，这个过程我们需要组装起来。有了这样一些业务服务类型，从业务开通压力上，运营商面临越来越多的快速推向市场的压力，要求尽快地准备好。面向客户服务是要提供一揽子的统一服务能力。增值业务与合作要体现全价值链上下游的支撑，最终用户也可能是产生业务的人，也可能是创造业务的人。这当中需要他把上下游联系起来，完善支撑的过程。

　　目标是良好支撑，电信需求的系统。有这样几层从数据层到中间的原子业务层到组装业务层，统称成中间业务层，向上提供一个访问的业务层。我们在整个PSS五整个角度去看这样的模型，从这样的角度看可以垂直逻辑地分开。不见得把计费、业务保障是独立的系统，往往提供独立的系统，后台是不是有一个分散的后台的能力，是要根据具体的情况分析的。

　　如果前后端同时放在一起，界面加上后台真正的数据相关内容的管理，才能成为统一的客户服务，才能成为逻辑上、垂直上独立的按照eTOM组织的模型和过程完成对电信支撑能力。放在SOA的框架下是什么模型，是一个三层的应用架构解决之道。有三个总线，由于电信内部数据交换是复杂的，我们看到有很多交叉，有是时的，有异步的，有些是一周，有的是几个小时，这样的模型下带来对数据层的需求会比较大，我们看前面按照不同言颜色划分的系统，他们不是独立只访问自己，用户如果问我的业务开通两天了现在什么状况，要看一些细细等等，所以这时候要组合后台的数据提供给前端业务服务层的统一的视图。

　　当然这个服务要求是快速的，简单的开发或者创建，这个过程不是传统的靠写代码完成。写代码所有事情都可以做，但不能满足灵活性上的需求，所以这里是基于直观的可视化的方式完成的。业务服务层就是要把我分散在不同的子模块过程是独立的应用当中的能力抽象出来透过网络能访问它，并不希望是点对点的访问，我希望有一个统一的路口，这个就是业务的服务总线，在这个总线上注册进来，我能够看到它，并且访问到这层，由于有了松耦合，就是解耦的过程，后台的系统即使发生了变更影响也不大，如果是简单IT层面的变化没有影响。如果是可兼容，兼容原来的接口或者是服务能力的话，对前端的能力也不造成大的影响。

　　基于服务组装能力，是基于大的界面去组装它，才能满足我灵活性的要求，能够进行一些无状态的、短周期的，以同步为主的。往往我们长周期的，有人机交互参与的，有这样的在里面像灰色图的业务流程控制逻辑。从统一应用展现上来看，我们也是通过一种服务完成的，也是一个一个的服务，展现也是一种服务，这种服务应该不是把后面的代码拷贝到我的机器上，因为你拷贝上来有问题，如果不拷贝自己写行不行呢？他有他业务展现的要求，除非掌握全世界业务规则才能做，这很难以。所以希望有这样的一层统一的完成展现服务的统一管理，和映射战线出来。

　　实际上看起来是这样的情况，完成的是实时对后台的访问，这个界面也从后台抓取过来的，不是拷贝过来的，后面发生变化前面也要变化。基本上非常浅地探讨了SOA情况下帮助电信运营商支撑系统做些什么，我的演讲就是这些内容，非常感谢。