国际上有许多组织根据自己的需求定义了特定的XML格式报文，这样不同组织间要进行报文交换就很困难。2004年9月，OASIS技术委员会定义了和发布了UBL（UniversalBusinessLanguage）1.0,称为通用商业语言。UBL提供让许多的商业文档可以用一种普遍地可理解和可识别的商业语法合理的组装而成，也是商业间的信息交互运行在一个标准的业务框架下，就如ISO15000（ebXML）。UBL可以通过扩展来满足不同行业的需要，从而试图解决下面存在的不同XML格式报文的问题。

　　（1）对不同版本的相同商务文档（如购买订单和发票）进行开发和维护，工作重复，浪费时间和人力。

　　（2）开发和维护多种能满足跨商业领域交易关系的适配器，是项艰巨的工作。

　　（3）由于多种XML版本的出现，后台办公系统中的XML信息整合工作变得更加困难。

　　（4）需要花费大量的资金购买能够支持多种XML版本的软件，而且软件维护困难。

　　事实上，不同的XML版本之中都包括一些基本的文档，如购买订单、货运通知和发票等，而这些版本中文档的格式、名目、数据类型不同。如果有一个通用的语言标准，使之能符合各个领域的要求，就可以满足所有用户的需要。

　　OASIS的UBL[1]（Universal Business Language）作为一个基于XML的信息交换通用语言标准可以解决上述问题。它为商业文档定义一个通用的XML交换格式，并可以通过扩展满足特殊领域的要求。

　　XML是一种元标记语言，可用来设计与特定领域有关的标记语言。每种基于XML的标记语言都叫做XML应用程序。这种应用不是像Mozilla Web浏览器、Gnumeric电子表格或 XML Pro那样的编辑器一样地使用XML,而是在特定的领域中应用XML,如化学上用的化学标记语言（Chemical Markup Language,简写为CML）或是家谱上用的GedML.每种XML应用程序有它自已的句法和词汇表。这种句法和词汇表遵守XML的基本规则。XML是以文本数据为基础的非常灵活的格式。在本章中讨论的广泛的应用都选择了XML作为基础的原因是（排除大肆宣传的因素），XML提供了切合实际的并清楚地描述了的易于读写的格式。应用程序将这种格式用于它的数据，就能够将大量的处理细节让几个标准工具和库函数去解决。更进一步说，对于这样的程序也容易将附加的句法和语义加到XML提供的基本结构之上。

　　1  UBL的产生和发展

　　电子数据交换（ElectronicDataInterchange,EDI）就是将数据的信息规范化和格式化，并通过计算机网络进行联通处理。EDI系统在很多领域有广泛的应用，如医疗、零售、海运等，主要用来做组织机构间相互交换信息。

　　传统贸易中是使用各种单据、单证、票据通过人工或半人工的方式来实现贸易相关方之间的信息流转。将传统贸易模式过渡到EDI贸易模式，那将可以大大提高交易效率，简化交易流程，减少错误，降低成本。特别是在外贸物流行业，贸易所涉及到环节繁多，人工出错率大，数据需要反复确认等许多不利因素。EDI系统将有效帮助解决这类因素，从而加快物流通关速度，节约物流通关成本。因此，国家也在大力推行各地方电子口岸的建设。

　　近年来随着XML的普及，电子商务进入了XML和EDI结合的电子商务数据交换新时代[2].现在流行使用的XML-EDI模式有很多种，xCBL[4]（XML Common Business Library）是其中影响较大的一种。它定义了一组可重用的、标准的XML组件标准，以此为基础构成电子商务数据交换的XML文档。xCBL不是一个产品或一种业务，而是一种任何组织和个人都可以获得的标准框架。为了更好地支持电子商务中的信息交换，OASIS在2001年10月17日宣布以xCBL 3.0为起点，基于其他XML商业库或类似技术的信息交换经验，对xCBL 3.0进行修改，开发了UBL.因此UBL将在很多方面与xCBL很类似，并会继续以xCBL 3.0为。2004年5月1日OASIS正式发布了UBL 1.0版本，本文所提到的UBL指的就是UBL的1.0版本。

　　通用商业语言（UBL）OASIS 技术委员会在 2001 年 10 月 17 日宣告成立。UBL 是用于商业交易的文档库，它是从中小型组织以及大型组织的角度来设计的。UBL 背后的委员会（UBL TC）对他们的雄心作了的概括：UBL TC 的目的是，通过修改现有 XML 模式库来开发 XML 商业文档（采购订单和发票等等）的标准库，以合并其它现有 XML 商业库的特性。随后 TC 将设计一种机制，该机制通过将转换规则应用于常见的 UBL 源库，来生成特定于上下文的商业模式。UBL 旨在成为每个人都不必获得特许或支付其它费用就可自由使用的电子交易国际标准。

　　2  UBL在供应链中的通用应用框架

　　供应链中常见的交易过程是买方和卖方之间从订单到发票的订货-发货交易过程，UBL支持这种交易过程中常用的商业表单。除此之外，UBL还包含以下的功能：具有一个可以重用数据组件的XML模式库，可以重用地址、货物、应付款等日常商业文档中经常使用的数据元素；拥有一套通用商业文档的XML模式，在组件库中构建了订单、发货通知、收据等元素，这些元素都能应用到一般的订货-发货交易过程之中；在特殊交换关系中UBL可以进行特殊定制。

　　订货-发货交易过程是供应链中常见的从买方到卖方的交易过程，其中主要包括三个主体：货物的买方、卖方和货物的接收方（可能是也可能不是买方）。UBL所提供的文档模式支持整个交易过程，其具体的交易流程如图1所示[1].

　　UBL描述了通用的订货-发货过程中需要的商业规范。其中主要包括：

　　（1）订单。订单指出了货物、供应量以及付费说明。付费说明包括收费方式和付费人，还包括一个默认的全局流通货币单位。订单还提供了许多订单行，每个订单行都详细说明了一批货物的送货地点、数量和需求时间。

　　（2）简要订单回复。简要订单回复是卖方确认收到买方发出订单的一种方法。它表明了买方对待订单的态度：不接收订单或者不作任何修改的接收订单。

　　（3）详细订单回复。卖方对订单进行了修改，然后以详细订单回复的形式发出并覆盖原来的订单，这是卖方用来向买方确定和提供订单相关细节的一种方法。详细订单回复包括：货运时间、价格、交易折扣、费用、商品分类编码等信息。

　　（4）订单更改。买方通过订单更改项修改以前接收的订单，比如改变订单货物、数量、送货日期、收货地点等。供应商可以用详细订单回复或者简要订单回复接收或者拒绝订单更改。

　　（5）订单取消。在交易过程中，买方可以通过订单取消来取消已建立的订单事务。但是合法合同、交易协议和商业规范都对订单取消的时间做了一定的约束。

　　（6）发货通知。发货通知应该包括下列信息：运输的方法、模式、多种货运平台、时间、地点，发货时的包装类型和标识。在发货通知中，还需表明货物的来源及其危险性。

　　（7）收货通知。收货通知由接收方发给卖方，用来确认收到货物并货物的短缺和损坏情况。在收货通知中，接收者可以从发货货物中找出缺点并因特定原因拒绝货物接收。

　　（8）收据。收据包括计价时需要的信息，不会重申任何订单、订单更改、订单回复、发货通知和接收通知中已经存在的不必要的信息。如有必要，收据可以提供订单、发货通知和接收通知接口，其中每行都对应订单、发货通知或接收通知中的相应行。

　　UBL作为一个通用商业信息交换语言标准，很好地支持了供应链中通用的商业交换流程。但是由于各个行业及领域的特殊性，还需要结合特定的接口才能应用到实际的供应链活动中。

　　3  UBL应用实例

　　我们需要在EDI系统中建立一套UBL定义的报文格式标准，作为EDI系统中的中间报文格式，利用UBL的特性，我们建立和维护这套报文标准就方便许多。用户的报文格式都转换成中间的报文格式，然后再把中间的报文格式转换成接收方可以接收的格式。

　　（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（在此例中因为只有一个地址所以为空）、公司所在街道、公司所在城市、所在州信息ISO 3166-2 NY、所在国家的信息ISO 3166-1 US以及买方的联系方式。第22行</BuyerParty>表示买方资料结束。第23~33行记述了订单行信息。其中第24行<OrderLine>表明订单行信息开始，订单行包括买方的ID第33行表示订单行信息结束。第34行表示订单po结束。

　　（2）简单订单回复

　　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行说明了简要订单回复的基本信息，表明简要订单回复开始。简要订单回复名称为ors,其格式使用UBL 1.0中的简要订单回复格式。

　　第3行表明了简要订单回复的ID为6489105763,此ID为订单在卖方公司的ID.

　　第4行表明简要订单回复的日期为2004年9月9日。

　　第5行表明了简要订单回复对订单的接受状态为真，即无改变的接收订单。

　　第6~10行记述了订单接口。其中第6行的<OrderReference>表示订单接口的开始，订单接口包括买方的ID R300、卖方的ID 154135798、订单的日期2004-09-08.订单接口的内容与其要回复的订单内容相符，使订单和订单回复能一一对应。

　　第11~17行定义了买方资料，由于是简要订单回复，这里只说明了买方名字为IDES INC US.根据UBL 1.0格式要求，需要定义在party中的partyname中的name属性中。

　　第18~27行定义了卖方的资料。其中第18行表明了卖方资料定义的开始，卖方资料包括卖方名字Joes Supply、订单联系人属性。第27行表明卖方资料结束。

　　第28行表明简要订单回复ors结束。

　　通过以上二个实例可以看出：UBL与XML一样，文档中的各项元素都用<元素名>开始，以</元素名>结束，中间的内容就是该项元素的数据。与其他语言不同的是，其他语言对元素名没有特殊的要求，而UBL将订货-发货交易过程中各个阶段中常用的元素名都进行了统一定义。UBL委员会成立了一个附属委员会，从事 UBL 命名和设计规则（UBL Naming and Design Rule,NDR）工作，该附属委员会编写了一个综合文档，包含UBL XML组件中的命名和总体设计规则。这些规则的建立确保了包括在UBL中的XML组件的一致性。

　　UBL构造的名称必须使用大小写混合（camel-case），个字母为大写，以后名称中每个内部单词的个字母大写，其后跟着小写字母，如：AmountType.

　　对于每个基于对象类的复杂类型定义，必须定义其内容模型，以便它将对象类的每个特性反映为一个元素声明，它在内容模型内的基数和定位由与语法无关的模型详细信息确定。数据类型的特性指的是W3C XML Schemas（WXS）数据类型，它被选为UBL的标准模式语言。作为辅助格式，这些文档类型用ASN.1（Abstract Syntax Notation number One）模式定义。

　　4  结束语

　　综上所述，UBL在供应链中的订货-发货交易过程中对常用的元素做了定义和规范。这使各个公司之间的交易信息交换变得更加容易，不会再因为同一元素的命名不同或者不同元素的同一命名造成误解以及交易失误。

　　UBL可以很好地解决现今电子商务信息交换，尤其是供应链中的信息交换问题。它定义严格，利用并参考了其他技术成果。由于它无需支付版税，因此被广泛采用。

　　现在的UBL才刚刚起步，短期内并不会取代目前已经比较成熟的xCBL.由于xCBL是UBL的基础，xCBL的发展并不会阻碍UBL的发展，而会促进UBL的发展。这样，UBL一定会在xCBL的基础上健康成长，终取代xCBL而成为电子商务信息交换的主要模式。