ebXML 快速指南

上一頁
下一頁

ebXML 簡介

企業不可避免地以各種方式相互互動。直到最近幾年，許多大公司都習慣於透過電子資料交換 (EDI) 自動通訊，這允許兩家公司使用預定的訊號進行通訊。

EDI 的問題在於它非常昂貴，最初它是為大型機世界建立的。現在 ebXML 正在取代 EDI。

定義

ebXML 代表 **電**子 **業**務可 **擴**展 **標**記 **語**言。它是一個全球電子商務標準，使任何人在任何地方都可以透過網際網路與任何人進行商務交易。

特點

ebXML 的特點如下：

  • ebXML 是一個端到端的 B2B XML 框架。
  • ebXML 是一套規範，可以實現模組化框架。
  • ebXML 依賴於網際網路現有的標準，例如 HTTP、TCP/IP、MIME、SMTP、FTP、UML 和 XML。
  • ebXML 幾乎可以在任何計算平臺上實施和部署。
  • ebXML 提供具體的規範，以實現動態的 B2B 協作。

ebXML 願景

ebXML 旨在建立一個全球電子市場，讓任何規模的企業，在任何地方都可以

  • 透過電子方式找到彼此。
  • 開展業務 -
    • 使用 XML 訊息交換。
    • 根據標準的業務流程順序。
    • 具有清晰的業務語義。
    • 使用現成的商業應用程式。
    • 根據雙方共同商定的貿易伙伴協議。

為什麼選擇 ebXML？

  • 現有的 B2B 框架不足
    • EDI 和 RosettaNet 過於重量級且過於僵化。
    • BizTalk 是專有的、單廠商的和單平臺的。
  • 僅靠簡單物件訪問協議 (SOAP)、Web 服務定義語言 (WSDL) 和通用描述、發現和整合 (UDDI) 是不夠的。
    • WSDL 沒有解決業務協作問題。
    • SOAP 的基本形式不提供安全可靠的訊息傳遞。
    • UDDI 不提供業務物件的儲存庫功能。
  • 越來越需要標準化業務協作以解決以下問題：
    • 業務流程
    • 參與業務協作的各方及其角色
    • 在業務協作中交換 XML 文件
    • 業務協作的安全、可靠性和服務質量要求

    ebXML 解決了所有這些需求。

ebXML 成立組織

ebXML 是聯合國貿易便利化和電子商務中心 (UN/CEFACT) 和結構化資訊標準促進組織 (OASIS) 的一項聯合倡議。

聯合國貿易便利化和電子商務中心 (UN/CEFACT)

  • 它代表聯合國貿易便利化和電子商務中心。
  • 它維護著電子資料交換 (EDI) 的 UN/EDIFACT 標準。

結構化資訊標準促進組織 (OASIS)

  • 它代表結構化資訊標準促進組織。
  • 它建立和維護 XML 互操作性規範，並得到廣泛的行業支援。

ebXML 架構

根據定義，**B2B 協作**的迭代生命週期包括以下步驟：

  • 流程定義
  • 合作伙伴發現
  • 合作伙伴註冊
  • 電子外掛
  • 流程執行
  • 流程管理
  • 流程演變

ebXML 的整體規範旨在涵蓋 B2B 協作的幾乎整個過程，並旨在滿足上述需求。

ebXML 團隊定義的 ebXML 架構提供：

  • 定義業務流程及其相關訊息和內容的方法。
  • 註冊和發現具有相關訊息交換的業務流程式列的方法。
  • 定義公司配置檔案的方法。
  • 定義貿易伙伴協議的方法。
  • 統一的訊息傳輸層。

因此，ebXML 的技術架構由五個模組組成：

  • 業務流程規範
  • 合作伙伴配置檔案和協議
  • 登錄檔和儲存庫
  • 核心元件
  • 訊息服務

這些模組將在接下來的五個章節中介紹。該圖顯示了 ebXML 的簡化架構。

ebXML Architecture

ebXML 業務流程

業務流程是企業執行的某項活動，例如購買電腦部件或銷售專業服務。它涉及以某種可預測的方式在兩個或多個貿易伙伴之間交換資訊。

業務流程定義規範使組織能夠表達其業務流程，以便其他組織能夠理解。它使公司內部或多個公司之間的業務流程整合成為可能。

**ebXML 業務流程規範模式 (BPSS)** 提供了描述組織如何開展業務的 XML 文件的定義。ebXML BPSS 是對構成業務流程的合作伙伴、角色、協作、編排和業務文件交換的宣告。

下圖給出了業務流程的概念檢視。

Business Process Overview

業務協作

業務協作是一組編排的業務交易活動，其中兩個貿易伙伴交換文件。

最常見的是二元協作，其中兩個夥伴交換文件。當資訊在多於兩個方之間交換時，就會發生多方協作。

多方協作實際上是編排的二元協作。

在最低級別，業務協作可以分解為業務交易。

業務交易

業務交易是業務流程中工作的原子級別。它要麼完全成功，要麼完全失敗。

業務交易是貿易伙伴實際傳輸業務文件的交易。

業務文件流

業務交易實現為在請求方和響應方角色之間流動的業務文件。總會有一個請求業務文件，並且根據所需的交易語義（例如，單向通知與雙向對話），可以選擇一個響應業務文件。

實際的文件定義是使用 ebXML 核心元件規範實現的，或者透過 ebXML 之外的某種方法實現，但會產生 ebXML 業務流程規範可以指向的 DTD 或模式。

編排

編排是用狀態及其之間的轉換來表達的。業務活動被稱為抽象狀態，業務協作和業務交易活動被稱為具體狀態。使用活動圖概念（例如起始狀態、完成狀態等）在 ebXML 業務流程規範模式中描述編排。

業務文件

業務文件由業務資訊物件或先前已識別的較小的資訊塊組成。

當然，這些塊或元件不攜帶任何資訊。它們僅僅是結構，例如 XML 模式或 DTD，定義資訊和表示。最終結果是一個可預測的結構，其中放置資訊，以便最終文件的接收者可以解釋它以提取資訊。

業務流程規範示例

下面給出了業務流程規範的部分示例。

<BusinessTransaction name="Create Order">
    <RequestingBusinessActivity name=""
        isNonRepudiationRequired="true"
        timeToAcknowledgeReceipt="P2D"
        timeToAcknowledgeAcceptance="P3D">
    <DocumentEnvelope BusinessDocument="Purchase Order"/ >
    </RequestingBusinessActivity>
    <RespondingBusinessActivity name=""
        isNonRepudiationRequired="true"
        timeToAcknowledgeReceipt="P5D">
    <DocumentEnvelope isPositiveResponse="true"
        BusinessDocument="PO Acknowledgement"/>
    </DocumentEnvelope>
    </RespondingBusinessActivity>
</BusinessTransaction>

結論

業務流程規範

  • 描述兩個合作伙伴之間的協作
  • 定義角色、關係和責任
  • 定義業務文件的編排
  • 以平臺和供應商無關的格式表達
  • 可以使用 UMM（聯合國貿易便利化和電子商務中心建模方法）建模
  • 由業務流程規範模式 (BPSS) 正式描述
  • 由 CPP 和 CPA 引用。
  • 引用業務文件定義。

ebXML - CPP 和 CPA

協作協議配置檔案

協作協議配置檔案 (CPP) 提供了有關特定貿易伙伴打算如何進行電子商務的所有必要資訊。CPP 定義了貿易伙伴的以下屬性：

  • 透過業務流程實現的業務能力。

  • 他們在協作中扮演的角色（買方或保險公司）。

  • 交付渠道和傳輸協議。（HTTP、SMTP 等）

  • 業務文件的打包方式。

  • 安全限制（SSL、數字證書）。

  • 對業務流程規範的每方配置。

CPP 儲存在 ebXML 登錄檔中，並具有全域性唯一識別符號 (GUID)，業務合作伙伴可以透過登錄檔找到彼此的 CPP。

CPP 中的資訊可以搜尋，因此潛在的貿易伙伴可以確定該組織是否具有開展業務的能力。

CPP 的結構

CPP 在其根元素上定義名稱空間和版本，以區分任何後續更改。CPP 的結構由一個根協作協議配置檔案元素以及以下元素組成：

  • **PartyInfo：**PartyInfo 元素提供有關組織的資訊。

  • **Packaging：**Packaging 元素提供有關實際構建訊息的方式的資訊。訊息作為 SOAP 訊息處理。

  • **Signature：**文件的可選部分。

  • **註釋元素：**可以包含。

<CollaborationProtocolProfile
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="1.1">
<PartyInfo>
    ...
    <!--REQUIRED, Repeatable-->
...
</PartyInfo>
<Packaging id="ID">
    ...
    <!--REQUIRED-->
    ...
<Packaging>
<ds:Signature>
    ...
    <!--OPTIONAL-->
    ...
</ds:Signature>
<Comment>
    ...
    <!-- OPTIONAL -->
    ...
</Comment>
</CollaborationProtocolProfile>

貿易伙伴協議

貿易伙伴協議 (TPA) 是一個合同，定義了貿易關係中雙方當事人的法律條款和條件以及技術規範。CPA 源自貿易伙伴的 CPP。

電子 TPA 指定的規則獨立於任一方的業務流程。TPA 中條款和條件的技術描述以 XML 文件的形式表達，該文件配置每個 IT 系統以根據協議規則執行。

TPA 屬性包括其名稱、合作伙伴名稱、起始日期和結束日期、角色和其他引數。通常，一方生成 CPA 並將其提供給另一方批准。一旦雙方達成協議，他們各自獲取同一 CPA 的電子副本並使用它來配置他們的系統。

CPA 也可以新增到登錄檔以供參考，但這並非標準要求。

CPA 的結構

CPA在其根元素上定義名稱空間和版本，以區分任何後續更改。CPP的結構由一個根協作協議協議元素以及以下元素組成

  • 開始和結束：這些元素以協調世界時表示此CPA生效的起始和結束時間。

  • 參與方資訊（PartyInfo）：PartyInfo元素提供有關組織的資訊。此處包含參與協議的雙方參與方資訊。

  • 打包（Packaging）：Packaging元素提供有關訊息實際構造方式的資訊。訊息作為SOAP訊息進行處理。

  • 簽名：文件的可選部分。

  • **註釋元素：**可以包含。

<CollaborationProtocolAgreement
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink = "http://www.w3.org/1999/xlink"
cpaid="http://www.example.com/cpas/CPAS"
version="1.7">
<Status value = "proposed"/>
<Start>1998-04-07T18:50:00</Start>
<End>1999-04-07T18:50:00</End>
<ConversationConstraints invocationLimit = "150"
concurrentConversations = "10"/>
<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
</PartyInfo>
<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
    </PartyInfo>
<Packaging id="N20">
    ...
    <!--REQUIRED, repeatable-->
    ...
</Packaging>
<ds:Signature>
    <!--OPTIONAL-->
</ds:Signature>
<Comment xml:lang="en-gb">
    <!--OPTIONAL-->
</Comment>
</CollaborationProtocolAgreement>

ebXML - 註冊中心和資源庫服務

什麼是註冊中心和資源庫？

ebXML註冊中心充當資源庫對外部世界的索引和應用程式閘道器，它包含管理各方如何與資源庫互動的API。ebXML資源庫是元件的持有者。

  • ebXML註冊中心是ebXML架構的核心。

  • 註冊中心也可以被視為支援使用ebXML進行電子商務的專案資料庫的API。

  • ebXML註冊中心作為資料庫，用於共享與ebXML業務交易相關的公司資訊，例如公司能力、業務流程、技術藍圖、訂單表單、發票等等。

  • 資源庫中的專案是透過向註冊中心發出的請求建立、更新或刪除的。

  • 資源庫為貿易伙伴提供共享的業務語義。

  • ebXML註冊中心是訪問和發現共享業務語義的介面。

  • 註冊中心介面的設計獨立於底層網路協議棧，例如基於TCP/IP的HTTP或SMTP。

註冊中心提供已提交內容的穩定持久儲存，其中包括XML模式和文件、流程描述、核心元件、上下文描述、UML模型、有關各方資訊，甚至軟體元件。這可以表示為如下圖所示的服務軟體棧。

Registry Stack

ebXML註冊中心的目標

ebXML註冊中心的目的是為了使利益相關方之間能夠共享資訊，從而實現它們之間的業務流程整合。

ebXML註冊中心的益處

ebXML註冊中心提供以下益處：

  • 註冊內容的發現和維護。

  • 支援協作開發，使用者可以建立XML內容並將其提交到註冊中心，供授權方使用和潛在增強。

  • 在貿易伙伴之間的互動過程中，持久儲存Web服務業務流程執行語言(WS-BPEL)、WSDL和業務文件。

  • 註冊內容的安全版本控制。

  • 聯合協作註冊中心，透過無縫查詢、同步和重新定位註冊內容，提供註冊內容的單一檢視。

  • 透過電子郵件或Web服務進行事件通知。

合規性

根據ebXML註冊中心服務規範，如果註冊中心實現滿足以下條件，則符合ebXML規範：

  • 它支援ebXML註冊中心資訊模型。

  • 它支援註冊中心介面和安全的語法和語義。

  • 它支援ebXML註冊中心DTD。

  • 可選支援註冊中心中SQL查詢的語法和語義。

如果註冊中心客戶端實現滿足以下條件，則符合ebXML規範：

  • 它支援ebXML CPA和引導過程。

  • 註冊中心客戶端介面的語法和語義。

  • ebXML錯誤訊息DTD。

  • ebXML註冊中心DTD。

註冊中心物件和元資料

註冊中心物件

指提交到註冊中心進行儲存和保管的物件

  • 稱為“資源庫專案”

  • XML文件或DTD、業務流程模型、CPP等。

元資料

  • 它由註冊中心用於對註冊中心物件進行分類和管理。

  • 它由註冊中心條目表示。

註冊中心資訊模型(RIM)

註冊中心資訊模型(RIM)為ebXML註冊中心中的元資料提供高階藍圖。這可以表示為服務軟體棧或如下圖所示的服務金字塔。資訊模型的元素表示關於內容的元資料，而不是資源庫中的內容本身。註冊中心資訊模型定義了儲存和組織在註冊中心中的物件型別。

資訊模型是元資料型別及其之間關係的路線圖。註冊中心資訊模型可以對映到關係資料庫模式、物件資料庫模式或其他物理模式。

RIM Stack

ebXML 核心元件

“核心元件捕獲有關現實世界業務概念的資訊，以及該概念與其他業務概念之間的關係。核心元件可以是單個業務資訊片段，也可以是一組業務資訊片段。之所以稱為核心，是因為它出現在許多不同的行業/業務資訊交換領域。”

…由Eric Chiu簡化的xbXML定義

核心元件是一個基本的、可重用的構建塊，包含表示業務概念的資訊。採購訂單部分的核心元件示例包括採購訂單日期、銷售稅和總金額。

一般來說，核心元件用於許多不同的領域、行業和業務流程。在ebXML環境中，核心元件是用於訊息和文件中的XML語義和業務詞彙的構建塊。

從業務流程中的特定業務文件中，我們可以參考核心元件，它包含最少的一組電子商務資訊。如果業務流程是電子商務術語中的動詞，則核心元件表示名詞和形容詞。

核心元件可用於多個業務部門，但它也可以成為特定業務領域的上下文專用，例如單個行業領域。

核心元件與註冊中心一起工作，因為它可以使用標準ebXML註冊中心進行儲存和檢索。中央核心元件庫作為跨行業業務流程的常見業務實踐的參考文件。

工具和參考

ebXML為業務和技術分析師提供的核心元件基本參考和工具列表如下：

  • 上下文和核心元件的可重用性：本檔案包含上下文定義、分類值列表的來源以及描繪核心元件和上下文描述符關係的圖形模型。

  • 上下文驅動程式目錄：本檔案提供上下文驅動程式目錄。

  • 文件組裝和上下文規則：這描述了使用上下文驅動的核心元件組裝文件的程式和模式。

  • 核心元件字典：本檔案分為幾個部分。每個部分都從關於適用類別和核心元件型別的資料開始。

  • 核心元件編輯器和瀏覽器：這些工具幫助分析師瀏覽現有的核心元件並將它們整合起來，以定義貿易伙伴之間交換的XML訊息的格式，並正確定義和應用上下文規則。

核心元件示例

  • 核心元件A

    • 供應商（行業1）
    • 製造商（行業2）
    • 供應商（行業3）

  • 核心元件B

    • 分銷商（行業1）
    • 批發商（行業2）
    • 商家（行業3）

  • 核心元件C

    • 商店（行業1）
    • 門店（行業2）
    • 零售商（行業3）

結論

核心元件是 -

  • 唯一可識別的。
  • 可重用的低階資料結構
    • - 例如，參與方、地址、電話、日期、貨幣
    • - 上下文相關的
  • 用於定義業務流程和資訊模型。
  • 促進不同系統之間的互操作性。
  • ebXML中的核心元件可以包含另一個核心元件。

ebXML 訊息服務

完整的郵件稱為郵件包，它是一個多用途網際網路郵件擴充套件 (MIME) 物件。郵件包包含兩個主要部分：

  • SOAP訊息容器：這是訊息的必需部分，包含ebXML的SOAP擴充套件元素，例如路由資訊、貿易伙伴資訊、訊息標識和傳遞語義資訊。

  • 有效負載容器：這是訊息的可選部分，可以包含要在各方之間交換的任何型別的資訊。

訊息設計標準

根據訊息服務規範，ebXML訊息服務的設計目標是：

  • 儘可能利用現有標準。

  • 易於實現。

  • 支援各種規模的企業。

  • 支援各種通訊協議（HTTP、SMTP、FTP等）。

  • 支援任何型別的有效負載（XML、EDI事務、二進位制資料等）。

  • 支援可靠的訊息傳遞。

  • 確保安全。

訊息架構

ebXML訊息服務的設計是在ebXML計劃的整體背景下進行的。但是，ebXML技術架構是模組化的，訊息服務可以獨立於ebXML使用。

ebXML訊息服務在業務應用程式和網路協議之間具有三個邏輯架構級別：

  • 訊息服務介面 (MSI)：它是業務應用程式呼叫訊息處理程式功能以傳送和接收訊息的應用程式介面。類似於ODBC、JDBC和其他抽象服務介面，它將訊息處理程式功能作為定義的一組API公開給業務應用程式開發人員。

  • 訊息服務處理程式 (MSH)：它具有基本服務，例如報頭處理、報頭解析、安全服務、可靠訊息傳遞服務、訊息打包和錯誤處理。

  • 訊息傳輸介面 (MTI)：它旨在透過各種網路和應用程式級通訊協議傳送訊息。傳輸介面將ebXML特定資料轉換為網路服務和協議攜帶的其他形式。這涉及雙方之間的完整交換， piggybacking on top of existing protocols in the network stack. (這句話翻譯略有調整，因為直接翻譯顯得不通順)

下圖顯示了ebXML訊息架構。

ebXML Architecture

訊息格式

ebXML訊息必須根據ebXML訊息服務規範進行格式化，並且必須符合MIME語法、格式和編碼規則。XML元素的定義由XML模式提供，該模式擴充套件了SOAP以定義ebXML訊息頭、跟蹤頭、清單、狀態和確認。

結論

ebXML訊息必須根據ebXML訊息服務規範進行格式化，並且必須符合MIME語法、格式和編碼規則。XML元素的定義由XML模式提供，該模式擴充套件了SOAP以定義ebXML訊息頭、跟蹤頭、清單、狀態和確認。

ebXML訊息 -

  • 使用帶附件的SOAP作為有效負載信封。

  • 執行在各種通訊協議上，例如HTTP、SMTP、FTP。

  • 支援業務交易中所需的高階語義。（安全性與可靠性）

ebXML 使用示例

下圖顯示了一個ebXML場景，這使得更容易理解ebXML的概念。此示例取自技術架構規範。

Usage Example

此示例展示了組織如何準備ebXML，搜尋新的貿易伙伴，然後參與電子商務。

  • 公司A瀏覽ebXML登錄檔以檢視線上可用內容。 最好情況下，公司A可以重用ebXML登錄檔中已儲存的與其行業共同的現有業務流程、文件和核心元件。 否則，公司A設計缺失的部分，將它們儲存在ebXML登錄檔中，並使其可供其行業合作伙伴使用。

  • 公司A決定以ebXML的方式進行電子商務，並考慮實施符合ebXML標準的本地應用程式。 ebXML業務服務介面（BSI）提供了公司與外部ebXML世界之間的連結。 公司必須建立一個協作協議配置檔案（CPP），其中描述了支援的業務流程功能、約束和技術ebXML資訊，例如加密演算法的選擇、加密證書和傳輸協議的選擇。

  • 公司A將其CPP提交到ebXML登錄檔。 從那時起，公司A將在ebXML登錄檔中公開列出，並且可能會被查詢新貿易伙伴的其他公司發現。

  • 公司B已在ebXML登錄檔中註冊，並正在尋找新的貿易伙伴。 公司B查詢ebXML登錄檔並接收公司A的CPP。 然後公司B有兩個CPP：公司A的CPP和它自己的CPP。 這兩家公司必須就如何開展業務達成一致，在ebXML術語中稱為協作協議（CPA）。 公司B使用ebXML CPA編制工具從兩個CPP的要求中匯出CPA。

  • 在此場景中，公司B直接與公司A通訊，並將新建立的CPA傳送給公司A以供其接受。 公司A同意CPA後，兩家公司都已準備好進行電子商務。

  • 然後，公司使用底層的ebXML框架並交換符合CPA的業務文件。 這意味著兩家公司都遵循CPA中定義的業務流程。

列印頁面
上一頁
下一頁
廣告
© . All rights reserved.