kapok

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 實(shí)現(xiàn)階段

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

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

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

圖 4 運(yùn)行時(shí)階段

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

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

圖5 CPP 概念

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

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

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

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

各元素描述如下：

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

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

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

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

清單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>

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

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

參考資料
· 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