kapok

ebXML 簡介
　　為什么我們需要另一種 XML 語言呢？似乎每天都會開發出或批準新的 XML 標準。同時，又好像有一臺巨型 XML機器在模仿業界或公共語言而創造著新語言。這種嚴酷的條件可能會引起某種不規則性，技術專家必須設法確定從過去所使用的遺留格式轉移到新XML版本所產生的價值。當然，在維護健全性（sanity）和安全性時，必須已全部完成所有這些工作。
　　XML 語言這種不確定性部分是由于XML自身的簡單性。XML無法獨自實現多少功能，而且在某些方面還過于簡單。必須在現有規范的基礎上繼續開發規范，將XML打造成為有用的東西。不少情況下，開發新 XML 語言僅因娛樂，似乎始終需要“XML化”每一種可能的計算格式或交互。
　　本簡介的主要目標是使讀者確信，ebXML并不只是對基于非XML EDI (Electronic Data Interchange) 的業務交互的格式的盲目更改。雖然ebXML早已被冠以“不過是另一種XML語言”的頭銜，但事實上它對于業務而言有著重要的總體益處，這主要是由于其特殊的視角。

特殊業務的視角
　　ebXML鋒芒最勁的功能之一是其實現特殊業務交互的能力。乍一看，特殊（ad hoc）這個術語會使人聯想起自然災害和意外事件等負面景象，但正是ebXML的該功能特性才使之對于經營電子商務而言功能尤為強大。
　　為了做一簡單類比，設想在當地超市購買食品。假定您一直常從超市 A 購買食品。隨著時間的推移，您基于其提供的商品和同意購買物品的流程（比如，與超市職員交互及使用ATM卡來進行購買）與該超市發展業務關系。雖然您與超市A有長久的關系，但您與超市的關系是臨時的、是權宜之計。
　　設想現在新開一家商店，超市B，對于同一種商品它以更低的價格對外出售。當然，您最好與超市B開始發展新的業務關系，而且您可能會這樣做，因為可以預計其業務流程和交互與超市A的沒什么兩樣，也就是說您將用英語講話以及可能使用ATM卡來進行交易。此處，這種業務關系的特殊本質是使自由市場經濟運作起來；您可以輕松地放棄先前與超市A的關系并迅速與超市B建立新關系。
　　然而，通過 Internet 的電子商務另有基礎設施的成本，該成本包括在經營業務的總價格之內。例如，如果安排兩個業務進行電子交易，則必須付出籌備基礎設施和軟件的代價，而且還要使業務交互和策略規范化，包括充分的安全策略。
　　隨著時間的推移，如果出現提供更低的商品和服務價格的新業務，則該交互模式和所需的技術將成為經濟障礙。換言之，如果經營業務的成本包括沉重的基礎設施和流程修改成本，則沒有理由降低商品價格（如果最終不會遇到麻煩的話）。
　　例如，假定超市B只是稍稍壓低價格，而超市的所有職員都講不同的語言并只收兩美元面值的現鈔。在這種情況下，您經營業務所需的額外成本（例如，您學習語言以及手頭上有合適的貨幣）可能會超過該價差。
　　ebXML的核心價值之一是其技術角度的寬廣視野。它構建于XML、SOAP、HTTP及SMTP（所有這些都是比較容易進入的開放標準）之上。從理論上講，關注技術廣度會使電子商務接近于特殊自由市場的概念（我們在超市購物時都曾親身體驗過）。

XML Web 服務如何？
　　好像我已犯下了一個分類錯誤，在未提及XML Web服務或面向服務的架構的情況下而對SOAP和XML高談闊論。然而，原來ebXML架構先于許多普通的XML Web服務標準，而不遵從大多數概念。了解XML Web服務和ebXML架構概念廣度的一種簡單方法是對以下三個術語進行重新整理：線、描述和發現。
　　第一個術語表示消息傳輸技術。對于XML Web服務和ebXML而言，都是SOAP，但相似之處僅此而已。XML Web服務有一個松散耦合的線堆棧，該堆棧由可靠傳輸 (WS-Reliability) 和 安全 (WS-Security) 的各個規范組成，而ebXML將所有這些功能都融入到自己的消息傳遞標準和ebMS中，從而使用混合技術。
　　對于描述和發現堆棧，XML Web服務分別使用Web Services Description Language (WSDL) 和UDDI。對于ebXML，這些描述和發現機制是ebXML注冊的一部分；此外，ebXML還包含針對業務流程和協作的附加規范。
　　簡而言之，ebXML是一個獨立的規范集，具有內部一致性，而且不依賴于新興標準和規范。

ebXML 概述
　　為了實現剛才所討論的特殊視野，ebXML為業務交互提供一個完整的框架，全部是作為供應商中立規范集而交付的。該完整的框架設計用于答復大量的全盤業務問題。這些問題的觀點針對指定的貿易合作伙伴來進行表述：

• 我如何描述自己的業務流程和特定接口呢？
• 我如何與其他合作伙伴共享自己的業務流程呢？
• 我如何得知自己的合作伙伴支持哪些業務流程呢？
• 我如何描述特殊交易的業務消息呢？
• 我如何描述要使用的安全策略和技術配置呢？

　　從理論上講，如果貿易合作伙伴可以用這些術語描述其自身，則便可以進一步融入于臨時的、電子的自由市場之中。這些問題中的許多可以通過實現共享的信息注冊來解決，其中業務協議和流程可以集中。該中心點存儲庫稱為ebXML注冊。同時，還有實際線級消息傳遞層及業務流程規范和協作信息的規范。具體的ebXML規范集反映為如下概念：

• 集中的共享注冊：Registry Information Model、Registry Services Specification (ebRIM、ebRS)
• 業務流程和協作：Business Process Specification Schema、Collaboration-Protocol Profile 和 Agreement Specification (ebBPSS、ebCPPA)
• 消息傳遞：Message Services Specification (ebMS)

ebXML 注冊
　　ebXML實現的關鍵部分是ebXML注冊。注冊本身用途相當廣泛，而且可以表示范圍廣泛的數據對象，包括 XML 模式、業務流程描述、ebXML Core Component、UML模型、一般貿易合作伙伴信息及軟件組件。為了支持如此多樣的數據，使用一個定義良好的信息模型而不是目錄，將ebXML注冊設計得更像一個數據庫。這一點相當重要，因為人們普遍認為，ebXML注冊在與XML Web服務（如UDDI）的注冊服務在搞競爭。事實上，兩者的目的截然不同：可能有人會在 UDDI目錄中發現已發布的ebXML注冊端點，但UDDI并不設計用于處理與ebXML注冊的可能復雜分類關系。
　　有兩種查看ebXML注冊的方式：從外向內看，或從信息模型向外看。前一種查看方式提供更簡潔的概觀，因為它出自客戶端期望訪問ebXML注冊所提供的兩個接口中的某一個這一觀點。這兩個接口包括 Lifecycle Management Interface和Query Management Interface。在注冊中，LifeCycle Management Interface用于管理對象的生命周期（亦稱為存儲庫項目），Query Management Interface用于根據注冊進行查詢。為了領會這兩個接口的工作原理，我們必須簡單地看一下在注冊中信息是如何進行邏輯存儲的。

ebXML 注冊信息模型
　　ebXML注冊所使用的核心信息模型是基于樹的分類方案，這意味著有關業界或業務合作伙伴的信息是在一個層次結構中進行分布的。ebXML注冊信息模型與簡單層次結構的主要不同點在于，它能傳達更復雜的關系。例如，考慮以下在ebRIM 規范中表示的基于樹的層次結構：

圖1 ebXML注冊信息模型 (ebRIM)

　　在圖1中，讀者會注意到該層次結構的一部分加上了陰影。加陰影的部分為實際注冊對象，而未加陰影的部分稱為分類。在許多方面，ebXML注冊所使用的分類方案更像事物的本體或知識結構。請注意，樹中的任意一片樹葉都可以分享附加分類關系。

ebXML注冊接口
　　ebXML Registry Architecture根據注冊服務和注冊客戶端定義。在該信息模型中，注冊服務有兩個用于管理對象的主要接口：生命周期管理和查詢管理。生命周期管理接口有submitObjects、updateObjects、removeObjects 及 deprecatedObjects等抽象方法，這些方法用來將對象或分類提交到信息模型中。與此類似，查詢管理接口有submitAdhocQuery、getRegistryObject及getRepositoryItem等接口，它們用于查詢注冊本身。
　　抽象注冊服務接口使用Web Services Description Language (WSDL) 文件定義，該文件可以從OASIS ebXML Registry Technical Committee獲得。有三個到這兩個接口的具體綁定：HTTP上的 SOAP、ebMS及直接 HTTP。綁定選擇的多樣性意味著，ebXML客戶端將以瘦客戶端和胖客戶端的形式發布。瘦客戶端很可能成為基于瀏覽器的只讀接口，而胖客戶端用于對運行注冊進行更改或添加。
　　然后做出總結，有5個重要的ebXML規范：ebRIM、ebRS、ebBPSS、ebCPP 和 ebMS。ebMS 規范定義ebXML Message Service Protocol，該規范設計用于啟用貿易合作伙伴間安全可靠的業務消息交換。雖然作為業務事務的一部分而發送的實際業務消息固然很重要，但ebXML的消息傳遞部分不過是整個ebXML架構的一小部分而已，該部分根據許多不同的組件和規范進行定義。關于ebXML交互如何進行的一個重要的高層次畫面可以就ebXML功能階段來進行表述。

ebXML功能階段
　　籌備新業務關系的舉措意味著訪問共享的ebXML注冊，這通常由當前功能階段所支配。三個功能階段通過ebXML技術架構定義。這三個部分包括實現階段、發現和檢索階段以及運行時階段。每一階段都攜帶自己安全的需求和流程。接下來的三小節給出各個階段的生動概述?？傮w而言，關于實現和檢索的前兩階段表示排序的信號交換，而最后的運行時階段則表示實際業務單元。

實現階段
　　ebXML的實現階段被認為是貿易合作伙伴使用ebXML框架做出有效決策來經營業務的時間。如圖2所示，在該階段，貿易合作伙伴將根據ebXML所得的結論來分析自己的業務流程，而且還要將自己的業務流程發布到注冊。在該階段，實際的ebXML實現必須產生，要么通過核心ebXML規范自行構建要么通過第三方供應商獲取。實現階段的結果是一個工作式ebXML框架，包括一組發布的業務流程和接口。Collaboration Protocol Profile (CPP) 也在此時發布。

圖2 實現階段

發現和檢索階段
　　ebXML的發現和檢索階段包括，使用注冊來發現其他貿易合作伙伴所發布的業務流程和接口的貿易合作伙伴。通常，特定合作伙伴的CPP或合作伙伴集合在此時進行交換。CPP描述特定業務流程和技術細節，包括安全、傳輸及可靠性細節。CPP中所表示的具體細節用作在運行時階段所交換消息的基礎。圖 3 展示了兩個正相互發現對方的Collaboration Protocol Profile文檔的貿易合作伙伴。

圖 3 發現和檢索階段

運行時階段
　　運行時階段與實際業務事務和合作伙伴之間所交換消息的表現有關。在運行時階段通常沒有運行時訪問注冊。各參與的貿易合作伙伴所發布的CPP實例不足以構成Collaboration Protocol Agreement (CPA)。CPA是依賴于特定交易會話的特殊業務協議，它從各貿易合作伙伴所發布的不同CPP實例的交集派生出顯式需求。如圖3所示，各貿易合作伙伴通過在各合作伙伴的CPP實例之間執行交運算來提供該CPA。在實際的ebMS交換之前，各貿易合作伙伴應對CPA實例進行比較，以確保兩者之間保持一致。在交易發生之前，CPA實例應與兩個終點都相匹配。
　　圖4可以用三個簡單的步驟進行總結。在步驟1，各個貿易合作伙伴負責獲取想使其參與的業務合作伙伴的必需的CPP文檔。在大多數情況下，CPP將從 ebXML 注冊中進行檢索。在步驟2，各合作伙伴派生Collaboration Profile Agreement (CPA)，從而使用CPP中所提供的選擇范圍成為顯式的。最后，在步驟3，合作伙伴可以在CPA的支配下開始業務事務。從這種意義上講，ebMS消息和派生的CPA之間存在著某種策略關系。

圖 4 運行時階段

Collaboration Protocol Profile和Collaboration Protocol Agreement
　　正如早先所描述的，ebXML的關鍵組件之一是稱為CPP或Collaboration Protocol Profile的工件。CPP包含支持特殊業務流程的具體技術實現細節。將CPP發布到ebXML注冊并描繪出受支持的技術綁定細節。CPP的主要目的是確保貿易合作伙伴（依賴于不同供應商的ebXML框架）之間的互操作性。
　　從安全角度來看，CPP非常重要，因為它屏蔽了安全策略信息及特定消息交換細節（全部用XML表示）。在安全網關或防火墻的上下文中，該策略信息可以用于配置安全代理來處理相應的消息級安全操作。
　　CPP所定義的某些消息交換細節包括傳輸協議機制、消息可靠性機制、傳輸安全性機制、信任的工件（如，X.509證書）以及消息級安全策略信息等具體內容。除了實現細節，CPP還引用了受支持的業務協作（定義受支持的業務事務）集合。
　　CPP不獨自實施消息交換的具體選擇。只有至少兩個CPP文檔的交集才產生能實施特定消息級安全和可靠性機制的CPA。CPA的組織結構幾乎等同于CPP，而且出于聲明性安全策略的目的，在CPP中出現的元素和描述由CPA共享。最后，讀者應將CPA視為一組ebMS消息交換的最終支配性安全策略聲明。

CPP結構
　　CPP描述消息交換能力及貿易合作伙伴所支持的業務協作的集合。消息交換能力是運行時階段的實現細節和策略，業務協作是特定的業務事務，它用處理規范文檔進行描述。圖5是CPP的圖解視圖。

圖5 CPP 概念

　　有關圖5的最重要的一點是CPP表示一個在生成CPA時將縮小的選擇列表。CPA通常依賴于貿易合作伙伴雙方所使用的某一處理規范文檔。處理規范文檔表示正在執行的業務單元，它超出本文所討論的范圍。關于處理規范文檔的更多信息可以在ebXML Business Process Specification Schema找到。

CPP數據模型
　　具體的CPP實例通過5個直接子元素定義，如清單1所示。用一種簡單的BNF語法描述元素的基數?！?”表示一個或多個，“?”表示零個或一個，而“*”表示零個或多個。缺少指示符表示正好一個。

清單1 Collaboration Protocol Profile (CPP) XML結構

<CollaborationProtocolProfile>
　　(<PartyInfo>) +
　　(<SimplePart>) +
　　(<Packaging>) +
　　(<Signature>) ?
　　(<Comment>) *
</CollaborationProtocolProfile>

各元素描述如下：

• <PartyInfo>
  該元素標識其能力由CPP描述的組織（或其各部分）。
  
• <SimplePart>
  該元素描述用于構成復合消息的成分。
  
• <Packaging>
  該元素用于描述如何為傳輸打包消息頭及有效負載。
  
• <Signature>
  該元素包含用于對實際CPP文檔進行簽名的XML Signature。
  
• <Comment>
  該元素用于注釋。

　　<CollaborationProtocolProfile> 的每個子元素都包含許多多層嵌套的子項。CPP本身相當復雜，要分析其結構會用去一整篇文章。目前，我將站在最外層，展示一個高層次的概觀。
　　如果我們要放下這些概念，進入更深一層的具體實現，則我們可以更詳細地查看各個功能階段。

實現、發現和檢索階段細節
　　按開發人員的觀點，這些階段需要與發布和檢索業務文檔和流程的ebXML注冊進行交互。對于實現階段，將使用ebXML注冊生命周期管理 服務，而對于發現階段，則將使用查詢管理接口。為了實際訪問這些接口，開發人員有根據已發布的WSDL選擇三種具體綁定的權利。在這種情況下，WSDL 是ebXML Registry Service規范的一部分并將隨不同的規范版本而發生變化。可用的綁定包括 HTTP 上的SOAP、ebMS 及直接HTTP。
　　第一個綁定表示一個胖客戶端，其中開發人員使用在注冊中管理對象狀態的WSDL描述來構建實際的客戶端。在這種情況下，該客戶端的表現非常像純Web服務客戶端。第二個綁定與第一個非常類似，不過線格式使用ebMS（構建于SOAP之上）。第三個選項是 HTTP 接口，它是三者中量級最輕的一個。原則上，它可以通過 XML 感知瀏覽器來實現。使用該綁定，開發人員可以通過注冊本身的本機 Web 應用程序訪問該注冊。在此必須強調的是，在該階段無業務事務；我們并不過是在通過為參與業務事務的其他合作伙伴提供必要的信息來管理注冊。

運行時階段
　　在前兩個階段，業務信號交換發生之后，已傳輸的實際消息將受 ebMS規范所支配。ebMS 規范使用帶有附件的SOAP打包業務數據。主SOAP有效負載包含已使用XML Signature進行簽名的頭信息，包括實際有效負載的清單或列表。實際業務消息作為一個或多個MIME部分進行傳送，而且不在SOAP正文中表示。雖然ebMS基于SOAP，但它寧愿將SOAP用作一個方便的打包機制也不愿將其用作成熟的Web服務傳輸。
　　ebMS 的模式定義是根據SOAP v1.1擴展點定義的。特別指出的是，元素結構的BNF語法樣式視圖如清單2所示。與SOAP相比，ebMS規范在SOAP頭中添加了<MessageHeader>，并在SOAP正文中添加了<Manifest>元素。該結構使用標準基數符號，其中“*”表示零個或多個，“?”表示零個或一個，“+”表示一個或多個，而缺少符號則表示正好一個。為了提高透明度，已省略名稱空間。

清單2 SOAP/ebMS元素結構

<Envelope>
  <Header>
    <MessageHeader>
      <From>
      <To>
      <CPAId>
      <ConversationId>
      <Service>
      <Action>
      <MessageData> 
      (<DuplicateElimination>) ?
      (<Description>)          *
    </MessageHeader>              
  <Header>
  <Body>
     (<Manifest>
       (<Reference>        +
         (<Schema>)        *
         (<Description>)   *
        </Reference )      +
     </Manifest> )         ?
  <Body>
</Envelope>

　　實際業務有效負載是特定于域的，而且您會發現它作為第一主SOAP有效負載之后的MIME附件。

結束語
　　本文介紹了ebXML及其特殊的業務視野。此時，讀者頭腦中應該有一個清晰的ebXML總體輪廓，包括構成標準的概述。此外，讀者還應該領會Collaboration Protocol Profile (CPP) 的目的及其與Collaboration Protocol Agreement (CPA) 的不同程度，同時還對ebXML功能階段進行了一些深入分析。

參考資料
· ebXML.org
· S/MIME規范
· PGP/MIME
· W3C簽名
· W3C XML加密
· W3C Web Services活動
· SOAP/XML協議
· 帶有附件的SOAP消息
· OASIS WS-Security

原文出處
http://dev2dev.bea.com/technologies/webservices/articles/ebXML.jsp