很土的话题，但是最近帮朋友做这个东西，所以写点东西出来给初学者参考。
一、准备资料
SP开发资料网站上有很多，但是主要是以下几个文档：
1、MISC1.6 SP订购通知接口要求
2、ＳＭＰＰ协议
3、MISC系统短信SP接入培训(精简版).ppt
4、DSMP规范中的SSO平台接入规范详细说明 v1.5.1.pdf
5、可供SP查看的错误代码
6、DSMP规范中的SSO平台接入规范.pdf
7、互联网短信网关接口协议V3.0
二、短信业务分类
短信业务主要分2种，一种是点播业务，另外一种是定制业务
1、点播业务
其service_id前面没有-号,例如YLSH
说明：计费代码，和service_id就是一个东西
手机用户有发送过信息，sp才能下发信息，移动根据一个上行分配一个linkid，在一定的时间内sp可以给他下发信息，可以下发多条信息，但是每条的信息都是同一个linkid
，一个linkid可以带一个计费代码（这个是在移动申报的，凭这个代码扣费，1元或者2元或者N元）
例如手机13912345678 发了一个上行信息A，该指令是在移动申报过的，misc平台通过他，则分配一个linkid返回给sp，sp根据指令A来判断用户用了什么业务，然后给用户下
发信息，下发信息一定要带上lingkid和计费代码，否则不能下发，例如下发3条，每条信息的linkid和计费代码都是一样的（因为用户只有一个上行指令），所以其实虽然sp发了3
条，只能扣到一条的费用。带linkid和计费代码只是为了保证信息的成功下发的一个参数。所有的业务都是这样，点播，以及后面说的定制
2、定制业务：
其service_id前面有-号，例如-YLQTYX
手机用户发送过一次信息，经过misc鉴权，承认他愿意使用定制业务，则将他列为定制用户，之后，哪怕用户没有发过信息，sp也可以主动给他发信息，此时就没有分配
linkid了，只是service_id，也就是计费代码，每次下发信息都必须带上这个service_id才可以。
他还分两小类
1）、定制按条
sp可以给有定购关系的用户下发信息，用户每收到一条，就按照service_id标明的资费扣费，一个月，最多扣用户10元，超过10元的部分，还是需要带service_id下发，只是
移动不再扣费（该部分，sp不需要管）
2）、包月业务
sp可以给有定购关系的用户下发信息，所有的信息都要带service_id下发，扣费由移动发起，sp不管。
三、开发技术
只要满足第一点的协议和规范要求，用目前流行的开发语言和数据库等都可以做。
1、主要关键的是网络编程，和SOAP的编程
2、相关名词解释
MISC(Mobile Information Service Center移动信息服务中心)是一个完全符合中国移动数据业务管理平台技术规范（DSMP）的数据运营平台，它完成数据业务的业务管理和控制功
能，实现用户管理、业务管理和SP管理，对外提供开放的、标准统一的Web Service接口，并可以为各个业务网关、SP提供代计费。
ＳＭＰＰ接口协议最初由ＥＴＳＩ收录在 ＧＳＭ０３.３９规范中，描述了短消息中心与短消息实体之间通信交互的协议关系及数据传输格式，本规范对ＳＭＰＰ接口协议的描述
主要面向简单的通信交互，制定规范的厂家将其协议版本号定为Ｖ３.３０；后由ＳＭＰＰ开发者论坛将协议版本向前演进为Ｖ３.４０，ＳＭＰＰ Ｖ３.４０协议规范完全兼容Ｇ
ＳＭ ０３.３９协议标准。本规范中，所采用的短消息中心设备与短消息股票交易业务处理平台之间的接口采用ＧＳＭ０３.３９ Ｖ３.３０协议规范，如无特殊说明全部以此协
议规范为准。ＳＭＰＰ协议可以以ＴＣＰ／ＩＰ或Ｘ.２５作为底层通讯承载。
ISMG Intenet Short Message Gateway 互联网短信网关
DSMP Data Service Manage Platform 数据业务管理平台
SMPP Short Message Peer to Peer 短消息点对点协议
CMPP China Mobile Peer to Peer 中国移动点对点协议
CMPP协议主要提供以下两类业务操作：
（1）短信发送（Short Message Mobile Originate，SM MO）
详细的流程请参考《移动梦网短信业务信令流程规范V3.0.0》；
（2） 短信接收（Short Message Mobile Terminated，SM MT）
详细的流程请参考《移动梦网短信业务信令流程规范V3.0.0》；
SMSC Short Message Service Center 短消息中心
GNS Gateway Name Server 网关名称服务器（汇接网关）
SP Service Provider 业务提供者
ISMG_Id 网关代码：0XYZ01~0XYZ99，其中XYZ为省会区号，位数不足时左补零，如北京编号为1的网关代码为001001，江西编号为1的网关代码为079101，依此类推
SP_Id SP的企业代码：网络中SP地址和身份的标识、地址翻译、计费、结算等均以企业代码为依据。企业代码以数字表示，共6位，从“9XY000”至“9XY999”，其中“
XY”为各移动公司代码
SP_Code SP的服务代码：服务代码是在使用短信方式的上行类业务中，提供给用户使用的服务提供商代码。服务代码以数字表示，全国业务服务代码长度为4位，即“1000
”－“9999”；本地业务服务代码长度统一为5位，即“01000”－“09999”；信产部对新的SP的服务代码分配提出了新的要求，要求以“1061”－“1069”作为前缀，目前中国移
动进行了如下分配：
1062：用于省内SP服务代码
1066：用于全国SP服务代码
其它号段保留。
Service_Id SP的业务类型，数字、字母和符号的组合，由SP自定，如图片传情可定为TPCQ，股票查询可定义为11
DSMP 数据业务管理平台
SSO Single Sign On，单点登录
HTTP Hyper Text Transfer Protocol，超文本传输协议。
HTTPS Hyper Text Transfer Protocol over Secure Socket Layer，基于安全套接字层的超文本传输协议。
ICP Internet Content Provider，因特网内容提供商
WWW World Wide Web
XML eXtensible Markup Language，可扩展标记语言
Session 是指HTTP 访问过程中的一个完整会话过程
互联网短信网关（ISMG）是业务提供商（SP）与移动网内短信中心之间的中介实体，互联网短信网关一方面负责接收SP发送给移动用户的信息和提交给短信中心。另一方面，移动
用户点播SP业务的信息将由短信中心通过互联网短信网关发给SP。另外，为了减轻短信中心的信令负荷，互联网短信网关还应根据路由原则将SP提交的信息转发到相应的互联网短
信网关。互联网短信网关通过向汇接网关（GNS）查询的方式获得网关间的转发路由信息。
另外，ISMG还必须与数据业务管理平台DSMP进行连接，在业务流程中对用户、业务以及定购关系等进行鉴权并对业务进行批价。
3、接口命名规范
接口名称采用单词首字母大写，其他字母小写的方式。缩略语中的字母都大写；接口参数和消息内
容定义中，基本数据类型的字段命名规范采用单词首字母大写，单词间没有连接符的方式；对于缩写单
词，例如ID，URL、ICP、MSISDN 等，将统一采用大写。
SSO 平台实际上是用户归属地DSMP 的一部分功能。用户登录时都需要重定向到归属地DSMP 的用户自服务门户上，无论全网SP 还是本地SP，都是到用户归属地的SSO 平台做用户登
录，并且完成Session 的管理，用户订购的信息是存储在归属地DSMP 平台的，用户认证由归属地DSMP 完成。因此，SP 需要与接入地的SSO 平台连接，以便完成Session 的管理。
同时，在各个SSO 平台之间，也需要有一套机制管理和同步相互间需要的用户数据，以保证用户数据在任何SSO 平台上都可以得到。为实现这个要求，建议采用集中控制、各点按
需同步的方式实现，也就是在整个DSMP 部署架构中存在一个统一的中央节点，集中存放所有已登录的用户数据，各省的SSO 平台在用户需要登录时通过将用户重定向到中央SSO 平
台完成登录操作。具体流程参见下文中的用户登录、业务订购/点播和用户签退流程说明。
四、相关数据说明
1、SyncOrderRelationReq
<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
<TransactionID xmlns="
http://www.monternet.com/dsmp/schemas/">00110338785301</TransactionID> 该消息编号
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<SyncOrderRelationReq xmlns="http://www.monternet.com/dsmp/schemas/">
<Version>1.5.0</Version> 该接口消息的版本号
<MsgType>SyncOrderRelationReq</MsgType> 消息类型
<Send_Address> 发送方的地址
<DeviceType>0</DeviceType> 设备类型0：DSMP
<DeviceID>0011</DeviceID> 设备编号
</Send_Address>
<Dest_Address> 接收方的地址 使用用户标识当使用用户和计费用户为同一用户的时候，FeeUser_ID和DestUser_ID的值相同。
<DeviceType>400</DeviceType> 设备类型400：SP
<DeviceID>0</DeviceID> 设备编号
</Dest_Address>
<FeeUser_ID> 计费用户标识
<UserIDType>1</UserIDType> 用户标识类型1：用手机号标识
<MSISDN>13912345678</MSISDN> 用户手机号
<PseudoCode></PseudoCode> 用户伪码
</FeeUser_ID>
<DestUser_ID> 使用用户标识
<UserIDType>1</UserIDType> 用户标识类型1：用手机号标识
<MSISDN>13912345678</MSISDN> 用户手机号
<PseudoCode></PseudoCode> 用户伪码
</DestUser_ID>
<LinkID>SP</LinkID> 临时订购关系的事务ID
<ActionID>2</ActionID> 服务状态管理动作代码，具体值如下：1： 开通服务；2： 停止服务；3： 激活服务；4： 暂停服务；
<ActionReasonID>1</ActionReasonID>
ActionReasonID:产生服务状态管理动作原因的代码，具体值如下：1：用户发起行为产生服务状态管理动作原因的代码，具体值如下：
1：用户发起行为
2：Admin&1860发起行为
3：Boss停机
4：Boss开机
5：Boss过户
6：Boss销户
7：Boss改号
8：扣费失败导致的服务取消
9：其他
<SPID>419613</SPID> SP的企业代码
<SPServiceID>-LTYLBY</SPServiceID> SP中该服务的服务代码，标示每一种业务的内容，并也叫计费代码，业务代码
<AccessMode>3</AccessMode> 服务的访问方式3：SMS 2：WAP 1：WEB
<FeatureStr>MTA2NjIxNDQgVERBRA==</FeatureStr> 服务订购参数,用BASE64编码
</SyncOrderRelationReq>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
2、SyncOrderRelationResp
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">
<SOAP-ENV:Header>
<dsmp:TransactionID xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">
<%=TransactionID %>
</dsmp:TransactionID> 该消息编号
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<dsmp:SyncOrderRelationResp xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">
<MsgType>SyncOrderRelationResp</MsgType>
<Version><%=Version %></Version> 该接口消息的版本号，本次所有的接口消息的版本都为“1.5.0
<hRet><%=hRet %></hRet>
</dsmp:SyncOrderRelationResp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
3、取消服务请求包
反向取消流程描述：
反向取消是从SP发起的取消流程，MISC在处理来自SP的取消消息的时候，其处理流程和来自其他网元的消息一样处理，流程如下：
（0） SP代替用户，向MISC发起反向取消请求UnSubscribeServiceReq并等待MISC处理；
（0） MISC对消息中的来源地址、企业代码进行鉴权，判断是否允许该SP进行反向取消；
（0） 接入鉴权成功后，再进行用户鉴权和订购关系鉴权，判断用户状态是否正确以及是否存在订购关系；
（0） 上面鉴权成功后，MISC向SP发送订购关系同步请求包SyncOrderRelationReq；
（0） SP收到同步请求后，对订购请求做相应的取消处理，并返回订购关系同步应答SyncOrderRelationResp；
（0） MISC收到应答后，判断应答值是否为0。如果应答值为0，则在MISC中取消订购关系，并给SP返回成功的反向取消处理应答包UnSubscribeServiceResp；如果应答值不为0，则
不取消订购关系，同时给SP返回不成功的反向取消应答包UnSubscribeServiceResp；
（0） SP如果收到MISC的错误响应，则说明取消失败，SP必须对这个失败消息做相应处理，比如把已取消的订购关系恢复等等；
（0） 如果收到MISC的正确响应，则SP可以不做任何处理；
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" SOAP-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns="http://www.monternet.com/dsmp/schemas/">
<SOAP-ENV:Header>
<TransactionID xmlns="http://www.monternet.com/dsmp/schemas/" xsi:type="xsd:string">9130020301801050</TransactionID> 该消息编号
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<UnSubscribeServiceReq xmlns="http://www.monternet.com/dsmp/schemas/">
<Version>1.5.0</Version>
<MsgType>UnSubscribeServiceReq</MsgType> 消息类型
<Send_Address> 发送方的地址
<DeviceType>400</DeviceType>
<DeviceID>913002</DeviceID>
</Send_Address>
<Dest_Address> 接收方的地址
<DeviceType>0</DeviceType>
<DeviceID>0024</DeviceID>
</Dest_Address>
<FeeUser_ID> 计费用户标识
<UserIDType>1</UserIDType> 见下面的定义
<MSISDN>13805002424</MSISDN> 用户手机号
<PseudoCode />
</FeeUser_ID>
<DestUser_ID> 使用用户标识当使用用户和计费用户为同一用户的时候，FeeUser_ID和DestUser_ID的值相同。
<UserIDType>1</UserIDType>
<MSISDN>13805002424</MSISDN>
<PseudoCode />
</DestUser_ID>
<Service_ID> 服务标识
<ServiceIDType>1</ServiceIDType>
<SPID>913002</SPID>
<SPServiceID>-TQAAU</SPServiceID>
<AccessNo />
<FeatureStr />
</Service_ID>
<FeatureStr />
</UnSubscribeServiceReq>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
取消服务回应包
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">
<SOAP-ENV:Header>
<dsmp:TransactionID xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">9130020301801050</dsmp:TransactionID>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<UnSubscribeServiceResp xmlns="http://10.1.2.122/misc/dsmp.xsd">
<Version>1.5.0</Version>
<MsgType>UnSubscribeServiceResp</MsgType>
<hRet>0</hRet> 返回值:见下文定义
</UnSubscribeServiceResp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
4、返回值定义
在HTTP 通信时的状态码请参见HTTP/1.1 协议中规定的状态码值，不包含在本
规范的返回值统一定义中。
具体描述如下：
0 ： 成功
1 ： 未知错误
2-99：保留
4000－4999 为MISC 与SP 之间的接口消息中的错误代码：
4000： 无效的msgtype
4001： 无效的action_id；
4002： 无效的action_reasonid；
4003： 无效的SP ID
4004： 无效的serviceID
4005： 无效的pseudocode
4006： 无效的accessmode
4007： MISC 同步开通服务,但SP 端已存在订购关系,且状态为开通
4008： MISC 同步开通服务,且SP 端不存在订购关系,但开通服务失败
4009： MISC 同步开通服务,但SP 端已存在订购关系, 且状态为暂停
4010： MISC 同步停止服务, 且SP 端存在订购关系, 但取消服务失败
4011： MISC 同步停止服务, 但SP 端不存在订购关系
4012： MISC 同步暂停服务, 且SP 端存在订购关系, 但暂停服务失败
4013： MISC 同步暂停服务, 但SP 端不存在订购关系
4014： MISC 同步暂停服务, 但SP 端已存在订购关系, 且状态为暂停
4015： MISC 同步激活服务, 但SP 端已存在订购关系, 且状态为开通
4016： MISC 同步激活服务, 但SP 端不存在订购关系
4017： MISC 同步激活服务, 且SP 端存在订购关系, 但激活服务失败
9000-9999 为系统级错误：
9000： 系统磁盘读写错误
9001： 网络异常
9002： 网络错误
9003： 业务网关忙，业务网关缓存
9004： 业务网关忙，并且业务网关缓冲区满，MISC 缓存，并暂时不要发送消息，
等待一段时间重试。
9005： MISC 忙，MISC 缓存
9006： MISC 忙，并且MISC 缓冲区满，业务网关缓存，并暂时不要发送消息，等待一段时间重试。
9007： 业务网关超过限制的流量
9008： MISC 异常，并不可用
9009： 业务网关异常，并不可用
9010： 该业务网关没有权限调用该接口消息
9011： MISC 没有权限发送该接口消息给业务网关
9012： 版本不支持
第 6 页
MISC SP 业务反向接口
9013： 消息类型不对，系统不支持
9014： 验证错误，无法解析SOAP 和XML 结构、缺少必须存在的字段，或者消息,格式不正确
9015： 拒绝消息，服务器无法完成请求的服务
5、DeviceType 定义
设备类型
0：DSMP
100：ISMG
101：WAP SP PROXY
1XX：其他业务网关
200：WAP PORTAL
201：WWW PORTAL
202：VOICE PORTAL
203：PDA PORTAL
2XX：其他门户
300：MMSC
301：KJAVA SERVER
302：LSP
3XX：其它应用平台
400：SP
6、DeviceID 定义
设备编号，设备编号采用各设备的入网编号，例如短信网关使用网关ID、对SP使用其企业代码，该设备编号由DSMP分配，并且在同一设备类型中该编号唯一
7、UserIDType 定义
用户标识类型
1：用手机号标识
2：用伪码标识
3：两者同时标识
8、SPType
SP业务种类
1：所有的SP
2：提供短信服务的SP
3：提供WAP服务的SP
4：提供MMS服务的SP
5：提供KJAVA服务的SP
6：提供MAIL服务的SP
7：提供LBS服务的SP
8：提供WWW服务的SP
9~：扩展
9、ServiceIDType
服务类型的标识方式：
1：SPID+SPServiceID
2：AccessNo+FeatureStr
五、MISC对MO的业务匹配处理流程说明
处理说明：
1、 SP进行业务申请时，按照不同的业务类型填写业务指令，根据业务类型的不同，可能存在“订购指令、取消指令、点播指令和普通MO”4种指令模式，设置指令时，需要指
定指令对应的发送号码（长号码）和指令内容，并可分别指定对发送号码和指令内容是否需要做精确匹配。
精确匹配的意思是指只有当所匹配内容和所设置的指令需要完全相同（包括长度也一样）时，才算匹配。例如如果设置了发送号码为“800101”，则只有当用户发送一条MO到
“80010123”时，将不会匹配上“800101”的那条指令；只有发往“800101”的指令才会被匹配上。
【注】对于同一种指令模式，每个服务可以设置多条，例如一个服务可以设置5条订购指令和5条取消指令，目前MISC可以支持超过5条的指令，但是从方便管理的角度考虑，对于同
一条模式的指令，建议SP设置时不要超过5条。
2、 用户的MO短信由两部分构成：发送号码和发送的内容，再加上业务申请时设置的匹配模式，这三样共同构成了匹配时的依据。
3、 当一条MO到MISC进行鉴权时，MISC先对发送号码（长号码）进行匹配，按照最大匹配+精确匹配的原则进行。如果有匹配成功的，则取出对应业务代码和指令类型；如果匹
配不上，则鉴权失败，该MO将不能发给SP。
4、 在上一步匹配出来的列表中，再对指令内容进行匹配，也是按照最大匹配+精确匹配的原则进行。如果有能匹配上的结果，则取出对应的业务代码和指令类型；如果没有能
对应上的匹配结果，则取Service ID返回空值，同时通知短信网关将此条短信当作普通MO向SP转发。
5、 SP在填写MO定购指令是尽量避免有嵌套的指令（例如同时存在“888801”和“8888011”的AccessNO）。
6、 对于匹配成功的指令，MISC根据匹配出的指令的模式不同，处理方式如下：
? 对于订购指令，则MISC将检查该用户是否已订购该服务，如果没有订购，则MISC将会完成订购，同时会将用户MO中的内容通过用户订购关系数据同步接口（Provision接口
）传送给SP，在Provision接口中的FeatureStr字段中将会有用户MO的长号码和指令内容，长号码和指令内容之间将以空格符分隔。同时MISC会通知短信网关这是一条订购指令，短
信网关将不向SP转发该MO。
如果该用户已订购该服务，则对于包月类服务，MISC会将该MO当作普通MO向短信网关返回鉴权成功的结果，通知短信网关将此条短信当作普通MO向SP转发；对于定制包月类服务，
则MISC会将该MO当作点播类型的MO向短信网关返回鉴权成功的结果，通知短信网关将此条短信当作点播MO向SP转发。
? 对于取消指令，则MISC将检查该用户是否已订购该服务，如果已经订购，则MISC将会完成取消，同时会将用户MO中的内容通过用户订购关系数据同步接口（Provision接口
）传送给SP，在Provision接口中的FeatureStr字段中将会有用户MO的长号码和指令内容，长号码和指令内容之间将以空格符分隔。
如果该用户未订购该服务，则MISC会向短信网关返回鉴权失败，短信网关将不会向SP转发该MO。
? 对于点播指令，MISC需要先判断该业务是定制点播类业务还是普通的点播类业务
1） 对于定制点播类业务，需要判断用户是否已订购该服务，如果已订购，则MISC会生成临时订购关系（LinkID），同时向短信网关返回鉴权成功，并将LinkID返回给短信网
关，由短信网关将该MO作为点播MO向SP转发；如果用户未订购，则MISC只是简单向短信网关返回鉴权成功的响应，通知短信网关将此条短信当作普通MO向SP转发。
2） 对于点播类业务，则MISC会直接生成临时订购关系（LinkID），同时向短信网关返回鉴权成功，并将LinkID返回给短信网关，由短信网关将该MO作为点播MO向SP转发。
? 对于普通MO短信，MISC向短信网关返回鉴权成功的响应，通知短信网关将此条短信当作普通MO向SP转发。
范例说明：
seq AccessNO FeatureStr ANCheckFlag FSCheckFlag
1 8888 xw 1 0
2 888801 xw 0 0
3 888801 xw1 0 1
4 8888 01xw 1 1
5 8888 (null) 0 0 (HELP)
【注】AccessNO表示MO的发送号码
FeatureStr表示指令内容
ANCheckFlag表示对AccessNO是否使用精确匹配
FSCheckFlag表示对指令内容是否使用精确匹配
针对上面的设置，
用户发送 xw1到8888011我们匹配第3条记录
用户发送 xw01到888801我们将匹配到第2条记录(先最长匹配接入号)
用户发送01xw到888802我们匹配到第5条记录（不会匹配到第4条记录，因为第4条记录的AccessNO是精确匹配）
用户发送01xw到8888我们匹配到第4条记录
用户发送 xw01到8888我们匹配第1条记录
用户发送 A到8888我们匹配第5条记录,
六、业务指令举例
业务类别 业务名称 IOD PUSH STK 产品描述
业务代码 点播指令 计费类型 价格 返回条数 业务代码 计费类型 价格 发送频率 业务代码
计费类型 价格 返回条数
应用服务 哈妮 HY 发自然语句到XXX 包月 5元 1 通过自然语言和虚拟主
持“哈妮”交流
聊天 帅哥靓妹 LT 发A到XXX 按条 0.2元 1 用户注册分配ID号，通
过ID号找聊友匿名聊天交友
测试 其实不懂你的心 CS 发P到XXX 包月 7元 1 心理测试大全
游戏 风月俏佳人 JR 法M到XXX 包月 7元 1 恋爱角色游戏
游戏 非常告白 GB 法GB到XXX 按条 0.2元 1 ， 情感故事
测试 识情男女 NV 法NV到XXX 按条 0.2元 1 爱情测试游戏
传情语 鱼和水的故事 YS 法YS到XXX 按条 0.1元 1,2 传情语
测试 官运财运桃花运 YU 法YU到XXX 按条 0.2元 1 生日测试
游戏 女儿国 YG 法YG到XXX 按条 0.2元 1 新西游记角色游戏
游戏 向左走向右走 ZY 法ZY到XXX 按条 0.2元 1,2 漫画短信故事
游戏 心上人 XR 法XR到XXX 按条 0.3元 1 通过对方的留言，猜他的手机号
测试 星星知我心 XX 法XX到XXX 按条 0.2元 1,3 星座测试
易程 塔罗牌 TL 法TL到XXX 包月 7.0元 1,3 塔罗牌短信版
易程 姓名与人生 XM 法XM到XXX 按条 0.4元 1,4 姓名测试
游戏 前世今生 QS 法QS到XXX 按条 0.5元 1,4 生日游戏
——即只要是上面的字母开头的发送到相应端口开头的，移动都认为存在点播或者定制关系，具体怎么区别是什么业务，有provision接受到的包来处理，目前基本已经做到。
——由于移动已经没有免费代码，即原来的free等都不能使用，故不再有错误提示，如果已经设计有的，则是扣费信息；
——只要用户存在了定购关系，所有的下行都必须使用计费代码下行，定制业务则会扣费，包月业务用计费代码下发，则移动不会将其当作沉默用户
七、DSMP 平台Web Services 接口定义和SOAP 绑定
DSMP 平台Web Service 接口设计和开发准则
DSMP 规范中的所有Web Service 接口依据W3C 组织颁布的Web Services
Description
Language (WSDL) 1.1(2001/03/15)规范而设计和定义，并与WSDL 标准后续版本
中的相关规定
的保持一致性。所有采用DSMP 规范的产品的接口设计和开发应遵守以下原则：
接口中的所有消息及相关数据类型的XML 模式定义均应采用由本规范提供的
XML
模式定义，内容详见附录C。部署Web Service 时，所有由DSMP 定义的XML 模式
定义均被包含在dsmp.xsd 文件中，并以公开的URL 地址被引用。在WSDL 定义中
采用名为dsmp 的命名空间来限定， 在WSDL 定义中为
xmlns:dsmp=”http://www.monternet.com/dsmp/dsmp.xsd”，引用时采用dsmp:
前缀，例
如：
<MESSAGE NAME="SG.USERREGISTERREQ">
<part name="UserRegisterInput" type="dsmp:UserRegisterReqType"/>
</message>
附录为DSMP 规范定义了所有被引用到的类型和元素的命名空间及XML 模式，此命
名空
间作用范围涵盖所有WSDL 接口消息。SOAP 消息中命名空间的使用方法见第2 节
的举例说
第 V 页
明。
接口的WSDL 定义均应采用本规范提供的WSDL 定义，内容详见本附录的第3 节。
部署Web Service 时，所有WSDL 定义内容被包含在dsmp.wsdl 文件中，并以
公开的URL 被引用。按照WSDL 标准的规定，本规范接口的WSDL 定义主要包含
如下部分：
类型（Types）：本规范采用的是文件引用的方法，所有DSMP 规范定义的消息
类型被包含在dsmp.xsd 文件中；
消息（Message）：即在调用过程中产生的请求或响应的SOAP 封装里的消息
结构；
操作（Operation）：被本规范定义的Web Service 所支持的动作的理论描述；
端口类型（Port Type）：被终端所支持的一套操作的集合的定义；
绑定（Binding）：即SOAP 绑定的定义部分，按照WSDL1.1 标准，端口类型
被绑定到SOAP1.1 协议，因而，任何采用DSMP 规范的产品，无论采用何种
支持Web Service 的中间件平台或SOAP 专用程序来实现Web Service 接口，
或是调用Web Service 接口，均应支持对SOAP1.1 的绑定。例如对调用者而
言，只有向服务器端发送标准的SOAP 封装消息包，才能得到正确的返回，否
则均被视作调用格式错误；
端口（Port）：即实现接口的程序的网络地址的定义；
服务（Service）：即实现接口的一系列端口集。
SOAP 绑定原则
本规范定义的Web Service 接口与SOAP1.1 协议格式相绑定，所有请求和响应消
息均应采用SOAP 格式的消息封装，包含SOAP 封套(Envelope)，SOAP 包头
(Header)
和SOAP 包体（Body）三部分。对任何技术实现的调用者而言，发出的调用请求消
息均
须带有以上三部分内容，包头和包体消息结构中引用的类型均来自dsmp.xsd 中的
定义。
但在SOAP 包体中，如果按照规范定义某一参数为可选，则SOAP 消息中可不包含
标识
该参数的元素。返回的SOAP 消息结构同请求消息；
在本规范中，为支持事物处理而定义的TransactionID 参数被包含在SOAP 包头
中
传送，因而，本规范要求所有SOAP 消息均必须带有SOAP 包头，接口程序应根据
需要对SOAP 包头中的TransactionID 做相应的处理（用来标识事物或忽略）。
TransactionID 的产生规则是DeviceID+10 位的数字，该10 位数字从1 开始，
并且不足10 位的前补0。每次增长的步长为1，依次循环使用。
本规范遵循WSDL 标准，接口通讯层与HTTP1.1 协议的POST 和GET 绑定在一起。
按本规范规定，服务器和客户端之间均通过HTTP 的POST 方法来进行交互。与此
相关，HTTP 报文内容格式与MIME 格式绑定，例如Content-Type 为text/xml
等均遵循MIME 标准
以上是总结SMS开发经验所得的重点内容，由于是刚接触几个月，有很多细节不能包括，详细的内容可以察看相关的文档。还有理解上肯定存在很多误区，大家可以到我的BLOG交流
。欢迎转载，但注明出处。blog.csdn.net/cutemose
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=654922
