國(guó)際上有許多組織根據(jù)自己的需求定義了特定的XML格式報(bào)文，這樣不同組織間要進(jìn)行報(bào)文交換就很困難。2004年9月，OASIS技術(shù)委員會(huì)定義了和發(fā)布了UBL（UniversalBusinessLanguage）1.0,稱為通用商業(yè)語言。UBL提供讓許多的商業(yè)文檔可以用一種普遍地可理解和可識(shí)別的商業(yè)語法合理的組裝而成，也是商業(yè)間的信息交互運(yùn)行在一個(gè)標(biāo)準(zhǔn)的業(yè)務(wù)框架下，就如ISO15000（ebXML）。UBL可以通過擴(kuò)展來滿足不同行業(yè)的需要，從而試圖解決下面存在的不同XML格式報(bào)文的問題。

　�。�1）對(duì)不同版本的相同商務(wù)文檔（如購買訂單和發(fā)票）進(jìn)行開發(fā)和維護(hù)，工作重復(fù)，浪費(fèi)時(shí)間和人力。

　　（2）開發(fā)和維護(hù)多種能滿足跨商業(yè)領(lǐng)域交易關(guān)系的適配器，是項(xiàng)艱巨的工作。

　�。�3）由于多種XML版本的出現(xiàn)，后臺(tái)辦公系統(tǒng)中的XML信息整合工作變得更加困難。

　�。�4）需要花費(fèi)大量的資金購買能夠支持多種XML版本的軟件，而且軟件維護(hù)困難。

　　事實(shí)上，不同的XML版本之中都包括一些基本的文檔，如購買訂單、貨運(yùn)通知和發(fā)票等，而這些版本中文檔的格式、名目、數(shù)據(jù)類型不同。如果有一個(gè)通用的語言標(biāo)準(zhǔn)，使之能符合各個(gè)領(lǐng)域的要求，就可以滿足所有用戶的需要。

　　OASIS的UBL[1]（Universal Business Language）作為一個(gè)基于XML的信息交換通用語言標(biāo)準(zhǔn)可以解決上述問題。它為商業(yè)文檔定義一個(gè)通用的XML交換格式，并可以通過擴(kuò)展?jié)M足特殊領(lǐng)域的要求。

　　XML是一種元標(biāo)記語言，可用來設(shè)計(jì)與特定領(lǐng)域有關(guān)的標(biāo)記語言。每種基于XML的標(biāo)記語言都叫做XML應(yīng)用程序。這種應(yīng)用不是像Mozilla Web瀏覽器、Gnumeric電子表格或 XML Pro那樣的編輯器一樣地使用XML,而是在特定的領(lǐng)域中應(yīng)用XML,如化學(xué)上用的化學(xué)標(biāo)記語言（Chemical Markup Language,簡(jiǎn)寫為CML）或是家譜上用的GedML.每種XML應(yīng)用程序有它自已的句法和詞匯表。這種句法和詞匯表遵守XML的基本規(guī)則。XML是以文本數(shù)據(jù)為基礎(chǔ)的非常靈活的格式。在本章中討論的廣泛的應(yīng)用都選擇了XML作為基礎(chǔ)的原因是（排除大肆宣傳的因素），XML提供了切合實(shí)際的并清楚地描述了的易于讀寫的格式。應(yīng)用程序?qū)⑦@種格式用于它的數(shù)據(jù)，就能夠?qū)⒋罅康奶幚砑?xì)節(jié)讓幾個(gè)標(biāo)準(zhǔn)工具和庫函數(shù)去解決。更進(jìn)一步說，對(duì)于這樣的程序也容易將附加的句法和語義加到XML提供的基本結(jié)構(gòu)之上。

　　1  UBL的產(chǎn)生和發(fā)展

　　電子數(shù)據(jù)交換（ElectronicDataInterchange,EDI）就是將數(shù)據(jù)的信息規(guī)范化和格式化，并通過計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行聯(lián)通處理。EDI系統(tǒng)在很多領(lǐng)域有廣泛的應(yīng)用，如醫(yī)療、零售、海運(yùn)等，主要用來做組織機(jī)構(gòu)間相互交換信息。

　　傳統(tǒng)貿(mào)易中是使用各種單據(jù)、單證、票據(jù)通過人工或半人工的方式來實(shí)現(xiàn)貿(mào)易相關(guān)方之間的信息流轉(zhuǎn)。將傳統(tǒng)貿(mào)易模式過渡到EDI貿(mào)易模式，那將可以大大提高交易效率，簡(jiǎn)化交易流程，減少錯(cuò)誤，降低成本。特別是在外貿(mào)物流行業(yè)，貿(mào)易所涉及到環(huán)節(jié)繁多，人工出錯(cuò)率大，數(shù)據(jù)需要反復(fù)確認(rèn)等許多不利因素。EDI系統(tǒng)將有效幫助解決這類因素，從而加快物流通關(guān)速度，節(jié)約物流通關(guān)成本。因此，國(guó)家也在大力推行各地方電子口岸的建設(shè)。

　　近年來隨著XML的普及，電子商務(wù)進(jìn)入了XML和EDI結(jié)合的電子商務(wù)數(shù)據(jù)交換新時(shí)代[2].現(xiàn)在流行使用的XML-EDI模式有很多種，xCBL[4]（XML Common Business Library）是其中影響較大的一種。它定義了一組可重用的、標(biāo)準(zhǔn)的XML組件標(biāo)準(zhǔn)，以此為基礎(chǔ)構(gòu)成電子商務(wù)數(shù)據(jù)交換的XML文檔。xCBL不是一個(gè)產(chǎn)品或一種業(yè)務(wù)，而是一種任何組織和個(gè)人都可以獲得的標(biāo)準(zhǔn)框架。為了更好地支持電子商務(wù)中的信息交換，OASIS在2001年10月17日宣布以xCBL 3.0為起點(diǎn)，基于其他XML商業(yè)庫或類似技術(shù)的信息交換經(jīng)驗(yàn)，對(duì)xCBL 3.0進(jìn)行修改，開發(fā)了UBL.因此UBL將在很多方面與xCBL很類似，并會(huì)繼續(xù)以xCBL 3.0為。2004年5月1日OASIS正式發(fā)布了UBL 1.0版本，本文所提到的UBL指的就是UBL的1.0版本。

　　通用商業(yè)語言（UBL）OASIS 技術(shù)委員會(huì)在 2001 年 10 月 17 日宣告成立。UBL 是用于商業(yè)交易的文檔庫，它是從中小型組織以及大型組織的角度來設(shè)計(jì)的。UBL 背后的委員會(huì)（UBL TC）對(duì)他們的雄心作了的概括：UBL TC 的目的是，通過修改現(xiàn)有 XML 模式庫來開發(fā) XML 商業(yè)文檔（采購訂單和發(fā)票等等）的標(biāo)準(zhǔn)庫，以合并其它現(xiàn)有 XML 商業(yè)庫的特性。隨后 TC 將設(shè)計(jì)一種機(jī)制，該機(jī)制通過將轉(zhuǎn)換規(guī)則應(yīng)用于常見的 UBL 源庫，來生成特定于上下文的商業(yè)模式。UBL 旨在成為每個(gè)人都不必獲得特許或支付其它費(fèi)用就可自由使用的電子交易國(guó)際標(biāo)準(zhǔn)。

　　2  UBL在供應(yīng)鏈中的通用應(yīng)用框架

　　供應(yīng)鏈中常見的交易過程是買方和賣方之間從訂單到發(fā)票的訂貨-發(fā)貨交易過程，UBL支持這種交易過程中常用的商業(yè)表單。除此之外，UBL還包含以下的功能：具有一個(gè)可以重用數(shù)據(jù)組件的XML模式庫，可以重用地址、貨物、應(yīng)付款等日常商業(yè)文檔中經(jīng)常使用的數(shù)據(jù)元素；擁有一套通用商業(yè)文檔的XML模式，在組件庫中構(gòu)建了訂單、發(fā)貨通知、收據(jù)等元素，這些元素都能應(yīng)用到一般的訂貨-發(fā)貨交易過程之中；在特殊交換關(guān)系中UBL可以進(jìn)行特殊定制。

　　訂貨-發(fā)貨交易過程是供應(yīng)鏈中常見的從買方到賣方的交易過程，其中主要包括三個(gè)主體：貨物的買方、賣方和貨物的接收方（可能是也可能不是買方）。UBL所提供的文檔模式支持整個(gè)交易過程，其具體的交易流程如圖1所示[1].

　　UBL描述了通用的訂貨-發(fā)貨過程中需要的商業(yè)規(guī)范。其中主要包括：

　�。�1）訂單。訂單指出了貨物、供應(yīng)量以及付費(fèi)說明。付費(fèi)說明包括收費(fèi)方式和付費(fèi)人，還包括一個(gè)默認(rèn)的全局流通貨幣單位。訂單還提供了許多訂單行，每個(gè)訂單行都詳細(xì)說明了一批貨物的送貨地點(diǎn)、數(shù)量和需求時(shí)間。

　�。�2）簡(jiǎn)要訂單回復(fù)。簡(jiǎn)要訂單回復(fù)是賣方確認(rèn)收到買方發(fā)出訂單的一種方法。它表明了買方對(duì)待訂單的態(tài)度：不接收訂單或者不作任何修改的接收訂單。

　�。�3）詳細(xì)訂單回復(fù)。賣方對(duì)訂單進(jìn)行了修改，然后以詳細(xì)訂單回復(fù)的形式發(fā)出并覆蓋原來的訂單，這是賣方用來向買方確定和提供訂單相關(guān)細(xì)節(jié)的一種方法。詳細(xì)訂單回復(fù)包括：貨運(yùn)時(shí)間、價(jià)格、交易折扣、費(fèi)用、商品分類編碼等信息。

　�。�4）訂單更改。買方通過訂單更改項(xiàng)修改以前接收的訂單，比如改變訂單貨物、數(shù)量、送貨日期、收貨地點(diǎn)等。供應(yīng)商可以用詳細(xì)訂單回復(fù)或者簡(jiǎn)要訂單回復(fù)接收或者拒絕訂單更改。

　�。�5）訂單取消。在交易過程中，買方可以通過訂單取消來取消已建立的訂單事務(wù)。但是合法合同、交易協(xié)議和商業(yè)規(guī)范都對(duì)訂單取消的時(shí)間做了一定的約束。

　　（6）發(fā)貨通知。發(fā)貨通知應(yīng)該包括下列信息：運(yùn)輸?shù)姆椒ā⒛Ｊ�、多種貨運(yùn)平臺(tái)、時(shí)間、地點(diǎn)，發(fā)貨時(shí)的包裝類型和標(biāo)識(shí)。在發(fā)貨通知中，還需表明貨物的來源及其危險(xiǎn)性。

　�。�7）收貨通知。收貨通知由接收方發(fā)給賣方，用來確認(rèn)收到貨物并貨物的短缺和損壞情況。在收貨通知中，接收者可以從發(fā)貨貨物中找出缺點(diǎn)并因特定原因拒絕貨物接收。

　�。�8）收據(jù)。收據(jù)包括計(jì)價(jià)時(shí)需要的信息，不會(huì)重申任何訂單、訂單更改、訂單回復(fù)、發(fā)貨通知和接收通知中已經(jīng)存在的不必要的信息。如有必要，收據(jù)可以提供訂單、發(fā)貨通知和接收通知接口，其中每行都對(duì)應(yīng)訂單、發(fā)貨通知或接收通知中的相應(yīng)行。

　　UBL作為一個(gè)通用商業(yè)信息交換語言標(biāo)準(zhǔn)，很好地支持了供應(yīng)鏈中通用的商業(yè)交換流程。但是由于各個(gè)行業(yè)及領(lǐng)域的特殊性，還需要結(jié)合特定的接口才能應(yīng)用到實(shí)際的供應(yīng)鏈活動(dòng)中。

　　3  UBL應(yīng)用實(shí)例

　　我們需要在EDI系統(tǒng)中建立一套UBL定義的報(bào)文格式標(biāo)準(zhǔn)，作為EDI系統(tǒng)中的中間報(bào)文格式，利用UBL的特性，我們建立和維護(hù)這套報(bào)文標(biāo)準(zhǔn)就方便許多。用戶的報(bào)文格式都轉(zhuǎn)換成中間的報(bào)文格式，然后再把中間的報(bào)文格式轉(zhuǎn)換成接收方可以接收的格式。

　�。�1）訂單

　　1. <po:Order xmlns:po=″urn:oasis:names:tc:ubl:Order:1.0:

　　0.70″xmlns=″urn:oasis:names:tc:ubl:CommonAggregate-

　　Types:1.0:0.70″>

　　2.   <ID>4500004875</ID>

　　3.   <IssueDate>2004-09-08</IssueDate>

　　4.   <BuyerParty>

　　5.      <ID>R300</ID>

　　6.      <PartyName>

　　7.         <Name>IDE INC UK</Name>

　　8.      </PartyName>

　　9.      <Address>

　　10.         <ID></ID>

　　11.         <Street>West Pike</Street>

　　12.         <CityName>Paris</CityName>

　　13.         <CountrySub-EntityCode listID=″3166-2″ listAgencyID

　　=″ISO″>NY</CountrySub-EntityCode>

　　14.         <Country>

　　15.           <Code listID=″3166-1″ listAgencyID=″ISO″>US

　　</Code>

　　16.         </Country>

　　17.       </Address>

　　18.       <BuyerContact>

　　19.         <ID></ID>

　　20.         <Name>Joe Blog</Name>

　　21.       </BuyerContact>

　　22.   </BuyerParty>

　　23.   <OrderLine>

　　24.      <BuyersID></BuyersID>

　　25.      <Quantity unitCode=″unit″>10</Quantity>

　　26.      <Item>

　　27.         <ID>R100016</ID>

　　28.         <Description>Tuner X300</Description>

　　29.         <BasePrice>

　　30.           <PriceAmount currencyID=″USD″>350</PriceAmount>

　　31.         </BasePrice>

　　32.       </Item>

　　33.   </OrderLine>

　　34. </po:Order>

　　第1~3行說明了訂單的基本信息，表明訂單開始。其中包括訂單的名稱po,格式UBL 1.0中的訂單格式以及訂單的ID 4500004875（這是訂單在買方公司的ID），還有訂單的日期2004年9月8日。第4~22行記述了買方的資料。其中第6行的<BuyerParty>表示買方資料的開始。買方資料包括買方的ID R300、買方的公司名IDE INC UK、公司的地址、公司的ID（在此例中因?yàn)橹挥幸粋�(gè)地址所以為空）、公司所在街道、公司所在城市、所在州信息ISO 3166-2 NY、所在國(guó)家的信息ISO 3166-1 US以及買方的聯(lián)系方式。第22行</BuyerParty>表示買方資料結(jié)束。第23~33行記述了訂單行信息。其中第24行<OrderLine>表明訂單行信息開始，訂單行包括買方的ID第33行表示訂單行信息結(jié)束。第34行表示訂單po結(jié)束。

　�。�2）簡(jiǎn)單訂單回復(fù)

　　1.   <ors:OrderResponseSimple xmlns:ors=″urn:oasis:names:

　　tc:ubl:OrderResponseSimple:1.0:0.70″ xmlns=″urn:oasis:

　　names:tc:ubl:CommonAggregateTypes:1.0:0.70″>

　　2.   <ID>6489105763</ID>

　　3.   <IssueDate>2004-09-09</IssueDate>

　　4.   <AcceptedIndicator>true</AcceptedIndicator>

　　5.   <OrderReference>

　　6.      <BuyersID> R300</BuyersID>

　　7.      <SellersID>154135798</SellersID>

　　8.      <IssueDate>2004-09-08</IssueDate>

　　9.   </OrderReference>

　　10.   <BuyerParty>

　　11.      <Party>

　　12.      <PartyName>

　　13.         <Name> IDES Retail INC US </Name>

　　14.      </PartyName>

　　15.      </Party>

　　16.   </BuyerParty>

　　17.   <SellerParty>

　　18.      <Party>

　　19.         <PartyName>

　　20.           <Name>Joes Supply</Name>

　　21.         </PartyName>

　　22.      </Party>

　　23.      <OrderContact>

　　24.         <Name>Betty Jo </Name>

　　25.      </OrderContact>

　　26.   </SellerParty>

　　27. </ors:OrderResponseSimple>

　　第1~2行說明了簡(jiǎn)要訂單回復(fù)的基本信息，表明簡(jiǎn)要訂單回復(fù)開始。簡(jiǎn)要訂單回復(fù)名稱為ors,其格式使用UBL 1.0中的簡(jiǎn)要訂單回復(fù)格式。

　　第3行表明了簡(jiǎn)要訂單回復(fù)的ID為6489105763,此ID為訂單在賣方公司的ID.

　　第4行表明簡(jiǎn)要訂單回復(fù)的日期為2004年9月9日。

　　第5行表明了簡(jiǎn)要訂單回復(fù)對(duì)訂單的接受狀態(tài)為真，即無改變的接收訂單。

　　第6~10行記述了訂單接口。其中第6行的<OrderReference>表示訂單接口的開始，訂單接口包括買方的ID R300、賣方的ID 154135798、訂單的日期2004-09-08.訂單接口的內(nèi)容與其要回復(fù)的訂單內(nèi)容相符，使訂單和訂單回復(fù)能一一對(duì)應(yīng)。

　　第11~17行定義了買方資料，由于是簡(jiǎn)要訂單回復(fù)，這里只說明了買方名字為IDES INC US.根據(jù)UBL 1.0格式要求，需要定義在party中的partyname中的name屬性中。

　　第18~27行定義了賣方的資料。其中第18行表明了賣方資料定義的開始，賣方資料包括賣方名字Joes Supply、訂單聯(lián)系人屬性。第27行表明賣方資料結(jié)束。

　　第28行表明簡(jiǎn)要訂單回復(fù)ors結(jié)束。

　　通過以上二個(gè)實(shí)例可以看出：UBL與XML一樣，文檔中的各項(xiàng)元素都用<元素名>開始，以</元素名>結(jié)束，中間的內(nèi)容就是該項(xiàng)元素的數(shù)據(jù)。與其他語言不同的是，其他語言對(duì)元素名沒有特殊的要求，而UBL將訂貨-發(fā)貨交易過程中各個(gè)階段中常用的元素名都進(jìn)行了統(tǒng)一定義。UBL委員會(huì)成立了一個(gè)附屬委員會(huì)，從事 UBL 命名和設(shè)計(jì)規(guī)則（UBL Naming and Design Rule,NDR）工作，該附屬委員會(huì)編寫了一個(gè)綜合文檔，包含UBL XML組件中的命名和總體設(shè)計(jì)規(guī)則。這些規(guī)則的建立確保了包括在UBL中的XML組件的一致性。

　　UBL構(gòu)造的名稱必須使用大小寫混合（camel-case），個(gè)字母為大寫，以后名稱中每個(gè)內(nèi)部單詞的個(gè)字母大寫，其后跟著小寫字母，如：AmountType.

　　對(duì)于每個(gè)基于對(duì)象類的復(fù)雜類型定義，必須定義其內(nèi)容模型，以便它將對(duì)象類的每個(gè)特性反映為一個(gè)元素聲明，它在內(nèi)容模型內(nèi)的基數(shù)和定位由與語法無關(guān)的模型詳細(xì)信息確定。數(shù)據(jù)類型的特性指的是W3C XML Schemas（WXS）數(shù)據(jù)類型，它被選為UBL的標(biāo)準(zhǔn)模式語言。作為輔助格式，這些文檔類型用ASN.1（Abstract Syntax Notation number One）模式定義。

　　4  結(jié)束語

　　綜上所述，UBL在供應(yīng)鏈中的訂貨-發(fā)貨交易過程中對(duì)常用的元素做了定義和規(guī)范。這使各個(gè)公司之間的交易信息交換變得更加容易，不會(huì)再因?yàn)橥�一元素的命名不同或者不同元素的同一命名造成誤解以及交易失誤。

　　UBL可以很好地解決現(xiàn)今電子商務(wù)信息交換，尤其是供應(yīng)鏈中的信息交換問題。它定義嚴(yán)格，利用并參考了其他技術(shù)成果。由于它無需支付版稅，因此被廣泛采用。

　　現(xiàn)在的UBL才剛剛起步，短期內(nèi)并不會(huì)取代目前已經(jīng)比較成熟的xCBL.由于xCBL是UBL的基礎(chǔ)，xCBL的發(fā)展并不會(huì)阻礙UBL的發(fā)展，而會(huì)促進(jìn)UBL的發(fā)展。這樣，UBL一定會(huì)在xCBL的基礎(chǔ)上健康成長(zhǎng)，終取代xCBL而成為電子商務(wù)信息交換的主要模式。