了解ebXML

当您阅读有关ebXML的内容时，很难确切了解它的内容–而不是它的内容。 ebXML中的“ eb”代表“电子商务”，您可以将短语发音为“电子商务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）： W3C协议，用于在ebXML倡议认可的分布式环境中交换信息。 ebXML令人感兴趣的是SOAP作为信封的功能，它定义了一个框架来描述消息中的内容以及如何处理消息。

ebXML.org主页提供了以下简短特征：

ebXML是一组规范，这些规范共同支持模块化的电子商务框架。 ebXML的愿景是建立一个全球电子市场，在这里，任何规模和地理位置的企业都可以通过交换基于XML的消息来彼此见面并开展业务。

换句话说，ebXML希望成功实现电子数据交换（Electronic Data Interchange），通常以其缩写EDI闻名。 （官方描述倾向于强调向EDI学习，而不是摒弃它。）

ebXML术语

整理ebXML涉及几个步骤。 理解ebXML细节的第一件事可能就是消化新缩略语和其他特殊术语的字母汤。 在查看ebXML交互的整个“构想”之前，右边的侧栏中（ ebXML术语 ）有很多需要考虑的术语 。 附加术语适用于整个系统，但是这些特定术语是一个很好的起点。 牢记这一新词汇，并从以下有关ebXML来源的背景知识开始，您可以开始理解ebXML中所有不同的过程是如何结合在一起的。

在本文开头描述了ebXML的功能之后（至少是概述），最后一节将更详细地介绍业务流程规范架构，该架构是ebXML底层基础结构的最重要元素之一。

背景

ebXML是一项倡议，其参与者和认可者几乎包括您可以想到的全球每家大公司和政府标准协会。 好吧，也许不是您能想到的每个人，但肯定有数百家大型公司和机构。

计算机/技术公司并不是唯一认可ebXML的实体； 支持者包括大量的工业，航运，银行和其他一般利益公司。 ebXML的直接赞助商是OASIS（结构化信息标准促进组织）和UN / CEFACT（联合国贸易便利化和电子商务中心）。 许多标准机构也参与其中，包括NIST（美国国家标准技术研究院）和W3C（万维网联盟）。

有了如此众多的支持者，ebXML似乎注定要占领世界。 我倾向于对行业流行语和炒作持愤世嫉俗的态度。 但是，对于ebXML，我最希望它在未来五年内成为大多数业务交易的全球协议，成为其计费标准。

在我看来，ebXML将通过将越来越多的企业无论如何都要进行的规范纳入规范而成功实现通用化，这实际上是通过使企业以不同的方式开展业务。 对于ebXML规范的开放性，我不确定我的估计是愤世嫉俗还是值得鼓舞，但是ebXML倡议显然持有拥抱现有的标准和方法的态度。

把它放在一起

基于ebXML技术架构规范的示例（ 图1 ）（ 请参阅 参考资料 ）可能对弄清ebXML对业务的意义大有帮助。

下面图1中的公司A将首先查看ebXML注册表的内容，尤其是可在此处下载或查看的核心库。 核心库（可能还有其他已注册的业务流程）将使公司A可以确定自己实现ebXML的要求（以及ebXML是否适合其业务需求）。

图1：两家公司之间的ebXML交互的高级概述

基于对ebXML注册中心提供的信息的回顾，公司A可以构建或购买适合其预期ebXML交易的ebXML实现。 ebXML计划的希望是供应商将支持ebXML的所有元素。 此时，“ ebXML系统”可能只不过是预打包的桌面应用程序。 或者，更现实的说，ebXML系统将至少与商业数据库系统（仍需要DBA）一样可管理。 图1表明假设的公司B使用了这种预包装的应用程序。

无论哪种方式，下一步都是让公司A在注册处创建CPP并进行注册。 公司A可能希望为注册管理机构贡献新的业务流程，或者只是引用可用的业务流程。 CPP将包含潜在合作伙伴确定公司A感兴趣的业务角色所需的信息，以及愿意为这些角色参与的协议类型。

一旦注册了公司A，公司B就可以查看公司A的CPP以确定它与公司B的CPP和要求兼容。 届时，B公司应该能够根据CPP的一致性以及作为ebXML标准或建议给出的协议协议，与A公司自动协商CPA。

最后，两家公司开始实际交易。 这些事务可能涉及符合进一步的ebXML标准和建议的业务消息。 但是，在所有这些情况的某个时刻，可能会发生“现实世界”的活动（例如，将货物从一个地方运送到另一个地方，或者提供服务）。 ebXML将有助于同意，监视和验证这些实际活动。 当然，在我们的“信息经济”中，许多事情可能仍在ebXML领域之内-也许是特定业务关系中的所有事情。

业务流程架构

利用UML的UN / CEFACT建模方法论（UMM）可能有助于对ebXML业务流程进行建模。 但是，这样的建模仅仅是推荐，而不是要求。 无论如何，由于本文针对XML开发人员，并且不涉及OOD（面向对象的设计），因此在这里更有趣的是查看XML文档中符合业务流程规范DTD和XML Schema的模型的表示形式。 此时，DTD（名称为“ ebXMLProcessSpecification-v1.00.dtd”）似乎是主要规则表示形式。 这个DTD和W3C XML Schema，它是（大概）语义和语法兼容，可以在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属性是流程规范的全局唯一标识符。 name和version特定于所表示的模型（ 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>
[...]

结论

ebXML规范的批准正在以相当快的速度进行（对于标准组织来说肯定如此）。 规范草案于2001年5月中旬被批准为1.0版建议。我怀疑，要实现这一雄心勃勃的愿景，可能还需要一两年的时间才能解决所有问题和细节。 但是，ebXML似乎在几年后将被广泛使用。 因此，现在是企业开始认真考虑自己的ebXML实施计划的时候了。

---

翻译自: https://www.ibm.com/developerworks/xml/library/x-ebxml/index.html