电子商务全球化标准:ebXML

最近做的项目中涉及到了电子商务公司之间的数据交换,及数据格式转化

refer to:  点击打开链接

电子商务全球化标准:ebXML


20多年前,电子商务的想法诞生,通过链接在一起的计算机系统,数据能从一个系统传送到其他系统,从而不再使用纸介质文件来交换商业数据。这个概念就是EDI(Electronic Data Interchange,电子数据交换)的原型。EDI的出现大大提高了商业运作效率,但虽然全世界的前10000家公司中98%以上都在使用EDI,但全世界其他公司中却仅有5%是EDI的用户。这是为什么呢?这是因为EDI虽然很有效,但启动费用很高。
  近一段时间以来,人们一直在寻找EDI的替代方案,希望能够找到一种使全球不同规模的公司都能受益的简单、便宜的交换标准商务文档的方法。在这样的背景下ebXML应运而生了。

  一、什么是ebXML

  "ebXML是一组支持模块化电子商务框架的规范。ebXML支持一个全球化的电子市场,它使得任意规模的企业通过交换基于XML的信息,不受地域限制地接洽和处理生意。ebXML是联合国(UN/CEFACT,贸易促进和电子商务中心)和OASIS(结构化信息标准发展组织)共同倡导、全球参与开发和使用的规范。"
  ebXML规范的最初版本于2001年5月发布。它的目标是使任何规模的商家能够和任何人开展电子商务。在现阶段,ebXML是一套文档,包含若干完善的原型,但是有许多企业现在正在建造支持它的系统。

  二、ebXML的任务

  由于XML本身不具备使其适应商务世界需求的所有工具,所以希望通过ebXML实现:

  1) 使电子商务简单、容易,并且无所不在;
  2) 最大限度地使用XML;
  3)为B2B和B2C提供一个同样的开放标准以进行跨行业的商务交易;
  4) 将各种XML商务词汇的结构和内容一起放进一个单一的规范;
  5) 提供一条从当前EDI标准和XML词汇表移植的途径;
  6)鼓励行业在一个共同的长期目标下致力于直接的或短期的目标;
  7)用ebXML进行电子商务活动,避免要求最终用户投资于专有软件或强制使用专业系统;
  8) 保持最低成本;
  9) 支持多种书面语言并容纳国内、国际贸易的通用规则。


原文地址:点击打开链接

理解 ebXML

解开未来商业 Web 之谜

David Mertz 博士 (userid@us.ibm.com), 现象学统一者, Gnosis Software, Inc.
author
David Mertz 了解的商业技术越多,他就越深入地为劳工运动所牵挂。可以通过 mertz@gnosis.cx 与 David 联系;可以在 gnosis.cx/publish/ 上了解他的生活。欢迎提出对本文、以前或将来的文章提出意见和建议。

简介: ebXML 是一个由许多部分组成的大项目。在本文中,David Mertz 概述了这些部分是如何组合在一起的。这篇概述介绍了 ebXML 概念,然后稍微详细地讨论了商业过程的表示,这是 ebXML 实现的重要起点。两段短的代码样本演示了 ProcessSpecification DTD 和一个协作包。


当读到 ebXML 时,很难了解它到底是什么 -- 以及不是什么。ebXML 中的 'eb' 代表“电子商务”,可以将这个短语读成 "electronic business XML"、"e-biz XML"、"e-business XML" 或简单地读成 "ee-bee-ex-em-el"。

什么是 ebXML?

一方面,ebXML 似乎要承诺统一商业过程所做的每一件事,以便相互通信。另一方面,人们也可以认为:ebXML 只是现有标准应该遵循的神圣而又空洞的声明。与所有“即将发生的重大事件一样”,答案位于二者中间。


ebXML 术语

注册表:一个中央服务器,它存储使 ebXML 工作所需的各种数据。在这些信息中,“注册表”以 XML 形式显示给用户的有:“商业过程和信息元模型”、“核心库”、“协作协议概要”以及“商业库”。基本上,当商家要与另一个商家建立 ebXML 关系时,它向“注册表”发出请求,以查找合适的伙伴并查找有关处理那个伙伴的需求方面的信息。

商业过程:商家可以参与的活动(对于商业过程,商家通常需要一个或多个伙伴)。“商业过程”由“商业过程规范模式”(一种“W3C XML 模式”和一个 DTD)正式描述,但也可以用 UML 建模。

协作协议概要 (CPP):由希望参与 ebXML 事务的商家用“注册表”归档的概要。CPP 将指定商家的某些“商业过程”,以及它支持的某些“商业服务接口”。

商业服务接口:商家可以执行其“商业过程”中必需的事务的方式。 “商业服务接口”还包括商家所支持的“商业消息”种类以及传递这些消息可能采用的协议。

商业消息:作为商业事务一部分进行通信的实际信息。一条消息将包含多层。在外层,必须使用实际的通信协议(例如 HTTP 或 SMTP)。SOAP 是 ebXML 推荐的消息“酬载”信封。其它层可以处理加密或认证。

核心库:可以在更大的 ebXML 元素中使用的标准“部件”集。例如,“商业过程”可以引用“核心过程”。“核心库”由 ebXML 发起者本身提出,而更大的元素可能由特定厂家或商家提出。

协作协议协定 (CPA):本质上是两个或多个商家之间的契约,它可以从各自公司的 CPP 中自动获取。如果一个 CPP 说:“我 可以做 X”,则 CPA 会说“我们 一起做 X。”

简单对象访问协议 (SOAP):由 ebXML 发起者认可的分布式环境中的信息交换 W3C 协议。ebXML 中很重要的一点就是 SOAP 作为信封的功能,该功能定义一个描述什么是消息以及如何处理消息的框架。

ebXML.org 主页提供了以下简短描述:

ebXML 是一个规范集,这些规范共同实现了模块化电子商务框架。ebXML 的构想是实现一个全球电子市场,其中,不同规模和不同地区的企业可以通过交换基于 XML 的消息来合作和进行商业活动。

换句话说,ebXML 希望成功实现“电子数据交换”,即我们常听到的 EDI。(官方描述趋向于强调从 EDI 学习,而不是摒弃它。)

ebXML 术语

弄清 ebXML 涉及几个步骤。理解 ebXML 细节所需的第一件事可能是领会新的字首组合词和其它特殊术语。在查看 ebXML 交互的整个“构想”之前,请先了解以下右边侧栏( ebXML 术语)中的一些术语。还有一些术语适合整个系统,但是,这些特殊术语是很好的起点。记住了这个新的词汇表和以下这些有关 ebXML 出处的背景知识,就可以了解 ebXML 中的所有不同过程是如何组合在一起的。

在本文开头描述了 ebXML 做什么(至少是概述说明)之后,最后一节将详细讨论“商业过程规范模式”,该模式构成了 ebXML 底层体系结构的最重要元素之一。

背景知识

ebXML 是一项倡议,其参与者与认可者包括了您所能想到的世界上每一家大公司和官方标准协会。可能不是您所能想到的 每一个,但确实包括几百家大公司和团体。

计算机/技术公司不是认可 ebXML 的唯一实体;支持者包括大量工业、航运、银行业以及其它综合业务公司。ebXML 的直接赞助者是 OASIS(结构化信息标准促进组织)和 UN/CEFACT(联合国贸易辅助和电子商务中心)。许多标准团体也参与其中,包括 NIST(国家标准和技术学会)和 W3C(World Wide Web Consortium(万维网联盟)。

拥有这样一些支持者,ebXML 看起来注定要统治世界。对于时髦语和广告宣传,我往往采取鄙视的态度。然而,对于 ebXML,我还是希望它能象它所宣传的那样,在未来五年内成为大多数商业事务的通用协议。

照我看来,ebXML 将通过实际允许商家以 不同的方式进行商业活动,尽可能多地将商家 在任意方面的所作所为越来越多地合并到规范中,从而成功地成为通用协议。我不知道,我的判断是对 ebXML 开放性的讽刺还是鼓舞,但是,ebXML 发起人明确抱有一种“接纳现有标准和方法”的态度。


组合在一起

基于“ebXML 技术体系结构规范”(请 参阅 参考资料)的图解( 图 1)可能会在理解 ebXML 对于商业的意义方面给您以很大帮助。

“图 1”中的“公司 A”将首先复查“ebXML 注册表”的内容,特别是可以下载或就地查看的“核心库”。“核心库”(可能还有其它已注册的“商业过程”)将允许“公司 A”确定其自己的 ebXML 实现的要求(以及 ebXML 是否适合于它们的商业需求)。


图 1:两个公司之间 ebXML 交互的高级概述
图 1:两个公司之间 ebXML 交互的高级概述

根据对从“ebXML 注册表”获得的信息的复查,“公司 A”可以构建或购买适合于它所预想的 ebXML 事务的 ebXML 实现。ebXML 倡议的希望是:厂商将支持所有 ebXML 元素。那时,“ebXML 系统”可能只不过是一个预先包装的桌面应用程序。或者更为现实一些,ebXML 系统将至少象商业数据库系统(仍需要一名 DBA)那样可管理。 图 1 暗示着:假想的“公司 B”使用类似于这种预先包装的应用程序。

不管哪种方法,“公司 A”的下一步是创建一个 CPP,并向“注册表”注册它。“公司 A”可能希望向“注册表”添加新的“商业过程”,或只是引用已有的商业过程。CPP 将包含一些信息,潜在的伙伴将使用这些信息确定“公司 A”所感兴趣的商业角色,以及为扮演这些角色,“公司 A”愿意使用哪种协议。

一旦注册了“公司 A”,“公司 B”就可以查看“公司 A”的 CPP,以确定它与“公司 B”的 CPP 和要求兼容。那时,“公司 B”应该在能够顺应 CPP 的基础上自动与 “公司 A”协商 CPA,以及作为 ebXML 标准或建议给出的、双方达成的协议。

最后,这两家公司开始处理实际事务。这些事务可能涉及到符合未来 ebXML 标准和建议的“商业消息”。在所有这些过程中的某一处,可能会发生“现实世界”的活动(例如,从一地向另一地发货,或提供服务)。ebXML 将有助于同意、监控和验证这些现实世界的活动。当然,在我们的“信息经济”中,许多正在进行的事物可能处于 ebXML 领域 -- 可能是特定商业关系中的每件事。


商业过程模式

UN/CEFACT Modeling Methodology (UMM) 利用了 UML,它可能对建立“ebXML 商业过程”的模型有所帮助。然而,这种建模只是建议,而不是要求。无论如何,既然本文针对 XML 开发人员并且不讨论 OOD(面向对象的设计),所以在符合“商业过程规范 DTD 和 XML 模式”的 XML 文档中查看模型的表示也更为有趣。在这种情况下,DTD(即 "ebXMLProcessSpecification- v1.00.dtd")就成为主要的规则表示。这个 DTD 和(假设)在语义和语法上都兼容的“W3C XML 模式”都可以在 EbXML_BPschema_1.0 建议中找到(请 参阅 参考资料)。

ebXML 过程规范有一个根元素 ProcessSpecification 。特定的过程规范也许包含了对其它过程规范和文档规范以及其它文档的字节点引用。 ProcessSpecification 的 DTD 声明提供了“商业过程”文档的结构概述:


清单 1:ProcessSpecification DTD 声明
<!ELEMENT ProcessSpecification
          (Documentation*,
          (Include* | DocumentSpecification* |
            ProcessSpecification* | Package |
            BinaryCollaboration | BusinessTransaction |
            MultiPartyCollaboration)*)>
<!ATTLIST ProcessSpecification
          name    ID    #REQUIRED
          version CDATA #REQUIRED
          uuid    CDATA #REQUIRED >

属性 uuid 是过程规范的全局唯一标识; nameversion 特定于显示的模型( name 不应该与嵌套的过程规范冲突)。

在过程规范中, Package 定义一系列协作,它既可以是 MultiPartyCollaboration 元素,也可以是 BinaryCollaboration 元素。协作反过来也包含团体的各种角色。一段从 EbXML_BPschema_1.0 建议中(请 参阅 参考资料)包含的过程规范摘录的代码有助于理解该结构:


清单 2:协作包
<Package name="Ordering">
  <!-- First the overall MultiParty Collaboration -->
  <MultiPartyCollaboration name="DropShip">
    <BusinessPartnerRole name="Customer">
      <Performs authorizedRole="requestor"/>
      <Performs authorizedRole="buyer"/>
      <Transition fromBusinessState="Catalog Request"
                  toBusinessState="Create Order"/>
    </BusinessPartnerRole>
    <BusinessPartnerRole name="Retailer">
      <Performs authorizedRole="provider"/>
      <Performs authorizedRole="seller"/>
      <Performs authorizedRole="Creditor"/>
      <Performs authorizedRole="buyer"/>
      <Performs authorizedRole="Payee"/>
[...]
  <BinaryCollaboration name="Request Catalog">
    <AuthorizedRole name="requestor"/>
    <AuthorizedRole name="provider"/>
    <BusinessTransactionActivity name="Catalog Request"
                                 businessTransaction="Catalog Request"
                                 fromAuthorizedRole="requestor"
                                 toAuthorizedRole="provider"/>
  </BinaryCollaboration>
[...]


阅读更多
上一篇程序算法与人生选择
下一篇10 Things Extraordinary People Say Every Day
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭