kapok

ebXML 简介
　　为什么我们需要另一种 XML 语言呢？似乎每天都会开发出或批准新的 XML 标准。同时，又好像有一台巨型 XML机器在模仿业界或公共语言而创造着新语言。这种严酷的条件可能会引起某种不规则性，技术专家必须设法确定从过去所使用的遗留格式转移到新XML版本所产生的价值。当然，在维护健全性（sanity）和安全性时，必须已全部完成所有这些工作。
　　XML 语言这种不确定性部分是由于XML自身的简单性。XML无法独自实现多少功能，而且在某些方面还过于简单。必须在现有规范的基础上继续开发规范，将XML打造成为有用的东西。不少情况下，开发新 XML 语言仅因娱乐，似乎始终需要“XML化”每一种可能的计算格式或交互。
　　本简介的主要目标是使读者确信，ebXML并不只是对基于非XML EDI (Electronic Data Interchange) 的业务交互的格式的盲目更改。虽然ebXML早已被冠以“不过是另一种XML语言”的头衔，但事实上它对于业务而言有着重要的总体益处，这主要是由于其特殊的视角。

特殊业务的视角
　　ebXML锋芒最劲的功能之一是其实现特殊业务交互的能力。乍一看，特殊（ad hoc）这个术语会使人联想起自然灾害和意外事件等负面景象，但正是ebXML的该功能特性才使之对于经营电子商务而言功能尤为强大。
　　为了做一简单类比，设想在当地超市购买食品。假定您一直常从超市 A 购买食品。随着时间的推移，您基于其提供的商品和同意购买物品的流程（比如，与超市职员交互及使用ATM卡来进行购买）与该超市发展业务关系。虽然您与超市A有长久的关系，但您与超市的关系是临时的、是权宜之计。
　　设想现在新开一家商店，超市B，对于同一种商品它以更低的价格对外出售。当然，您最好与超市B开始发展新的业务关系，而且您可能会这样做，因为可以预计其业务流程和交互与超市A的没什么两样，也就是说您将用英语讲话以及可能使用ATM卡来进行交易。此处，这种业务关系的特殊本质是使自由市场经济运作起来；您可以轻松地放弃先前与超市A的关系并迅速与超市B建立新关系。
　　然而，通过 Internet 的电子商务另有基础设施的成本，该成本包括在经营业务的总价格之内。例如，如果安排两个业务进行电子交易，则必须付出筹备基础设施和软件的代价，而且还要使业务交互和策略规范化，包括充分的安全策略。
　　随着时间的推移，如果出现提供更低的商品和服务价格的新业务，则该交互模式和所需的技术将成为经济障碍。换言之，如果经营业务的成本包括沉重的基础设施和流程修改成本，则没有理由降低商品价格（如果最终不会遇到麻烦的话）。
　　例如，假定超市B只是稍稍压低价格，而超市的所有职员都讲不同的语言并只收两美元面值的现钞。在这种情况下，您经营业务所需的额外成本（例如，您学习语言以及手头上有合适的货币）可能会超过该价差。
　　ebXML的核心价值之一是其技术角度的宽广视野。它构建于XML、SOAP、HTTP及SMTP（所有这些都是比较容易进入的开放标准）之上。从理论上讲，关注技术广度会使电子商务接近于特殊自由市场的概念（我们在超市购物时都曾亲身体验过）。

XML Web 服务如何？
　　好像我已犯下了一个分类错误，在未提及XML Web服务或面向服务的架构的情况下而对SOAP和XML高谈阔论。然而，原来ebXML架构先于许多普通的XML Web服务标准，而不遵从大多数概念。了解XML Web服务和ebXML架构概念广度的一种简单方法是对以下三个术语进行重新整理：线、描述和发现。
　　第一个术语表示消息传输技术。对于XML Web服务和ebXML而言，都是SOAP，但相似之处仅此而已。XML Web服务有一个松散耦合的线堆栈，该堆栈由可靠传输 (WS-Reliability) 和 安全 (WS-Security) 的各个规范组成，而ebXML将所有这些功能都融入到自己的消息传递标准和ebMS中，从而使用混合技术。
　　对于描述和发现堆栈，XML Web服务分别使用Web Services Description Language (WSDL) 和UDDI。对于ebXML，这些描述和发现机制是ebXML注册的一部分；此外，ebXML还包含针对业务流程和协作的附加规范。
　　简而言之，ebXML是一个独立的规范集，具有内部一致性，而且不依赖于新兴标准和规范。

ebXML 概述
　　为了实现刚才所讨论的特殊视野，ebXML为业务交互提供一个完整的框架，全部是作为供应商中立规范集而交付的。该完整的框架设计用于答复大量的全盘业务问题。这些问题的观点针对指定的贸易合作伙伴来进行表述：

• 我如何描述自己的业务流程和特定接口呢？
• 我如何与其他合作伙伴共享自己的业务流程呢？
• 我如何得知自己的合作伙伴支持哪些业务流程呢？
• 我如何描述特殊交易的业务消息呢？
• 我如何描述要使用的安全策略和技术配置呢？

　　从理论上讲，如果贸易合作伙伴可以用这些术语描述其自身，则便可以进一步融入于临时的、电子的自由市场之中。这些问题中的许多可以通过实现共享的信息注册来解决，其中业务协议和流程可以集中。该中心点存储库称为ebXML注册。同时，还有实际线级消息传递层及业务流程规范和协作信息的规范。具体的ebXML规范集反映为如下概念：

• 集中的共享注册：Registry Information Model、Registry Services Specification (ebRIM、ebRS)
• 业务流程和协作：Business Process Specification Schema、Collaboration-Protocol Profile 和 Agreement Specification (ebBPSS、ebCPPA)
• 消息传递：Message Services Specification (ebMS)

ebXML 注册
　　ebXML实现的关键部分是ebXML注册。注册本身用途相当广泛，而且可以表示范围广泛的数据对象，包括 XML 模式、业务流程描述、ebXML Core Component、UML模型、一般贸易合作伙伴信息及软件组件。为了支持如此多样的数据，使用一个定义良好的信息模型而不是目录，将ebXML注册设计得更像一个数据库。这一点相当重要，因为人们普遍认为，ebXML注册在与XML Web服务（如UDDI）的注册服务在搞竞争。事实上，两者的目的截然不同：可能有人会在 UDDI目录中发现已发布的ebXML注册端点，但UDDI并不设计用于处理与ebXML注册的可能复杂分类关系。
　　有两种查看ebXML注册的方式：从外向内看，或从信息模型向外看。前一种查看方式提供更简洁的概观，因为它出自客户端期望访问ebXML注册所提供的两个接口中的某一个这一观点。这两个接口包括 Lifecycle Management Interface和Query Management Interface。在注册中，LifeCycle Management Interface用于管理对象的生命周期（亦称为存储库项目），Query Management Interface用于根据注册进行查询。为了领会这两个接口的工作原理，我们必须简单地看一下在注册中信息是如何进行逻辑存储的。

ebXML 注册信息模型
　　ebXML注册所使用的核心信息模型是基于树的分类方案，这意味着有关业界或业务合作伙伴的信息是在一个层次结构中进行分布的。ebXML注册信息模型与简单层次结构的主要不同点在于，它能传达更复杂的关系。例如，考虑以下在ebRIM 规范中表示的基于树的层次结构：

图1 ebXML注册信息模型 (ebRIM)

　　在图1中，读者会注意到该层次结构的一部分加上了阴影。加阴影的部分为实际注册对象，而未加阴影的部分称为分类。在许多方面，ebXML注册所使用的分类方案更像事物的本体或知识结构。请注意，树中的任意一片树叶都可以分享附加分类关系。

ebXML注册接口
　　ebXML Registry Architecture根据注册服务和注册客户端定义。在该信息模型中，注册服务有两个用于管理对象的主要接口：生命周期管理和查询管理。生命周期管理接口有submitObjects、updateObjects、removeObjects 及 deprecatedObjects等抽象方法，这些方法用来将对象或分类提交到信息模型中。与此类似，查询管理接口有submitAdhocQuery、getRegistryObject及getRepositoryItem等接口，它们用于查询注册本身。
　　抽象注册服务接口使用Web Services Description Language (WSDL) 文件定义，该文件可以从OASIS ebXML Registry Technical Committee获得。有三个到这两个接口的具体绑定：HTTP上的 SOAP、ebMS及直接 HTTP。绑定选择的多样性意味着，ebXML客户端将以瘦客户端和胖客户端的形式发布。瘦客户端很可能成为基于浏览器的只读接口，而胖客户端用于对运行注册进行更改或添加。
　　然后做出总结，有5个重要的ebXML规范：ebRIM、ebRS、ebBPSS、ebCPP 和 ebMS。ebMS 规范定义ebXML Message Service Protocol，该规范设计用于启用贸易合作伙伴间安全可靠的业务消息交换。虽然作为业务事务的一部分而发送的实际业务消息固然很重要，但ebXML的消息传递部分不过是整个ebXML架构的一小部分而已，该部分根据许多不同的组件和规范进行定义。关于ebXML交互如何进行的一个重要的高层次画面可以就ebXML功能阶段来进行表述。

ebXML功能阶段
　　筹备新业务关系的举措意味着访问共享的ebXML注册，这通常由当前功能阶段所支配。三个功能阶段通过ebXML技术架构定义。这三个部分包括实现阶段、发现和检索阶段以及运行时阶段。每一阶段都携带自己安全的需求和流程。接下来的三小节给出各个阶段的生动概述。总体而言，关于实现和检索的前两阶段表示排序的信号交换，而最后的运行时阶段则表示实际业务单元。

实现阶段
　　ebXML的实现阶段被认为是贸易合作伙伴使用ebXML框架做出有效决策来经营业务的时间。如图2所示，在该阶段，贸易合作伙伴将根据ebXML所得的结论来分析自己的业务流程，而且还要将自己的业务流程发布到注册。在该阶段，实际的ebXML实现必须产生，要么通过核心ebXML规范自行构建要么通过第三方供应商获取。实现阶段的结果是一个工作式ebXML框架，包括一组发布的业务流程和接口。Collaboration Protocol Profile (CPP) 也在此时发布。

图2 实现阶段

发现和检索阶段
　　ebXML的发现和检索阶段包括，使用注册来发现其他贸易合作伙伴所发布的业务流程和接口的贸易合作伙伴。通常，特定合作伙伴的CPP或合作伙伴集合在此时进行交换。CPP描述特定业务流程和技术细节，包括安全、传输及可靠性细节。CPP中所表示的具体细节用作在运行时阶段所交换消息的基础。图 3 展示了两个正相互发现对方的Collaboration Protocol Profile文档的贸易合作伙伴。

图 3 发现和检索阶段

运行时阶段
　　运行时阶段与实际业务事务和合作伙伴之间所交换消息的表现有关。在运行时阶段通常没有运行时访问注册。各参与的贸易合作伙伴所发布的CPP实例不足以构成Collaboration Protocol Agreement (CPA)。CPA是依赖于特定交易会话的特殊业务协议，它从各贸易合作伙伴所发布的不同CPP实例的交集派生出显式需求。如图3所示，各贸易合作伙伴通过在各合作伙伴的CPP实例之间执行交运算来提供该CPA。在实际的ebMS交换之前，各贸易合作伙伴应对CPA实例进行比较，以确保两者之间保持一致。在交易发生之前，CPA实例应与两个终点都相匹配。
　　图4可以用三个简单的步骤进行总结。在步骤1，各个贸易合作伙伴负责获取想使其参与的业务合作伙伴的必需的CPP文档。在大多数情况下，CPP将从 ebXML 注册中进行检索。在步骤2，各合作伙伴派生Collaboration Profile Agreement (CPA)，从而使用CPP中所提供的选择范围成为显式的。最后，在步骤3，合作伙伴可以在CPA的支配下开始业务事务。从这种意义上讲，ebMS消息和派生的CPA之间存在着某种策略关系。

图 4 运行时阶段

Collaboration Protocol Profile和Collaboration Protocol Agreement
　　正如早先所描述的，ebXML的关键组件之一是称为CPP或Collaboration Protocol Profile的工件。CPP包含支持特殊业务流程的具体技术实现细节。将CPP发布到ebXML注册并描绘出受支持的技术绑定细节。CPP的主要目的是确保贸易合作伙伴（依赖于不同供应商的ebXML框架）之间的互操作性。
　　从安全角度来看，CPP非常重要，因为它屏蔽了安全策略信息及特定消息交换细节（全部用XML表示）。在安全网关或防火墙的上下文中，该策略信息可以用于配置安全代理来处理相应的消息级安全操作。
　　CPP所定义的某些消息交换细节包括传输协议机制、消息可靠性机制、传输安全性机制、信任的工件（如，X.509证书）以及消息级安全策略信息等具体内容。除了实现细节，CPP还引用了受支持的业务协作（定义受支持的业务事务）集合。
　　CPP不独自实施消息交换的具体选择。只有至少两个CPP文档的交集才产生能实施特定消息级安全和可靠性机制的CPA。CPA的组织结构几乎等同于CPP，而且出于声明性安全策略的目的，在CPP中出现的元素和描述由CPA共享。最后，读者应将CPA视为一组ebMS消息交换的最终支配性安全策略声明。

CPP结构
　　CPP描述消息交换能力及贸易合作伙伴所支持的业务协作的集合。消息交换能力是运行时阶段的实现细节和策略，业务协作是特定的业务事务，它用处理规范文档进行描述。图5是CPP的图解视图。

图5 CPP 概念

　　有关图5的最重要的一点是CPP表示一个在生成CPA时将缩小的选择列表。CPA通常依赖于贸易合作伙伴双方所使用的某一处理规范文档。处理规范文档表示正在执行的业务单元，它超出本文所讨论的范围。关于处理规范文档的更多信息可以在ebXML Business Process Specification Schema找到。

CPP数据模型
　　具体的CPP实例通过5个直接子元素定义，如清单1所示。用一种简单的BNF语法描述元素的基数。“+”表示一个或多个，“?”表示零个或一个，而“*”表示零个或多个。缺少指示符表示正好一个。

清单1 Collaboration Protocol Profile (CPP) XML结构

<CollaborationProtocolProfile>
　　(<PartyInfo>) +
　　(<SimplePart>) +
　　(<Packaging>) +
　　(<Signature>) ?
　　(<Comment>) *
</CollaborationProtocolProfile>

各元素描述如下：

• <PartyInfo>
  该元素标识其能力由CPP描述的组织（或其各部分）。
  
• <SimplePart>
  该元素描述用于构成复合消息的成分。
  
• <Packaging>
  该元素用于描述如何为传输打包消息头及有效负载。
  
• <Signature>
  该元素包含用于对实际CPP文档进行签名的XML Signature。
  
• <Comment>
  该元素用于注释。

　　<CollaborationProtocolProfile> 的每个子元素都包含许多多层嵌套的子项。CPP本身相当复杂，要分析其结构会用去一整篇文章。目前，我将站在最外层，展示一个高层次的概观。
　　如果我们要放下这些概念，进入更深一层的具体实现，则我们可以更详细地查看各个功能阶段。

实现、发现和检索阶段细节
　　按开发人员的观点，这些阶段需要与发布和检索业务文档和流程的ebXML注册进行交互。对于实现阶段，将使用ebXML注册生命周期管理 服务，而对于发现阶段，则将使用查询管理接口。为了实际访问这些接口，开发人员有根据已发布的WSDL选择三种具体绑定的权利。在这种情况下，WSDL 是ebXML Registry Service规范的一部分并将随不同的规范版本而发生变化。可用的绑定包括 HTTP 上的SOAP、ebMS 及直接HTTP。
　　第一个绑定表示一个胖客户端，其中开发人员使用在注册中管理对象状态的WSDL描述来构建实际的客户端。在这种情况下，该客户端的表现非常像纯Web服务客户端。第二个绑定与第一个非常类似，不过线格式使用ebMS（构建于SOAP之上）。第三个选项是 HTTP 接口，它是三者中量级最轻的一个。原则上，它可以通过 XML 感知浏览器来实现。使用该绑定，开发人员可以通过注册本身的本机 Web 应用程序访问该注册。在此必须强调的是，在该阶段无业务事务；我们并不过是在通过为参与业务事务的其他合作伙伴提供必要的信息来管理注册。

运行时阶段
　　在前两个阶段，业务信号交换发生之后，已传输的实际消息将受 ebMS规范所支配。ebMS 规范使用带有附件的SOAP打包业务数据。主SOAP有效负载包含已使用XML Signature进行签名的头信息，包括实际有效负载的清单或列表。实际业务消息作为一个或多个MIME部分进行传送，而且不在SOAP正文中表示。虽然ebMS基于SOAP，但它宁愿将SOAP用作一个方便的打包机制也不愿将其用作成熟的Web服务传输。
　　ebMS 的模式定义是根据SOAP v1.1扩展点定义的。特别指出的是，元素结构的BNF语法样式视图如清单2所示。与SOAP相比，ebMS规范在SOAP头中添加了<MessageHeader>，并在SOAP正文中添加了<Manifest>元素。该结构使用标准基数符号，其中“*”表示零个或多个，“?”表示零个或一个，“+”表示一个或多个，而缺少符号则表示正好一个。为了提高透明度，已省略名称空间。

清单2 SOAP/ebMS元素结构

<Envelope>
  <Header>
    <MessageHeader>
      <From>
      <To>
      <CPAId>
      <ConversationId>
      <Service>
      <Action>
      <MessageData> 
      (<DuplicateElimination>) ?
      (<Description>)          *
    </MessageHeader>              
  <Header>
  <Body>
     (<Manifest>
       (<Reference>        +
         (<Schema>)        *
         (<Description>)   *
        </Reference )      +
     </Manifest> )         ?
  <Body>
</Envelope>

　　实际业务有效负载是特定于域的，而且您会发现它作为第一主SOAP有效负载之后的MIME附件。

结束语
　　本文介绍了ebXML及其特殊的业务视野。此时，读者头脑中应该有一个清晰的ebXML总体轮廓，包括构成标准的概述。此外，读者还应该领会Collaboration Protocol Profile (CPP) 的目的及其与Collaboration Protocol Agreement (CPA) 的不同程度，同时还对ebXML功能阶段进行了一些深入分析。

参考资料
· ebXML.org
· S/MIME规范
· PGP/MIME
· W3C签名
· W3C XML加密
· W3C Web Services活动
· SOAP/XML协议
· 带有附件的SOAP消息
· OASIS WS-Security

原文出处
http://dev2dev.bea.com/technologies/webservices/articles/ebXML.jsp