RosettaNet

RosettaNet 這一名字源自於 1799 年在埃及發現的 Rosetta Stone 。這要追溯到公元前 196 年，該石頭是在 Rosetta (Rashid) 鎮附近被人發現的，上面用兩種不同的語言以三種不同的筆體鐫刻了同一訊息。使用希臘語，學者們可以譯解該象形文字。 RosettaNet 這一名字非常類似於 18 世紀發現的 Rosetta Stone ，它是一個業務協定，通過為電子商務制定全球性語言，企業可以克服在 Internet 上經營業務的障礙。

基本介紹

• 外文名：RosettaNet
• 起源時間：1799年
• 起源地：埃及
• 來源：Rosetta Stone
• 性質：業務協定
• 主要目標：供應鏈及其最佳化

解析

簡而言之， RosettaNet 的主要目標集中在供應鏈及其最佳化上，它通過增強的 B2B 集成提高其效率和性能。 RosettaNet 電子商務過程標準旨在提高速度、效率和可靠性，允許在貿易合作夥伴間進行更大規模的協作和交流。 RosettaNet 提供一個公共交流平台，也可以說是一種公共語言，它允許參與業務流程的不同貿易合作夥伴自動化流程並在 Internet 上執行。該公共平台解決了 EDI 的主要成本開銷之一：業務流程中貿易合作夥伴的 IT 部門必須為與其互動的各貿易合作夥伴設計、實現和測試定製業務流程。與 EDI 和早期的 B2B 集成工作不同， RosettaNet 已完全設計用於與安全性的結合和按需集成；這使得原本要花費數日的傳統業務事務批處理可以在幾分鐘之內迅速完成。

EDI 和 RosettaNet 之間的主要區別在於， EDI 在公司之間交換文檔，而 RosettaNet 跨網路定義業務流程並對其進行集成，以確定最佳操作過程。大量的案例分析已顯示， RosettaNet 帶來了勝過 EDI 的多種利益。普遍認為帶來的利益如下：

· 更輕鬆、更經濟高效的實現，投資回報 (ROI) 更大

· 自動化更加大量的業務流程的能力

· 相對於批處理的實時事務處理

· 更高的可伸縮性

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 ，貿易合作夥伴可以從可重複規範和準則的全局框架中受益，該框架允許調節和自動化實時的、伺服器到伺服器的事務，這意味著獲得了跨整個供應鏈的全局事務可視性和一致性。使用這些標準化過程，還讓貿易合作夥伴降低了成本、更快速地回響客戶請求，而且它還可以提升效率、保證高度完整的數據處理。這些標準涵蓋以下核心領域：

· 合作夥伴接口過程（ Partner Interface Processes ）

· RosettaNet 實現框架（ RosettaNet Implementation Framework ）

· RosettaNet 業務和技術字典（ RosettaNet Business and Technical Dictionaries ）

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 不應加密。

字典

在過去，B2B 集成工作所面臨的核心問題之一是，處理各公司在其採購過程中所使用的惟一定義的術語。這不可避免地在貿易合作夥伴之中造成了許多混淆。為了解決該問題，RosettaNet 聯盟提供一個公共辭彙表，以供指導電子商務之用。RosettaNet Business Dictionary (RNBD) 指定，在貿易合作夥伴之間定義業務活動的屬性。該字典定義PIP Message Guideline 中的 Business Property（例如，業務地址）和 Fundamental Business Data Entity（例如，BusinessTaxIdentifier）。

RosettaNet Technical Dictionary (RNTD) 提供定義產品和服務的屬性。RNTD 排除了當實現多個 PIP 時貿易合作夥伴使用各自字典的需要。 而且它不再是行業特定的，可以用在各種供應鏈應用程式中。 RNTD 設計用於支持生產信息的無歧義、自動化的電子交換。這通過標準化用於描述產品特徵和信息的語義來實現。