kapok

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 實現(xiàn)階段

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

圖 3 發(fā)現(xiàn)和檢索階段

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

圖 4 運行時階段

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

CPP結(jié)構(gòu)
　　CPP描述消息交換能力及貿(mào)易合作伙伴所支持的業(yè)務協(xié)作的集合。消息交換能力是運行時階段的實現(xiàn)細節(jié)和策略，業(yè)務協(xié)作是特定的業(yè)務事務，它用處理規(guī)范文檔進行描述。圖5是CPP的圖解視圖。

圖5 CPP 概念

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

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

清單1 Collaboration Protocol Profile (CPP) XML結(jié)構(gòu)

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

各元素描述如下：

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

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

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

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

清單2 SOAP/ebMS元素結(jié)構(gòu)

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

　　實際業(yè)務有效負載是特定于域的，而且您會發(fā)現(xiàn)它作為第一主SOAP有效負載之后的MIME附件。

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

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

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