W3C#

World Wide Web Consortium 發展許多基本的網路技術，這些技術又成為其他標準組織的 building blocks。它由國際研究者與工程師團隊管理，成員涵蓋廠商、內容提供者、政府、研究實驗室等。

W3C 在工作小組中、以及後續的公開階段採用開放、協作的審查流程，產出雖然冗長但品質普遍很高的迭代版本；透過 W3C 產生的技術通常不受會員的智慧財產權主張所束縛。

W3C 的技術包含 SOAP、WSDL 以及所有核心 XML 規格。

OASIS#

Organization for the Advancement of Structured Information Standards 是建立在 W3C 技術之上的組織之一。它原本被授權推動 SGML 開發的準則，如今這個非營利廠商聯盟聚焦於推動全球電子商務標準的採用。

OASIS 的技術委員會正產出許多新興 Web service 標準，例如 ebXML 與 WS-Reliability；它也主持 xml.org 入口網站。

WS-I#

Web Services Interoperability Organization 的目標是確保 Web service 技術與標準適合以通用、可互通的方式促成商業協作，推廣能跨多種系統、平台與語言的協定與實務。

達成這些目標的關鍵戰術是 WS-I Basic Profile——它指定了一組 Web service 標準連同版本號（第一個 profile 是 XML Schema 1.0、SOAP 1.1、WSDL 1.1 與 UDDI 1.0），以及它們該如何搭配使用的慣例。

它由 Microsoft、IBM、BEA Systems、Oracle 等主要 Web service 廠商創立與管理。

JCP#

Java Community Process 為其他組織所發展的技術（例如 Web services 與訊息標準）產出 Java 語言繫結與 J2EE API，由 Sun Microsystems 主導。

JCP 在歷史上並非開放流程：雖然它使用專家小組與類似其他標準組織的提案流程，但智慧財產權通常由 Sun 保留，並收費授權給 Java 與 J2EE 平台廠商；多數 JSR 專家小組也由 Sun 的工程師領導。

另一方面，JCP 也因為 Sun 所提供的焦點（較不受外部議程干擾）而受益。

臨時性的廠商聯盟#

在爭奪新興 Web services 技術控制權（尤其是為了企業整合）的競賽中，IBM 與 Microsoft 這類傳統競爭者有時會聯手發布「準標準」，卻不把成果送交任何標準組織——許多 WS-* 規格就屬於這一類。

透過廠商聯盟發展的標準常常最後仍被送交標準組織：前景看好的 BPEL 早期就是 Microsoft 與 IBM 的創作，後來才提交給 OASIS。

業務流程元件#

亞里斯多德不滿足於只影響物件導向程式設計、結構分解與領域建模，他還調皮地拋出了一個困擾軟體架構的最有影響力的修辭問句：世界主要是一連串「流程」，還是一連串「物件」？

世界是一連串物件，而這些物件最重要的特徵，通常是它們藉以與其他物件互動與關聯的那些流程。往往是物件相對於其他物件的行為，而非它自身的內部組成，才最為重要。

在 Web services 與企業整合的領域中，這種物件／流程混血的觀點稱為「業務流程元件（business process component）」——它把一系列服務結合成一個邏輯單元，再透過訊息與其他這樣的單元互動，以達成高度可擴展、有韌性的邏輯與資料流動。

這與「單純呈現一個外部介面」不同——它還包含了治理「介面使用之間的行為」的那些規則。

在新興標準中，業務流程元件是一個內部由一組 Web service 與「訊息如何流入流出它們」的定義所構成的單一元件。

Web service 與其他訊息目的地是用來組成更大組合的積木，而這些組合的互動遵循訊息模式——流程元件本身的組成，以及把多個流程元件串成應用程式，兩者都遵循訊息模式。

業務流程標準處理的是**「Web service 之間訊息的關聯，以建立執行流」**，並涵蓋與錯誤、交易與資料交換相關的行為。

延伸：三個關鍵的業務流程標準

ebXML Message Service（ebMS）#

ebMS 訊息以「帶附件的 SOAP 訊息」形式組成。預設是非同步遞送，但也可以同步遞送；錯誤處理機制相當精密，視實作而定能同時提供 SOAP Fault 資訊與酬載專屬的錯誤訊息。

為了提供可靠性，ebMS 實作的關鍵元素——稱為 ebXML Message Service Handlers——在對話的發送端把訊息持久化。開發者能為個別訊息或訊息群組宣告「恰好一次（once-and-only-once）」「儲存後轉送（store-and-forward）」這類語意宣告。

ebMS 也規定了管理循序遞送與管理的服務——最後這項服務透過一個代表 Control Bus 的 Message Status Service 實作。它能查詢先前送進 ebMS 系統之訊息的狀態，而底層是靠 Message History 與相關模式的實作在運作。

BPEL4WS#

Business Process Execution Language for Web Services（常被念成「bee-pel」，或更糟的「bee-pel for wuss」）代表 IBM 與 Microsoft 兩個競爭提案的合流：

• IBM 的 WSFL 規定了建立與串接服務端點以編排 Web service 工作流程的方式
• Microsoft 的 XLANG 提供了建立工作流程元件的語法與開發模型（實現於 BizTalk 產品）

BPEL4WS 兩者兼具：既有「從既有服務組成流程」的語法，也有「描述流程介面以便串成更大工作流程」的語法。它由 BEA Systems、IBM 與 Microsoft 的臨時協作創造，並已提交給 OASIS。

BPEL 的設計是：把稱為「partners」的 Web service 串接起來，依稱為「activities」的規則，把 XML 訊息放進與取出稱為「containers」的訊息儲存。 一組服務串接、訊息容器與活動，就構成單一個業務流程元件。

BPEL 語法透過匯入各服務的 WSDL 檔，串接一組 Web service 的 portType 與 operation，並宣告用什麼順序接收服務訊息、送到哪裡、何時與如何回覆、何時喚起其他 Web service，等等。

JSR-207：Process Definition for Java#

由 BEA Systems 提交，目標是為在 Java/J2EE 環境中建立業務流程，定義中介資料、介面與執行期模型。

這個 JSR 意在規定「用 Java 語言與類 Javadoc 中介資料註記來打造業務流程元件」的標準方式。它被提議作為 J2EE 的補充，也能用來建立 BPEL4WS、WSCI 等業務流程倡議的 Java 實作。

它建立在 Java Language Metadata（JSR-175） 之上，提供描述業務流程的簡單語法：中介資料可以直接套用到 Java 原始碼上，動態生成並繫結流程行為——包含非同步訊息、平行執行、訊息關聯、訊息路由、錯誤處理等常見流程活動。

值得注意的是：這個 JSR 並非「在 J2EE 中建立業務流程元件」的必要條件——今天就做得到，但那是繁重的工作，要求開發者在非常低的層次套用訊息模式，產出的工作流程維護成本又高。

這份規格的用意是簡化流程元件的建立，讓開發者能在更高層次運用技能，更快做出更強大、且長期演進與管理成本更低的應用程式。

JSR-208：Java Business Integration（JBI）#

由 Sun 提出，意在為 WSCI、BPEL4WS 等規格定義「建立業務整合環境」所需的服務提供者介面（SPI）。

JBI 的目標相當高遠：把各種系統與協定標準（包括描述流程間關係的多種語法，不論專有或標準）彼此對應、並對應到 J2EE，為訊息編排提供 Java 繫結，不論底層訊息與流程的細節為何。 >

WS-* 規格群#

最流行的 Web service 協定與傳輸方式既無狀態又不可靠，無法提供交易式流程所需的服務品質——這個不足膨脹成一個至關重要的問題。

以下幾組規格分別針對交易性、可靠性、路由、對話狀態與安全性。

WS-Coordination 與 WS-Transaction#

實務上，這個不足意味著：若開發者想用基於 Web service 的整合機制，就得在那些機制之內自己長出一套交易方案。

一組透過非同步訊息發生的服務喚起，必須能被原子性地批次處理——讓這些訊息作為一個單元一起失敗或回滾，或作為一個「失敗時能觸發某種補償」的單元。這在專有 MOM 系統中很常見。

WS-Coordination（由 BEA、Microsoft 與 IBM 起草）規定了「讓流程中所有參與服務建立與傳播脈絡資訊」的方式，即使是非同步、跨越參差不齊的時間區間也適用。它描述了一個可擴充的框架，用來建立協調應用程式與服務動作的協定——這些協定的運作方式，是建立並註冊「隨 SOAP 訊息一起傳播、由互動中所有端點的協調者使用」的 XML 式脈絡。

WS-Reliability 與 WS-ReliableMessaging#

Web service 之間基於訊息的互動，常需要即使在網路、應用或元件故障時仍可靠且可保證的訊息傳遞，並包含持久化機制與重送語意。但最流行的 Web service 技術並不提供這種可靠性——例如未經強化的 SOAP，在許多企業訊息情境中並不全面適用，因為它最流行的繫結並不可靠地保證訊息送達。

為了補救，應用開發者通常被迫用 SOAP Header 這類 Web service 擴充機制自行實作可靠性。

於是有兩個競爭的規格出現（由不同的廠商陣營支持，卻瞄準同一個問題領域）：

WS-Reliability#

為 SOAP 式 Web service 提供「非同步交換訊息，並保證送達、無重複、且訊息有序」的能力。它是管理訊息聚合與排序的 SOAP 標準，為 Guaranteed Delivery 與 Resequencer 等模式提供了標準的實作戰術。

它利用 SOAP Header 機制，加入 MessageHeader、ReliableMessage、MessageOrder 與 RMResponse 等表頭元素，用來標示群組 id 與序號、時間戳、存活時間值、訊息型別值、收發雙方資訊，以及確認回呼資訊。

運作方式：

寄件端必須把訊息持久化，直到存活時間到期、或收到確認、或發生失敗；接收端也必須把訊息持久化，直到它能可靠地傳給應用層。

為了確保「恰好一次」的訊息行為，WS-Reliability 提供了可依應用需求啟用的序號機制：被歸在一起的訊息可共用群組識別碼，但各自在 SOAP 表頭中標示自己的序號，讓接收端能在交給應用程式之前重新排序。

它由 Sun、Oracle、Sonic 等廠商產出，已提交 OASIS，並深受前述 ebMS 功能的影響。

WS-ReliableMessaging#

描述一個類似的協定，讓訊息能在故障存在的情況下於分散式應用之間可靠地遞送。協定本身以獨立方式描述，因而能用多種網路傳輸技術與繫結實作（規格中也包含一個 SOAP 專屬繫結）。它由 BEA、IBM、Microsoft 支持，當時尚未釋出給任何標準組織。

它的運作原理與 WS-Reliability 相同——類似地使用確認、回呼、識別碼，也暗示類似地使用持久化訊息快取，並提供詳細的 fault 訊息。它確保訊息依四種基本遞送保證之一遞送：至多一次、至少一次、恰好一次、以及有序。

實務上這意味著 WS-ReliableMessaging 使用其他標準的特定慣用形式來提供這些資訊，而 WS-Reliability 支援這些功能、卻尚未堅持要用那些新標準所規定的慣用形式。

WS-Conversation#

規定一個協定，管理寄件端與收件端之間（通常跨兩個 SOAP 端點）有狀態的非同步訊息交換。

相對於「依賴一個封裝性的業務流程元件來管理多個夥伴之間的有狀態訊息交換」，這個提案提供了「在單一客戶端與單一服務之間」達成同樣目的的簡單方式（此處客戶端本身也可以是服務）。

WS-Security#

WS-ReliableMessaging、WS-Coordination 與 WS-Addressing 提供了各種辨識訊息寄件端的機制，但沒有任何一個規格能保證「寄件端真的擁有它所宣稱的身分」。

WS-I Basic Profile 的元素（XML Schema、SOAP、WSDL、UDDI）完全沒提到身分如何被驗證與保證、訊息完整性又該如何維持。Web services 的早期採用者要嘛讓服務對所有人開放，要嘛自行發展專有安全協定來填補這個缺口——而專有、私有的作法在收發雙方之間製造了不受歡迎的耦合，這在「本應非同步且鬆散耦合的訊息節點聯邦」中特別刺眼。

WS-Security（也稱 Web Services Security Language）就是為解決這些議題而提出的標準。

它提供一種通用、可擴充的方式把安全 token 與 SOAP 訊息關聯起來、並把 token 傳播到 SOAP 端點；也規定了在 SOAP 訊息中編碼二進位安全 token（數位憑證、Kerberos ticket）的標準作法。

它不描述特定的固定協定，而是建立一組通用機制，用來實作任意多種安全協定、並納入任意多個信任域、簽章格式與加密技術。由於它能納入數位憑證、摘要，以及 PKI、Kerberos、SSL 這類技術的實作，WS-Security 代表了「把熟悉的網際網路安全老將套用到 SOAP 端點」的一條路。

除了驗證寄件端身分之外，WS-Security 也能透過運用 W3C 的 XML Signature 與 XML Encryption 標準來保護訊息完整性——保護它在網路傳輸期間不被中介者窺看。

但在不涉及中介者與第三方服務的情況下，使用 HTTPS 是保護傳輸中 SOAP 訊息的常見替代方式。

安全模型規定：SOAP 訊息的寄件端提出一系列宣稱（身分、群組、權限等），這些宣稱以「已簽署的安全 token」形式收集起來；訊息接收端則負責背書這些宣稱。 token 與簽章放在 SOAP Header 區塊中、WS-Security 命名空間下的 <security> 表頭元素內。

接收端背書宣稱時若發生錯誤，錯誤分兩類：「unsupported」錯誤（端點不支援某種 token 或加密演算法）與**「failure」錯誤**（其餘多數錯誤，包含所有與無效 token 及簽章相關的）。

規格並不強制要求 failure 錯誤一定要被回報，因為它們可能是攻擊的結果。

WS-Addressing、WS-Policy 與其他#

還有許多其他被提議的 WS-* 規格，支持與接受程度各異，有些範圍相當窄：

• WS-Addressing——定義用來在訊息中識別 Web service 端點的 XML 元素，目標是以傳輸中立的方式，支援穿過端點管理器、代理、防火牆與閘道等中介者的訊息傳遞。

本質上，WS-Addressing 是標示「訊息從誰來（From:）、要送給誰（To:）」的標準方式。它提供了把 SOAP 式 Web service 接進 Recipient List 方案的手段；而由於它提供了指定「回覆該送往何處」的方式，它看來注定會成為解決 Return Address 議題的標準 Web services 作法。

• WS-Policy（Web Services Policy Framework）——提供描述 Web service 政策的語法，政策包含服務需求、偏好、能力與服務品質中介資料。
• WS-PolicyAssertions——規定「斷言某訊息或服務端點支援特定政策」的方式，作法是檢視 WS-Policy 宣告以尋找特定的必要政策。
• WS-PolicyAttachment——描述這些政策標準如何嵌入既有 Web service 技術：規定如何把政策運算式與 WSDL 型別定義及 UDDI 實體關聯起來，也定義如何把實作專屬的政策與整個或部分的 WSDL portType 關聯起來。

這些新興的 WS- 標準當時尚非「實作可互通的企業訊息系統」的必要條件；一旦它們成為阻礙或干擾，就該大膽忽略它們，直到它們成熟為止。

小結#

許多努力正透過 Web service 標準延伸訊息模式，其中許多標準聚焦於稱為「業務流程元件」之工作流程元件的組成與行為；BPEL、WSCI 與 WS-* 規格處理了本書所描述的許多問題，也實作了這套模式語言中的數個模式。

套用模式時，應用開發者應避免被標準拖住，而該把焦點放在手上的具體使用案例。看看某些標準是怎麼處理某個問題的，若合理或對實作有幫助，就採納那些戰術性、慣用的模式實作——不論該作法是否已在各廠商產品之間標準化。

開發者也可以向標準組織提供回饋，去挑戰、批評，並確保標準真正實用，而不是淪為學術或廠商的練習。