協議設計的總體說明
用戶的資金能夠在證券公司和銀行之間進行劃撥的前提是用戶必須在銀行和證券公司都擁有自己的帳號，比如在證券公司用戶需要有股票資金帳戶，在銀行需要有活期帳戶（只有活期存款可以隨時進行劃撥）。我們設計的協議不考慮這些帳號的開戶，即我們認為這些帳號是已經建立起來了。
我們設計的協議允許用戶既可以在銀行，也可以在證券公司辦理轉帳功能。只要這兩個機構已經連網並且用戶在這兩個機構都擁有自己的帳號。實際上，比如在銀行端,銀行會保存和該用戶活期存款帳號相關的所有信息，如果用戶需要在銀行端辦理轉帳功能，只要用戶能夠提供銀行活期存款帳號的號碼和正確的密碼，同時又能夠提供證券公司的資金帳號和密碼，系統首先會在本地查找該活期存款帳號是否存在，密碼是否相符，如果是的話，會判斷該活期存款帳號是否已經和用戶提供的證券公司的資金帳號相關聯，如果已經相關聯的話，就返回一個錯誤信息，表示用戶已經辦理過該業務。如果還沒有相關聯的話，銀行通訊服務器就會和證券公司的相關的通訊服務器相聯系，如果證券公司返回信息認為用戶提供的資金帳號和密碼都是正確的話，這樣就在銀行和證券公司的相關的數據庫中分別加上標志，來表明某個特定的資金帳號已經和某個特定的活期存款帳號相關聯。這樣，轉帳功能就建立起來了。同時，會隨機生成一個授權碼，該授權碼是用戶進行轉帳時所需要鍵入的密碼，用來表示用戶有權限執行這個操作。事實上，在證券公司端辦理轉帳功能的基本流程也和這個相類似。
當用戶已經辦理了轉帳功能以後，事實上，用戶可以自己通過浏覽器（需要支持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＜/長度＞
＜是否固定長度＞否＜是否固定長度＞
＜/數據項＞