RosettaNet 这一名字源自于 1799 年在埃及发现的 Rosetta Stone 。这要追溯到公元前 196 年，该石头是在 Rosetta (Rashid) 镇附近被人发现的，上面用两种不同的语言以三种不同的笔体镌刻了同一消息。使用希腊语，学者们可以译解该象形文字。 RosettaNet 这一名字非常类似于 18 世纪发现的 Rosetta Stone ，它是一个业务协议，通过为电子商务制定全球性语言，企业可以克服在 Internet 上经营业务的障碍。

RosettaNet 是什么?

RosettaNet 和 ebXML

RosettaNet 标准

Partner Interface Processes (PIP)

RNIF

RosettaNet Business Message

RosettaNet 字典

RosettaNet 是什么?

简而言之， RosettaNet 的主要目标集中在供应链及其优化上，它通过增强的 B2B 集成提高其效率和性能。 RosettaNet 电子商务过程标准旨在提高速度、效率和可靠性，允许在贸易合作伙伴间进行更大规模的协作和交流。 RosettaNet 提供一个公共交流平台，也可以说是一种公共语言，它允许参与业务流程的不同贸易合作伙伴自动化流程并在 Internet 上执行。该公共平台解决了 EDI 的主要成本开销之一：业务流程中贸易合作伙伴的 IT 部门必须为与其交互的各贸易合作伙伴设计、实现和测试定制业务流程。与 EDI 和早期的 B2B 集成工作不同， RosettaNet 已完全设计用于与安全性的结合和按需集成；这使得原本要花费数日的传统业务事务批处理可以在几分钟之内迅速完成。

EDI 和 RosettaNet 之间的主要区别在于， EDI 在公司之间交换文档，而 RosettaNet 跨网络定义业务流程并对其进行集成，以确定最佳操作过程。大量的案例分析已显示， RosettaNet 带来了胜过 EDI 的多种利益。普遍认为带来的利益如下：

· 更轻松、更经济高效的实现，投资回报 (ROI) 更大

· 自动化更加大量的业务流程的能力

· 相对于批处理的实时事务处理

· 更高的可伸缩性

RosettaNet 和 ebXML

通过考察其他基于 XML 的 B2B 集成项目（即 ebXML ），我们尝试将 RosettaNet 与其进行比较。人们常常将 ebXML 描述为横向 B2B 标准，意思是有一组用于所有电子商务的规范；它是通用的而不针对任何特殊部门或行业。而另一方面， RosettaNet 是一个纵向标准；它关注特定行业的需要（例如，电子部件制造商）以及供应链自动化和优化的业务范畴。自两个项目创建以来，各自标准中的规范已存在着某些重复和交叉。或许让这些标准彼此适应的最佳方式是考虑把 RosettaNet （纵向）插入到 ebXML （横向）中。关于这方面有一个很好的实例，使用 ebXML Business Process Specification Schema (BPSS) 来描述 RosettaNet Partner Interface Processes (PIPs)? 。正如我们稍后即将看到的， PIP 定义了合作伙伴之间的业务流程。

RosettaNet 、实现 和 Web Services

要了解 RosettaNet 如何影响 Web services ，我们从定义 Web services 开始。术语 Web services 指的是使用 SOAP 和 WSDL 来描述和访问网络上的服务。许多公司已认识到使用 Web services 来实现其业务流程的好处。这包括 Web services 所基于的开放标准、面向服务的方法及实现的灵活程度，从而允许重用现有的基础设施和技术。所有这些听起来都非常熟悉，而且此时您可能会想，“如果能使用 Web services 实现自己的业务流程，那么使用 RosettaNet 的利益又何在？”为了回答这个问题，我们需要更详细地查看业务流程并理解公共过程和私有过程之间的区别。

业务流程由一组步骤组成，当执行时，这些步骤实现某个业务目标。 RosettaNet Implementation Framework (RNIF) 将私有过程定义为公司的内部业务流程，将公共过程定义为与贸易合作伙伴的相关交互。首先，我们设想一个简单的业务流程：请求报价。客户通过发送一个包含报价说明书的消息，向供应商发出报价请求。供应商检查产品清单中项目的可用性，如果符合报价要求，则向客户发送报价。如果供应商无法满足报价要求，则它可能为该客户确定另一个供应商。在这种情况下，向客户发送推荐。

在本例中，在供应商的产品清单中查检项目可用性和确定备选供应商都是内部过程，这些过程对于客户而言不是可见的，而且不涉及贸易合作伙伴。因此这样的过程是私有的。通常，各公司都有其自己的遵循自己内部标准的私有过程定制实现。它们可能利用 Java 、 CORBA 、 Web services 或遗留技术的任何组合。在实例的第一步中，客户向供应商发出了报价请求；这是公共过程。使用 Web services 单独实现这一步的问题在于，在贸易合作伙伴之间没有明确定义的对话，我们很快便会遇到 EDI 所面临的关键问题：对于我们要合作的每一个贸易合作伙伴，我会分别不同地实现该服务。通过确保该公共过程的 Web services 实现遵循 RosettaNet 标准，我们可以向经营同一业务的任意数量的贸易合作伙伴请求报价，而无需每次都做重复工作。因此， RosettaNet 和 Web services 是令人称道的， Web services 担当 RNIF 的实现机制。然而，应当强调的是，我们并不限于将 Web services 用作 RosettaNet 的实现。私有业务流程可以用任何适当的技术（包括 Web services ）来实现，但是要确保当该标准 B2B 在贸易合作伙伴之间通信时公共过程遵循 RosettaNet 规范，这样才有意义。在典型的实现模型中，我们可能期望找到要用于处理私有业务流程的定制 Web services 和符合 RosettaNet 的服务来处理公共过程。

RosettaNet 标准

RosettaNet 标准为电子商务标准化提供一个健壮的、非专有的解决方案，它是免费的，可以通过 RosettaNet 网站公开。这些标准是由全球领先的高科技公司通力协作而开发出来的。通过遵循这些标准，贸易合作伙伴、解决方案提供商及系统集成商可以利用这些专业技术和经验。此外，通过采用 RosettaNet ，贸易合作伙伴可以从可重复规范和准则的全局框架中受益，该框架允许调节和自动化实时的、服务器到服务器的事务，这意味着获得了跨整个供应链的全局事务可视性和一致性。使用这些标准化过程，还让贸易合作伙伴降低了成本、更快速地响应客户请求，而且它还可以提升效率、保证高度完整的数据处理。这些标准涵盖以下核心领域：

· 合作伙伴接口过程（ Partner Interface Processes ）

· RosettaNet 实现框架（ RosettaNet Implementation Framework ）

· RosettaNet 业务和技术字典（ RosettaNet Business and Technical Dictionaries ）

Partner Interface Processes (PIP)

Partner Interface Processes (PIP) 是对确定每一层供应链而进行广泛研究的结果。它们是一组常规的、标准化的过程，可以用于现实世界中企业对企业相互适应的基础。 PIP 旨在通过为各贸易合作伙伴指定业务文档的结构和格式、活动、操作及角色来封装业务流程。简而言之，可以将 PIP 定义为与贸易合作伙伴进行交换的表现形式和消息内容。要记住 PIP 是规范而不是实现；这赋予了采用 RosettaNet 的贸易合作伙伴很大的灵活性，可以自己实现 PIP 规范或购买可降低开发成本的第三方产品。 RosettaNet 将 PIP 指定的整个电子商务供应链领域划分为 7 组称为“集群”的核心业务流程，外加用于管理目的的第 8 个集群。这些集群如下：

· RosettaNet Support ：提供管理功能。

· Partner Product 和 Service Review ：允许为贸易合作伙伴配置文件和产品信息订阅的开发进行信息收集、维护和分发。

· Product Information ：支持产品和设计信息的分发和定期更新，包括产品变更声明和详细技术规范。

· Order Management ：支持整个订单管理业务领域，从定价和提供报价，一直到采购订单初始化、状态报告和管理。订单开票、付款和差错通知也都使用该过程集群来管理。

· Inventory Management ：支持库存管理，包括协作、补给、价格保护、报告和受限产品的分配。

· Marketing Information Management ：支持市场信息发布，包括活动计划、引导信息和设计注册。

· 服务和支持：提供售后销售技术支持、服务担保支持及资产管理能力。

· 制造：提供设计交换、配置、过程、质量和其他制造方面的信息，以支持“虚拟制造”环境。

每个集群由两个或多个段组成。段是相关功能的组。作为一个例子，“CLUSTER 3: Order Management”拥有用于管理报价、订单条目以及运输和分发方面的段。段进一步划分为 PIP，PIP 定义一个或多个活动（Activity），而活动又指定了操作（Action）。在解释活动和操作的区别之前，我们先分析一个关于集群的层次结构的实例：

CLUSTER 3: Order Management

Segment A: Quote and Order Entry

PIP 3A1: Request Quote

Activity: Request Quote

Action: Quote Request Action

Action: Quote Confirmation

Segment B: Transportation and Distribution

Segment C: Returns and Finance

Segment D: Product Configuration

图 1 是展示 PIP 中业务角色、消息及其交换顺序的 PIP 交互图。

可以将 PIP 描述为专门的系统到系统的、基于 XML 的对话。每个 PIP 规范都由以下三个主要部分组成 ：

· Business Operation View (BOV) 负责捕获业务实体的语义和角色之间的信息流（当它们参与业务活动时）。 BOV 通常附有流程图。

· Functional Service View (FSV) 派生于 BOV ，它在 PIP 执行期间详细描述了网络组件之间的交互。网络组件通常被视为 RosettaNet “服务”。在图 1 中，“ Buyer （买方）”和“ Seller （卖方）”是两个 RosettaNet 服务，双方都映射到 BOV 中定义的角色。

· Implementation Framework View (IFV) 根据 RosettaNet Implementation Framework 指定 RosettaNet 服务之间的操作消息格式和通信要求。通信要求包括安全的传输协议，如 SSL 和数字签名。对于消息格式， RosettaNet 为在 PIP 执行时进行交换的操作消息分配 XML DTD 和 Message Guideline 。要注意， RosettaNet 联盟旨在使用 W3C XML-Schemas 来定义未来的 Action 和 Signal 消息的结构。

活动（ Activity ）是贸易合作伙伴（更确切地说，是在 BOV 中定义的贸易合作伙伴角色）之间业务信息的交换。例如，可以将一对贸易合作伙伴视为 Buyer 和 Seller 。 Buyer 可以向 Seller 请求报价，而且该活动被正式命名为“ Request Quote ”。在 Activity 过程中进行交换的 PIP 模型的 BOV 中，每个 Action 都映射到 Business Document 。 PIP 规范的早期版本包括了对等网络组件间的通信请求。从 RNIF 2.0 起，情况与以往不同了，这些方面可以从 PIP 规范的 BOV 和 FSV 部分派生。

RNIF

RosettaNet Implementation Framework (RNIF) 设计用于辅助电子商务系统实现者和解决方案提供者，他们需要创建或实现协同执行 RosettaNet PIP 的可互操作的软件应用程序组件。通过遵守 RNIF 规范，这些团体可以确保其应用程序能与经营同一业务的贸易合作伙伴进行集成。RNIF 定义 PIP 的打包、身份验证、授权、加密和非拒绝性要求。RNIF 2.0 还介绍传输独立性的概念：这确保 RosettaNet Business Message 必须以与发送者生成它们的完全相同的方式交付给贸易合作伙伴。 当前， RosettaNet 为 HTTP 和 SMTP 传输协议指定传输绑定和其他细节。将来，其他实现也将受支持，不过到那时，开发人员应意识到使用其他协议将被认为不符合 RosettaNet 。为了确保所有贸易合作伙伴都能支持至少一种传输协议，HTTP 传输协议必须可用于所有解决方案提供者。RNIF 2.0 的核心是 RosettaNet Business Message 规范。图 2 展示了用于交换 RosettaNet Business Message 的 RosettaNet 网络应用协议栈。

RosettaNet Business Message

图 3 描述了 RosettaNet Business Message 的各个组成部分。该消息是在 RosettaNet 端点间进行交换的基本单位，而且包含 PIP （即操作和签名消息）中的各个文档及其他任何相关实体，比如标题、附件和数字签名。通过提供关于支配其创建和表现形式的规则的细节， RNIF 可以确保所有贸易合作伙伴都能理解这些业务消息。

Preamble Header 实例

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE Preamble SYSTEM "Preamble_MS_V02_00.dtd">

<Preamble>

<standardName>

<GlobalAdministeringAuthorityCode>RosettaNet</GlobalAdministeringAuthorityCode>

</standardName>

<standardVersion>

<VersionIdentifier>V02.00</VersionIdentifier>

</standardVersion>

</Preamble>

通过 Preamble XML 文档的样本实例我们可以看到，它识别标准 (RosettaNet) 及其版本 (02.00)。 Activity 中第一条消息的发送者固定了 Preamble 中元素的值，而且这些值必须在后继消息中保持不变。 RNIF 规范声明，Preamble 的结构必须遵循 Preamble DTD。

Delivery Header 实例

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE DeliveryHeader SYSTEM "DeliveryHeader_MS_V02_00.dtd">

<DeliveryHeader>

<isSecureTransportRequired>

<AffirmationIndicator>Yes</AffirmationIndicator>

</isSecureTransportRequired>

<messageDateTime>

<DateTimeStamp>20041109T145200.000Z</DateTimeStamp>

</messageDateTime>

<messageReceiverIdentification>

<PartnerIdentification>

<domain>

<FreeFormText>DUNS</FreeFormText>

</domain>

<GlobalBusinessIdentifier>012345678</GlobalBusinessIdentifier>

<locationID>

<Value>London</Value>

</locationID>

</PartnerIdentification>

</messageReceiverIdentification>

<messageSenderIdentification>

<PartnerIdentification>

<GlobalBusinessIdentifier>880123456</GlobalBusinessIdentifier>

<locationID>

<Value>Hong Kong</Value>

</locationID>

</PartnerIdentification>

</messageSenderIdentification>

<messageTrackingID>

<InstanceIdentifier>083084</InstanceIdentifier>

</messageTrackingID>

</DeliveryHeader>

Service Header 实例

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ServiceHeader SYSTEM "ServiceHeader_MS_V02_00.dtd">

<ServiceHeader>

<ProcessControl>

<ActivityControl>

<BusinessActivityIdentifier>Create Purchase Order</BusinessActivityIdentifier>

<MessageControl>

<fromRole>

<GlobalPartnerRoleClassificationCode>Buyer</GlobalPartnerRoleClassificationCode>

</fromRole>

<fromService>

<GlobalBusinessServiceCode>Buyer Service</GlobalBusinessServiceCode>

</fromService>

<Manifest>

<numberOfAttachments>

<CountableAmount>0</CountableAmount>

</numberOfAttachments>

<ServiceContentControl>

<ActionIdentity>

<GlobalBusinessActionCode>Purchase Order Request Action

</GlobalBusinessActionCode>

</ActionIdentity>

</ServiceContentControl>

</Manifest>

<toRole>

<GlobalPartnerRoleClassificationCode>Seller</GlobalPartnerRoleClassificationCode>

</toRole>

<toService>

<GlobalBusinessServiceCode>Seller Service</GlobalBusinessServiceCode>

</toService>

</MessageControl>

</ActivityControl>

<GlobalUsageCode>Test</GlobalUsageCode>

<pipCode>

<GlobalProcessIndicatorCode>3A4</GlobalProcessIndicatorCode>

</pipCode>

<pipInstanceId>

<InstanceIdentifier>20041109T145200.000Z</InstanceIdentifier>

</pipInstanceId>

<pipVersion>

<VersionIdentifier>1.4</VersionIdentifier>

</pipVersion>

<KnownInitiatingPartner>

<PartnerIdentification>

<domain>

<FreeFormText>DUNS</FreeFormText>

</domain>

<GlobalBusinessIdentifier>880123456</GlobalBusinessIdentifier>

<locationID>

<Value>Hong Kong</Value>

</locationID>

</PartnerIdentification>

</KnownInitiatingPartner>

</ProcessControl>

</ServiceHeader>

Service Header 为消息提供过程上下文。它还提供以下方面的信息：消息是 Test 消息还是 Production 消息、PIP 的发起者、发起者是已知的合作伙伴还是未知的合作伙伴以及QoS协商信息（当前未使用）。

RNIF2.0 的一个新功能（RNIF 1.1 中所没有的）是支持通过集线器路由 RosettaNet Business Message。 Delivery Header 使该路由变得轻松自如，而且还包含用于发送和接收贸易合作伙伴身份的元素、消息的日期和时间戳以及全球惟一跟踪 ID。消息发起者必须确保 Delivery Header 在 RosettaNet Business Message 中出现，而且必须由发起者进行添加。正如我们前面所提到的，RosettaNet Business Message 中的每一个文档都作为单独的 MIME 或 S/MIME 部分进行打包。在 RNIF 2.0 中 ，RosettaNet Business Message 的某些部分可以加密，包括 Service Content 和 Service Header 部分。为了使无访问加密 Service Header 的权限的第三方集线器能为消息进行路由，RNIF 指定，Delivery Header 不应加密。

RosettaNet 字典

在过去，B2B 集成工作所面临的核心问题之一是，处理各公司在其采购过程中所使用的惟一定义的术语。这不可避免地在贸易合作伙伴之中造成了许多混淆。为了解决该问题，RosettaNet 联盟提供一个公共词汇表，以供指导电子商务之用。RosettaNet Business Dictionary (RNBD) 指定，在贸易合作伙伴之间定义业务活动的属性。该字典定义PIP Message Guideline 中的 Business Property（例如，业务地址）和 Fundamental Business Data Entity（例如，BusinessTaxIdentifier）。

RosettaNet Technical Dictionary (RNTD) 提供定义产品和服务的属性。RNTD 排除了当实现多个 PIP 时贸易合作伙伴使用各自字典的需要。 而且它不再是行业特定的，可以用在各种供应链应用程序中。 RNTD 设计用于支持生产信息的无歧义、自动化的电子交换。这通过标准化用于描述产品特征和信息的语义来实现。