移动增值业务平解决实例.docVIP

移动增值业务平台解决实例 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 - 分布式体系结构。在一篇名为: 面向对象的分布式开发系统 - 理论篇 中有较详细的介绍。或查阅网站: , 获得更多信息，及下载相关软件。 3.移动增值业务系统的设计方案 以短信和彩信为主要业务模式，对移动增值业务做分析，设计方案。 3.1短信、彩信的业务流程 在前言中，已经描述了短信的业务模式。在此基础上，再来看看业务的流程，见下图: 图表2 非常类似Web应用，短信应用是由用