XML在金融行業中應用的問題分析

xml|問題

　　導讀-- XML以其開放、自描述、向前相容的特性逐漸成為資料交換的事實標準，並將觸角伸展到金融行業的不同領域，儘管道路不是很平坦，頗有些泥濘。

 　　XML以其開放、自描述、向前相容的特性逐漸成為資料交換的事實標準，並將觸角伸展到金融行業的不同領域，儘管道路不是很平坦，頗有些泥濘，但XML在金融業的應用依然向前。
　　漸行漸近的行業標準

　　目前，針對不同的金融應用領域已經出現了幾種不同的XML 格式。如Interactive Financial Exchange (IFX)和 Open Financial Exchange (OFX)標準，它們處理的對象是消費者和其他形式的小額銀行業務。

　　Financial Information eXchange (FIX)是作為產權交易資料的標準通訊協定出現的。SWIFT在加入 ISO 15022 XML 工作群組後，已經採用XML 作為主要的表示格式，並把它的曆史悠久的資料模型轉化成了 XML 形式。Financial Products Markup Language(金融產品標記語言，FpML)用於金融衍生市場事務，通常用於錯綜複雜的協商。eXtensible Business Reporting Language(可擴充商業報告語言，XBRL)，主要用於商業報告和資料的準備與交換。

　　上述這些標準都不能涵蓋所有的銀行業務。會計和審計制度的不同使這些標準很難應用在國內的金融行業。國內也缺乏專門的機構和人才對金融資料交換制定適合國情的，並具有一定權威性的標準，但是這些標準具有重要的參考意義不容忽視。

　　邁過五道坎

　　XML的誘惑已經使很多銀行和金融公司開始制定內部的XML標準用於資料交換和儲存。關於標記的制定、屬性值的枚舉、交易要素的多少、元素的細分等環節的隨意編寫也嚴重損害了XML的標準意義。不同銀行在相同領域使用不同的XML報文規範，以及同一個銀行內部不同系統之間使用不同的XML報文規範在很大程度上削弱了XML語言的開放性。

　　同時，在XML實際用於金融資料交換時要處理好以下五個問題，邁過這五道坎之後，XML將發揮出真正的實力。

　　1. DTD和Schema

　　為了說明XML詞彙表的文法規則，可以採用文件類型定義描述(DTD)。DTD使用正式的文法定義XML文檔的結構和允許值。通過建立DTD，能夠正式而精確地定義詞彙表，從而使解析器可以利用DTD驗證文檔執行個體的有效性和完整性。遺憾的是DTD的資料類型對XML檔案的約束顯得並不詳盡。例如，帳號和申請人的名字均被描述成#PCDATA(字串)。但是帳號是一個整數，還可能是一個32位長的整數。另一個遺憾是，DTD使用非XML檔案來描述XML檔案。使用XML Schema則可以在一定程度上解決上述問題。XML Schema是一個良好格式的XML檔案，提供了多種資料類型定義並允許對這些定義進行擴充、限制和組合以建立自己的複雜類型。但是需要注意的是XML Schema規範正在發展之中。

　　作為銀行跨系統的應用，使用DTD或XML Schema可以更好的表現和理解用於交換的XML文檔結構，並對XML文檔中的結構和內容錯誤進行指示。但是一般自訂的XML報文均缺少DTD或XML Schema定義，文檔規則隨意且不斷修改。這也許在一個系統內部的交換沒有什麼問題，但對於跨系統和跨銀行之間資料交換則會帶來認識的差異和效率的低下。

　　2. 長度與效能

　　自解釋的一個主要後果就是XML文檔長度難以控制。標記和屬性的顯示大大加長了報文長度。報文長度的增加產生了兩個方面的副作用:報文發送的成功率降低以及解析報文的記憶體和CPU佔用增加。不論是使用SOCKET還是訊息中介軟體進行報文傳遞一般都有報文長度的限制。隨著報文長度的增加，通訊的成功率明顯降低，尤其是廣域網路通訊。另外無論是使用DOM還是SAX解析XML文檔，存在相當的記憶體和CPU資源佔用。

　　金融交易一般交易元素眾多，特別是加入客戶關係管理和綜合賬戶資訊後，發送和返回的資訊明顯增多。常用的一種方法是對報文壓縮和進行傳遞，實際應用中一般壓縮比可以達到30～50%。另外就是使用縮寫，例如，將Transaction _Account _Number寫成tranAccNum，可以降低報文長度，在一定程度上能夠避免人們將過多的注意力集中於標記而忽視真正的內容，當然也不能過於簡單，否則失去了使用XML語言的意義。將某些資訊作為XML屬性進行定義也可以減少文檔的長度。

　　3. 記憶體管理

　　所有的XML解析器基本上都分成兩類:基於樹結構的介面，如文件物件模型(DOM);基於事件的介面，如簡單XML API (SAX)。DOM類型的介面使用樹型結構作到隨機遍曆和修改XML文檔。但是使用這種類型的介面佔用記憶體較多。當使用XML處理大量的資料交換時會對系統產生壓力，甚至出現系統崩潰。

　　基於事件的介面可能是一個好的選擇。它不支援對XML文檔的隨機訪問，而是採用一種順序訪問的方式。無論XML文檔的大小，所用記憶體的多少基本上是一定的。同時，由於在運行時不用建立新的對象，處理器時間佔用也較少。但是使用SAX類型的介面編程比較複雜，並且沒有對文檔的後向引用。

　　在實際應用中，如果重視易用性，一般使用DOM介面;如更關注效能優勢則選擇SAX類型的介面較好。當然也可以通過減少XML元素嵌套層數減少DOM解析樹的記憶體佔用。

　　4. 標記粒度

　　元素的粒度在制定XML規範時總能讓人產生困惑。某些內容是合在一起成為一個元素還是分開作為多個元素進行標記?例如姓名，是分成姓和名兩個元素進行標記，還是放在一起作為一個元素?個人覺得關於粒度的標記定義指導原則就是一個:盡量細分。只有細分粒度越小，才可能支援各種形式的組合。另外許多資訊來源於遺留系統，如果採用囫圇吞棗的方式延用其資訊格式，表面上看節省了資料細分的難度，但是這對資料的共用和資料的整合會產生重大的障礙。

　　5. 結構化定義

　　很多時候為了提高XML文檔解析的效率或縮短文檔長度，有意識地避免採用多層結構化的XML文檔定義。當然不是說XML文檔沒有根節點，但是會將節點的層次控制在2 ～3層。這顯然違背了XML設計的初衷。沒有了結構的XML文檔同一般的交換報文還有什麼差異呢?實際上大量交換的資料和資訊存在層次。

　　在金融領域，可以在業務種類和業務要素兩個領域對節點層次進行劃分。首先是業務種類領域。一般交易資料包含報文頭、客戶基本資料、賬戶資訊、交易相關資訊等幾個大部分組成，其下則包含業務要素領域元素，如賬戶資訊領域下就包括帳號、賬戶類型、存期、幣種、冊號、筆號、開戶日期等多個相關業務要素元素。通過這兩個層次的劃分，基本可以說明用於交換的XML報文的階層。而業務要素領域元素則可以進一步劃分層次說明相關屬性。