XML在金融行业中应用的问题分析.docxVIP

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);基于事件