SMS短信开发技术总结--协议篇　

现在提供短信服务的SP都需要接入到各个移动运营商，虽然作为短信来说是同过SMPP协议和移动的交换中心进行通信。但是为了提供信息服务，对各种业务进行业务管理，以及计费，因此每个移动运营商都开发了相应的网关协议，给SP做开发接口。因此这些网关协议就是做一次转换，把SP发过来的信息转换成 SMPP协议发送给交换中心，并且实现了计费以及业务的管理功能。

从现有的四个移动运营商来说，分别有四个不同的短信网关协议。中国移动（CMPP），中国联通（SGIP），中国电信（SMGP），中国网通（CNGP）。前两个运营商主要针对现在手机的用户，后两个运营商是针对小灵通的用户。对于这些不同的协议，由于不同地方的移动运营公司采用不同厂家的产品，因此，在实现的时候都会有一些小差异，这点要比较注意，否则比如中国移动的CMPP网关在华为网关能够跑的系统，不一定可以在亚信网关上直接用的。
下面就对现在的每个网关协议进行介绍。

首先，要说得是也是大家用得最多的中国移动的网关协议--CMPP，CMPP协议还在用得是有两个版本，一个是CMPP2.0，另外一个是 CMPP3.0。从SP接入到CMPP3.0开始，就是接入了卓望的MISC系统。单从协议上讲CMPP2.0和3.0之间的最大区别是3.0增加了 LinkID。然后在Fee_terminal_type，Dest_terminal_type以及Src_terminal_type增加对用户号码的定义，当这些用户号码类型为0：表示真实号码；为1：表示伪码。从增加的这些信息可以看到，第一，LinkID其实是一个临时的定购关系标识，也就是说对于点播类业务，SP的短信系统收到这个LinkID后，才能建立正常的定购关系，而发送的信息必须携带LinkID才可以成功收费，否则就会监权失败，信息发送不出去。这样就从技术上阻止了SP乱发收费信息；第二，用户号码类型，现在传给SP还是普通的手机号码，那么有了这个标识就是以后有可能发送上来的不是用户的手机号码了，而是一个普通的伪码，那么以后SP就不能获得最终用户的手机号码了。CMPP3.0除了协议方面的改进外，还把定购关系从SP方面剥离。以前CMPP2.0的时代，用户的定购关系由SP自行把握，因此很容易出现SP私自捆绑用户收费的现象，现在中国移动上了MISC1.6后，就把所有定购关系都放在运营商，而通过Provision的方式来和SP进行定购用户的同步，并且订购关系以运营商里面的数据为准，这也是从技术上杜绝了SP 自己管理的定购关系所出现的问题。

然后，介绍一下在手机方面的另外一个网关协议，中国联通的SGIP，SGIP和移动的CMPP一样都有两个版本，SGIP1.2, SGIP1.3。新旧版本之间的主要区别也是增加了LinkID项。并且对于各种不同的业务类型，如手机点播，网上点播等都参数都做了重新的调整。中国联通也上了一个类似移动MISC的管理平台，SP的各种业务监权也通过该管理平台审核。

最后，要介绍一下的就是小灵通方面的两个协议，一个就是中国电信的SMGP1.3协议，另外就是中国网通的CNGP1.0协议，这两个协议在最近的升级里面都采用了联通的办法，使用MMSP这样一套系统进行监权管理，对于点播业务来说，只有和服务代码相对应的字冠才可以正常收发信息。

以上是对现在运营商提供的短信协议进行简单的介绍，详细协议的内容，请到SP论坛关于SMS技术那里都可以找到。

SMS短信开发技术总结--开发篇　

在上一篇协议篇里面，相信大家都对现有的移动运营商提供的短信网关协议有一定的了解。OK，那么我继续总结下去，开始和大家探讨一下如何基于这些网关协议开发短信系统，我在这里只是总结开发的思路，并不提供代码，因为具体到代码的实现就是各自的开发功力问题，不在技术总结的范围。不过，欢迎大家到SP论坛或者天堂鸟论坛来一起交流代码的实现。

现在当SP向移动运营商申请接入后，移动运营商除了提供他们所采用的短信网关协议文档外，还会提供由短信网关厂家提供的，短信网关通信的开发包，也就是我们所说的API了。对于是否使用这些API就见仁见智了，因此对于单说实现短信网关协议从开发上有两种做法，一种就是完全基于别人提供的API来实现网关协议；另外一种就是自己根据网关协议文档，自行写代码实现。对于第一种方法，就是开发速度快，底层通信以及短信协议的实现都不用自己考虑，缺点就是经常会有一些小问题：比如，厂家提供的API有内存泄漏，又或者这些API提供的时候就缺少一些库文件，又或者在长时间运作后莫名其妙死掉等问题，而且处理这些问题自己都没有办法解决，只有等待厂家提供新版本的API。对于第二种方法就是优点就是自己对协议理解，实现都比较清楚，出了问题好找，对于要求性能高，稳定性好的SP建议采用该办法，而缺点就是开发的时间相对来说会比较长，而且在对于不同厂家提供的网关会有一些小的改动。比如中国移动的CMPP网关，对于由亚信提供的短信网关，则在协议实现的时候，MO和MT要分别建立连接，而对于华为提供的短信网关，则在同一个连接处理MO和MT。

协议开发部分说完了，下面说说如何实现一个短信业务系统/平台。从简单的业务实现到复杂的运营商级的短信业务系统，实现上大致可以分为三类。

第一类，简单业务型短信系统/平台，由于业务类型的简单或者单一，比如只是做群发，或者只提供某些简单的交互信息服务，实现的办法就是在实现短信协议的同时，把业务逻辑都编写到程序里面去。这样对于只是提供比较单一服务的SP就可以很方便实现自己的短信系统，当然啦，这样的系统对于扩展性来说是很不利的，所以极少采用这种方法进行开发；那么如果能够业务逻辑和短信协议的实现分开就可以更好地实现短信系统了，对于第二类短信系统就是基本解决了这样的问题。

第二类，业务开发型的短信系统/平台，能够把业务逻辑和短信协议部分分开实现，采用一个短信服务号码，根据用户发送不同的短信代码来实现不同的业务，这样的系统是现有大部分SP都在使用的。其实现的办法是，对于短信的上行和下行有专门的协议实现程序，而收到以及要发送的信息通过数据库来做接口。对于业务逻辑的实现，就是通过专门编写业务实现模块的程序，或者直接利用数据库的存储过程来实现，业务模块通过查询数据库得到用户发送上来的MO信息，对该信息进行处理后，产生新的MT信息，并且写回数据库中，而短信协议模块则读取MT信息，把信息发送给用户。

第三类，运营商级的短信综合业务二次开发平台，对于这一类的短信平台，它把短信协议的实现，数据库的访问，以及各种字符，数字，逻辑等运算都封装起来，用户在设计和实现新的业务流程的时候，只需要把要实现的流程图画好，就可以利用平台提供的二次开发环境，不需要复杂的编程就可以实现新业务，有些二次开发环境还是图形界面非常简单方便，开发者完全可以不需要任何写代码的基础。这一类的平台，还可以同时加载上千个流程，并且可以实时加载和卸载流程而不影响其他流程正常的服务。实现的方法是，整个系统分成三个部分，第一部分是短信协议实现部分，这部分和以上两类没有太大区别只是和业务模块是通过网络通信的方式实现；第二部分是业务逻辑解析模块，所有编写好的业务逻辑都在这个模块上加载，运行。这个模块实现的就是封装各种各样的资源操作，并根据业务逻辑来执行。这里一般对于业务逻辑的实现都是通过状态机的状态跳转方式实现；第三部分就是业务开发模块，也就是我们平常所说的短信流程，把业务逻辑解析的各种资源动作通过一个开发窗口提供给用户使用，并且进行编译，校验用户编写的流程是否正确。

以上三类系统/平台的开发，对于第一类就不多说了，我们比较一下第二类和第三类的区别。第三类比第二类的好处在于，业务流程开发方便快捷，不需要专业的开发工程师就可以实现；在实现时候对于Session的控制简单；业务管理方便。而缺点则是前期的投入比较大，对于平台开发搭建的难度比较高。