移动应用平台(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是什么样子，如下图：
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开发中最重要的环节。现以短信的核心流程为例介绍。
上图，显示出短信笑话点播的工作流程：
●用户发送的点播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