基于UBL和纯XML数据库的EDI系统设计与实现(2)

最后，用这种方式存储XML文件，直接查询XML某个节点下的值变成很方便，如查询订舱报文中的订舱号可以用如下方法：

SQL> select extractValue(OBJECT_VALUE, '/Booking/Booking Number/Number')

2              from XML_DOCUMENT_TABLE;

EXTRACTVALUE(OBJECT_VALUE, '/Booking/Booking Number/Number')

------------------------------------------------------------------------------------------------

TOS_BK_8781991

    对于XML报文的存储，Native XML DB具有非常鲜明的优势，因此我们把EDI系统的中间格式报文直接存入Native XML DB。从而可以不需要为了建立关系数据模型花费大量的时间；可以保持报文中数据间的树型结构层次关系而不是二维数据关系；也可以通过SQL函数语句直接从报文中提取数据。 

4  EDI系统参考功能框架

根据对原有EDI系统的研究和现有建设EDI系统的需求，提出了如下的EDI系统的功能模型，包含如下：

(1)      EDI系统建设的前提条件

要使各贸易实体间信息放心地通过EDI系统进行流转，就必须保持EDI系统的中立性，保证数据传输的安全性，同时要保证数据不随意对外泄漏、未授权的人不能看到存储的数据信息。

(2)      提供多种接收通道

允许客户端从多种通道发送报文到EDI系统，包括FTP、FTP/s、EMAIL、HTTP、HTTP/s、WebServices、MQ等。

(3)      病毒检查

对所有接收进来的报文要进行病毒检查，可以通过防火墙或杀毒软件检查实现。

(4)      支持数据加密和数据签名

随着我国电子签名法的颁布，数字签名具有法律效力，使得无纸化贸易成为可能，所以EDI要支持一套统一的CA认证系统。发送方可以把数字签名放入报文中，从而使报文具有原始不可以抵赖性。

当用户和EDI系统都是采用了同一套CA认证体系，报文发送进来时，检查报文是否经过数据加密，如果数据经过加密，则EDI系统采用自己平台的私钥对报文先解密，然后再进行格式转换；当发送方不希望EDI系统看到相关的业务数据时，发送方可以采用接收方的公钥进行加密报文体或某些关键字段，此时EDI系统就不需要对此段报文进行解密。当EDI系统把报文格式转换成接收方的格式后，可以用接收方的公钥进行加密，然后把加密后的报文发送给接收方。

更复杂的，如果有多个不同CA系统间进行报文交换，那在系统内要支持不同CA系统之间的数据签名换签。

(5)                           报文间格式转换

EDI系统要提供的一个重要的功能，就是为发送和接收双方做格式转换。由于报文格式有很多种，假如有n种报文格式，如果我们在任意两种格式间做一个转换，那就有n*(n-1)对转换；另一种方式，如果我们把n种报文格式转换成一个中间的格式，然后再把中间报文格式转换成n种报文格式，这样我们仅需要做2*n对转换就可以实现任意两报文格式间的格式转换。这就很有效地减少了工作量和维护量。

中间报文格式我们定义成UBL格式，这样我们可以充分利用XML及UBL的技术优势，例如可以用XSL直接展现报文内容，编程处理方便性等。

(6)                           报文存储功能

经过EDI系统的报文需要一式三份进行存储。第一，存储刚接收进来的原始报文，作为原始报文的存证；第二，原始报文统一转为成平台定义的中间报文格式，此中间格式的报文都放入Native XML DB中，可以用作以后数据查询、显示和基于上面开发应用系统；第三，所有已转换好接收方可以接收的报文格式在发送的同时进行存储入库，作为发送报文的存证。第一和第三份报文也可以用文件方式存储。

在把原始报文转成中间XML报文格式时，再入库的同时可以对报文用XML Schema进行格式校验，如报文是否完整，必选字段是否缺少，字段是否超长等。

(7)                           报文数据继承功能

一个完善的EDI系统应该更多的为客户考虑，为客户提供个性化和便捷功能。如报文发送方可以指定EDI系统把他原来发送过的或接收到的报文重新发送一遍；或者，把他原来发送过的或接收到的报文提取出数据组装成一个新报文，再发给指定的接收方。总之，基于已有的报文数据我们可以开发许多客户化系统，系统提供的功能越多，对用户就会有更多的吸引力。

(8)                           报文查询和显示功能

客户可以根据需要，在EDI系统上查询出自己已经发送的报文和接收到报文，可以跟踪报文所处的状态，这些查询可以基于时间段、接收方、报文类型等条件。客户可以查看报文内容，并最好能提供友好的展现方式，而不是报文格式的再现。

(9)                           发送回执报文功能

当发送方把报文发送到EDI系统，系统需要给发送方一个已接收到报文回执；接着系统做格式校验和格式转换，这其中发现错误，需要给发送方一个错误回执，并有错误代码和错误描述；若报文没有错误就转成接收方可以接收的报文格式，再发送出去，同时给发送方一个已发送报文回执。

(10)                        提供测试环境

上生产环境前，当然要有一个测试环境，让客户进行联调测试、发现问题。当测试环境通过后，相关方签定协议后，就可以方便地切换到生产环境。

5  结束语

对EDI系统的建设，本文仅是抛砖引玉，描述了一个大体框架，其中用到的UBL和Native XML DB两种新技术可供参考，具体的实现读者可以参考相关资料完善。   

参 考 文 献

1．Uche Ogbuji. Thinking XML: 通用商业语言（UBL）.  http://www-128.ibm.com/developerworks/cn/xml/rdf/part16/

2．UBL TC. cd-UBL-1.0 . http://docs.oasis-open.org/ubl/cd-UBL-1.0/

3．江代有.电子数据交换——EDI.现在电子技术,2003

4．Sean Dillon. Which Storage XML.  http://www.oracle.com/technology/tech/xml/index.html. 2005

5．Oracle White Paper. Mastering XML DB Storage in Oracle Database 10g Release 2. http://www.oracle.com/technology/global/cn/tech/xml/xmldb/index.html

6．王文义，李阳阳. 纯XML数据库的原理分析及其应用. 计算机工程与应用,2004,10

7．赵阳，赵谦.基于XML的EDI开发方案.计算机工程与设计,2003,10

共2页: 上一页 [1] 2