發(fā)布日期： 7/5/2004 | 更新日期： 7/5/2004
Marc Levy
Microsoft Corporation
Ulrich Homann
Microsoft Corporation
適用于：
Microsoft Visual Studio .NET
Microsoft BizTalk Server
摘要：通過(guò)使用通信協(xié)議的體系結構來(lái)建立企業(yè)交互，在企業(yè)及其合作伙伴之間創(chuàng )建更健壯、更有效的交互。
本頁(yè)內容
簡(jiǎn)介將協(xié)議體系結構應用于 B2B小結在本文中，我們將論證今天的企業(yè)對企業(yè) (B2B) 通信自動(dòng)化方式是造成電子商務(wù)無(wú)法實(shí)現真正突破的主要障礙。首先，僅有數據不足以在交互的參與者之間清楚地交流所期望的信息 - 即指定協(xié)約。通過(guò)向企業(yè)服務(wù)規范添加過(guò)程說(shuō)明，新涌現的標準已在正確的方向上取得了進(jìn)步，但是，甚至在對單個(gè)交互的合適說(shuō)明之上假設協(xié)約，第二個(gè)問(wèn)題也會(huì )很快出現：在企業(yè)及其合作伙伴之間組織 很多交互。要解決這些問(wèn)題并提高企業(yè)交互的自動(dòng)程度，我們建議將通信協(xié)議的體系結構應用于企業(yè)交互。該體系結構代表了一種已在網(wǎng)絡(luò )通信中成功應用的解決協(xié)約 和組織 問(wèn)題的方式。
該方式解決了協(xié)約和組織問(wèn)題：
•
為了解決協(xié)約問(wèn)題，協(xié)議指定了通信規則。
•
為了解決組織問(wèn)題，這種分層的體系結構"分割并征服"了復雜的交互，使之成為單獨但連接的會(huì )話(huà)。
簡(jiǎn)介
在最近 10 年里，供應鏈運動(dòng)（從瘦制造模式到六西格馬質(zhì)量管理）方興未艾，成為全球企業(yè)管理人員重點(diǎn)關(guān)注的目標。
圖 1. 供應鏈管理運動(dòng)的發(fā)展過(guò)程
這些運動(dòng)反映了跨越行業(yè)、公司規模和位置的普遍趨勢：
•
市場(chǎng)需求推動(dòng)公司向協(xié)作網(wǎng)絡(luò )發(fā)展，在這樣的網(wǎng)絡(luò )中，每個(gè)公司專(zhuān)注于自己的核心競爭力。有兩個(gè)常見(jiàn)方式來(lái)實(shí)現這樣的專(zhuān)注：
•
將供應商作為伙伴集成到價(jià)值鏈中。
•
將非核心但必需的企業(yè)能力（例如工資冊）外包給企業(yè)過(guò)程服務(wù)提供商。
•
作出巨大的努力（像上面的供應鏈示例一樣）將價(jià)值鏈伙伴和服務(wù)提供商深入集成到相互連接和組織化的單位中。本質(zhì)上，就是要形成虛擬組織。
有了內部和外部合作伙伴之間的關(guān)系所產(chǎn)生的密度、復雜性和可變性，很顯然，簡(jiǎn)單、線(xiàn)性的方法不足以解決這些復雜、煩亂的結構和過(guò)程。
例如，電子數據交換 (EDI) 等只是組織和傳輸打包為企業(yè)文檔的信息?？蛻?hù)關(guān)系的上下文、關(guān)聯(lián)的功能和過(guò)程則不是該標準的組成部分。像 RosettaNet 這樣的活動(dòng)已在該基本方法上進(jìn)行了改進(jìn)，例如，為幾種企業(yè)情況定義了簡(jiǎn)單的合作伙伴接口過(guò)程。雖然標準文檔和合作伙伴接口對于解決交互的難題是必需的，但它們不足以完全提供所需的解決方案。
需要做什么呢？我們如何創(chuàng )建能夠處理具有個(gè)性化、多樣性和復雜性要求的環(huán)境，而不會(huì )導致對底線(xiàn)造成進(jìn)一步壓力的集成和交互成本發(fā)生迅速增長(cháng)？我們如何捕獲合作伙伴網(wǎng)絡(luò )中所有角色不斷增長(cháng)的自動(dòng)化、交互和通信能力，從而創(chuàng )造市場(chǎng)化的價(jià)值？
Web 服務(wù)技術(shù) (
http://msdn.microsoft.com/webservices/) 和面向服務(wù)的體系結構（即 SOA，
http://msdn.microsoft.com/library/en-us/dnea/html/EaAppConServices.asp）為開(kāi)發(fā)可支持豐富和自動(dòng)化交互的環(huán)境提供了堅實(shí)的技術(shù)基礎。但是，還有一些其他方法可以支持交互結構架構師和設計人員完成為上述問(wèn)題提供解決方案這一艱巨的任務(wù)。我們認為，B2B 環(huán)境中的通信所面對的問(wèn)題的性質(zhì)類(lèi)似于網(wǎng)絡(luò )通信系統的設計人員所面對的問(wèn)題；因此，我們將協(xié)議體系結構的原則應用于企業(yè)交互。該方法的基石首先是為 B2B 交互定義的協(xié)約，其次是組織大量這類(lèi)交互的方法。
期望值交流障礙
幾乎所有 B2B 工作所存在的一個(gè)主要問(wèn)題是：現有方法無(wú)法清楚地交流參與者之間的期待信息。EDI 模型（及其專(zhuān)門(mén)面向數據的關(guān)注）已經(jīng)成為大多數 B2B 工作的主要模型。最近的活動(dòng)或多或少只是使用新的 Internet 技術(shù)將一個(gè)格式 (EDI) 替換為另一個(gè)格式。雖然向標準技術(shù)（主要是 XML）的發(fā)展減少了數據處理所涉及的成本，但這只是第一步。
對于使用現有的、以數據為中心的格式在企業(yè)之間建立通信，其復雜性的非正式衡量手段是 Ariba
cXML（例如，參閱 cXML 1.2）的用戶(hù)文檔、購買(mǎi)定單 (PO) 和相關(guān)文檔。文檔為以下基本問(wèn)題提供了答案："PO 的含義是什么？是給我的嗎？是給我的合作伙伴的嗎？是為交易中所涉及的其他要素？"描述與這些業(yè)務(wù)文檔（您必須了解才能成功使用該標準）相關(guān)的交互需要使用大約 100 頁(yè)打印紙。
該示例顯示，描述 PO 這一看起來(lái)很簡(jiǎn)單的任務(wù)其實(shí)并不簡(jiǎn)單。為了成功地進(jìn)行交流，所有相關(guān)各方必須了解至少以下幾點(diǎn)：
•
交互的目的：以某個(gè)價(jià)格、數量和日期時(shí)間購買(mǎi)或出售（取決于視角）產(chǎn)品。
•
關(guān)于角色和通信信道的假設：誰(shuí)出售？誰(shuí)購買(mǎi)？消息如何以及何時(shí)到達？是否需要加密？
•
詞匯：構成會(huì )話(huà)的消息是什么？誰(shuí)發(fā)送和接收消息？使用什么語(yǔ)言？會(huì )話(huà)是否使用特定標準（例如 cXML）？
•
消息格式：消息如何編碼？必需的具體消息頭和詳細信息是什么？
•
通信規則：我期望什么時(shí)候得到初始請求的答案？正確的答案集是什么？
很明顯，顧客和供應商必須了解和尊重這些期待才能成功完成交互。此外，該交易中可能涉及的其他各方（例如，后勤提供商）必須有相同的理解才能在正確的日期和時(shí)間完成交易。更糟糕的是，不僅所有相關(guān)各方必須首先閱讀文檔，他們還必須從文檔得到相同的結論，然后以兼容的方式將它們應用到各自的電子數據交易系統。
現有 B2B 通信系統無(wú)法以系統方式識別這種擴展的協(xié)約定義。它們的作用范圍局限于對編碼和詞匯的定義，并依賴(lài)于特別的協(xié)約、非正式的文檔和其他方式，從而最終影響合作伙伴的實(shí)現之間的通信。這就產(chǎn)生了傾向復雜、冗長(cháng)和錯誤的集成項目，因為人工解釋構成了自動(dòng)化的基礎。
雜亂的 Web 交互
實(shí)際的企業(yè)交互是由很多這樣的單獨協(xié)約構成的。圖 2 顯示供應鏈合作伙伴之間的申訴交互?？梢钥闯?，只指定用于控制單個(gè)交互的協(xié)約（在圖 2 中間展開(kāi)的視圖僅僅顯示了這種交互的一小部分）只是問(wèn)題的一小部分。通常，必需的、可用的或所希望的業(yè)務(wù)功能和它們的關(guān)聯(lián)過(guò)程是復雜、不清楚和不透明的。
此外，一定要注意到圖片只表現了申訴管理的單個(gè) 客戶(hù)/供應商集成圖，而沒(méi)有 與供應商的（或客戶(hù)的）關(guān)聯(lián)企業(yè)功能和系統進(jìn)行必需的集成。B2B 交互不僅復雜，而且還非常不標準。這些過(guò)程反映了合作伙伴之間變化的和單獨的關(guān)系 (Hammer, M.; Champy, J.:Reengineering the Cooperation; Harper Collins Publishers; New York; 1993; Chapter III)，包括通過(guò)個(gè)性化客戶(hù)服務(wù)在這些關(guān)系中創(chuàng )建價(jià)值的活動(dòng)。因此，除了圍繞單個(gè)交互指定協(xié)約以外，還必須處理管理無(wú)數這種交互的復雜性。
圖 2. 在項目之前單個(gè)供應商/客戶(hù)的 cc 交互
顯然，我們需要某些方法來(lái)抽象和管理這些交互。這需要在操作而不僅是數據方面使單獨的過(guò)程變得透明。大多數當前的方法并非如此。
返回頁(yè)首將協(xié)議體系結構應用于 B2B
一開(kāi)始，網(wǎng)絡(luò )通信社區面對類(lèi)似的問(wèn)題：迅速增加的終結點(diǎn)數，以及不斷增長(cháng)的功能需求。兩個(gè)核心問(wèn)題是終結點(diǎn)之間的互操作性，以及對支持豐富功能所需的很多交互類(lèi)型有意義的整個(gè)體系結構組織。這些問(wèn)題的答案是：
•
使互操作性所需的協(xié)約正式化的網(wǎng)絡(luò )協(xié)議模型。
•
建立通信服務(wù)模型和分層體系結構，使很多網(wǎng)絡(luò )協(xié)議的功能相關(guān)，并產(chǎn)生一個(gè)整體，而不僅僅是其各個(gè)部分的匯總。
在以下各節中，我們將把這些概念應用于 B2B 交互。
協(xié)約
Gerard J. Holzmann 在他的 Design and Validation of Computer Protocols （1991 年出版，Prentice Hall 軟件系列，ISBN：0-13-539925-4）一書(shū)中將協(xié)議定義為"在分布式系統中用于控制并發(fā)過(guò)程的交互的規則集合"。
我們將使用簡(jiǎn)單的申訴管理示例來(lái)說(shuō)明 B2B 交易在協(xié)議設計方面的確是個(gè)問(wèn)題，并說(shuō)明為了使 B2B 向前發(fā)展企業(yè)和協(xié)議需要連接的理由。圖 3 顯示了簡(jiǎn)化的客戶(hù)申訴事務(wù)的圖片（從圖 2 展開(kāi)的視圖）。協(xié)議控制完成事務(wù)所需的每個(gè)交互（申訴處理、管理質(zhì)量提高、信任顧客等等）。
圖 3. 簡(jiǎn)單的申訴管理交互（從圖 2 展開(kāi)）
為了解決有缺陷的交貨問(wèn)題，客戶(hù)必須通過(guò)提供與有缺陷的商品、相關(guān)的購買(mǎi)定單、問(wèn)題的優(yōu)先級和其他細節有關(guān)的詳細信息，將他的申訴告訴供應商。而供應商必須通過(guò)直接接受或拒絕申訴來(lái)對該申訴請求作出響應。另外，供應商可以在對申訴作出任何明確決定之前通過(guò)請求其他信息來(lái)啟動(dòng)研究。顯然：
•
每次用滿(mǎn)足所討論的需求的答案（可能由類(lèi)似圖 3 中所概括的多個(gè)響應組成）來(lái)響應具體請求時(shí)，實(shí)體雙方將相互交互。
•
交互并發(fā)地 移動(dòng)（每個(gè)實(shí)體作出自己的決定，但通常與在前面收到的事件相關(guān)），直到最后做出決定。
•
交互是分布式 的。
•
交互是由一系列指向特定目標的操作所組成的過(guò)程。
最后建立了滿(mǎn)足 Holzmann 所提供的協(xié)議定義的 B2B 交互以后，我們需要考查該方式的詳細信息，以及它的結果和對 B2B 交互的好處。
協(xié)議元素
既然我們了解企業(yè)交互，讓我們開(kāi)始以一種能夠被自動(dòng)化系統進(jìn)行處理的方式更精確地收集描述交互所需要的所有元素。
注 Holzmann 在其規范的定義中包括了對協(xié)議所提供服務(wù)的定義。我們將在"組織"一節中再討論這個(gè)關(guān)鍵的方面。
非正式地說(shuō)，上述交互讀作"客戶(hù)向企業(yè)發(fā)送申訴。企業(yè)在收到申訴時(shí)承認該請求。取決于申訴的優(yōu)先級，企業(yè)有 24 到 72 個(gè)小時(shí)的時(shí)間來(lái)解決申訴。"
與環(huán)境有關(guān)的假設
示例的"環(huán)境"由申訴管理服務(wù)的兩個(gè)用戶(hù)以及一個(gè)傳輸信道組成?？梢约僭O用戶(hù)只是提交申訴，并等待它得到確認。假設傳輸信道不會(huì )丟失、復制、插入或重新排序消息。
協(xié)議詞匯
協(xié)議詞匯定義了在給定交換中允許的消息。在我們的示例中，有六個(gè)明顯不同的消息類(lèi)型：
•
COMPLAINT 表示帶有操作請求的消息。
•
ACK 表示與對 COMPLAINT 的肯定答復組合在一起的消息。
•
ACCEPTANCE 表示包含對 COMPLAINT 的肯定或否定的確認的消息。
•
如果供應商沒(méi)有在給定的時(shí)間框架內作出回答，則客戶(hù)發(fā)出 DUNNING。
•
INFORMATION REQUEST 表示請求更多信息
•
INFORMATION 表示客戶(hù)對 INFORMATION REQUEST 作出回答。
消息格式
合作伙伴之間對協(xié)約的消息所采用的編碼標準（EDI，XML）達成一致是很重要的。注意，交互的詞匯（UN/EDIFACT，
http://www.unece.org/trade/untdid/welcome.htm；cXML，
http://www.cxml.org/）與編碼是完全無(wú)關(guān)的。實(shí)際上，保持雙方的獨立是很關(guān)鍵的，因為相似企業(yè)情況的其他環(huán)境可能需要不同的實(shí)現。
過(guò)程規則
規則權威性地定義了為指導行為或操作而提出的原則。甚至我們的簡(jiǎn)單示例也需要若干組需要雙方以共同方式理解的規則，這樣才能成功結束希望的企業(yè)事務(wù)。通過(guò)將這些規則正式化，可以讓我們對交互進(jìn)行抽象，然后自動(dòng)執行它。
事件和序列
首先，必須了解傳入的請求以及可能或正確的響應。然后，必須定義事件序列，以便用正確的響應回答發(fā)出請求的事件?？梢詫θ魏翁囟ㄊ录枋龆鄠€(gè)有效的回答，但答案必須是預定義的有效回答集合的一部分。對于受支持的序列集合，雙方都必須擁有相同的完整理解，這樣通信才能成功。
數據
在任何給定的交互中，事件都是高級別、可確認的過(guò)程。通常，每個(gè)事件都有與之關(guān)聯(lián)的數據，數據攜帶交互所需的細節?，F在，該數據通常格式化為 XML 消息。注意，這些細節的某些部分有時(shí)會(huì )影響行為。例如，在申訴交互中，priority 字段通常是申訴數據的一部分。這個(gè)簡(jiǎn)單的數字字段描述了來(lái)自客戶(hù)的期待：我收到了使我無(wú)法生產(chǎn)的有缺陷商品。請及時(shí)并無(wú)條件地對該情況采取補救措施。為了保持成功的商業(yè)關(guān)系，供應商必須了解和尊重該期待。
限制
簡(jiǎn)單的遵循規定的事件序列將不會(huì )為各方提供足夠的細節來(lái)成功地完成業(yè)務(wù)。在大多數業(yè)務(wù)情況下（與我們的申訴示例一樣），必須在定義的間隔內作出正確的響應。如果在協(xié)約所指定的時(shí)間間隔內沒(méi)有對最初的申訴消息作出反應，則可能出現嚴重的經(jīng)濟和商業(yè)關(guān)系后果。注意，不像我們的簡(jiǎn)單示例，完整和正確的申訴管理過(guò)程必須描述處理過(guò)程的例外。
相關(guān)性
可能會(huì )有數百個(gè)事件在任何給定時(shí)刻到達，需要系統加以處理。問(wèn)題是，"哪個(gè)事件與哪個(gè)過(guò)程關(guān)聯(lián)？"上面的示例使用申訴跟蹤數字作為查找正在管理特定申訴的申訴過(guò)程的數據。類(lèi)似情況是，將引用數字包括在正常的業(yè)務(wù)通信中。如果仔細審閱圖 3 所示的交互模式，這一部分協(xié)議設計的目的是將含義（或者也許更好的用詞是上下文）添加到單個(gè)消息上，并為交互提供端到端的視圖。該視圖允許雙方了解成功的交互所需的期待，并相應地做好準備。
相關(guān)性的重點(diǎn)只放在使正確的請求與正確的業(yè)務(wù)過(guò)程匹配上。在該級別沒(méi)有聚合。
申訴交互的過(guò)程規則
該示例交互的過(guò)程規則很簡(jiǎn)單。在為上述規則建立的元素后面，協(xié)議如下所示：
交互由下列內容組成：三個(gè)必需的事件 (E)、三個(gè)可選的事件 (E) 和三個(gè)限制 (C)，這里"c"是客戶(hù)，"s"是供應商：
•
E：(c) 將 COMPLAINT 發(fā)送給 (s)。
•
E：(s) 向 (c) 承認 (ACK) 收到申訴消息。
•
C：(s) 在收到消息后立即向 (c) 承認申訴。
•
E：(c) 可以向 (s) 發(fā)送 DUNNING 提醒消息。
•
C：(s) 沒(méi)有在所需期限內響應 (c)。
•
E：(b) 可以從 (c) 請求 INFORMATION。
•
E：(c) 如果 INFORMATION 請求已經(jīng)發(fā)送，則 (c) 必須用所請求的 INFORMATION 對 (s) 作出響應。
•
E：(s) 必須向 (c) 發(fā)出 CONFIRM（接受或拒絕申訴）。
•
C：(s) 必須在取決于優(yōu)先級的期限內接受或拒絕申訴。
組織
既然我們已經(jīng)看到如何圍繞協(xié)約解決問(wèn)題，那么問(wèn)題是如何封裝交互并創(chuàng )建抽象，我們可以操作這樣的抽象來(lái)生成細致但可管理的系統，從而處理很多這樣的交互。
描述交互模式是業(yè)務(wù)協(xié)議設計的重要組成部分，并且完全足以作為規定來(lái)改善單個(gè)業(yè)務(wù)活動(dòng)的執行（例如，"CC 處理"）。但是，"CC 處理"活動(dòng)本身不會(huì )成功地解決申訴。除了啟動(dòng)申訴（"CC 處理"活動(dòng)中對此進(jìn)行了說(shuō)明）以外，解決申訴需要提高質(zhì)量管理（例如，培訓供應商雇員、修復有缺陷的機器）并交換信用注意信息。圖 4 概括了解決單個(gè)申訴所需要的一組其他業(yè)務(wù)活動(dòng)：
圖 4. 申訴管理系統的單個(gè)服務(wù)
在該圖中，"CC 處理"服務(wù)依賴(lài)于進(jìn)一步的活動(dòng)（即質(zhì)量管理和信用管理）以實(shí)現全部處理。但是，用解決方案過(guò)程來(lái)超載由"CC 處理"服務(wù)表示的申訴啟動(dòng)是沒(méi)有意義的，因為這些過(guò)程可以基于申訴、合作伙伴或地理上的臨近而有所不同。對這些過(guò)程進(jìn)行分解（按圖 4 的建議）有業(yè)務(wù)和技術(shù)上的意義，因為它考慮到了靈活性和可擴展性。
但是，如圖所示，涉及"CC 處理"的交互是獨立的，并且與組成申訴解決辦法的其他任何服務(wù)無(wú)關(guān)。我們如何在單個(gè)、獨立的交互與實(shí)際上允許合作伙伴執行業(yè)務(wù)的、充分完善的業(yè)務(wù)交互之間架起橋梁？
關(guān)鍵在于將各段聚合成一個(gè)有用 的整體。通常，這需要共享或相關(guān)的標識符（比如唯一的申訴號），以及對業(yè)務(wù)交互實(shí)際狀態(tài)的整體理解。就是說(shuō)，申訴必須在質(zhì)量管理或信用服務(wù)甚至是相關(guān)的之前被承認或拒絕。在我們看到如何對申訴管理示例這樣做之前，我們將首先描述如何有效地使用服務(wù)的概念來(lái)封裝交互。
通信服務(wù)
通常，服務(wù)為具體的問(wèn)題提供業(yè)務(wù)邏輯和狀態(tài)管理（有關(guān)服務(wù)的概述，請訪(fǎng)問(wèn) http://msdn.microsoft.comlibrary/en-us/dnea/html/EaAppConServices.asp）。好的服務(wù)應當基于對包括什么和實(shí)現什么作為單獨的服務(wù)（組織）所作出的明智選擇，有效地封裝與真實(shí)的過(guò)程（協(xié)約）關(guān)聯(lián)的邏輯和數據。對于 B2B 交互來(lái)說(shuō)，使服務(wù)基于協(xié)議是這樣做的有意義的方式。
網(wǎng)絡(luò )體系結構的中心概念是通信服務(wù)。例如，這些服務(wù)提供有用的功能（例如，向分布式的通信各方傳遞雙向、可靠的字節流，即傳輸控制協(xié)議 (TCP)）。
圖 5. 通信服務(wù)
在良好的工程形式中，通信服務(wù)隱藏了用于提供它們所提供的功能的通常很復雜的內部工作機制，這是因為在面向對象編程 (OOP) 中的對象有方法。您不需要了解方法如何工作來(lái)調用它。
以傳輸控制協(xié)議 (TCP) 和文件傳輸協(xié)議 (FTP) 為例。它們的通信服務(wù)抽象是對網(wǎng)絡(luò )協(xié)議進(jìn)行全面分層組織的要點(diǎn)。這樣的組織讓您可以創(chuàng )建更高級別的服務(wù)，若以其他方式，則這些服務(wù)需要管理一組不可能很復雜的交互。例如，FTP 服務(wù)層位于 TCP 所提供的、可靠的字節流傳遞服務(wù)之上。這就允許 FTP 參與有關(guān)文件傳輸的會(huì )話(huà)，而不用擔心如何管理有序數據傳遞以及所有其他瑣碎的細節。如圖 6 所示，該 FTP 會(huì )話(huà)當然是虛擬的，因為實(shí)際的通信路徑需要通過(guò) TCP。
圖 6. 分層的體系結構允許在更高級別實(shí)現虛擬通信
在文章的其余部分，以我們的申訴管理為例，我們討論了如何將類(lèi)似的全面組織化結構應用于企業(yè)交互。在這種情況下，合作伙伴之間的全面申訴過(guò)程被抽象為高級別的交互，以管理整個(gè)申訴生命周期。該交互受三個(gè)管理支持過(guò)程的服務(wù)的支持：初始申訴、質(zhì)量改進(jìn)和信用，如圖 7 所示。
圖 7. 應用于客戶(hù)申訴示例的分層體系結構
分層/復合結構
在給定的組織中，一旦識別了交互及其關(guān)聯(lián)各項所需的業(yè)務(wù)能力，就可以構造它們并以文檔描述它們的層次結構。這為透明化提供了需要的基礎，以便可以抽象通用功能，并將通用功能隔絕在可交換的層中。圖 8 以客戶(hù)申訴情形為例，顯示了這種結構化映射的高度抽象示例：
圖 8. 客戶(hù)申訴情形的高級別視圖
在我們的示例中，結構以 Customer Complaint 系統的形式出現，該系統被組織為可為客戶(hù)和供應商之間的申訴提供解決方案的服務(wù)。Customer Complaint 服務(wù)本身是通過(guò)初始處理、質(zhì)量管理和財務(wù)補償來(lái)管理申訴的復合實(shí)體。這些功能中的每一個(gè)分別由服務(wù)提供。整體效果是在系統的組件之間獲得更好的交互因子分解。例如，質(zhì)量管理服務(wù)現在封裝了所有詳細的 QM 交互，并允許它們有所變化（例如，可以將 ISO 過(guò)程替換為六西格馬過(guò)程）而不會(huì )影響系統的其余部分。
還可以在該結構中很容易地識別傳統的網(wǎng)絡(luò )通信系統組織，在該組織中非常復雜的交互被作為分層服務(wù)進(jìn)行管理。與 TCP 向 HTTP 提供可靠的基于流的通信同樣類(lèi)似的是，QM 服務(wù)向申訴服務(wù)提供質(zhì)量管理，而不用顯示（在該作用范圍內）雜亂和不相關(guān)的細節。注意圖 8 和圖 7 之間的相似性。
將申訴系統上的該視圖與圖 2 中的視圖進(jìn)行對照也具有指導意義，在圖 2 的視圖中，通過(guò)提供兩個(gè)主要角色（客戶(hù)和供應商公司）之間非常復雜的交互這種方式，對系統進(jìn)行因子分解。這里我們已經(jīng)引入了額外的角色（即申訴服務(wù)），所得到的是封裝很多交互復雜性的實(shí)際好處。
B2B 交互采用協(xié)議方式的好處
將示例交互映射到協(xié)議定義之后明顯體現的優(yōu)點(diǎn)：
•
為（更）完整和明確地描述 B2B 交互提供了框架：經(jīng)驗性證據（主要基于查閱現有的 EDI 實(shí)現）顯示，單獨基于數據的交互不足以為自動(dòng)進(jìn)行業(yè)務(wù)通信提供堅實(shí)和清晰的基礎。具體來(lái)說(shuō)，這樣的情況不包括異常處理。與此形成對照的是，協(xié)議設計強制對以可靠方式進(jìn)行通信所需要的所有元素進(jìn)行文檔記錄。實(shí)際上，協(xié)議說(shuō)明為系統自動(dòng)執行交互提供了基礎。傳輸控制協(xié)議/Internet 協(xié)議 (TCP/IP) 允許在全球網(wǎng)絡(luò )內的匿名節點(diǎn)之間進(jìn)行可靠和普遍被理解的二進(jìn)制數據傳輸，這并不需要復雜的集成項目，只需要遵守一組良好定義和被認同的規則。同樣，業(yè)務(wù)協(xié)議將構成健壯的 B2B 通信的基礎。一旦存在這樣的框架，我們就可以使用它來(lái)：
•
設計可實(shí)現參與合作伙伴的業(yè)務(wù)目標的有效交互。
•
與合作伙伴共享這些交互的定義。
•
將定義用于與其他過(guò)程的有效集成。
•
有效地實(shí)現這些交互。
•
確定所需功能：遵守協(xié)議設計的規定，具體來(lái)說(shuō)就是將所有所需的元素以顯式方式用文檔記錄在機器可處理的位置，這將允許參與處理的系統動(dòng)態(tài)確定所需的功能，并報告丟失的功能。
•
對所需輸入/輸出內容的機器可驗證性：通過(guò)理解所應用協(xié)議的需求，軟件就可以確定輸入/輸出是否滿(mǎn)足所概括的限制條件，并且可以進(jìn)行糾正操作。
返回頁(yè)首小結
Web 服務(wù)技術(shù)（例如，XML、SOAP、BPEL4WS）和產(chǎn)品（比如 Microsoft?Visual Studio?.NET 和 Microsoft?BizTalk?Server 2004）為在合作伙伴之間實(shí)現豐富的交互提供了功能強大并且價(jià)格適中的工具。這些技術(shù)和工具與面向服務(wù)的體系結構原理組合在一起，構成了良好的軟件設計的基礎。
但是，正如在注重通信的其他領(lǐng)域中顯示的一樣，為實(shí)現自動(dòng)化而設計交互是一項復雜和容易犯錯誤的冒險。通過(guò)從通信服務(wù)設計中吸取經(jīng)驗，并使用本文所概括的協(xié)議設計的原則，交互結構架構師可以更有效地使用 Web 服務(wù)技術(shù)和 SOA。
將這些要素集合在一起，基于對給定交互的所有方面進(jìn)行清晰地標識和封裝、對這些協(xié)議加以組織并通過(guò)服務(wù)進(jìn)行正確的分割，協(xié)約將：
•
允許對更改作出更快的反應。
•
限制更改的作用范圍。
•
允許合作伙伴自定義交互的某些方面。
關(guān)于作者
在過(guò)去的五年里，Marc Levy 一直從事業(yè)務(wù)過(guò)程自動(dòng)化方面的研究。作為 BizTalk 團隊的架構師，他是實(shí)現協(xié)調功能的重要負責人。參與 BizTalk 之前，Marc 負責 COM+ 安全性（參與撰寫(xiě)"Designing Secure Web-Based Applications for Microsoft Windows 2000"）。Marc 對分布式系統的熱情是從九十年代初開(kāi)始的開(kāi)放式軟件基礎 (OSF) 和分布式計算環(huán)境 (DCE) 的統一主題。
作為解決方案架構師，Ulrich Homann 負責 Web 服務(wù)的設計和體系結構，以及 .NET 平臺與業(yè)務(wù)應用程序的提供商和使用者的集成。后一項責任需要他參與關(guān)鍵合作伙伴和策略的客戶(hù)項目并與它們密切交互，從而深入地洞察各個(gè)所影響的產(chǎn)品組。這還需要大量的旅行預算……
以前，Uli 是企業(yè)程序管理團隊的程序經(jīng)理，并負責開(kāi)發(fā)與關(guān)鍵合作伙伴（主要是 SAP AG）的關(guān)系。Uli 還參加過(guò) Microsoft Consulting Services，當時(shí)，他在德國負責過(guò)幾個(gè)關(guān)鍵的分布式數據庫應用程序項目。
Uli 于 1991 年加入 Microsoft，此前他為幾個(gè)小咨詢(xún)公司設計和開(kāi)發(fā)分布式系統。
Uli 在系統行業(yè)有超過(guò) 15 年的經(jīng)驗。他的大部分職業(yè)時(shí)間都花在使用良好定義的應用程序和體系結構來(lái)簡(jiǎn)化業(yè)務(wù)應用程序的開(kāi)發(fā)并使之順暢運行。他對通過(guò)與客戶(hù)及其應用程序密切配合來(lái)提高產(chǎn)品計劃性充滿(mǎn)熱情，這驅使他對這項追求不斷作出貢獻。
