为了方便股民在他的股票资金帐户和银行帐户之间方便的进行资金的划拨，需要设计一个应用层协议来实现这个功能。一般都是基于TCP/IP协议设计高层的应用协议，并通过特定的应用程序实现这个功能。现在的实现都是基于客户/服务器模式来实现这个功能，证券公司做为客户端，而银行做为服务器端。这样，证券公司很大程度上只能选择一家银行来实现帐户的划拨，这样对于在其他银行开户的用户就相对不是很方便。
我们设计了一个通过WWW服务器之间的通讯实现转帐的协议体系结构，能够保证一个证券公司同时可以和多个银行进行交互，而同时，一个银行也可以同时和多个证券公司进行交互。
我们协议的设计是基于XML的标记模型（元素/属性）而建立的。我们的目的之一是建立一个和实现无关的通讯协议。每一个消息由一个有效的XML文档组成，在通讯的两端（银行和证券）通过发送和接收文档来进行交互。
实际上我们的协议是建立在HTTP基础上，是通过HTTP来进行传输的。我们采用的是HTTP的POST/Response机制。我们协议的本身没有考虑安全问题，因为W3C组织正在制定一些非常可靠的安全机制，我们的通讯安全完全可以通过这些机制来实现。同时加密也可以在传输层实现，比如通过SSL，PGP或者是S/MIME。通讯双方可以通过在通讯层使用证书的方法进行认证。
协议设计的总体说明
用户的资金能够在证券公司和银行之间进行划拨的前提是用户必须在银行和证券公司都拥有自己的帐号，比如在证券公司用户需要有股票资金帐户，在银行需要有活期帐户（只有活期存款可以随时进行划拨）。我们设计的协议不考虑这些帐号的开户，即我们认为这些帐号是已经建立起来了。
我们设计的协议允许用户既可以在银行，也可以在证券公司办理转帐功能。只要这两个机构已经连网并且用户在这两个机构都拥有自己的帐号。实际上，比如在银行端,银行会保存和该用户活期存款帐号相关的所有信息，如果用户需要在银行端办理转帐功能，只要用户能够提供银行活期存款帐号的号码和正确的密码，同时又能够提供证券公司的资金帐号和密码，系统首先会在本地查找该活期存款帐号是否存在，密码是否相符，如果是的话，会判断该活期存款帐号是否已经和用户提供的证券公司的资金帐号相关联，如果已经相关联的话，就返回一个错误信息，表示用户已经办理过该业务。如果还没有相关联的话，银行通讯服务器就会和证券公司的相关的通讯服务器相联系，如果证券公司返回信息认为用户提供的资金帐号和密码都是正确的话，这样就在银行和证券公司的相关的数据库中分别加上标志，来表明某个特定的资金帐号已经和某个特定的活期存款帐号相关联。这样，转帐功能就建立起来了。同时，会随机生成一个授权码，该授权码是用户进行转帐时所需要键入的密码，用来表示用户有权限执行这个操作。事实上，在证券公司端办理转帐功能的基本流程也和这个相类似。
当用户已经办理了转帐功能以后，事实上，用户可以自己通过浏览器（需要支持XML格式）自行进行资金帐户的划拨。在划拨的时候需要注意的是，只有帐户中的余额大于要划拨的款项的时候才能进行划拨。在满足这个条件的情况下，用户既可以把活期存款中的部分款项划拨到资金帐户中，也可以把资金帐户中的款项划拨到活期存款中。大大方便了用户资金的调度和操作。
我们设计的协议主要是针对证券公司的转帐服务器和银行的转帐服务器之间的通讯而言的，一个证券公司的转帐服务器可以和多个银行的转帐服务器进行通讯，而一个银行的转帐服务器也可以同时和多个证券公司的转帐服务器进行通讯。事实上，可以认为这些通讯服务器都是WWW服务器。
协议设计细节描述
下面我们具体描述协议的设计和相关的实现的细节：
协议包总体格式
首先我们来看整个通讯协议的总的体系结构：
＜ !ELEMENT 信息负载 （信息头，（请求信息|响应信息））＞
＜ !ATTLIST 信息负载
版本号 CDATA #REQUIRED
时间标签 CDATA #REQUIRED
＞
一条消息主要有三个元素组成：信息负载，信息头和请求信息或者是响应信息。信息负载是对这个数据包属性的描述，信息头用来表示信息的发送者和接收者，请求信息或者是响应信息是消息的主体内容。
信息负载包括两个属性：
版本号：用来表示通讯所使用的版本，必须保证通讯双方使用相同的版本号。这里我们设置为1.0
时间标签：用来表示该数据包发出的时间。实际时间标签的格式我们设定为：YYYY：MM：DDTHH:MI:SS,其中T是日期和时间的一个分隔标志符。比如：2000:03:01T10:22:33就是一个有效的时间标签。
下面是关于信息头的定义：
＜!ELEMENT 信息头(信息发送者,信息接收者)＞
信息头主要有两部分组成，信息的发送者和信息的接收者。用来表示消息的发出方和消息的接收方。消息发送发出方和接收方拥有相同的属性。它们的定义格式如下：
＜ !ELEMENT 信息发送者 EMPTY＞
＜ !ATTLIST 信息发送者
名称 CDATA #REQUIRED
发送者ID CDATA #REQUIRED
角色 （银行|证券）#REQUIRED
＞
＜ !ELEMENT 信息接收者 EMPTY＞
＜ !ATTLIST 信息接收者
名称 CDATA #REQUIRED
接收者ID CDATA #REQUIRED
角色 （银行|证券）#REQUIRED
＞
它们都拥有三个属性：其中名称是指消息发送方或者是接收方的名称，比如：工商银行上海市分行就是一个有效的发送方或者是接收方的名称。接收者ID是用来唯一的标识一个发送方或者是接收方，在实现的时候有两种机制。一种是简单的用URL作为对发送方或者是接收方的唯一标识。另外，可以对每一个发送方或者是接收方建立一个UUID，保证唯一的标识一个发送方或者接收方。角色是指消息发送或接收者的身份，是银行还是证券公司。
请求信息协议格式
下面我们来介绍信息的主体部分，首先我们介绍请求信息，以下是请求信息的定义：
＜!ELEMENT 请求信息 %交易形式＞
＜!ATTLIST 请求信息
请求信息ID CDATA #REQUIRED
＞
＜ !ENTITY %交易形式 "转帐开户+|转帐|交易查询+|交易管理|＞"
请求信息主要有转帐开户，转帐，交易查询和交易管理这四大块，这是和转帐业务相关的主要功能。请求信息只包括一个属性，就是请求信息的ID号，请求信息ID号在服务器A到服务器B的所有的数据包中必须是唯一的，即每一个数据包必须要有一个唯一的ID号。在一个数据包里面可以同时递交几个转帐开户申请，这就给实现带来了一定的灵活性。服务器可以迅速处理每一个用户的申请，也可以根据具体情况批量的进行处理。同时，服务器也可以同时递交多个交易查询。
转帐开户交易格式
我们首先来看转帐开户交易：
＜!ELEMENT 转帐开户 数据组＞
＜!ATTLIST 转帐开户
开户消息ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 （股民|储户|银行系统|证券系统） #REQUIRED
＞
转帐开户元素有三个属性：开户消息ID保证在所有一次递交的所有的开户申请业务中，每一个都有一个唯一的ID号。即必须保证该ID在一个包范围内的唯一性。交易代码是为了使机器能够更加方便的处理该业务。交易提出指明该业务是由谁触发的，是股民、储户、银行端的服务器系统还是证券端的服务器系统。
转帐业务包含了一个数据组，关于数据组的内容在下面还有详细的描述。这里，简单说明一下，数据组主要是用来表示在服务器之间进行和交易相关的业务数据的传递，比如资金帐号、交易金额等数据。
转帐交易格式
接下来我们来看转帐交易：
＜!ELEMENT 转帐 （资金帐户转出活期帐户转入+|
活期帐户转出资金帐户转入+|
交易结果查询+）＞
＜!ELEMENT 资金帐户转出活期帐户转入 数据组＞
＜!ATTLIST 资金帐户转出活期帐户转入
资金帐户转出活期帐户转入消息ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 （股民|储户） #REQUIRED
＞
＜!ELEMENT 活期帐户转出资金帐户转入 数据组＞
＜!ATTLIST 活期帐户转出资金帐户转入
活期帐户转出资金帐户转入消息ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 （股民|储户） #REQUIRED
＞
＜!ELEMENT 交易结果查询 （相关消息状态+）＞
＜!ATTLIST 交易结果查询
交易结果查询消息ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 (银行系统|证券系统） #REQUIRED
＞
＜!ELEMENT 相关消息状态 数据组＞
＜!ATTLIST 相关消息状态
请求消息的ID CDATA #REQUIRED
要查询的消息的ID CDATA #REQUIRED
＞
转帐交易是业务的核心，它实际上是处理在银行和证券之间的用户的资金的划拨，主要有两种模式，资金帐户转出活期帐户转入和活期帐户转出资金帐户转入。
我们来分析资金帐户转出活期帐户转入这种情况，当股民或者是储户提出转帐请求时，考虑一般性，我们设定是股民提出转帐请求，证券公司端的服务器将分析股民要求转帐的金额是否小于资金帐户的余额，如果成立的话，减少该资金帐户的余额，然后该数据包就发送到银行的服务器，银行的服务器如果能正确处理该条消息的话，就增加相关的活期存款的余额，并把操作成功的结果返回给证券方的服务器。
但是有可能证券服务器在发出了这个交易命令后收不到应答信息（可能是包丢失的原因）。正是因为这个原因，所以需要一个交易结果的查询。交易结果的查询可以同时查询多条已经发出但没有及时应答的那些消息。在相关消息状态元素中的那个属性：要查询的消息的ID就是没有得到响应的消息的ID号。请求消息的ID这个属性表示和该请求相关的请求包的ID号。这两个属性的组合唯一的决定了一条消息。比如证券服务器方发出了三条资金帐户转出活期帐户转入消息，但很久没有响应，就可以发出交易结果查询这个指令来向银行端服务器查该三条消息的执行情况。
交易查询格式
在分析了转帐交易以后，我们来分析交易查询的实现。交易查询的协议格式的定义如下：
＜!ELEMENT 交易查询 (当日交易明细查询+|
历史交易明细查询+|
活期帐户余额查询+|
资金帐户余额查询+)
＞
＜!ELEMENT 当日交易明细查询 数据组＞
＜!ATTLIST 当日交易明细查询
当日交易明细查询ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 股民|储户） #REQUIRED
＞
＜!ELEMENT 历史交易明细查询 数据组＞
＜!ATTLIST 历史交易明细查询
历史交易明细查询ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 股民|储户） #REQUIRED
＞
＜!ELEMENT 活期帐户余额查询 数据组＞
＜!ATTLIST 活期帐户余额查询
活期帐户余额查询ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 CDATA #FIXED "股民"
＞
＜!ELEMENT 资金帐户余额查询 数据组＞
＜!ATTLIST 资金帐户余额查询
资金帐户余额查询ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 CDATA #FIXED "储户"
＞
交易查询主要是由股民或者是储户发起的。主要有四种形式：查询当日交易明细，历史交易明细查询，活期帐户余额查询和资金帐户余额查询。其中如果用户是在证券那一端查询的话，如果查询当日交易明细，证券服务器就会和银行服务器通讯，银行服务器返回当日交易明细中的所有成功交易明细。如果用户是在银行那一端的话，就刚好相反。这样做的目的是保证用户看到的肯定是已经成功的交易。同时，如果用户在证券端查资金帐户余额和在银行端查询活期存款余额和本协议没有关系，因为都可以直接在本地服务器上找到。这里值得注意的是在一个数据包里面（实际上是一个XML文档）可以同时发送多个用户的请求。
交易管理格式
下面看交易管理的协议格式：
＜!ELEMENT 交易管理 (银行日终对帐|证券日终对帐|
封闭转帐交易功能|开放转帐交易功能|
修改授权码)
＞
＜!ELEMENT 银行日终对帐 数据组＞
＜!ATTLIST 银行日终对帐
银行日终对帐ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 CDATA #FIXED "银行系统"
明细文件 CDATA #REQUIRED
＞
＜!ELEMENT 证券日终对帐 数据组＞
＜!ATTLIST 证券日终对帐
证券日终对帐ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 CDATA #FIXED "证券系统"
明细文件 CDATA #REQUIRED
＞
＜!ELEMENT 封闭转帐交易功能 数据组＞
＜!ATTLIST 封闭转帐交易功能
封闭转帐交易功能ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 （股民|储户|银行系统|证券系统） #REQUIRED
＞
＜!ELEMENT 开放转帐交易功能 数据组＞
＜!ATTLIST 开放转帐交易功能
开放转帐交易功能ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 （股民|储户|银行系统|证券系统） #REQUIRED
＞
＜!ELEMENT 修改授权码 数据组＞
＜!ATTLIST 修改授权码
修改授权码ID CDATA #REQUIRED
交易代码 CDATA #REQUIRED
交易提出 （股民|储户） #REQUIRED
＞
因为在包传送过程中，有一些交易没有得到确认，所以必须在一天的业务结束后，银行和证券双方进行相互对帐。这是通过银行日终对帐和证券日终对帐两个消息来完成的。在日终对帐元素中包含一个属性为明细文件，实际上它是当日所有转出和转入的交易的明细所在的文件的名称。在具体实现的时候，系统可以根据这个属性通过FTP来得到该文件，以便银行和证券双方得到一个详细的交易明细互相进行对帐。用户、银行和证券三方都可以根据自己的特殊的情况要求暂时封闭转帐交易功能，也可以要求开放转帐交易功能。用户可以在系统工作时段要求更改授权码。
响应信息协议格式
证券方和银行方都可以向对方的服务器发出请求，然后接收请求的服务器在处理了该请求以后，向发出请求的服务器返回响应消息。
协议对请求的响应的协议格式定义：
＜!ELEMENT 响应信息(响应应答+)＞
＜!ATTLIST 响应信息
响应信息ID CDATA #REQUIRED
＞
＜!ELEMENT 响应应答 数据组*＞
＜!ATTLIST 响应应答
应答代码 CDATA #REQUIRED
应答代码描述 CDATA #REQUIRED
请求消息的ID CDATA #IMPLIED
相关消息的ID CDATA #IMPLIED
＞
每一个响应消息包都有一个响应消息ID用来唯一的标识该响应数据包。一个响应消息中可以包含多个响应应答。因为在一个请求包中可能包含多个请求，比如在一个要求转帐开户的数据包中可能要求同时对几个用户进行转帐功能的建立。所以需要同时对这几个请求消息进行答复。其中在响应应答元素中的应答代码，我们采用三位的数字字符。比如200表示消息成功处理。301表示活期帐号不存在等等。请求消息的ID就是那个请求数据包的唯一的标识号，而相关消息的ID就是指该数据包中的某一个特定的请求内容，比如请求对一笔资金帐户转出活期帐户转入的查询。其中数据组是指对该该请求相关的需要返回的数据项的一个集合。
数据组描述
下面我们定义了数据组和数据项的格式：
＜!-- 数据组描述 --＞
＜! ELEMENT 数据组 (数据项)+ ＞
＜!-- 数据项描述 --＞
＜ ! ELEMENT 数据项 EMPTY＞
＜ ! ATTLIST 数据项
数据元名称 CDATA #REQUIRED
类型 CDATA #REQUIRED
长度 CDATA #REQUIRED
是否固定长度 (是|否） #REQUIRED
数据元内容 CDATA #REQUIRED
＞
数据组由数据项组成，根据交易的特定，不同的交易请求包含不同的数据组，而对不同的交易的响应也包括不同的数据组。每一个数据项都定义了该数据项的名称，类型，长度，是否固定长度和数据项的实际的内容。
一个实际的交互例子
下面我们看一个股民开户的实际的一个交互过程的例子：
请求的数据包为：
＜?xml version="1.0"?＞
＜!DOCTYPE 资金划拨
SYSTEM "http://www.somestandard.org/银行证券信息交换协议.dtd"
＞
＜信息负载
版本号="1.0"
时间标签="2000-01-01T02:02:23"
＞
＜信息头＞
＜信息发送者
名称="Stock Corporation"
发送者ID="4af37b30-2c35-11d2-be4a-204c4f4f5020"
角色="证券"
/＞
＜信息接收者
名称="Bank Corporation"
接收者ID="3af37b50-2635-1172-b24a-26604f478021"
角色="银行"
/＞
＜/信息头＞
＜请求信息
请求信息ID="3434234334"＞
＜股民开户
开户消息ID="2342342334"
交易代码="1540"
交易提出="证券系统"
＞
＜数据组＞
＜数据项
数据元名称="资金帐号"
类型="数字字符"
长度="19"
是否固定长度="否"
数据元内容="000000000018"
＜/＞
＜数据项
数据元名称="资金帐号密码"
类型="二进制字符"
长度="8"
是否固定长度="是"
数据元内容="********"
＜/＞
＜数据项
数据元名称="证券公司代码"
类型="数字字符"
长度="6"
是否固定长度="是"
数据元内容="123111"
＜/＞
＜数据项
数据元名称="活期帐号代码"
类型="二进制字符"
长度="25"
是否固定长度="否"
数据元内容="2300232045018"
＜/＞
＜数据项
数据元名称="活期帐号密码"
类型="数字字符"
长度="8"
是否固定长度="是"
数据元内容="********"
＜/＞
＜数据项
数据元名称="银行代码"
类型="数字字符"
长度="6"
是否固定长度="是"
数据元内容="444222"
＜/＞
＜数据项
数据元名称="交易日期时间"
类型="数字符号字符"
长度="19"
是否固定长度="否"
数据元内容="2000-01-01T02:02:23"
＜/＞
＜/数据组＞
＜/股民开户＞
＜/请求信息＞
＜/信息负载＞
实际上该文档从证券服务器被发送到银行服务器上，如果银行服务器成功的处理了该请求，它返回的文档应该是如下的形式：
＜?xml version="1.0"?＞
＜!DOCTYPE 资金划拨
SYSTEM "http://www.somestandard.org/银行证券信息交换协议.dtd"
＞
＜信息负载
版本号="1.0"
时间标签="2000-01-01T02:03:45"
＞
＜信息头＞
＜信息发送者
名称="Bank Corporation"
发送者ID="3af37b50-2635-1172-b24a-26604f478021"
角色="银行"
/＞
＜信息接收者
名称="Stock Corporation"
接收者ID="4af37b30-2c35-11d2-be4a-204c4f4f5020"
角色="证券"
/＞
＜/信息头＞
＜响应信息
响应信息ID="4587874878"
＞
＜响应应答
应答代码="200"
应答代码描述 ="成功交易"
请求消息的ID="3434234334"
相关消息的ID="2342342334"
＞
＜数据组＞
＜数据项
数据元名称="授权码"
类型="数字字符"
长度="10"
是否固定长度="是"
数据元内容="0012300454"
＜/＞
＜数据项
数据元名称="交易日期时间"
类型="数字符号字符"
长度="19"
是否固定长度="否"
数据元内容="2000-01-01T02:03:45"
＜/＞
＜/数据组＞
＜/响应应答＞
＜/响应信息＞
＜/信息负载＞
主要数据项的内容
＜数据项＞
＜数据元名称＞资金帐号＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞19＜/长度＞
＜是否固定长度＞否＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞活期帐号＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞25＜/长度＞
＜是否固定长度＞否＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞授权码＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞10＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞交易金额＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞12＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞银行流水号＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞12＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞证券公司流水号＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞12＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞银行代码＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞6＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞银行名称＜数据元名称＞
＜类型＞数字字母符号字符＜/类型＞
＜长度＞50＜/长度＞
＜是否固定长度＞否＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞证券公司代码＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞6＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞证券公司名称＜数据元名称＞
＜类型＞字母数字字符＜/类型＞
＜长度＞50＜/长度＞
＜是否固定长度＞否＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞资金帐号密码＜数据元名称＞
＜类型＞二进制字符＜/类型＞
＜长度＞8＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞活期帐号密码＜数据元名称＞
＜类型＞二进制字符＜/类型＞
＜长度＞8＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞活期帐号余额＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞12＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞资金帐号余额＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞12＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞交易日期时间＜数据元名称＞
＜类型＞数字符号字符＜/类型＞
＜长度＞19＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞用户姓名＜数据元名称＞
＜类型＞数字字母字符＜/类型＞
＜长度＞12＜/长度＞
＜是否固定长度＞是＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞用户身份证＜数据元名称＞
＜类型＞数字＜/类型＞
＜长度＞18＜/长度＞
＜是否固定长度＞否＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞用户地址＜数据元名称＞
＜类型＞数字字母符号字符＜/类型＞
＜长度＞80＜/长度＞
＜是否固定长度＞否＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞用户电话＜数据元名称＞
＜类型＞数字符号字符＜/类型＞
＜长度＞14＜/长度＞
＜是否固定长度＞否＜是否固定长度＞
＜/数据项＞
＜数据项＞
＜数据元名称＞城市编号＜数据元名称＞
＜类型＞数字字符＜/类型＞
＜长度＞5＜/长度＞
＜是否固定长度＞否＜是否固定长度＞
＜/数据项＞
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
XML.ORG.CN讨论区 - XML技术 → 『 DTD/XML Schema 』 → 证券和银行之间转帐系统的设计
(订阅本版)
2005/1/21 10:25:00
新浪微博
证券和银行之间转帐系统的设计
