ebXML体系架构

6.2.4　ebXM L体系架构

1.贸易伙伴信息(合作协议配置文件CPP和合作协议协定CPA)

为了简化电子业务的运作，潜在的贸易伙伴需要一种机制对外发布他们所支持的业务过程以及其交换业务信息能力的技术实施细则。这些可以通过合作协议配置文件(CPP)来实现。CPP是贸易伙伴用来表达其支持的业务过程和业务服务接口需求的文件，并被其他使用ebXML的贸易伙伴所接受。

一个具体业务协定是CPA，CPA意味着两个或多个使用ebXML进行业务交易的贸易伙伴的正式合作。

CPP描述了贸易伙伴支持的具体技术能力以及为交换商业文件所需的服务接口。CPP中包含了贸易伙伴的基本信息:合同信息、行业分类、支持的业务过程、接口需求和消息服务需求，CPP中也可包括安全和其他具体的实施细则。每个ebXML贸易伙伴应在ebXML符合注册服务中注册他们的CPP，这样就提供了一种发现机制，使得贸易伙伴之间可以互相发现，并且发现其他贸易伙伴支持的业务过程。CPP定义中对于存在的多种实现可能(如HTTP或SMTP传输)，应该明确指定使用哪一种选择。

CPA表示两个CPP的相互协定，它由使用ebXML进行电子业务的贸易伙伴相互协定达成。CPA描述了下列内容:

(1)消息服务。

(2)两个或多个贸易伙伴协定的业务过程需求。

从概念上讲，为了达成电子业务交易的CPA，ebXML支持一个具有三层子集的视图(见图6-9)。最外面的一层是贸易伙伴能够支持的所有能力，下面一个子集是贸易伙伴协定支持的性能。

一个CPA包括消息服务接口需求和贸易伙伴双方协定业务过程的实施细则。贸易伙伴可以在ebXML注册服务中注册他们的CPA。

图6-9　CPA的三层视图

业务合作是ebXML贸易伙伴声明的第一个支持命令。在ebXML注册或其他服务的目录服务上，用于发布的专门定义的文档便于进行业务合作的声明。图6-10概括了ebXML中合作协议协定的范围。

2.业务过程和信息建模

业务过程和信息元模型是一种机制，它通过统一的建模理论使得贸易伙伴能获取具体业务剧本的细节。业务过程描述了共享的合作中，贸易伙伴具体的角色、关系和责任，以及如何与其他贸易伙伴进行交互。角色间的交互可以看做一连串设计好的业务交易。每次业务交易都可以表示为电子业务文件的一次交换。业务文件则由可重用的业务信息组件组成。在低层次上，业务过程可以分解为可重用的核心过程，而业务信息对象可以分解为可重用的核心组件。

图6-10　CPA的范围

ebXML业务过程和信息元模型支持需求、分析和设计，提供一套语义集，并形成便于业务过程和信息整合及互操作性的基准。

元数据模型的另一方面是提供支持配置，ebXML业务交易的运行时间系统。所需数据元组的直接规范通过从其他视图中提取建模元素，规范的模式(Specification Schema)形成ebXML业务过程和信息元模型的一个语义子集。规范的模式可以采用两种单独的表示方法: UML文档和文件类型定义DTD。

ebXML业务过程和信息元模型与ebXML规范模式的关系如图6-11所示。

图6-11　ebXML元模型——语义子集

规范模式支持业务交易的规范以及从业务交易到业务合作的转换。每个业务交易都可以用标准样式之一来实现。这些标准样式决定了贸易伙伴之间完成交易所交换的消息和信号。为了有助于规定这些格式，规范模式包括一组标准样式及其样式通用的建模元素组。因此一个业务过程的全部规范包括业务过程和信息元模型及据此规定的规范模式和样式的标识。它们是CPP和CPA信息的主要来源，如图6-12所示。

图6-12　ebXML元模型

当构造一个新的业务过程时，并不一定要使用建模语言，但是如果要用建模语言开发业务过程，就应使用统一建模语言(UML)。这种强制的目的在于保证创建业务过程时使用统一的、一致的建模方法。使用统一建模方法的好处之一是可以比较模型，以避免重复已有的业务过程(见图6-13)。

为了保证创建一致的业务过程和信息模型，ebXML将定义一组与主数据库对应的核心业务过程。ebXML的用户可以扩展或使用自己的业务过程。

两个贸易伙伴之间的协定定义了他们共同做业务交易的实际情况。业务过程和信息元模型与CPA之间的接口是业务过程文件的组成部分。它们可以作为XML文件表示的业务过程和信息元模型中的业务交易和合作层。业务交易的XML表示可在业务过程和贸易伙伴信息模型中共享。

业务过程示例应规定与其他贸易伙伴交换业务数据的约定。业务信息可由ebXML主数据库中的组件构成。通过引用适宜的业务和信息模型或者业务文件(如DTD或者Schemas)的XML文件，业务过程文件可以直接或间接地引用核心组件，连接核心组件和主数据库的机制应是每个组件的唯一标识符。

图6-13　ebXML业务过程和信息建模层

业务过程实例可以从一个注册服务传输到另一个注册服务。通过ebXML消息服务，它也可以在注册和用户应用程序之间进行传输。

在ebXML基础结构中使用的业务过程实例，可以通过注册查询进行检索，因此，每个业务过程都应包含一个唯一的标识符。

ebXML业务过程和信息元模型可根据UN/CEFACT建模方法(UMM)来生成，或者符合ebXML业务过程和信息元模型的其他任何方式。

3.核心组件和主数据库

多个业务领域中出现的业务对象，并在各行业间可重用的公共数据项称为核心组件。核心组件提供了ebXML实现互操作的方法，将贸易伙伴与中性的ebXML语法联系起来，核心组件捕捉了现实世界中业务概念的语境以及这些概念、与其他业务信息对象和内容描述间的关系，描述了核心或聚合信息实体在具体的ebXML电子业务剧本中的使用。

核心组件可以是一个独立的业务信息块，也可以业务信息对象合成一族，即聚合信息实体。

核心组件应被唯一标识，并具备下列基本功能:

(1)应利用ebXML注册机制可存储和检索。

(2)应获取和保留满足业务的基本信息。

(3)应使用XML句法进行表述。

核心组件可在业务文件中直接或间接引用。作为业务文件的一部分，业务过程可以单个或成组的核心组件定义作为必需的或可选的信息。通过在规定注册中进行存储和检索，核心组件应与注册机制相连接。核心组件可与其他XML词汇的XML元素实现连接，所以它可以作为一种语义等价被双边或单边地引用。

核心组件可以包含属性或者另外一个核心组件的一部分，对一个具体的业务环境，聚合核心组件的流程应包括标识一个核心组件在另一个核心组件中位置的方式。它由结构化的内容组合而成，便于在另一个核心组件或聚合信息实体的不同层次中重用。核心组件出现在业务信息对象中时，使用业务过程和消息元模型定义语境。

4.注册

ebXML注册(见图6-14)提供了一套服务，它使得贸易伙伴之间可以共享信息。在注册这个组件中，保留了一个连接已注册项目的原数据的接口。通过注册服务中的接口(API)可以访问ebXML注册。

图6-14　注册的整体架构

注册应存储的项目，由使用多字节字符组的语法进行表述。由提交组织定义的每一层级的每一个注册项必须有唯一标识。这将有利于注册应用程序的查询。

注册应返回零或一个确定的结果，以回复查询唯一标识符的内容。在这种情况下，如果出现两个或多个结果，则应向注册机构报告一个出错报文。

一个注册项目的构成应适于标识、命名、描述它的信息的关联，给出其管理和访问状态，定义其持续性和不定性，按照预定义的分类进行分类，确定其文件表示类型，并标识提交和负责组织。

注册接口相当于注册应用程序的进入机制。人与注册的交互应建立在注册接口的上一层(如Web浏览器)，而不是作为一个独立的接口。

注册接口应独立于网络协议套层(如: TCP/IP协议处于HTTP/SMTP的下一层)。注册接口交互具体结构包括在ebXML消息负载(Payload)中。

注册支持的流程还包括:

(1)一个在注册与注册客户端之间具体的CPA。

(2)一组包含注册与注册客户端的功能性过程。

(3)一组在注册与注册客户端之间交换的业务报文，作为业务过程的一部分。

(4)一组基本的接口机制，以支持业务报文和有关的检索与响应机制。

(5)一个具体的CPA，用于在符合的ebXML注册之间进行交互。

(6)一组注册—注册之间交互的功能性过程。

(7)一组出错响应和恢复处理条件。

为了便于发现流程，注册使用人机交互的检索方式(如Web浏览器)，用户应能根据有效的注册分类表浏览。

注册服务用于创建、修改和删除注册项目及其元数据。当访问时，采用适当安全协议为主数据库提供鉴别和监护。

ebXML注册系统中所有项目都应被分配一个统一标识符(UID)。对于ebXML的全部内容，UID是必须的参考。可以使用全球统一标识符(UUIDs)确保注册中注册项目在全球范围内唯一。因此，当系统通过UUID检索注册时，应仅有一个检索结果。

为了便于业务过程和信息元模型的语义识别，注册服务系统应提供一种人可阅读的注册项目描述机制。现有的业务过程和信息元模型(如RosettaNet PIPs)及核心组件在ebXML符合的注册系统注册时，应被赋予一个UID。这些UID可以通过XML语法以各种方式来实现。其中包括:

(1)非常明确的参考机制(比如，URN: UID方法)。

(2)参考点方式(比如，URI: UID/名称空间: UID)。

(3)与W3C模式符合的基于对象的参考(比如，URN:复合类型名称)。

(4)标准的数据类型(比如，ISO8601: 2000日期/时间/数据日期类型和传统数据类型)。

ebXML中的组件必须支持多种语言。UID的参考非常重要，因为它提供了一种语言中性参考机制。为了支持多种语言，ebXML规范应与Unicode和ISO/IEC10646字符集和UTF-8或者UTF-16的字符编码保持一致。

ebXML消息服务作为传输机制，用于输入和输出注册的所有通信。通过ebXML注册服务进行发布和检索业务过程、核心组件。

XML元素提供了贸易信息的标准元数据，并通过ebXML注册服务管理。因此，注册之间可以交叉引用。

5.消息服务

ebXML消息服务机制提供了一种标准的方法，在ebXML贸易伙伴间交换业务消息。它提供了一种非常可靠的方式，不依赖于技术和解决方案。ebXML消息包含消息标头(路由和传输必需的)和负载部分。

从概念上讲，ebXML消息服务分为三个部分:

①一个抽象的服务接口。

②消息服务层所提供的功能。

③到底层传输服务的映射。

抽象接口、消息服务层次与传输服务三者之间的关系如图6-15所示。

ebXML基础结构的用户间通过各种传输协议(如SMTP、HTTP/S、FTP等)交换ebXML消息，ebXML消息服务为此提供了一种安全、稳定、可靠的机制。在分布的ebXML组件(包括注册机制和符合的用户应用程序)间，ebXML消息服务预定义所有这些消息的格式。

ebXML消息服务不能对负载的内容作任何限定。

ebXML消息服务支持简单的(单路径)和请求/回复(同步或异步)消息交换。

当贸易伙伴间交换多重负载或多重消息时，ebXML消息服务支持负载的排序。

在合作协议配置协定(包括与消息传送有关的安全和业务过程功能，但不限于此)中，ebXML消息服务层执行贸易伙伴。合作协议协定规定了每个贸易伙伴都愿意接受的行为。这些规则由一些表格定义，如:正式的合作协议协定，在业务交易发生(如在线购书)时创建的相互作用的协议，或者其他协定的表格。消息服务层的功能就是执行这些规则，而违反规则会导致错误发生，出错信息将以适当的方式报告。

图6-15　ebXML消息服务

ebXML消息服务执行下列安全功能，包括:

(1)识别。

(2)鉴别。

(3)授权(存取控制)。

(4)保密性(加密)。

(5)完整性(消息签名)。

(6)抗抵赖性。

(7)日志记录。

ebXML消息服务(见图6-16)为ebXML提供了一个抽象接口，它的功能包括:

(1)发送——发送一条ebXML消息——参数值从ebXML消息标头中获得。

(2)接收——表示同意接收ebXML消息。

(3)通知——通知意料的和意外的事件。

(4)查询——提供查询具体的ebXML消息交换情况的方法。

ebXML消息服务应该与内部系统相连接，包括:

图6-16　消息服务架构

(1)内部系统中已接收消息的路径。

(2)出错通知。

图6-17说明了ebXML消息的逻辑结构。

在通信协议封装和ebXML消息封装的外部，ebXML消息由一个可选的传输协议组成。使用M IME对ebXML报文封装。在电子业务环境中，由于伙伴之间交换信息的多样性，可使用M IME作为打包方案。例如:双方或多方贸易伙伴复杂的业务交易需要包含一系列业务文件(XML或其他文件格式)、二进制图像或其他相关的业务消息的负载。

图6-17　ebXML消息的逻辑结构

6.一致性

与ebXML一致的通用框架、概念和规范包括:对ebXML一致性的概括、对每个ebXML技术规范一致性的指导、与技术架构规范的条款一致。目标是:

(1)保证对一致性的共同的理解，一致性的要求。

(1)保证每个组件说明中连续表示的一致性。

(3)促进业务过程和消息的互操作性和开放式交换。

(4)鼓励使用一致性测试，同时，促进一致性测试开发的一致性。

ebXML的一致性包括两部分，即与ebXML基础架构的一致和与ebXML相关技术规范的一致。ebXML一致性的主要目的就是增强XML业务文件和消息在实施和开放式交换之间的互操作性的可能性。如果实施与ebXML规范的需求一致，互操作和开放式交换则更容易实现。

ebXML一致性就是保持其与ebXML系统的一致，在这个系统中，包含了所有的ebXML基础结构的所有架构组件，并能保证每个ebXML技术规范最起码的一致性，包括在技术架构规范中功能和接口的需求。

在ebXML的内容中，如果符合了所有ebXML技术规范的要求，则认为它坚持了一致性，每个ebXML技术规范的一致性条款都表达了一致性的要求。一致性条款明确规定了所有该规范一致的需求。在每个规范中，这些需求可在不同层使用和成组。

技术架构规范中一致性的需求是:

(1)应支持本技术规范的所有功能和接口要求。

(2)不应规定任何与ebXML及其组件相冲突或不一致的需求。

(3)可以包含增加比本规范需求更具体的一致性需求条款。

(4)应仅包含可测试的需求。

一致性测试的目标就是确定实施是否与ebXML规范需求一致。一致性测试能够让卖方实施建立在ebXML基础之上的兼容和互操作系统。ebXML实施和应用程序应用有效的测试组测试来验证其与ebXML规范的一致性。

一些中性组织如OASIS和NIST的一些公开有效测试组可被用来确定ebXML实施、应用程序和组件是否与ebXML保持一致。卖方可使用开放式参考实施来测试其产品接口的兼容性、一致性和互操作性。

7.安全问题

ebXML安全模型在一个单独的文件中表述。安全模型适用于整个ebXML基础架构，它的基本目的就是最大限度地满足ebXML用户的需要。

安全模型遵从ebXML需求文件中规定的安全需要。

参考资料: ebXM L业务剧本示例下列剧本定义了如何使用ebXML相关软件来实施一般电子业务的模式。这些剧本用来指导公司如何使用开放的标准在Internet上正确地进行电子业务，它们是规范和真实交易的桥梁。

计划使用ebXML软件的公司可从中获益。因为这些举例显示了公司如何基于ebXML规范实施普通的商业剧本。

目录:

(1)两个贸易伙伴达成一个协定，进行相关电子交换。

(2)三个或多个贸易伙伴建立一个业务过程实施供应链，并进行相关电子交换。

(3)一个公司建立一个入口(Portal)来定义一个使用外部业务服务的业务过程。

(4)三个或多个贸易伙伴使用共享的业务过程进行业务，并进行相关电子交换。

剧本1　两个贸易伙伴达成一个协定，进行电子数据交换

在这个剧本中:

(1)每个贸易伙伴定义了自己的合作协议配置文件(CPP)。

(2)每个配置文档参考:

●ebXML注册中一个或多个业务过程。

●一个或多个消息定义，每个消息定义都由注册中的可重用组件构成。每个CPP定义了:

●贸易伙伴进行的业务交易。

●贸易伙伴能够支持的技术协议(如: HTPP，SMTP等)和技术性能(如具体的加密技术、有效性、鉴别)。

●贸易伙伴确认每个CPP后，生成一个CPA。

(3)贸易伙伴实施各自的配置文件，通过下面的方式来实现:

●创建或构造一个业务服务接口

●或者将他们所运行的传统软件进行升级

在两种情形中，步骤大约是这样的:

●将传统软件加入到按消息服务规定的ebXML技术基础结构中。

●软件能够正确地实施规定内容。

●语义交换与认同的消息定义一致。

●技术交换与ebXML消息服务一致。

(4)贸易伙伴开始交换消息，完成协定的业务交易。

剧本2　三个或多个贸易伙伴间实施供应链业务过程，进行电子数据交换

两个贸易伙伴的简单情形的供应链可用剧本1中的术语定义。

在这里是多个贸易伙伴的供应链类型(见图6-18):

图6-18

与剧本1的不同之处在于“贸易伙伴2”同时与两个不同的贸易伙伴进行交易。我们假定业务过程的局部“状态”由每个贸易伙伴自己来维持，也就是说，每个贸易伙伴对自己所涉及的业务贸易负全部的责任(“贸易伙伴3”只知道“贸易伙伴2”，“贸易伙伴2”知道“贸易伙伴3”和“贸易伙伴1”，“贸易伙伴1”知道“贸易伙伴2”)。

在这个剧本中:

(1)每个贸易伙伴定义自己的CPP。每个CPP都包括:

●一个或多个ebXML注册中的业务过程。

●一个或多个消息定义。每个消息定义都由ebXML注册中可重用的组件(核心组件)构成。

CPP定义了:

●贸易伙伴从事的业务交易。“贸易伙伴2”必须至少能够支持两种商业交易。

●贸易伙伴所支持的技术协议(如HTPP，SMTP等)和技术性能(如具体加密技术、有效性和鉴别)。对于“贸易伙伴2”，它与“贸易伙伴1”和“贸易伙伴3”进行交换的技术需要是不同的。因此，“贸易伙伴2”必须能够支持不同的协议和特性。

●贸易伙伴确认彼此的配置文件，生成相应的合作协议协定(CPA)(在这种情况下至少有2个)。

●“贸易伙伴2”参与两个合作协议协定(CPA)。

(2)贸易伙伴实施各自的配置文件，并通过下面的途径来实现:

●创建或者构造业务服务接口。

●将自己运行的传统软件进行升级。

这两种情况下，其步骤是:

●将传统软件加入到按消息服务规定的ebXML技术基础结构中。

●软件能够正确地实施规定内容。

●语义交换与认同的消息定义一致。

●技术交换与ebXML消息服务一致。

●为了能够与不同的贸易伙伴进行业务合作，“贸易伙伴2”可能需要执行一个复杂的业务服务接口。

(3)贸易伙伴开始交换消息，完成协定的业务交易。

●“贸易伙伴3”向“贸易伙伴2”发出一个订单。

●“贸易伙伴2”(最终)向“贸易伙伴1”发出一个订单。

●“贸易伙伴1”履行订单。

●“贸易伙伴2”履行订单。

剧本3　某公司建立一个使用外部业务服务定义的业务过程入口

本剧本描述了一个服务提供方(SP)。“客户”请求SP提供服务。SP通过与其他可以提供相关信息的贸易伙伴实施交换，来履行客户的请求。

图6-19是最简单的模型:

图6-19

在此省略此剧本的描述。

剧本4　三个或多个贸易伙伴使用共享业务过程，进行电子数据交换

本剧本包括三个或者更多的贸易伙伴复杂的关系。一个典型的例子就是使用外部传输服务来发送货物(见图6-20)。

图6-20

在本剧本中，每个贸易伙伴与多于一个的贸易伙伴发生关系，而且这种关系是非线性的。客户向SP订购产品或货物，由第三方递送。

在本剧本中:

(1)每个贸易伙伴定义自己的CPP。每个CPP包括:

●一个或多个ebXML注册中的业务过程。

●一个或多个消息定义。每个消息定义都由ebXML注册中可重用的组件(核心组件)构成。

每个CPP定义了:

●贸易伙伴从事的业务交易。在这种情况下，每个贸易伙伴必须至少能够支持两种商业交易。

●贸易伙伴所支持的技术协议(如HTPP，SMTP等)和技术性能(如具体的加密技术、有效性和鉴别)的要求。如果支持不同电子交换的技术基础结构不同，每个贸易伙伴都必须能够支持不同的协议和性能(如:订单通过Web网页完成，递送是通过E-mail的格式)。

●贸易伙伴确认彼此的配置文件，生成CPA。在本剧本中，每个贸易伙伴都必须商定至少两个协定。

每个贸易伙伴都参与两个合作协议协定(CPA)。

(2)贸易伙伴实施各自的配置文件，并通过下面的途径来实现:

●创建或构造一个业务服务接口。

●或将自己运行的传统软件进行升级。

这两种情况，其步骤大约是:

●将传统的软件加入到按消息服务规定的ebXML技术基础结构中。

●软件能够正确地实施规定内容。

●语义交换与认同的消息定义一致。

●技术交换与ebXML消息服务一致。

●为了能够适应不同贸易伙伴之间CPA的差异性，所有的贸易伙伴都可能需要实施复杂的业务服务接口。

(3)贸易伙伴开始交换消息，完成协定的业务交易。

●客户向SP发一个订单。

●SP确认客户的订单。

●SP通知邮递服务商向客户递送货物。

●邮递服务商向客户递送货物。

●客户通知SP已收到货物。