基于UBL和純XML數(shù)據(jù)庫的EDI系統(tǒng)設計與實現(xiàn)

基于UBL和純XML數(shù)據(jù)庫的EDI系統(tǒng)設計與實現(xiàn)

摘要本文在總結(jié)原有EDI系統(tǒng)建設中存在的問題基礎上，引入了UBL和NativeXMLDB兩種新技術(shù)，最后，提出了構(gòu)建EDI系統(tǒng)所需實現(xiàn)的基本功能框架。本文可以為正興起的地方電子口岸的EDI系統(tǒng)建設起到一個指導作用。關鍵詞電子數(shù)據(jù)交換EDIUBL純XML數(shù)據(jù)庫1EDI簡述及現(xiàn)狀電子數(shù)據(jù)交換（ElectronicDataInterchange，EDI）就是將數(shù)據(jù)的信息規(guī)范化和格式化，并通過計算機網(wǎng)絡進行聯(lián)通處理。EDI系統(tǒng)在很多領域有廣泛的應用，如醫(yī)療、零售、海運等，主要用來做組織機構(gòu)間相互交換信息。傳統(tǒng)貿(mào)易中是使用各種單據(jù)、單證、票據(jù)通過人工或半人工的方式來實現(xiàn)貿(mào)易相關方之間的信息流轉(zhuǎn)。將傳統(tǒng)貿(mào)易模式過渡到EDI貿(mào)易模式，那將可以大大提高交易效率，簡化交易流程，減少錯誤，降低成本。特別是在外貿(mào)物流行業(yè)，貿(mào)易所涉及到環(huán)節(jié)繁多，人工出錯率大，數(shù)據(jù)需要反復確認等許多不利因素。EDI系統(tǒng)將有效幫助解決這類因素，從而加快物流通關速度，節(jié)約物流通關成本。因此，國家也在大力推行各地方電子口岸的建設。傳統(tǒng)的基于增值網(wǎng)絡的EDI系統(tǒng)造價昂貴，需要租用線路，可擴展性不強。如今Internet是如此的普及和方便，各貿(mào)易實體當然希望能夠通過Internet的方式實現(xiàn)和EDI系統(tǒng)進行信息交換，但是Internet上傳輸?shù)臄?shù)據(jù)存在很大的不安全性，這就需要增加物理鏈路的安全性和數(shù)據(jù)本身的安全性。EDI系統(tǒng)間傳輸?shù)膱笪目梢圆捎脟H標準，如UN/EDIFACT等，而這種國際標準往往是為了支持全球EDI系統(tǒng)，報文結(jié)構(gòu)復雜，可讀性不強，程序處理也不方便。我們?nèi)绻槍τ趨^(qū)域化貿(mào)易數(shù)據(jù)流轉(zhuǎn)，可以不采用結(jié)構(gòu)復雜的UN/EDIFACT報文格式，而采用自定義報文格式，如定長或分隔符區(qū)分字段或元素。只要收發(fā)雙方統(tǒng)一好格式，實現(xiàn)起來比較簡單。但是，自定義報文格式也有一些限制，如數(shù)據(jù)中出現(xiàn)格式上的保留符號就比較難處理，報文結(jié)構(gòu)不適合加密，報文解析程序不能靈活適應格式修改，報文格式正確性難以校驗。因此，我們用XML報文進行傳輸數(shù)據(jù)能克服以上不足，并能利用和發(fā)揮XML的優(yōu)勢和許多成熟的技術(shù)。在將來的EDI系統(tǒng)中，將有越來越多的行業(yè)基于XML框架。2UBL的定義及在EDI系統(tǒng)中的應用國際上有許多組織根據(jù)自己的需求定義了特定的XML格式報文，這樣不同組織間要進行報文交換就很困難。2004年9月，OASIS技術(shù)委員會定義了和發(fā)布了UBL(UniversalBusinessLanguage)1.0，稱為通用商業(yè)語言。UBL提供讓許多的商業(yè)文檔可以用一種普遍地可理解和可識別的商業(yè)語法合理的組裝而成，也是商業(yè)間的信息交互運行在一個標準的業(yè)務框架下，就如ISO15000(ebXML)。UBL可以通過擴展來滿足不同行業(yè)的需要，從而試圖解決現(xiàn)有存在的大量不同XML格式報文的問題。發(fā)布的UBL1.0提供了如下內(nèi)容：⑴XMLSchema描述的可重用的數(shù)據(jù)組件庫，如“地址”、“條款”、“付款”——這些每天商業(yè)上都要使用的數(shù)據(jù)元素。⑵通用商業(yè)文檔如“訂單”、“發(fā)票”、“發(fā)貨通知”等可以從UBL組件庫抽取出需要的構(gòu)件稱特定的XMLSchemas集。⑶在特定的貿(mào)易關系中，支持UBL的個性化定制。如一個訂艙報文（bookingmessage），里面有船舶名稱、發(fā)貨人名稱、收貨人名稱、貨物名稱、港口、備注等信息（參見下圖），圖1訂艙報文UBL組件模型這些信息單元都是基于UBL中定義的基本商業(yè)信息實體（BasicBusinessInformationEntity）。我們也可以把幾個相關的基本業(yè)務信息實體組成一個集合商業(yè)信息實體（AggregateBusinessInformationEntity），如訂艙貨物信息可以由貨物名稱、包裝類型、件數(shù)、體積、毛重、凈重這六個基本業(yè)務信息實體組成一個集合業(yè)務信息實體，稱CargoLineItem。最后一個訂艙報文的形成就可以通過把有關的基本商業(yè)信息實體或集合商業(yè)信息實體按一定順序拼在一起。同時，這些基本/集合商業(yè)信息實體都是可以在其他報文中重用的。只要我們建立起了這些組件庫，我們的中間XML報文格式定義就像拼裝零件一樣簡單，這樣我們的報文格式也易于管理和維護。在UBL1.0版本中也給出了許多可重用的基本組件庫，下圖（圖2）是以XMLSchema形式給出的Party信息實體，圖2Party信息實體的Schema定義在實際的報文中如發(fā)貨人、收貨人、通知人等的定義都是以Party信息實體為基礎，并進行定制而成的，我們也可以把自己定制而成的信息實體根據(jù)需要放入自己的基本組件庫。圖3實際中Shipper_Party信息實體的構(gòu)成圖另外，我們把每一個基本信息實體當作一個小模塊，用XSL語言把每個小模塊定義好在WEB上的顯示方式。當我們要以WEB方式顯示一個報文時，可以把用到的信息實體對應的XSL模塊重新在jsp或asp中構(gòu)建一起，根據(jù)需要調(diào)整各模塊間的順序或格式大小，這樣一個報文就可以方便以WEB方式展現(xiàn)給客戶。報文交換平臺需要提供給客戶報文查詢功能，按照這樣方式，客戶查詢出的報文可以直接以WEB方式顯示，而且實現(xiàn)簡單，可以達到顯示風格統(tǒng)一。我們需要在EDI系統(tǒng)中建立一套UBL定義的報文格式標準，作為EDI系統(tǒng)中的中間報文格式，利用UBL的特性，我們建立和維護這套報文標準就方便許多。用戶的報文格式都轉(zhuǎn)換成中間的報文格式，然后再把中間的報文格式轉(zhuǎn)換成接收方可以接收的格式。3NativeXMLDB在EDI存儲系統(tǒng)中的應用NativeXMLDB又稱純XML數(shù)據(jù)庫，它把一個XML文檔作為基本的邏輯存儲單元。如現(xiàn)在的Oracle10g就支持NativeXML數(shù)據(jù)庫，并且定義XMLType作為一種數(shù)據(jù)類型，它使數(shù)據(jù)庫可以理解含有XML的列或表，就像DATE數(shù)據(jù)類型使數(shù)據(jù)庫可以理解含有日期的列，它可以同其它數(shù)據(jù)類型一樣使用。NativeXMLDB的簡單使用可以按照下面操作：首先把某個報文類型相應的XMLSchema報文標準（用UBLSchema定義的），注冊到NativeXMLDB，Oracle可以通過調(diào)用DBMS_XMLSCHEMA.REGISTER_SCHEMA()的PL/SQL過程來注冊Schema。當基于該Schema的實際報文存儲入庫時，可以用XMLType數(shù)據(jù)類型提供的方法isSchemaValid()和schemaValidate()來驗證報文是否滿足報文標準的定義。然后創(chuàng)建表，類似其他建表的方法，SQL>createtableXML_DOCUMENT_TABLE2(3FILENAME

varchar2(50)，4XML_DOCUMENT

XMLType5)或者，當有XMLSchema已經(jīng)向數(shù)據(jù)庫注冊后，可以用以下方法來創(chuàng)建表，對于XML報文的存儲，NativeXMLDB具有非常鮮明的優(yōu)勢，因此我們把EDI系統(tǒng)的中間格式報文直接存入NativeXMLDB。從而可以不需要為了建立關系數(shù)據(jù)模型花費大量的時間；可以保持報文中數(shù)據(jù)間的樹型結(jié)構(gòu)層次關系而不是二維數(shù)據(jù)關系；也可以通過SQL函數(shù)語句直接從報文中提取數(shù)據(jù)。4EDI系統(tǒng)參考功能框架根據(jù)對原有EDI系統(tǒng)的研究和現(xiàn)有建設EDI系統(tǒng)的需求，提出了如下的EDI系統(tǒng)的功能模型，包含如下：(1)

EDI系統(tǒng)建設的前提條件要使各貿(mào)易實體間信息放心地通過EDI系統(tǒng)進行流轉(zhuǎn)，就必須保持EDI系統(tǒng)的中立性，保證數(shù)據(jù)傳輸?shù)陌踩?，同時要保證數(shù)據(jù)不隨意對外泄漏、未授權(quán)的人不能看到存儲的數(shù)據(jù)信息。(2)

提供多種接收通道允許客戶端從多種通道發(fā)送報文到EDI系統(tǒng)，包括FTP、FTP/s、EMAIL、HTTP、HTTP/s、WebServices、MQ等。(3)

病毒檢查對所有接收進來的報文要進行病毒檢查，可以通過防火墻或殺毒軟件檢查實現(xiàn)。(4)

支持數(shù)據(jù)加密和數(shù)據(jù)簽名隨著我國電子簽名法的頒布，數(shù)字簽名具有法律效力，使得無紙化貿(mào)易成為可能，所以EDI要支持一套統(tǒng)一的CA認證系統(tǒng)。發(fā)送方可以把數(shù)字簽名放入報文中，從而使報文具有原始不可以抵賴性。當用戶和EDI系統(tǒng)都是采用了同一套CA認證體系，報文發(fā)送進來時，檢查報文是否經(jīng)過數(shù)據(jù)加密，如果數(shù)據(jù)經(jīng)過加密，則EDI系統(tǒng)采用自己平臺的私鑰對報文先解密，然后再進行格式轉(zhuǎn)換；當發(fā)送方不希望EDI系統(tǒng)看到相關的業(yè)務數(shù)據(jù)時，發(fā)送方可以采用接收方的公鑰進行加密報文體或某些關鍵字段，此時EDI系統(tǒng)就不需要對此段報文進行解密。當EDI系統(tǒng)把報文格式轉(zhuǎn)換成接收方的格式后，可以用接收方的公鑰進行加密，然后把加密后的報文發(fā)送給接收方。更復雜的，如果有多個不同CA系統(tǒng)間進行報文交換，那在系統(tǒng)內(nèi)要支持不同CA系統(tǒng)之間的數(shù)據(jù)簽名換簽。(5)報文間格式轉(zhuǎn)換EDI系統(tǒng)要提供的一個重要的功能，就是為發(fā)送和接收雙方做格式轉(zhuǎn)換。由于報文格式有很多種，假如有n種報文格式，如果我們在任意兩種格式間做一個轉(zhuǎn)換，那就有n*(n-1)對轉(zhuǎn)換；另一種方式，如果我們把n種報文格式轉(zhuǎn)換成一個中間的格式，然后再把中間報文格式轉(zhuǎn)換成n種報文格式，這樣我們僅需要做2*n對轉(zhuǎn)換就可以實現(xiàn)任意兩報文格式間的格式轉(zhuǎn)換。這就很有效地減少了工作量和維護量。中間報文格式我們定義成UBL格式，這樣我們可以充分利用XML及UBL的技術(shù)優(yōu)勢，例如可以用XSL直接展現(xiàn)報文內(nèi)容，編程處理方便性等。(6)報文存儲功能經(jīng)過EDI系統(tǒng)的報文需要一式三份進行存儲。第一，存儲剛接收進來的原始報文，作為原始報文的存證；第二，原始報文統(tǒng)一轉(zhuǎn)為成平臺定義的中間報文格式，此中間格式的報文都放入NativeXMLDB中，可以用作以后數(shù)據(jù)查詢、顯示和基于上面開發(fā)應用系統(tǒng)；第三，所有已轉(zhuǎn)換好接收方可以接收的報文格式在發(fā)送的同時進行存儲入庫，作為發(fā)送報文的存證。第一和第三份報文也可以用文件方式存儲。在把原始報文轉(zhuǎn)成中間XML報文格式時，再入庫的同時可以對報文用XMLSchema進行格式校驗，如報文是否完整，必選字段是否缺少，字段是否超長等。(7)報文數(shù)據(jù)繼承功能一個完善的EDI系統(tǒng)應該更多的為客戶考慮，為客戶提供個性化和便捷功能。如報文發(fā)送方可以指定EDI系統(tǒng)把他原來發(fā)送過的或接收到的報文重新發(fā)送一遍；或者，把他原來發(fā)送過的或接收到的報文提取出數(shù)據(jù)組裝成一個新報文，再發(fā)給指定的接收方?？傊?，基于已有的報文數(shù)據(jù)我們可以開發(fā)許多客戶化系統(tǒng)，系統(tǒng)提供的功能越多，對用戶就會有更多的吸引力。(8)報文查詢和顯示功能客戶可以根據(jù)需要，在EDI系統(tǒng)上查詢出自己已經(jīng)發(fā)送的報文和接收到報文，可以跟蹤報文所處的狀態(tài)，這些查詢可以基于時間段、接收方、報文類型等條件?？蛻艨梢圆榭磮笪膬?nèi)容，并最好能提供友好的展現(xiàn)方式，而不是報文格式的再現(xiàn)。(9)發(fā)送回執(zhí)報文功能當發(fā)送方把報文發(fā)送到EDI系統(tǒng)，系統(tǒng)需要給發(fā)送方一個已接收到報文回執(zhí)；接著系統(tǒng)做格式校驗和格式轉(zhuǎn)換，這其中發(fā)現(xiàn)錯誤，需要給發(fā)送方一個錯誤回執(zhí)，并有錯誤代碼和錯誤描述；若報文沒有錯誤就轉(zhuǎn)成接收方可以接收的報文格式，再發(fā)送出去，同時給發(fā)送方一個已發(fā)送報文回執(zhí)。(10)提供測試環(huán)境上生產(chǎn)環(huán)境前，當然要有一個測試環(huán)境，讓客戶進行聯(lián)調(diào)測試、發(fā)現(xiàn)問題。當測試環(huán)境通過后，相關方簽定協(xié)議后，就可以方便地切換到生產(chǎn)環(huán)境。5結(jié)束語對EDI系統(tǒng)的建設，本文僅是拋磚引玉，描述了一個大體框架，其中用到的UBL和NativeXMLDB兩種新技術(shù)可供參考，具體的實現(xiàn)讀者可以參考相關資料完善。參考文獻1．UcheOgbuji.ThinkingXML:通用商業(yè)語言（UBL）./developerworks/cn/xml/rdf/part16/2．UBLTC.cd-UBL-1.0./ubl/cd-UBL-1.0/3．江代有.電子數(shù)據(jù)交換——EDI.現(xiàn)在電子技術(shù)，20034．SeanDillon.Wh