RosettaNet

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

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

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

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

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

· 更高的可伸縮性

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

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

· RosettaNet 實現框架（ RosettaNet Implementation Framework ）

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

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 部分派生。

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 網絡應用協議棧。

圖 3 描述了 RosettaNet Business Message 的各個組成部分。該消息是在 RosettaNet 端點間進行交換的基本單位，而且包含 PIP （即操作和簽名消息）中的各個文檔及其他任何相關實體，比如標題、附件和數字簽名。通過提供關於支配其創建和表現形式的規則的細節， RNIF 可以確保所有貿易合作伙伴都能理解這些業務消息。

<?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。

<?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>

<?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 設計用於支持生產信息的無歧義、自動化的電子交換。這通過標準化用於描述產品特徵和信息的語義來實現。