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

 　在上一篇协议篇里面，相信大家都对现有的移动运营商提供的短信网关协议有一定的了解。OK，那么我继续总结下去，开始和大家探讨一下如何基于这些网关协议开发短信系统，我在这里只是总结开发的思路，并不提供代码，因为具体到代码的实现就是各自的开发功力问题，不在技术总结的范围。不过，欢迎大家到SP论坛或者天堂鸟论坛来一起交流代码的实现。
 
  现在当SP向移动运营商申请接入后，移动运营商除了提供他们所采用的短信网关协议文档外，还会提供由短信网关厂家提供的，短信网关通信的开发包，也就是我们所说的API了。对于是否使用这些API就见仁见智了，因此对于单说实现短信网关协议从开发上有两种做法，一种就是完全基于别人提供的API来实现网关协议；另外一种就是自己根据网关协议文档，自行写代码实现。对于第一种方法，就是开发速度快，底层通信以及短信协议的实现都不用自己考虑，缺点就是经常会有一些小问题：比如，厂家提供的API有内存泄漏，又或者这些API提供的时候就缺少一些库文件，又或者在长时间运作后莫名其妙死掉等问题，而且处理这些问题自己都没有办法解决，只有等待厂家提供新版本的API。对于第二种方法就是优点就是自己对协议理解，实现都比较清楚，出了问题好找，对于要求性能高，稳定性好的SP建议采用该办法，而缺点就是开发的时间相对来说会比较长，而且在对于不同厂家提供的网关会有一些小的改动。比如中国移动的CMPP网关，对于由亚信提供的短信网关，则在协议实现的时候，MO和MT要分别建立连接，而对于华为提供的短信网关，则在同一个连接处理MO和MT。
 
  协议开发部分说完了，下面说说如何实现一个短信业务系统/平台。从简单的业务实现到复杂的运营商级的短信业务系统，实现上大致可以分为三类。
 
  第一类，简单业务型短信系统/平台，由于业务类型的简单或者单一，比如只是做群发，或者只提供某些简单的交互信息服务，实现的办法就是在实现短信协议的同时，把业务逻辑都编写到程序里面去。这样对于只是提供比较单一服务的SP就可以很方便实现自己的短信系统，当然啦，这样的系统对于扩展性来说是很不利的，所以极少采用这种方法进行开发；那么如果能够业务逻辑和短信协议的实现分开就可以更好地实现短信系统了，对于第二类短信系统就是基本解决了这样的问题。
 
  第二类，业务开发型的短信系统/平台，能够把业务逻辑和短信协议部分分开实现，采用一个短信服务号码，根据用户发送不同的短信代码来实现不同的业务，这样的系统是现有大部分SP都在使用的。其实现的办法是，对于短信的上行和下行有专门的协议实现程序，而收到以及要发送的信息通过数据库来做接口。对于业务逻辑的实现，就是通过专门编写业务实现模块的程序，或者直接利用数据库的存储过程来实现，业务模块通过查询数据库得到用户发送上来的MO信息，对该信息进行处理后，产生新的MT信息，并且写回数据库中，而短信协议模块则读取MT信息，把信息发送给用户。
 
  第三类，运营商级的短信综合业务二次开发平台，对于这一类的短信平台，它把短信协议的实现，数据库的访问，以及各种字符，数字，逻辑等运算都封装起来，用户在设计和实现新的业务流程的时候，只需要把要实现的流程图画好，就可以利用平台提供的二次开发环境，不需要复杂的编程就可以实现新业务，有些二次开发环境还是图形界面非常简单方便，开发者完全可以不需要任何写代码的基础。这一类的平台，还可以同时加载上千个流程，并且可以实时加载和卸载流程而不影响其他流程正常的服务。实现的方法是，整个系统分成三个部分，第一部分是短信协议实现部分，这部分和以上两类没有太大区别只是和业务模块是通过网络通信的方式实现；第二部分是业务逻辑解析模块，所有编写好的业务逻辑都在这个模块上加载，运行。这个模块实现的就是封装各种各样的资源操作，并根据业务逻辑来执行。这里一般对于业务逻辑的实现都是通过状态机的状态跳转方式实现；第三部分就是业务开发模块，也就是我们平常所说的短信流程，把业务逻辑解析的各种资源动作通过一个开发窗口提供给用户使用，并且进行编译，校验用户编写的流程是否正确。
 
  以上三类系统/平台的开发，对于第一类就不多说了，我们比较一下第二类和第三类的区别。第三类比第二类的好处在于，业务流程开发方便快捷，不需要专业的开发工程师就可以实现；在实现时候对于Session的控制简单；业务管理方便。而缺点则是前期的投入比较大，对于平台开发搭建的难度比较高。
 
  以上是我自己在短信技术开发思路上的一些总结，或者大家可能有其他不同的实现思路以及方法，欢迎大家一起探讨，谢谢！