移动增值业务平台解决实例

类别:软件工程 点击:0 评论:0 推荐:
作者:陈立峰   来源:赛迪网     摘 要

J2EE为WEB应用提供了多层次的结构体系,而在传统软件(非Web 应用),如何建立合理的、灵活的结构体系,是本文的主要目的。本文基于一个分布式中间件开发工具– SoftEngine, 以移动通讯的增值业务平台为例,阐述分组件化布式系统的基本技术及特征。

关键字:

中间件 Middle-ware ,分布式系统Distributed System,结构体系 Architecture,移动互联

Wireless Internet,短信 SMS,彩信 MMS

1. 前言-移动增值业务平台的三个难点

如果说二十世纪末,是互联网(Internet)辉煌的时期;那么二十一世纪初,是无线互联(Wireless Internet)崛起的时代。自从摆脱了WAP的阴影,手机短信在其成功的运营模式推动下,迅速成为新的经济热点。数百家营业性网站几乎同时都做起了短信的生意,并不断涌现新的创意。近日,随着移动网络以及终端设备的改进,以多媒体技术为主导的彩信(MMS)业务也已加入火热的市场。移动增值业务真正进入了一个“应用为王”的时代。

从字面上理解: 无线互联(Wireless Internet)是互联网(Internet)的移动领域的一种衍生。在本质上也是如此。所以许多无线互联的应用,从表面上看,是WEB应用的一部分,有的甚至依托于WEB。但在表现的背后,两者的实现技术,有着本质的不同。下图可看出,手机用户使用短信(移动)业务的过程,类似通过互联网访问特定的网站。只是用户利用手机通过移动运营商(中国移动/联通),与Internet联接,而不是常用的电脑。



图表1 短信应用业务模式

最简单的建立短信应用的方法:利用移动运营商的网关接口API,直接与移动网关对接;再配以数据库或文件作为数据交换的方式。这做法,适用于单个的短信应用。如果应用种类增多,由于体系结构的关系,很难有好的性能。

尤其在竞争激烈的移动增值业务中,新应用推向市场的时间(Time-to-Market)是关键。有人统计过:短信应用的平均生存周期为3个月。也就是说,每个应用从策划完成到推出市场的时间越短,开发成本越低,应用的市场价值也就越大。所以,移动增值应用的技术难点,不在于应用的实现,而是在实现的速度,及质量。而众所周知:软件开发中,时间与质量成反比。 这是移动增值应用的第一个难点。

第二个难点:速度。在2001年的春节除夕,手机用户就已经体会到了。虽然移动运营商已经通过扩容,改善了短信的通道。但流量的压力会从移动网关,转移到了应用端,这对应用系统提出了更高的要求。而且,短信的特点:内容短,数量大,突发性高。所以,简单地依靠数据库、文件系统传递数据,不能满足关键应用的性能要求。

第三个难点,没有前两个问题那样容易表达,简要来讲:许多看似简单的事情放在一起解决,问题就会变得复杂。在竞争激烈的移动增值业务中,应用的数量、种类,是取得优势的因数之一。新的应用层出不穷,相关的内容也是追求新颖别致。内容有的是自己在准备,而更多以合作的模式获得,甚至应用也是如此。在解决应用的同时,还要解决为不同运营商提供服务。虽然国内只有移动(CMCC)和联通(UNICOM)两大主要移动运营商,但一些原因,使得应用提供商需要和不同区域的当地运营商分别提供应用,不可避免地需要与不同运营商的网关接入。如何有效地管理:应用、内容、网关接入,以及计费、统计、分析等诸多后台工作,是增值应用平台所需要考虑的。

虽然通过增加维护人员、设备,可以在某种程度上缓解这些问题。但随着业务增多,维护成本会不断增加;随着时间的延续,设备的更新成本也不容忽视。还需要考虑人员变更,设备故障等不定因素带来的负面影响。

从根本上解决问题,一个稳定的、有效的运行系统是不可缺少的。它可以减轻维护、管理压力,提高业务运作的准确率,制作应用才会变得真正的”简单”。 构造这样的系统,我们需要从结构体系着手。

2.应用平台基础–SoftEngine的结构体系

结构体系(Architecture)这个词,会在全文中多次出现。因为,它是软件系统的灵魂。何种结构体系,决定了系统具备哪些优点、哪些缺点,以及性能。在开始构建系统平台前,我们最好了解一下,它的基础SoftEngine - 分布式体系结构。在一篇名为: << 面向对象的分布式开发系统 - 理论篇>> 中有较详细的介绍。或查阅网站: www.snapbug.net, 获得更多信息,及下载相关软件。

3.移动增值业务系统的设计方案

以短信和彩信为主要业务模式,对移动增值业务做分析,设计方案。

3.1短信、彩信的业务流程

在前言中,已经描述了短信的业务模式。在此基础上,再来看看业务的流程,见下图:



图表2

非常类似Web应用,短信应用是由用户发出的上行短信(MO)到应用端,返回结果称为:下行短信(MT)。不同之处在于,应用可以在没有上行的情况下,主动发起下行信息,用户被动接收。运营商的网关包括: 移动网关(ISMG)和联通网关(SMG),分别以CMPP或SGIP协议与应用提供商(SP)连接。

彩信比短信要复杂一些,而且物理承载层也有了变化,但运营商已很好地进行了封装,所以对于SP,它们的业务流程也是相近的:运营商提供彩信中心(MMSC)作为网关,通过MM7协议与SP通讯。

3.2需要考虑的问题

在设计应用平台的具体方案前,我们还需要就业务流程,预先考虑几个问题:

1.平台需要与不同的网关以不同的协议连接,而且也存在版本升级的问题。所以与网关的接口模块是组件化的,可以按需要动态加载。

2.应用模块与接口模块之间存在一对多的关系。不可能为不同的网关/协议定制不同的应用。所以应用与接口之间必须是无关性的,即:应用无需了解接口的属性,反之也一样。

3.应用的个数、种类是多变的。所以应用模块也是组件化的,可按照一定的规则挂接或脱离。同时应用也有可能由合作者提供,所以应用的对外接口也是需要的。

4.同时下行的信息可以按照不同的规则路由到指定的网关。上行信息也需要路由到指定的应用。而这些动作不应当由接口或网关承担。

5.对于不同的网关及应用都需要分别做计费、统计、日志管理。以满足与运营商核对账单,与应用的合作者提供分账的明晰。

以上列出的仅仅是核心的问题,在充分理解的基础上,我们需要借用SoftEngine的体系结构以及设计理念,得出成熟的解决办法。同时平台的体系结构也逐渐随着问题的解决,慢慢明朗。

3.3移动应用平台的结构体系

首先,让我们从宏观上看看平台是如何工作、提供服务的。如下图:



图表3 MAP-Mobile Application Platform



移动应用平台(Mobile Application Platform,以下简称平台),主要的使用角色只有两种:

●注册用户(Subscriber),是平台的受众群体。通过各种移动设备使用平台所提供的多种应用。WWW服务做为辅助工具,方便了注册用户的订阅、点播及了解更多的应用信息。

●管理维护人员(Administrator)。平台需要日常的管理和维护,除了通过专有通讯方式外,WWW服务是必不可少的、实用的手段。这里的管理人员包括:系统配置人员、应用配置人员、内容管理人员、内容发布编辑(内部/外部)、客服人员、计费统计人员。大部分人员都可以通过,WWW服务完成各自的任务。

所以,平台以移动应用系统(Mobile Application System,简称MAS)为主体,WWW服务为辅助工具,数据库存放平台所需的各种数据。

●移动应用系统(MAS)。几乎所有的移动应用都由MAS完成。MAS完全基于上文介绍的分布式开发系统 – SoftEngine的体系结构,并继承了SoftEngine的所有特性,包括:应用的组件化、数据安全性、以及内部组件可根据负载压力的分布处理。同时利用SoftEngine提供的Web方式对外接口 – WebPostTaskServe实现与WWW应用的结合,如:网上收费应用等。也为内容应用第三方合作者提供了便利的接口。MAS最主要的接口是与不同移动运营商网关的连接,被定义为网关适配器(Adapter for Gateway)。

●WWW服务。除了为注册用户提供辅助功能,还可以为系统人员提供管理工具。包括的功能参见上述两个角色的描述。

●数据库。MAS运行,可以不需要数据库的辅助。但为了对系统管理的方便,以及应用内容的有效管理,我们还是加入了数据库。存放的数据包括:系统配置数据、应用配置信息、注册用户信息、应用内容等。

从上图,可以看出:在移动应用平台的三个组成部分中,MAS是结构中的关键。它的特性决定了,平台的优略。普通的设计,很难处理在本文开始所提到的三个难点。只有从根本上,采用上一章节介绍的分布式的体系结构来解决。所有我们将重点介绍MAS的内部结构。

3.4移动应用系统MAS的设计

在上文的 “应用平台基础 – SoftEngine的结构体系”,我们已经对分布式系统有了初步的认识。MAS完全以SoftEngine为基础,继承了所有的组件化、分布式等体系结构特点,所以在MAS的设计工作中,已无须对其基础结构过多地考虑。在充分了解移动业务及其中需要关心的问题后,我们可以按照SoftEngine的开发流程,直接设计MAS的工作流程,然后定义完成工作所需对象组件(Object Component)。由于篇幅的限制,先从整体上描述MAS的组件结构,然后着重介绍其中一个主要的工作流程。从中体会到组件化设计的乐趣。

3.4.1MAS的组件结构图

先来看看被定义好的MAS是什么样子,如下图:



图表4 MAS组件结构图



MAS虽然包含许多对象和组件,但这些对象可以按照功能的不同,分为五类:与移动网关连接的适配器组件;负责转换不同协议的信息转换组件;包含所有应用的组件群;日志纪录、资费统计的计费组件;以及可作为MAS与WWW应用、外方合作接口的通讯组件。这样,MAS的结构就比较简单清晰了, 以下分类介绍。

3.4.2网关适配器 Gateway Adapters

网关适配器主要由SoftEngine的通讯服务类(Serve Class)的派生对象实现通讯协议。考虑到实际情况中,MAS会和不同移动运营商的不同网关连接,所以网关适配器组件里,需要包含支持不同协议的通讯组件,可划分为多种接入门户(Portal):

●支持中国移动CMPP协议的短信门户(CMPP Portal)。

●支持联通SGIP协议的短信门户(SGIP Protal)。

●支持中国移动MM7协议的彩信门户(MMS Portal)。

●其他未知的种类,如:将来可以增加联通彩信。

在每种Portal内,还会涉及到不同地区的接入点,以中国移动短信门户(CMPP Portal)为例(假设协议版本唯一):为了同时与多个CMPP网关(ISMG)同时接入,需要把CMPP通讯服务类(CmppServe Class),通过配置,实例化出三个对象CmppServeToBeijing, CmppServeToJiangshu, CmppServeToSichuan,分别与北京、江苏、四川的网关连接。为了区分不同地区短信,还需要在组件中加入路由对象OutgoingRouter和IncomingRouter,处理MT/MO短信。这样,通过实例化新的CmppServer,同时调整信息的路由配置,就可以在短时间内增加新的接入点。调整操作,就像在一台PC机上又增加或删除了一块网卡一样方便,几乎对系统中的其他部件没有任何影响。

联通短信接入门户(SGIP Portal),只要更换通讯服务类为SgipServe,其他与移动门户一样的。彩信接入门户虽然在接口协议上与短信有较大的区别,但主体结构没有变化。但由于信息的内容不像短信那样简短,通常在10K-50K之间,所以多媒体内容只有在发送前,才由功能对象FetchDataFunc从文件系统或Web方式读取到内存,再通过相应的通讯对象传送到移动网关。

3.4.3信息转换 Message Transfer

在网关适配器组件内个对象之间,所传递的任务是与具体的通讯协议想关。对于发送的内容并不关心。为了做到应用与通讯协议的无关性,在应用与网关适配器之间需要有一个关键的协议转换功能,在MAS内被定义为:信息转换(Message Transfer)。

从图中,可以看出Transfer的左边是网关适配器组件,右边是应用组件群。在应用组件内,只包含通讯协议中与应用相关的信息,其他信息都需要通过Transfer对象翻译。所以MAS的短信信息转换对象SmsTransferFunc起到:通讯协议任务与应用任务之间相互转换的作用。信息转换的作用会在后续的短信工作流程范例中具体描述。

3.4.4应用组群 Application Group

应用组群是MAS中最活跃的部分,从应用形式上可分为:

●定制类型: 定制一项服务后,用户会定时接受到系统主动下发的信息。

●点播类型: 无需事先定制。需要时发送指定的命令内容到服务商,得到特定的内容。

从内容上分为:

●新闻类型: 以固定时间为周期,刷新内容。一般是一些时实性强的内容,比如:天气预报,新闻等。

●咨询类型: 信息没有太强的时效,如:幽默笑话、生活指南等。

●交互类型: 用户与用户、用户与系统之间的动态交互内容。如:游戏类、聊天等。

以上的分类,还可以相互交错结合,形成丰富的、多态的应用。

在构造MAS初期,我们可以先实现几种常规应用,如:新闻和咨询类型的定制及点播服务。在以后业务发展中,只需配置就可在极短时间内,增加新的内容。但更多的应用需要量身定做。即使这样,SoftEngine的功能对象(Func Object)也可最大程度上提高代码的可重复性,缩短应用的开发周期。涉及到SoftEngine的开发细节,这里不做过多的介绍。

在应用中还需要考虑:如何与第三方在应用内容合作。合作方式有两种:

1.MAS作为应用平台,第三方提供内容

2.MAS作为通讯通路,第三方提供应用

第一种方式,如果合作属于常规应用,可以直接通过配置,为第三方开放内容管理权限,就可以开通应用了;如果属于特殊应用,就需要在MAS内开发新的应用了。

第二种方式,对于MAS,比较容易实现了。首先,利用SoftEngine的对外接口WebPostTaskServe,将任务以HTTP协议传递到外界,或接受外部任务。为了不影响MAS内部各组件协调工作,需要在功能组群中事先准备好特殊的对象:ExtraAppShellFunc,最为外部应用群在内部的映射,有些类是与SoftEngine中的虚拟对象的感念。

3.4.5计费系统 Billing System

在MAS内,所有与通讯相关的操作,都需要留下日志,作为日后分析及计费使用。MAS的日志有两大类:通讯日志、应用日志。前者通过计费核心组件按期计算出与移动运营商对帐的计费信息;后者可以在前者的基础上统计出各个应用的收费信息,以及第三方合作伙伴的分账详细纪录。这在MAS运作中起着比较关键的作用。

日志信息需要及时写入文件或数据库中,对实时系统的效率提出了挑战。采用分布式技术,可以很好地解决。

3.4.6短信工作流程

MAS中的各个组件,通过预定义的工作流程(Work Flow)协调在一起工作。工作流程的设计是SoftEngine开发中最重要的环节。现以短信的核心流程为例介绍。



图表5 Work Flow



上图,显示出短信笑话点播的工作流程:

●用户发送的点播MO信息,通过服务对象接收并形成CMPP任务 (CmppMoTask)。

●CmppMoTask经过路由对象IncomingRouter传递到信息转换对象(SmsTransferFunc)。

●根据配置,SmsTransferFunc将CmppMoTask转换为应用可以接收的应用任务(AppMoTask),并传递到笑话应用AppJokeFunc。

●AppJokeFunc对任务处理后,返回结果任务(AppMtTask)。

●AppMtTask被SmsTansferFunc转换为CmppMtTask,通过下行路由传递到CmppServeToBeijing,并发送到移动网关。

在上述流程中,CmppServeToBeijing和SmsTransferFunc是信息不同阶段的分界点,所以需要纪录日志。前者纪录通讯日志,后者纪录应用日志。纪录的费时操作,并不在分界点完成,而是利用上文提到的流水线设计模式,由计费系统的专有日志纪录对象完成。分界点的日志操作,只是将产生的日志信息,以任务的方式转发到日志对象。这样,避免核心工作流程包含费时操作,使其保持高速运转的效率。

4.解决问题的机制

4.1MAS的快速应用开发优势

由于MAS采用了MessageTransfer作为信息的转换组件,对应用组件而言,屏蔽了多种不同通讯协议带来的干扰。在组件的开发过程中,无需考虑怎样同时支持中国移动、联通的协议。只要按照规范,即可实现:同一应用组件,同时为移动和联通的手机用户服务。减少了一半的开发工作量。

其次,大部份的应用开发,都可采用上文提到的面向对象技术,将设计、开发的重点放在业务逻辑的实现。而且由于复杂操作的封装,使得开发在一种固有的规范下进行,降低了开发难度。即使是刚接触移动业务的程序员,也可在参考前人工作纪录的情况下,独立完成。

对于一些具有复杂业务逻辑的应用,通过组件化的流程设计,将一个应用化分为多个相对独立的组件,易于团队协助开发。只要团队中的每个程序员,确保相关组件的功能正确性、稳定性,通过任务信息的传递,降低团队开发的协调难度,提高接口的准确率,成倍缩短整体测试的时间。

以上这些特点,使得MAS在应用开发上,能够始终保持时间上的先机。

4.2信息处理的速度优势

在上文中,可以看到通过工作流程的优化,提高信息的响应能力。以短信的响应时间为例:用户发送短信请求的响应时间,合理范围在4 ~10秒内,同时丢包率必须小于99%(不包括移动运营商的影响)。利用SoftEngine原有的任务驱动、数据安全机制,可以轻易的满足上面的参数要求,尤其在短信高峰期间。以图表5的主要信息传递工作流程为例:

图表5中黑线, 显示出短信笑话点播的关键处理流程。整个流程都没有涉及到任何的数据库及文件系统的操作,所有信息都由SoftEngine在负责传送。据统计,上下来回的系统处理时间在2位毫秒级。

同时为了计费统计,任务在高速处理过程中,被同时发送到日志纪录组件(图中红线标注)。日志组件虽然有较慢的文件写操作,但已被分在关键处理流程之外,对信息的处理性能没有任何影响。

信息通过内存与网络在组件间高速、有效地传输,是SoftEngine所赋予MAS的自然特性。SoftEngine的可扩展特性,将始终保持MAS的快速响应优越性。

4.3MAS灵活的扩展性能

任何一个系统在它投入使用的初期都不可能立即达到最高负荷,以及最佳状态。都有一个不断完善,不断扩容的过程。对于MAS,不确定的应用数量、种类,和未来会承受的信息压力,都是在建设初期难以预料。组件化的“软总线”结构,为应用的无限增加提供了可能。SoftEngine的非程序化分布式对象机制,使MAS在体系结构不变的情况下,通过增加硬件、调整组件分布, 解决应用的在线扩容、负载均衡等棘手问题。

4.4准确多变的计费体系

计费是MAS后端处理的关键问题。MAS不仅要计算能从移动运营商得到多少信息费用,还需准确给出,与内容信息合作伙伴的分账清单。

MAS的日志有两大类:通讯日志、应用日志。前者通过计费核心组件按期计算出与移动运营商对帐的计费信息;后者可以在前者的基础上统计出各个应用的收费信息,以及第三方合作伙伴的分账详细纪录。

在图5看到,合作伙伴的增删,MAS转换为应用组群(Application Group)的某个组件的调整。网关适配器内的组件变化,体现了移动运营商的变化。这些变更,都会通过日志组件,直接体现在计费系统的处理结果中,并且是非程序化的。

5.小结

本文,以移动增值业务平台作为例子,在体系层面上,介绍如何利用组件化的分布式技术实现灵活、高效的方案,省略了有关开发及系统发布的细节。在实际开发中,整个项目最多同时投入了5位软件工程师,其中只有2位用于MAS的建设中。从设计到发布用了2个月,测试时间只有10个工作日,整个系统就投入了使用。简短的整体测试周期换来相对稳定的系统,这也是组件化技术的一个特点。

在平台运作中,常规应用的增加、调整,以及为第三方提供通讯通路的配置工作,只需1个小时即可开通。如果涉及到开发新应用,平均开发耗时5个工作人日,即可投入运行环境试运行(其中不包括:页面制作等外围辅佐工作)。

从中,可感受到组件化和分布式技术的强大作用,为非Web应用,提供了另一条捷径。在网站:www.snapbug.net可以下载文中所涉及的相关软件,及技术资料。

本文地址:http://com.8s8s.com/it/it32765.htm