消息中心
1 系统结构
消息中心体系结构如下图所示：
图中红色线表示移动消息的推送路径。
此结构适用于企业消息中心，也适用于平台，消息推送代理的消息推送服务接口（Web Service）可以作为开放服务。
本地服务器是消息源。
新生成消息时，如果PC客户端在线，，则消息直接发送给客户端。否则，如果该用户启用了该应用的推送服务，都通过移动消息中心向移动客户端推送，无论移动客户端是否在线。
消息推送代理负责从消息存储库提取消息，根据用户的设备操作系统类型调用不同操作系统的消息推送服务提供者（Push Service Provider）。
图中标示了iOS和Andriod系统的推送服务提供者。
IOS Push Service Provider需要访问Apple的APNs。
消息推送服务接口是消息推送代理的接口，采用WebService实现。
应用服务器服务PC客户端和移动客户端，由本地消息引擎提供消息推送服务。需要推送到移动设备时，通过消息推送服务接口调用移动推送中心的服务。
本地数据库存储用户消息，和决定消息推送和移动推送的必要信息（设备信息，应用推送设置信息）。
2 移动推送中心
2.1 移动推送代理（Mobile Push Service Porter）
移动推送代理是移动消息推送中心的服务提供者。
接收到移动推送请求时,先保存在本地消息存储库中。写入后，唤醒后台服务执行推送。保存的目的有：
l 没有可用的Push Service Provider时，先保存然后等有可用的服务器时再执行发送
l 流量统计
推送时根据不同的操作系统类型，调用对应的PushService Provider服务。
移动推送代理与Push ServiceProvider之间通过网络通信（对于iOS和Andriod可以采用此方式）。
移动消息代理以Web Service方式提供服务。（采用gSOAP实现，参见WebSerice插件）
WebService插件（WSB-Web Service Box）的结构调整：
作为一个Web Service服务 容器，可以加载多个提供不同WebService的服务模块。chargeService（收费服务）是其中一个模块。
新增加push_notofication_Service服务（移动推送服务模块）。
2.2 推送服务提供者（Push Service Provider）
实际执行移动消息推送的服务器，iOS和Andriod分别实现。
每种系统的Push ServiceProvider可以单独建立集群。
l iOS
iOS系统的推送通知服务利用APNS（Apple-PNS:苹果推送通知服务）。
l Andriod
Andriod实现: XMPP协议
Android push notification(androidpn) 是一个基于XMPP协议的java开源实现，它包含了完整的客户端和服务器端。
3 本地消息引擎（NativeMessage Engine）
本地消息引擎结构如下图所示：
消息服务接口是外部访问本地消息引擎的API。
消息服务模块负责处理与消息相关的协议，消息存储库扫描，执行推送（直接到客户端或者调用移动推送模块）。
移动推送模块通过Web Service调用移动推送中心的推送服务（通过 IPushNotificationService接口）。
4 接口
4.1 本地消息引擎服务接口(IMessageService)
interface IMessageService { public: int Save(CMessage *msg); ///< 保存消息 int Query(CQueryCondtion &cond,vector
int Delete(__int64 object_id); ///< 删除指定的消息. };
|
4.2 消息推送服务接口（IPushNotificationService）
interface IPushNotificationService { public: int Send(CMobileMessage *msg); };
|
5 消息盒子
有三种类型消息盒子：
l 应用内置(Built-inMBox:B-MBox)：客户端进程的一部分，有2种使用方式：
n 客户端进程独享：外部不能访问
n 应用共享：不同的客户端应用可以通过消息盒子API访问（不支持）
l 独立消息盒子应用(ApplicationMbox:A-MBox)，为所有应用共享：
l 系统消息盒子(SystemMBox:S-MBox)：由操作系统提供，与App MBox类似，只是消息盒子的提供者不同。
可以设想存在A-MBox的第三方应用。目前，我们不打算使用，也不计划开发。
(PushMessenger大概可以归于这类应用，见http://push.since2006.com/)
B-MBox是本系统实现的目标，且只能在进程内使用。
消息盒子的结构如下图所示：
图中有3个组成部分：
l 消息盒子
l 客户端框架：消息盒子通过框架与服务器通信，接收并分派通知到消息盒子，通知消息的确认也是由消息盒子统一通过框架与服务器协作完成。客户端框架可以是PC客户端框架（ESE或者Hotfox），或者是移动客户端框架（UMDP）。
l 通知处理器：是消息盒子的使用者，负责具体的应用通知的处理。可以是一个窗口，插件，或者一个线程。
5.1 协议处理器
负责处理用户通知消息（680-Indication）。由客户端框架的协议分发器调度执行。
协议处理器在处理消息时，调用通知控制管理器的on_receive方法。
5.2 通知控制管理器
是消息盒子的核心。负责以下功能：
l 启动时从客户端sqlite数据库中加载缓存的消息类别信息，并负责版本比较和更新缓存
l 接受通知处理器的注册
l 接受外部指定的通知提示器
l 在on_receive函数中，在内存中组织通知，调用注册的通知处理器
l 提供通知管理功能：在窗口中显示接收到的通知，允许用户交互操作。
l 负责提示：调用应用指定的提示器，在接收到通知时提醒用户。PC端和移动端可以自定义提示器以满足不同设备和应用的需要。（选择一种提示器作为默认的内置提示器，如该提示器在PC上在托盘区提示，点击后弹出通知显示窗口，在存在多个通知时按消息类别分类显示，统计）