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

《移动增值业务平台解决实例》由会员分享，可在线阅读，更多相关《移动增值业务平台解决实例（23页珍藏版）》请在金锄头文库上搜索。

1、移动增值业务(yw)平台解决实例J2EE为WEB应用提供了多层次的结构(jigu)体系，而在传统软件非Web 应用(yngyng)，如何建立合理的、灵活的结构体系，是本文的主要目的(md)。本文基于一个分布式中间件开发工具 SoftEngine， 以移动通讯的增值业务平台为例，阐述(chnsh)分组件化布式系统的根本技术及特征。 关键字: 中间件 Middle-ware ,分布式系统Distributed System,结构体系 Architecture,移动互联 Wireless Internet,短信 SMS,彩信 MMS 1. 前言-移动增值业务平台的三个难点 如果说二十世纪末，是互联网

2、(Internet)辉煌的时期；那么二十一世纪初，是无线互联(Wireless Internet)崛起的时代。自从摆脱了WAP的阴影， 短信在其成功的运营模式推动下，迅速成为新的经济热点。数百家营业性网站几乎同时都做起了短信的生意，并不断涌现新的创意。近日，随着移动网络以及终端设备的改良，以多媒体技术为主导的彩信(MMS)业务也已参加炽热的市场。移动增值业务真正进入了一个“应用为王的时代。 从字面上理解: 无线互联(Wireless Internet)是互联网(Internet)的移动领域的一种衍生。在本质上也是如此。所以许多无线互联的应用，从外表上看，是WEB应用的一局部，有的甚至依托于WE

3、B。但在表现的背后，两者的实现技术，有着本质的不同。下列图可看出， 用户使用短信移动业务的过程，类似通过互联网访问特定的网站。只是用户利用 通过移动运营商中国移动/联通，与Internet联接，而不是常用的电脑。 图表(tbio)1 短信应用业务(yw)模式最简单(jindn)的建立短信应用的方法：利用移动运营商的网关接口API，直接与移动网关对接；再配以数据库或文件作为数据交换的方式。这做法，适用于单个的短信应用。如果应用种类增多(zn du)，由于体系结构的关系，很难有好的性能。 尤其(yuq)在竞争剧烈的移动增值业务中，新应用推向市场的时间Time-to-Market是关键。有人统计过：

4、短信应用的平均生存周期为3个月。也就是说，每个应用从筹划完成到推出市场的时间越短，开发本钱越低，应用的市场价值也就越大。所以，移动增值应用的技术难点，不在于应用的实现，而是在实现的速度，及质量。而众所周知：软件开发中，时间与质量成反比。 这是移动增值应用的第一个难点。 第二个难点：速度。在2001年的春节除夕， 用户就已经体会到了。虽然移动运营商已经通过扩容，改善了短信的通道。但流量的压力会从移动网关，转移到了应用端，这对应用系统提出了更高的要求。而且，短信的特点：内容短，数量大，突发性高。所以，简单地依靠数据库、文件系统传递数据，不能满足关键应用的性能要求。 第三个难点，没有前两个问题那样容

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

6、可以在某种程度上缓解这些问题。但随着业务增多，维护本钱会不断增加；随着时间的延续，设备的更新本钱也不容无视。还需要考虑人员变更，设备故障等不定因素带来的负面影响。 从根本上解决问题，一个稳定的、有效的运行系统是不可缺少的。它可以减轻维护、管理压力，提高业务运作的准确率，制作应用才会变得真正的简单。 构造这样的系统，我们需要从结构体系着手。 2.应用平台根底SoftEngine的结构体系 结构体系Architecture这个词，会在全文中屡次出现。因为，它是软件系统的灵魂。何种结构体系，决定了系统具备哪些优点、哪些缺点，以及性能。在开始构建系统平台前，我们最好了解一下，它的根底SoftEngin

7、e - 分布式体系结构。在一篇名为: 中有较详细的介绍。或查阅网站: , 获得更多信息，及下载相关软件。 3.移动增值业务系统的设计方案 以短信和彩信为主要业务模式，对移动增值业务做分析，设计方案。 3.1短信、彩信的业务流程 在前言中，已经描述了短信的业务模式。在此根底上，再来看看业务的流程，见下列图: 图表(tbio)2非常(fichng)类似Web应用，短信应用是由用户发出(fch)的上行短信(MO)到应用端，返回(fnhu)结果称为：下行短信(MT)。不同之处在于，应用可以在没有上行的情况(qngkung)下，主动发起下行信息，用户被动接收。运营商的网关包括: 移动(ydng)网关(I

8、SMG)和联通网关(SMG)，分别以CMPP或SGIP协议与应用提供商(SP)连接。 彩信比短信要复杂一些，而且物理承载层也有了变化，但运营商已很好地进行了封装，所以对于SP，它们的业务流程也是相近的：运营商提供彩信中心(MMSC)作为网关，通过MM7协议与SP通讯。 3.2需要考虑的问题 在设计应用平台的具体方案前，我们还需要就业务流程，预先考虑几个问题: 1.平台需要与不同的网关以不同的协议连接，而且也存在版本升级的问题。所以与网关的接口模块是组件化的，可以按需要动态加载。 2.应用模块与接口模块之间存在一对多的关系。不可能为不同的网关/协议定制不同的应用。所以应用与接口之间必须是无关性的

9、，即：应用无需了解接口的属性，反之也一样。 3.应用的个数、种类是多变的。所以应用模块也是组件化的，可按照一定的规那么挂接或脱离。同时应用也有可能由合作者提供，所以应用的对外接口也是需要的。 4.同时下行的信息可以按照不同的规那么路由到指定的网关。上行信息也需要路由到指定的应用。而这些动作不应当由接口或网关承当。 5.对于不同的网关及应用都需要分别做计费、统计、日志管理。以满足与运营商核对账单，与应用的合作者提供分账的明晰。 以上列出的仅仅是核心的问题，在充分理解的根底上，我们需要借用SoftEngine的体系结构以及设计理念，得出成熟的解决方法。同时平台的体系结构也逐渐随着问题的解决，慢慢明

10、朗。 3.3移动应用平台的结构体系 首先，让我们从宏观上看看平台是如何工作、提供效劳的。如下列图： 图表(tbio)3 MAP-Mobile Application Platform移动应用(yngyng)平台(Mobile Application Platform，以下(yxi)简称平台)，主要(zhyo)的使用角色只有两种： 注册(zhc)用户(Subscriber)，是平台的受众群体。通过各种移动设备使用平台所提供的多种应用。WWW效劳做为辅助工具，方便了注册用户的订阅、点播及了解更多的应用信息。 管理维护人员(Administrator)。平台需要日常的管理和维护，除了通过专有通讯方式

11、外，WWW效劳是必不可少的、实用的手段。这里的管理人员包括：系统配置人员、应用配置人员、内容管理人员、内容发布编辑内部/外部、客服人员、计费统计人员。大局部人员都可以通过，WWW效劳完成各自的任务。 所以，平台以移动应用系统Mobile Application System，简称MAS为主体，WWW效劳为辅助工具，数据库存放平台所需的各种数据。 移动应用系统(MAS)。几乎所有的移动应用都由MAS完成。MAS完全基于上文介绍的分布式开发系统 SoftEngine的体系结构，并继承了SoftEngine的所有特性，包括：应用的组件化、数据平安性、以及内部组件可根据负载压力的分布处理。同时利用So

12、ftEngine提供的Web方式对外接口 WebPostTaskServe实现与WWW应用的结合，如：网上收费应用等。也为内容应用第三方合作者提供了便利的接口。MAS最主要的接口是与不同移动运营商网关的连接，被定义为网关适配器Adapter for Gateway。 WWW效劳。除了为注册用户提供辅助功能，还可以为系统人员提供管理工具。包括的功能参见上述两个角色的描述。 数据库。MAS运行，可以不需要数据库的辅助。但为了对系统管理的方便，以及应用内容的有效管理，我们还是参加了数据库。存放的数据包括：系统配置数据、应用配置信息、注册用户信息、应用内容等。 从上图，可以看出：在移动应用平台的三个组

13、成局部中，MAS是结构中的关键。它的特性决定了，平台的优略。普通的设计，很难处理在本文开始所提到的三个难点。只有从根本上，采用上一章节介绍的分布式的体系结构来解决。所有我们将重点介绍MAS的内部结构。3.4移动(ydng)应用系统MAS的设计(shj) 在上文的 “应用(yngyng)平台根底(gnd) SoftEngine的结构(jigu)体系，我们已经对分布式系统有了初步的认识。MAS完全以SoftEngine为根底，继承了所有的组件化、分布式等体系结构特点，所以在MAS的设计工作中，已无须对其根底结构过多地考虑。在充分了解移动业务及其中需要关心的问题后，我们可以按照SoftEngine的

14、开发流程，直接设计MAS的工作流程，然后定义完成工作所需对象组件(Object Component)。由于篇幅的限制，先从整体上描述MAS的组件结构，然后着重介绍其中一个主要的工作流程。从中体会到组件化设计的乐趣。 3.4.1MAS的组件结构图 先来看看被定义好的MAS是什么样子，如下列图： 图表(tbio)4 MAS组件(z jin)结构图MAS虽然包含许多对象和组件，但这些对象可以按照功能的不同，分为五类：与移动网关连接(linji)的适配器组件；负责转换不同协议的信息转换组件；包含所有应用的组件群；日志纪录、资费统计的计费组件；以及可作为MAS与WWW应用、外方合作接口(ji ku)的通

15、讯组件。这样，MAS的结构(jigu)就比拟简单清晰了， 以下分类介绍。 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)，通