XML的数据协议组成
|
名词 |
说明 |
|
md5 |
message-digest algorithm 5 |
|
http |
hypertext transfer protocol |
|
xml |
extensible markup language |
交易交互是以http协议作为数据传输协议，这里定义发起交易请求的一端为客户端，客户端需要以http post 数据流（非表单方式）的方式提交交易请求，如下所示：
假设有一个查询指定玩法可销售期信息的交易请求，那么http消息体的内容如下：
<?xml version=”1.0” encoding=”utf-8”?>
<message version="1.0">
<header>
<messengerid>20091113101533000001</messengerid>
<timestamp>20091113101533</timestamp>
<transactiontype>12002</transactiontype>
<digest>7ec8582632678032d25866bd4bce114f</digest>
<agenterid>889931</agenterid>
<source>ivr</source>
<username>张三</username>
<compress>DES</compress>
</header>
<body>
<elements>
<element>
<lotteryid>118</lotteryid>
<issues>1</issues>
</element>
</elements>
</body>
</message>
注：实际http传输中，对内容进行编码，编码字符集utf-8(这主要是考虑到AJAX传输过程是以UTF-8编码)。
开发过程中会遇到这种情况，明明已经发送数据到服务器了，可是服务器收不到数据，遇到这种问题时的处理办法是，查看一下发送程序代码，是否进行了如下设置：
‘content-type’, ‘application/x-www-form-urlencoded’
如果有，去除，或者修改成：
‘content-type’,‘text/xml charset=utf-8'
1.0、消息包
每一个请求/响应的消息包都是一个xml，包含消息头和消息体，对于不同类型的请求/响应，消息头的格式是相同的，而消息体会携带具体的类型的请求/响应信息。请参照下面的消息包格式定义。
<?xml version=”1.0” encoding=”utf-8”?> <message version="1.0"> <header> <messengerid>200911131015330000000001</messengerid> <timestamp>20091113101533</timestamp> <transactiontype>102</transactiontype> <username>张三</username> <digest>7ec8582632678032d25866bd4bce114f</digest> <agenterid>800001</agenterid> </header> <body> <elements> <element> < lotteryname >D11</lotteryname> <issue>2009111301</issue> </element> </elements> </body> </message>
整个消息包是一个xml字符串，首先声明xml的版本和编码，这里定义encoding为utf-8。在消息包元素message中声明了version属性，表示该消息包使用的数据通信协议的版本，当前为1.0
1.1消息头
消息头对于所有的交易请求以及对每个交易请求的请求/响应都具有同样的数据结构。请参照下面的消息体格式定义。
注：在后面对交易请求消息体的描述中不再重复说明消息头的结构。
<header> <messengerid>20091113101533000001</messengerid> <timestamp>20091113101533</timestamp> <transactiontype>102</transactiontype> <digest>7ec8582632678032d25866bd4bce114f</digest> <agenterid>800001</agenterid> <username>张三</username> <source>ivr</source> <ipaddress>33.22.11.22</ipaddress > <compress>DES</compress>加密用的标签：使用什么方式加密（DES） </header>
header 元素定义了消息头的数据结构，其中：
|
名称 |
类型 |
长度 |
描述 |
|
messengerid |
String |
20 |
消息编号，格式为 yyyymmddhh24miss+六位递增序号。注：在非大客户模式下，可以为空。 |
|
timestamp |
String |
14 |
格式为：yyyymmddhh24miss或者yyyy-mm-dd hh24:mi:ss |
|
transactiontype |
String |
3 |
交易类型，详见附件 |
|
agenteridid |
String |
6 |
代理编号 |
|
username |
String |
<16 |
用户账号 |
|
digest |
String |
32 |
对消息包的摘要，摘要算法为md5，摘要内容为（时间戳+代理密码+消息体） |
|
source |
String |
16<= |
用户操作终端来源，如：ivr,sms,web等。 |
|
ipaddressaddress |
String |
20<= |
对于digest部分，表中已经定义了需要对消息体的哪些部分进行摘要，这里需要进行更进一步的说明，其中：
l 代理商密码：彩票支撑系统会为每个投注代理商分配一个交易访问密码，这个密码不会在消息中直接传输。无论是投注代理商向彩票支撑系统发送消息还是彩票支撑系统向某个代理发送消息，都会使用投注代理商的密码来执行摘要。
l 消息体： 消息包中body元素部分，包含<body>与</body>。
假如一个数据包的格式如下：
<?xml version='1.0' encoding='utf-8' ?>
<message version="1.0">
<header>
<messengerid>200911131015330000000001</messengerid>
<timestamp>20091113101533</timestamp>
<transactiontype>12002</transactiontype>
<digest>7ec8582632678032d25866bd4bce114f</digest>
<compress>DES</compress>
<agenterid>800001</agenterid>
</header>
<body>
<oelement>
<errorcode>0</errorcode>
<errormsg>操作成功</errormsg>
</oelement>
<elements>
<element>
<lotteryid>118</lotteryid>
<lotteryname>双色球</lotteryname>
<issue>2012070</issue>
<lasttime>86400</lasttime>
</element>
</elements>
</body>
</message>
<?xml version="1.0" encoding="utf-8"?>
<message version="1.0">
<header>
<messengerid>20091113101533000001</messengerid>
<timestamp>20091113101533</timestamp>
<transactiontype>12002</transactiontype>
<digest>041a1f10e7cd9fe5531a61f8bdef5faa</digest>
<compress>DES</compress>
<agenterid>1000002</agenterid>
</header>
<body>HmtGfqfbbCvzJvIvv+HjhHmbzgj+JRAutc2wOfw9+rsKAEKJX79jf2chPUk9XZTaMYphue6K/FeOZ3BNFjdnPsPvvL/1/vA75iGWiU8zKDYa9/jKDwz3Rbe1X6m3hamZPMLXz7FSXnD/Ur/BTZqfmta+0yJuMPGcWQEFjVnO/10amdeXoQDJDjP9gmOWb7r7WiMcXRYTSTmH1F8a5a1tVXQnK6WU4fmDkCU1Yq+RAowxwAH9VzvZiOP8ISyCGHpYPCADWcvpE5RtH0Le674kW29XIisxTJvcVhuDDamnMa0=
</body>
</message>
那么，被摘要的字串应该是（假设投注代理商的密码为111111）
111111<body><oelement><errorcode>0</errorcode><errormsg>操作成功</errormsg></oelement><elements><element><lotteryid>D11</lotteryid><issue>2009111301</issue></element></elements></body>
注：被摘要的body元素部分应该保留消息字串中的所有格式信息，比如空格，回车符等。
1.2 协议中协议头使用说明
协议头中包含一些通用的信息，对于系统中不同的环节，有些协议字段可以不填，有些协议字段需要在应用服务器端填写后，发送到无纸化平台。
<header> <messengerid>200911131015330000000001</messengerid> <timestamp>20091113101533</timestamp> <transactiontype>102</transactiontype> <digest>7ec8582632678032d25866bd4bce114f</digest> <agenterid>800001</agenterid> </header>
对于：flash,ajax + js等客户端模式下，messengerid,digest，agenterid，username等字段是不需要填写的。这些信息可以在服务端由具体的服务平台进行被充填写。因为有些安全信息，是不能在用户的电脑上执行的。
附录A：DES数据加密
为了数据的安全，XML协议在传输过程中，可以使用加密处理。
1、 数据按照PKCS5规则进行补位.（缺7位补7个0x07，缺6位则补6个0x06，以次类推，如果正好8位，也需要补8个0x08）。
2、 实际加密模式选择DES-ECB。
3、 经过DES加密后的数据必须通过Base64编码转换为明文的字符串。
在XML约定协议的header部分中，增加一个标签compress，如：<compress>DES</compress>，DES标明为加密的类型，如下：
<?xml version=”1.0” encoding=”utf-8”?> <message version="1.0"> <header> <messengerid>200911131015330000000001</messengerid> <timestamp>20091113101533</timestamp> <transactiontype>102</transactiontype> <digest>7ec8582632678032d25866bd4bce114f</digest> <agenterid>800001</agenterid> </header> <body> <oelement> <errorcode>0</errorcode> <errormsg>操作成功</ errormsg > </oelement> <elements> <element> <lotteryid>d11</lotteryid> <issue>2009111301</issue> </element> </elements> </body> </message> 需要DES加密的数据： <oelement> <errorcode>0</errorcode> <errormsg>操作成功</ errormsg > </oelement> <elements> <element> <lotteryid>d11</lotteryid> <issue>2009111301</issue> </element> </elements> 加密后提交的数据包： <?xml version=”1.0” encoding=”utf-8”?> <message version="1.0"> <header> <messengerid>200911131015330000000001</messengerid> <timestamp>20091113101533</timestamp> <transactiontype>102</transactiontype> <digest>7ec8582632678032d25866bd4bce114f</digest> <agenterid>800001</agenterid> <compress>DES</compress> </header> <body> =xxxxdafdfdsafsa== </body> </message>
附录B：数据DES加密与MD5的双重性问题。
MD5是在DES加密前进行的，MD5签名使用的密钥是用的渠道的密钥，DES加密数据使用的密钥是当前用户的密码明文经过MD5处理后，生成的长度为32字节的十六进制字符串的前16个字符。
比如：一用户的密码明文为：1234567890，经过MD5处理后，则数据转成为：e807f1fcf82d132f9bb018ca6738a19f，则进行DES加密数据时，密钥为：e0fff2129b1c63a9。
附录C：GZIP压缩传输
手机客户端与中间件接口传输与接收数据，均需要进行GZIP压缩传输，减少数据库传输流量。