?????????XML以其開放、自描述、向前兼容的特性逐漸成為數(shù)據(jù)交換的事實標準，并將觸角伸展到金融行業(yè)的不同領域，盡管道路不是很平坦，頗有些泥濘，但XML在金融業(yè)的應用依然向前。

漸行漸近的行業(yè)標準
????????目前，針對不同的金融應用領域已經出現(xiàn)了幾種不同的XML 格式。如Interactive Financial Exchange (IFX)和 Open Financial Exchange (OFX)標準，它們處理的對象是消費者和其他形式的小額銀行業(yè)務。
????????Financial Information eXchange (FIX)是作為產權交易數(shù)據(jù)的標準通信協(xié)議出現(xiàn)的。SWIFT在加入 ISO 15022 XML 工作組后，已經采用XML 作為主要的表示格式，并把它的歷史悠久的數(shù)據(jù)模型轉化成了 XML 形式。Financial Products Markup Language（金融產品標記語言，F(xiàn)pML）用于金融衍生市場事務，通常用于錯綜復雜的協(xié)商。eXtensible Business Reporting Language（可擴展商業(yè)報告語言，XBRL），主要用于商業(yè)報告和數(shù)據(jù)的準備與交換。
????????上述這些標準都不能涵蓋所有的銀行業(yè)務。會計和審計制度的不同使這些標準很難應用在國內的金融行業(yè)。國內也缺乏專門的機構和人才對金融數(shù)據(jù)交換制定適合國情的，并具有一定權威性的標準，但是這些標準具有重要的參考意義不容忽視。


邁過五道坎
????????XML的誘惑已經使很多銀行和金融公司開始制定內部的XML標準用于數(shù)據(jù)交換和存儲。關于標記的制定、屬性值的枚舉、交易要素的多少、元素的細分等環(huán)節(jié)的隨意編寫也嚴重損害了XML的標準意義。不同銀行在相同領域使用不同的XML報文規(guī)范，以及同一個銀行內部不同系統(tǒng)之間使用不同的XML報文規(guī)范在很大程度上削弱了XML語言的開放性。
????????同時，在XML實際用于金融數(shù)據(jù)交換時要處理好以下五個問題，邁過這五道坎之后，XML將發(fā)揮出真正的實力。
????????1. DTD和Schema
????????為了說明XML詞匯表的語法規(guī)則，可以采用文檔類型定義描述（DTD）。DTD使用正式的語法定義XML文檔的結構和允許值。通過創(chuàng)建DTD，能夠正式而精確地定義詞匯表，從而使解析器可以利用DTD驗證文檔實例的有效性和完整性。遺憾的是DTD的數(shù)據(jù)類型對XML文件的約束顯得并不詳盡。例如，賬號和申請人的名字均被描述成#PCDATA（字符串）。但是賬號是一個整數(shù)，還可能是一個32位長的整數(shù)。另一個遺憾是，DTD使用非XML文件來描述XML文件。使用XML Schema則可以在一定程度上解決上述問題。XML Schema是一個良好格式的XML文件，提供了多種數(shù)據(jù)類型定義并允許對這些定義進行擴展、限制和組合以創(chuàng)建自己的復雜類型。但是需要注意的是XML Schema規(guī)范正在發(fā)展之中。
????????作為銀行跨系統(tǒng)的應用，使用DTD或XML Schema可以更好的表現(xiàn)和理解用于交換的XML文檔結構，并對XML文檔中的結構和內容錯誤進行指示。但是一般自定義的XML報文均缺少DTD或XML Schema定義，文檔規(guī)則隨意且不斷修改。這也許在一個系統(tǒng)內部的交換沒有什么問題，但對于跨系統(tǒng)和跨銀行之間數(shù)據(jù)交換則會帶來認識的差異和效率的低下。
????????2. 長度與性能
????????自解釋的一個主要后果就是XML文檔長度難以控制。標記和屬性的顯示大大加長了報文長度。報文長度的增加產生了兩個方面的副作用：報文發(fā)送的成功率降低以及解析報文的內存和CPU占用增加。不論是使用SOCKET還是消息中間件進行報文傳遞一般都有報文長度的限制。隨著報文長度的增加，通信的成功率明顯降低，尤其是廣域網通信。另外無論是使用DOM還是SAX解析XML文檔，存在相當?shù)膬却婧虲PU資源占用。
????????金融交易一般交易元素眾多，特別是加入客戶關系管理和綜合賬戶信息后，發(fā)送和返回的信息明顯增多。常用的一種方法是對報文壓縮和進行傳遞，實際應用中一般壓縮比可以達到30～50%。另外就是使用縮寫，例如，將Transaction _Account _Number寫成tranAccNum，可以降低報文長度，在一定程度上能夠避免人們將過多的注意力集中于標記而忽視真正的內容，當然也不能過于簡單，否則失去了使用XML語言的意義。將某些信息作為XML屬性進行定義也可以減少文檔的長度。
????????3. 內存管理
????????所有的XML解析器基本上都分成兩類：基于樹結構的接口，如文檔對象模型（DOM）;基于事件的接口，如簡單XML API （SAX）。DOM類型的接口使用樹型結構作到隨機遍歷和修改XML文檔。但是使用這種類型的接口占用內存較多。當使用XML處理大量的數(shù)據(jù)交換時會對系統(tǒng)產生壓力，甚至出現(xiàn)系統(tǒng)崩潰。
基于事件的接口可能是一個好的選擇。它不支持對XML文檔的隨機訪問，而是采用一種順序訪問的方式。無論XML文檔的大小，所用內存的多少基本上是一定的。同時，由于在運行時不用創(chuàng)建新的對象，處理器時間占用也較少。但是使用SAX類型的接口編程比較復雜，并且沒有對文檔的后向引用。
????????在實際應用中，如果重視易用性，一般使用DOM接口；如更關注性能優(yōu)勢則選擇SAX類型的接口較好。當然也可以通過減少XML元素嵌套層數(shù)減少DOM解析樹的內存占用。
????????4. 標記粒度
????????元素的粒度在制定XML規(guī)范時總能讓人產生困惑。某些內容是合在一起成為一個元素還是分開作為多個元素進行標記？例如姓名，是分成姓和名兩個元素進行標記，還是放在一起作為一個元素？個人覺得關于粒度的標記定義指導原則就是一個：盡量細分。只有細分粒度越小，才可能支持各種形式的組合。另外許多信息來源于遺留系統(tǒng)，如果采用囫圇吞棗的方式延用其信息格式，表面上看節(jié)省了數(shù)據(jù)細分的難度，但是這對數(shù)據(jù)的共享和數(shù)據(jù)的整合會產生重大的障礙。
????????5. 結構化定義
????????很多時候為了提高XML文檔解析的效率或縮短文檔長度，有意識地避免采用多層結構化的XML文檔定義。當然不是說XML文檔沒有根節(jié)點，但是會將節(jié)點的層次控制在2 ～3層。這顯然違背了XML設計的初衷。沒有了結構的XML文檔同一般的交換報文還有什么差異呢？實際上大量交換的數(shù)據(jù)和信息存在層次。
????????在金融領域，可以在業(yè)務種類和業(yè)務要素兩個領域對節(jié)點層次進行劃分。首先是業(yè)務種類領域。一般交易數(shù)據(jù)包含報文頭、客戶基本信息、賬戶信息、交易相關信息等幾個大部分組成，其下則包含業(yè)務要素領域元素，如賬戶信息領域下就包括賬號、賬戶類型、存期、幣種、冊號、筆號、開戶日期等多個相關業(yè)務要素元素。通過這兩個層次的劃分，基本可以說明用于交換的XML報文的層次結構。而業(yè)務要素領域元素則可以進一步劃分層次說明相關屬性。