"Longhorn" 是即將推出的 Microsoft? Windows? 版本的代號，它將包括一個(gè)統一的編程模型和通信基礎結構，以用于開(kāi)發(fā)連接的系統。這個(gè)基礎結構（代號 "Indigo"）通過(guò)面向服務(wù)的編程模型來(lái)簡(jiǎn)化開(kāi)發(fā)，在該模型中，將使用異步消息傳遞功能來(lái)編寫(xiě)自治程序。為了使用這個(gè)編程模型，Indigo 提供了一套豐富的技術(shù)用來(lái)創(chuàng )建、使用、處理和傳送消息。
Indigo 的一個(gè)主要優(yōu)點(diǎn)是，它會(huì )為所有基于公共語(yǔ)言運行庫 (CLR) 的遠程技術(shù)提供一個(gè)統一的編程模型和協(xié)議棧。Indigo 會(huì )將 .NET Remoting、ASMX、System.Messaging 和 .NET Enterprise Services 的最佳功能結合到一個(gè)框架中，使得開(kāi)發(fā)人員能夠自由組合各種功能，如聲明性事務(wù)處理、可插接式偵聽(tīng)器和傳輸以及基于 XML 架構的序列化。
而且，Indigo 統一了各種傳輸協(xié)議（HTTP、TCP、UDP、IPC）、安全機制（公鑰和對稱(chēng)密鑰、證書(shū)）、拓撲（點(diǎn)對點(diǎn)、通過(guò)中間物的端到端、對等、發(fā)布和訂閱）和保證（事務(wù)處理、可靠、持久），從而使得 Indigo 能夠為許多現有系統提供豐富的連接性。
Indigo 使得面向服務(wù)的編程可用于廣泛的主流應用程序中。通過(guò)同時(shí)使用 CLR 和 Windows 的各種工具，Indigo 可用在對性能敏感的情形（如單主機甚至是單進(jìn)程集成）中。與當前的技術(shù)相比，這種尺度不變性使得基于 Indigo 的服務(wù)可被更廣泛的部署選項訪(fǎng)問(wèn)。
因為互操作性和范圍非常重要，所以 Indigo 對 XML 和 SOAP 均提供了深入的支持，而且還會(huì )為不斷涌現的高級 Web 服務(wù)協(xié)議提供支持，高級 Web 服務(wù)協(xié)議可為基于 SOAP 的應用程序添加安全性、可靠性和事務(wù)處理。
Indigo 是 Windows Longhorn 的一部分，可供每個(gè) Longhorn 應用程序使用。對于 Windows XP 和 Windows Server? 2003 來(lái)說(shuō)，Indigo 還可單獨下載。由于不同操作系統之間具有內在區別，所以在 Longhorn 上可能只能使用 Indigo 的少量高級功能或優(yōu)化。但是，無(wú)論部署到哪個(gè)操作系統上，Indigo 都會(huì )為開(kāi)發(fā)人員提供一個(gè)面向服務(wù)的一致編程模型。
面向服務(wù)的設計基礎
Indigo 基于面向服務(wù)的結構和編程的原則。面向服務(wù)的設計是對面向對象設計的重要補充，面向對象的設計應用了從組件軟件、面向消息的中間件和分布式對象計算得到的教訓。面向服務(wù)的設計與面向對象設計的主要區別在于如何定義“應用程序”一詞。面向對象的開(kāi)發(fā)主要關(guān)注從互相依賴(lài)的類(lèi)庫構建的應用程序，而面向服務(wù)的開(kāi)發(fā)則主要關(guān)注從一組自治服務(wù)構建的系統。這種區別對人們就開(kāi)發(fā)經(jīng)驗進(jìn)行的假設具有深遠的影響。
在 Indigo 中，服務(wù)只是一個(gè)用戶(hù)通過(guò)消息交換來(lái)與之交互的程序。系統就是一組部署的服務(wù)。構建每一個(gè)服務(wù)都是為了使其持續運行 — 某個(gè)特定服務(wù)的可用性和穩定性至關(guān)重要。構建由多個(gè)服務(wù)聚合的系統是為了使其允許進(jìn)行更改 — 該系統必須適應在原始服務(wù)和客戶(hù)端部署了很久之后才新出現的服務(wù)，而且這些情況下不得中斷功能。
面向服務(wù)的開(kāi)發(fā)基于如下所示的四個(gè)基本原則：
邊界明顯 面向服務(wù)的應用程序通常會(huì )包括跨越較長(cháng)地理距離、多個(gè)信任機構和不同執行環(huán)境的服務(wù)。從復雜程度和性能的角度看，穿越這些邊界所帶來(lái)的成本并非微不足道。面向服務(wù)的設計了解這些成本，從而對邊界交叉非常重視。因為每個(gè)跨邊界的通信都有可能帶來(lái)很高的成本，所以面向服務(wù)的設計基于顯式的消息傳遞模型，而不基于隱式的方法調用。與分布式對象相比，面向服務(wù)的模型將跨服務(wù)的方法調用視為一種專(zhuān)用的實(shí)現技術(shù)（而非基元構造）— 某個(gè)特定的交互可以作為方法調用實(shí)現，這一事實(shí)是在服務(wù)邊界外部看不到的專(zhuān)用實(shí)現細節。
盡管面向服務(wù)的設計不強調使用網(wǎng)絡(luò )范圍調用堆棧的 RPC 樣式這一概念，但是它可以支持強因果性概念。通常會(huì )在消息中明確表明某個(gè)特定的消息屬于哪個(gè)（哪些）消息鏈，這對于消息關(guān)聯(lián)和實(shí)現幾個(gè)常用的并發(fā)模型非常有用。
邊界明顯這一概念不僅適用于服務(wù)之間的通信，而且還適用于開(kāi)發(fā)人員之間的通信。即使對于所有服務(wù)都部署到一個(gè)位置的情形，以下情況也非常普遍：每個(gè)服務(wù)的開(kāi)發(fā)人員會(huì )跨越地理、文化和/或組織邊界。其中的每個(gè)邊界都會(huì )增加開(kāi)發(fā)人員之間的通信成本。面向服務(wù)的設計通過(guò)降低必須在服務(wù)邊界之間共享的抽象數量和復雜程度，來(lái)適應這種模型。通過(guò)盡可能縮小服務(wù)的覆蓋范圍來(lái)減少開(kāi)發(fā)組織之間的交互和通信。在面向服務(wù)的設計中有一個(gè)永恒的主題，那就是簡(jiǎn)單和通用不是奢侈品，而是重要的生存技能。
服務(wù)自治 面向服務(wù)的設計反映了真實(shí)的世界，因為它不會(huì )假設存在全知或全能的圣賢，即不存在能夠感知和控制運行系統所有部分的服務(wù)。這個(gè)服務(wù)自治概念表現在開(kāi)發(fā)的幾個(gè)方面，最明顯的位置是部署和版本控制領(lǐng)域。
面向對象的程序往往作為一個(gè)單元來(lái)部署。盡管在二十世紀九十年代盡力使類(lèi)能夠獨立部署，但事實(shí)證明，對于大多數開(kāi)發(fā)組織來(lái)說(shuō)，支持與組件進(jìn)行面向對象的交互所要求的原則是不切實(shí)際的。在面臨對于面向對象的接口進(jìn)行版本控制的復雜性時(shí)，許多組織在如何部署面向對象的代碼方面都變得極其保守。.NET 框架的 XCOPY 部署和專(zhuān)用程序集功能的普及性預示了這種趨勢。
面向服務(wù)的開(kāi)發(fā)與面向對象的開(kāi)發(fā)不同，它假設以原子方式部署應用程序是例外情況，而不是常規情況。盡管各個(gè)服務(wù)幾乎總是以原子方式部署的，但是整個(gè)系統/應用程序的聚合部署狀態(tài)很少保持不變。單個(gè)的服務(wù)通常在開(kāi)發(fā)任何商業(yè)應用程序（更不用說(shuō)部署到空白系統了）很久之前就進(jìn)行部署了。Amazon.com 就是這種“有產(chǎn)品就有顧客”哲學(xué)的一個(gè)示例。Amazon 的開(kāi)發(fā)人員根本未曾料到，可通過(guò)多種方法使用他們的服務(wù)來(lái)構建新穎有趣的應用程序。
通常，面向服務(wù)的應用程序的拓撲會(huì )隨著(zhù)時(shí)間的推移而演變，有時(shí)無(wú)需管理員或開(kāi)發(fā)人員的直接干預?？蓪⑿路?wù)引入面向對象的系統的程度既取決于服務(wù)交互的復雜程度，又取決于以通常方式進(jìn)行交互的服務(wù)的普遍性。面向服務(wù)的設計通過(guò)降低服務(wù)交互的復雜程度來(lái)鼓勵使用可增加普遍性的模型。當服務(wù)特定的假設滲透到服務(wù)的公共外觀(guān)時(shí)，很少有服務(wù)能夠合理地模仿該外觀(guān)并充當合理的替換服務(wù)。
自治服務(wù)這一概念還會(huì )對處理失敗的方式產(chǎn)生影響。所部署的多個(gè)對象將作為商業(yè)應用程序在同一個(gè)執行上下文中運行。面向服務(wù)的設計假設這種情形是例外情況，而不是常規情況。因此，這些服務(wù)期望商業(yè)應用程序可以在沒(méi)有通知（而且通常沒(méi)有任何通知）的情況下失敗。為了維持系統的完整性，面向服務(wù)的設計使用各種技術(shù)來(lái)處理部分失敗模式。在面向服務(wù)的系統中，這些技術(shù)（如事務(wù)處理、持久隊列、冗余部署和故障轉移）相當普遍。
因為所部署的許多服務(wù)都會(huì )在公共網(wǎng)絡(luò )（如 Internet）上運行，所以面向服務(wù)的開(kāi)發(fā)不僅會(huì )假設傳入的消息數據可能是錯誤的，而且會(huì )假設它可能是出于惡意目的而傳輸的。面向服務(wù)的結構可進(jìn)行自我保護，方法是要求應用程序證明已被授予了所有必需的權利和特權，以使得所有消息發(fā)送者都承擔舉證責任。面向服務(wù)的結構與服務(wù)自治的概念一致，它總是依賴(lài)以管理方式托管的信任關(guān)系，以便避免使用傳統 Web 應用程序中常見(jiàn)的每服務(wù)身份驗證機制。
服務(wù)共享架構和協(xié)定（而非類(lèi)）面向對象的編程鼓勵開(kāi)發(fā)人員用類(lèi)的形式創(chuàng )建新抽象?，F代的大多數開(kāi)發(fā)環(huán)境不僅使定義新類(lèi)變得不重要，而且隨著(zhù)類(lèi)數量的不斷增加，現代的 IDE 在指導您完成開(kāi)發(fā)過(guò)程方面能夠做得更好（如 IntelliSense? 之類(lèi)的功能會(huì )為特定的方案提供一個(gè)更有針對性的選項列表）。
類(lèi)是非常方便的抽象，這是由于它們會(huì )在單個(gè)的特定單元中共享結構和行為。面向服務(wù)的開(kāi)發(fā)沒(méi)有這樣的構造。相反，服務(wù)僅基于架構（用于結構）和協(xié)定（用于行為）來(lái)進(jìn)行交互。每個(gè)服務(wù)都會(huì )公布一個(gè)協(xié)定，該協(xié)定描述它可以發(fā)送和/或接收的消息的結構，以及針對這些消息的一定程度的排序約束。這種結構和行為之間的嚴格分離大大簡(jiǎn)化了部署，這是由于分布式對象概念（如按值封送）要求使用公共的執行和安全環(huán)境，這與自治計算的目標直接存在沖突。
服務(wù)本身不處理類(lèi)型或類(lèi)；而只是處理服務(wù)所支持的計算機可讀取和可驗證的合法“細節”說(shuō)明。鑒于面向服務(wù)的應用程序的開(kāi)發(fā)和部署方式內在的分布式特性，計算機可驗證性和驗證非常重要。與傳統的類(lèi)庫不同，服務(wù)必須非常仔細地驗證到達每個(gè)消息的輸入數據。使得結構基于計算機可驗證的架構和協(xié)定，不僅為開(kāi)發(fā)人員和基礎結構提供了保護單個(gè)服務(wù)完整性所需的提示，而且還為他們提供了保護整個(gè)應用程序的完整性所需的提示。
因為給定服務(wù)的協(xié)定和架構在廣泛的空間和時(shí)間內可見(jiàn)，所以面向服務(wù)的設計要求協(xié)定和架構不會(huì )隨著(zhù)時(shí)間的推移而改變。通常情況下，不可能將架構和/或協(xié)定中的更改傳播到曾經(jīng)遇到過(guò)某個(gè)服務(wù)的所有各方。因此，面向服務(wù)的設計中所使用的協(xié)定和架構往往比面向對象的傳統接口靈活。通常，服務(wù)使用諸如 XML 元素通配符（如 xsd:any）之類(lèi)的功能和可選的 SOAP 頭塊，按照不中斷已部署代碼的方式來(lái)演變服務(wù)。
基于策略來(lái)確定服務(wù)兼容性 面向對象的設計通常會(huì )混淆結構兼容性和語(yǔ)義兼容性。面向服務(wù)的設計則單獨處理這兩種兼容性。結構兼容性基于協(xié)定和架構，并且可以由基于計算機的技術(shù)（如探測數據包、驗證防火墻）來(lái)驗證（如果不是強制的話(huà)）。語(yǔ)義兼容性則基于功能和要求策略形式的顯式聲明。
每個(gè)服務(wù)都以計算機可讀取的策略表達式的形式來(lái)公布其功能和要求。策略表達式指出為了使得服務(wù)能夠正常運行，必須滿(mǎn)足哪些條件和保證（稱(chēng)作斷言）。策略斷言由一個(gè)穩定的全局唯一名稱(chēng)來(lái)標識，無(wú)論該斷言應用于哪個(gè)服務(wù)，這個(gè)唯一名稱(chēng)的含義都不隨時(shí)間和空間的變化而改變。策略斷言還可以有一些參數，以確保斷言會(huì )被正確解釋。單個(gè)的策略斷言對于系統基本上不透明，這使得實(shí)現能夠應用簡(jiǎn)單的建議邏輯以確定服務(wù)兼容性。
返回頁(yè)首什么是 Indigo？
Indigo 是一組基于 .NET 框架的用來(lái)構建和運行連接系統的技術(shù)。Indigo 是從 COM、COM+ 和 MSMQ 開(kāi)始的演變過(guò)程中的下一步，并會(huì )通過(guò) .NET Remoting、ASMX、System.Messaging 和 .NET Enterprise Services 繼續這個(gè)演變過(guò)程。Indigo 包含了這些技術(shù)，并為使用任何符合 CLR 的語(yǔ)言開(kāi)發(fā)服務(wù)提供了一個(gè)統一的編程體驗。
圖 1 Indigo 結構
正如圖 1 所示，Indigo 的主要子系統是 Indigo 服務(wù)模型、Indigo 連接器、宿主環(huán)境以及系統和消息服務(wù)。
Indigo 服務(wù)模型 Indigo 服務(wù)模型使用任何面向 CLR 的語(yǔ)言，使得面向服務(wù)的開(kāi)發(fā)非常明確和簡(jiǎn)單。開(kāi)發(fā)人員使用聲明性屬性來(lái)標記他們的類(lèi)型的哪些方面應當形成服務(wù)的外部協(xié)定。Indigo 服務(wù)模型支持兩種協(xié)定：數據協(xié)定和服務(wù)協(xié)定。數據協(xié)定在本質(zhì)上是有關(guān)結構的，它描述 CLR 類(lèi)型的外部格式。數據協(xié)定類(lèi)似于 XML 架構定義。服務(wù)協(xié)定在本質(zhì)上則是有關(guān)行為的，它描述用來(lái)與服務(wù)進(jìn)行交互的消息交換的模式。服務(wù)協(xié)定類(lèi)似于 WSDL portType 定義。Indigo 服務(wù)模型既支持代碼優(yōu)先的開(kāi)發(fā)模型，也支持協(xié)定優(yōu)先的開(kāi)發(fā)模型，其中包括對于 Web 服務(wù)描述語(yǔ)言 (WSDL) 和 XML 架構導入/導出的支持。
Indigo 服務(wù)模型的主要功能是將用戶(hù)定義的代碼與傳入的消息進(jìn)行關(guān)聯(lián)。這是通過(guò)使用 [ServiceMethod] 屬性來(lái)完成的。用該屬性標記的方法支持單向消息處理或相互關(guān)聯(lián)的請求/答復消息處理，具體情況取決于 OneWay 屬性的值。標記為服務(wù)方法的方法可被聲明為從整個(gè)消息或（如果需要的話(huà)）類(lèi)型化參數的角度來(lái)工作。消息本身可被視為強類(lèi)型化對象或 XML 信息集 (infoset)。
Indigo 服務(wù)模型為服務(wù)提供實(shí)例和上下文管理。Indigo 會(huì )將傳入的消息傳送給用戶(hù)定義的服務(wù)類(lèi)型的實(shí)例。開(kāi)發(fā)人員使用聲明性屬性來(lái)控制實(shí)例如何與傳入的消息相關(guān)聯(lián)，以及 Indigo 的會(huì )話(huà)管理功能如何將多個(gè)消息傳送給一個(gè)公共會(huì )話(huà)對象。另外，Indigo 服務(wù)模型使開(kāi)發(fā)人員能夠顯式控制執行上下文（因果性、調用上下文、事務(wù)處理）在協(xié)作服務(wù)之間的傳播。
最后，Indigo 服務(wù)模型會(huì )提供可自動(dòng)實(shí)現安全性和可靠性的聲明性行為。當方法進(jìn)入和離開(kāi)服務(wù)時(shí)，這些屬性會(huì )影響 Indigo 的行為，并強加一些最初由開(kāi)發(fā)人員聲明的策略，隨后由管理員通過(guò)配置使其變得具體。
與 ASMX 一樣，Indigo 使服務(wù)能夠在不共享程序集或源代碼的情況下使用。另外，Indigo 為 ASMX 兼容性提供了支持，ASMX 兼容性將允許用相對較少的修改使許多基于 ASMX 的 Web 服務(wù)變成基于 Indigo 的服務(wù)。
Indigo 連接器 Indigo 連接器是一個(gè)托管框架，它提供基于消息的安全可靠的連接。Indigo 連接器是一個(gè)分層的 I/O 框架，它基于 SOAP 數據和處理模型。Indigo 連接器允許您使用少量的概念（端口、消息、信道），構建獨立于傳輸或目標平臺且基于消息的應用程序，所有這些概念都將在本文的后面部分進(jìn)行介紹。Indigo 連接器在設計上體積很小并且具有優(yōu)異的吞吐量和執行等待時(shí)間特征，這使其可用在對性能敏感的系統中。
Indigo 連接器基于端口和信道。端口表示網(wǎng)絡(luò )空間中的某個(gè)位置，并為它所承載的所有服務(wù)提供一個(gè)基本的統一資源標識符 (URI)。信道是一種 I/O 設備，服務(wù)使用它來(lái)通過(guò)服務(wù)端口收發(fā)消息。一些信道是將基礎通信機制映射到 Indigo 的傳輸信道。其他一些信道是在一個(gè)或多個(gè)傳輸信道上提供特定消息處理規則或服務(wù)質(zhì)量的消息處理信道。Indigo 連接器還包括一個(gè)消息編碼器，該編碼器允許向系統中添加編碼，以便在抽象數據模型（由 Indigo 在內部使用）和字節序列（由特定傳輸使用）之間進(jìn)行轉換。序列化層采用各種 CLR 對象和類(lèi)，并對它們進(jìn)行提取，形成一個(gè)適合在各種服務(wù)邊界之間進(jìn)行共享的簡(jiǎn)單數據模型。
Indigo 連接器顯式支持中間物（包括防火墻、代理和網(wǎng)關(guān)）。Indigo 連接器的中間模型與 SOAP 處理模型一致。盡管支持與服務(wù)之間的直接通信，但是 Indigo 假設直接連接是例外情況，而不是常規情況。相反，Indigo 通過(guò)調整配置、元數據和服務(wù)策略來(lái)為消息確定最佳路線(xiàn)，并會(huì )根據需要利用網(wǎng)關(guān)或代理。而且，Indigo 連接器通過(guò)提供消息驗證、安全強制執行和基于內容的負載平衡，大大簡(jiǎn)化了應用程序級網(wǎng)關(guān)的創(chuàng )建，從而可以免除后端服務(wù)的工作負荷。
中間物的存在通常意味著(zhù)在發(fā)送方和最終接收方之間沒(méi)有端到端的傳輸連接。為了確保消息在這些情形下能夠可靠傳遞，Indigo 使用 WS-ReliableMessaging 協(xié)議通過(guò) SOAP 實(shí)現了可靠的端到端消息處理。Indigo 連接器提供兩種可靠的消息處理模式：快速和持久。當消息從來(lái)源傳遞到目標時(shí)，快速消息處理使用內存中的緩沖區來(lái)保存傳輸中的消息。如果發(fā)送方在發(fā)送消息之后立即發(fā)生了崩潰，則無(wú)法保證快速消息會(huì )被發(fā)送。相反，持久消息使用磁盤(pán)上的緩沖區，即使在系統發(fā)生崩潰時(shí)，它也能提供傳遞保證。
Indigo 連接器為安全消息處理（安全消息處理會(huì )提供獨立于消息傳輸的端到端保護）提供了內在的支持?；谙⒌哪Ｊ胶突跁?huì )話(huà)的模式均受支持?；跁?huì )話(huà)的安全性是首選模型，這是由于簽名和加密均可使用更輕量的、在建立會(huì )話(huà)的過(guò)程中進(jìn)行協(xié)商的會(huì )話(huà)密鑰?；谙⒌陌踩詫τ跀嚅_(kāi)連接或數據報情形是必需的，在這些情形下，消息的接收方在傳輸時(shí)不可用。這兩種模式都支持 WS-Security 系列的協(xié)議（WS-Trust 和 WS-Federation），這樣可確保即使在面臨中間物時(shí)，也能與非 Indigo Web 服務(wù)進(jìn)行互操作。如有可能（例如，在發(fā)送方和接收方之間使用直接 TCP/安全套接字層 (SSL) 連接時(shí)），Indigo 還會(huì )使用傳輸級安全性。
宿主環(huán)境 Indigo 連接器和服務(wù)模型可被顯式加載并用在系統上的任何 AppDomain 中。這使得 Indigo 非常適于將面向服務(wù)的外觀(guān)呈現于任何托管代碼段之前。如果在 AppDomain 中初始化 Indigo 連接器，則無(wú)論以哪種方式創(chuàng )建 AppDomain，都可為您提供基本的“服務(wù)撥號音”。事實(shí)上，如何啟動(dòng) AppDomain 完全超出了 Indigo 連接器的角色范圍。
為了使 Indigo 可被盡可能多的開(kāi)發(fā)人員訪(fǎng)問(wèn)，已經(jīng)對當前在 Windows 平臺上使用的各種宿主系統（如 svchost.exe 和 dllhost.exe）進(jìn)行了改編，以便為基于 Indigo 的服務(wù)提供專(zhuān)門(mén)支持。在這些宿主系統中，最有趣的是 ASP.NET 和 IIS。
隨著(zhù) Indigo 的發(fā)布，ASP.NET 現在支持一個(gè)用來(lái)管理 AppDomains 和 OS 進(jìn)程的系統范圍的工具。這就允許基于 Indigo 的服務(wù)可根據到達任何正確配置的傳輸的消息進(jìn)行按需啟動(dòng)。Indigo 為 TCP、HTTP 和進(jìn)程間通信 (IPC) 傳輸提供內置的支持。Indigo 宿主允許應用程序能夠像 IIS 模型一樣與 URI 后綴相關(guān)聯(lián)，以便將 URI 后綴映射到 VRoot。但是，與 IIS 不同的是，Indigo 不會(huì )與特定的傳輸協(xié)議或編程模型相關(guān)聯(lián)。
使用 ASP.NET 宿主的基于 Indigo 的服務(wù)會(huì )獲取另外一組管理服務(wù)，其中包括進(jìn)程/AppDomain 級別以及單個(gè)服務(wù)級別的可配置回收和鈍化。Indigo 還支持對進(jìn)程和 AppDomai 進(jìn)行基本的運行狀況監視。對于 ASP.NET 的宿主工具來(lái)說(shuō)，一個(gè)值得注意的新功能是服務(wù)代碼能夠參與服務(wù)管理（啟動(dòng)、停止）請求。這有助于具有中間工作的服務(wù)避免在不合適的時(shí)間處理回收。大多數基于服務(wù)器的新 Indigo 服務(wù)都將使用 ASP.NET 宿主功能，這將導致對于所有的托管中間層代碼都擁有一個(gè)相同的配置和管理體驗。
系統和消息服務(wù) 基于 Indigo 的系統有幾個(gè)為所有服務(wù)提供重要功能的系統服務(wù)。標識聯(lián)盟就是其中的一個(gè)系統服務(wù)。即將在 Windows 中推出的安全系統版本支持一個(gè)聯(lián)盟服務(wù)，該服務(wù)允許對來(lái)自外部信任邊界的標識進(jìn)行管理和驗證。Windows 聯(lián)盟服務(wù)使用 WS-Federation 來(lái)安全地代理服務(wù)和相應信任機構之間的身份驗證。
Indigo 還為事務(wù)編程提供了重要的支持。啟用了 Indigo 的 Windows 版本支持一個(gè)基于服務(wù)的事務(wù)處理管理器，該事務(wù)管理器可通過(guò) System.Transactions 框架或 WS-AtomicTransactions 協(xié)議來(lái)訪(fǎng)問(wèn)。新的 System.Transactions 框架使整個(gè)平臺（它支持 SQL Server?、ADO.NET、MSMQ、分布式事務(wù)處理協(xié)調器 (DTC) 等）上的事務(wù)編程都變得簡(jiǎn)單高效。System.Transactions 既支持基于 ITransaction 接口的顯式編程模型，也支持隱式的編程模型（Indigo 自動(dòng)管理其中的事務(wù)處理）。這兩個(gè)模型都可用于基于 Indigo 的應用程序。
System.Transactions 提供一個(gè)新的內存中事務(wù)處理管理器，該事務(wù)處理管理器允許高效地提交或回滾不穩定的事務(wù)處理（即，不涉及持久資源的事務(wù)處理），而不會(huì )導致任何磁盤(pán) I/O。為了支持持久性，這個(gè)內存中的事務(wù)管理器將以透明方式把不穩定的事務(wù)提升為持久事務(wù)，方法是通過(guò)基于磁盤(pán)的事務(wù)處理管理器（如 DTC）來(lái)協(xié)調持久資源管理器將其自身登記到事務(wù)處理中的時(shí)刻。
System.Transactions 為編寫(xiě)不穩定資源管理器和持久資源管理器定義了一個(gè)簡(jiǎn)單的托管接口。System.Transactions 還支持任何可與 OLE 事務(wù)處理或廣泛采用的 WS-AtomicTransaction 協(xié)議進(jìn)行通信的資源管理器。為了通過(guò)事務(wù)處理高效訪(fǎng)問(wèn)文件系統，Longhorn 版本的 System.Transactions 對內核事務(wù)處理管理器 (KTM) 和事務(wù)處理 NTFS (TxNTFS) 均提供直接支持。
Indigo 還提供了消息處理應用程序中使用的許多公共抽象的實(shí)現。具體來(lái)說(shuō)，Indigo 提供了簡(jiǎn)單但是可擴展形式的隊列、事件處理和基于內容的路由，所有這些都可用在任何基于 Indigo 的應用程序中。
返回頁(yè)首對 Indigo 進(jìn)行編程
Indigo 模型基于四個(gè)簡(jiǎn)單概念。首先，消息是一段可傳輸的、遵循 SOAP 數據模型的數據。消息有零或多個(gè)頭和一個(gè)主體，在 Indigo 中，消息由具體的 Message 類(lèi)來(lái)表示。盡管 Indigo 允許具有任意方法的對象存儲在消息中，但是所有的消息部分都可按照 SOAP 和 XML 數據模型以統一的方式交互。
第二，消息在端口之間流動(dòng)。Indigo 端口是服務(wù)之間通信的端點(diǎn)。端口可以獨立于傳輸來(lái)收發(fā)消息。端口有兩種形式：匿名和命名。命名端口可獨立于任何會(huì )話(huà)或連接顯式尋址，匿名端口只能作為已建立的通信會(huì )話(huà)的一部分隱式尋址。匿名端口接收的唯一消息是對發(fā)自該端口的消息的響應。
第三，服務(wù)是端口后面的一段不透明代碼。Indigo 是指作為服務(wù)駐留在端口后面的可執行代碼。服務(wù)既有策略又有協(xié)定；策略指出服務(wù)的功能和要求，協(xié)定則指出服務(wù)可參與的、可接受消息交換。
第四，服務(wù)通過(guò)信道與它們的端口進(jìn)行通信。服務(wù)可以創(chuàng )建和使用一系列信道來(lái)構建應用程序；信道的屬性、策略和行為因信道所提供的通信服務(wù)的特征而異。例如，可以創(chuàng )建用來(lái)連接另一個(gè)服務(wù)（由 URL 來(lái)標識）的對話(huà)信道。對話(huà)信道提供如下功能：設置“僅一次，按順序”傳遞的傳輸保證策略；使用這樣的信道，可以確保消息可靠地傳遞。
圖 2 中的圖表顯示了消息、端口、信道和服務(wù)之間的關(guān)系。
圖 2 關(guān)系
為了使這些概念具體化，最簡(jiǎn)單的方法就是查看一些代碼。這一部分中顯示的代碼是針對 Indigo 的 PDC 版本編寫(xiě)的 — 很自然地，從現在到最終版本之前，細節有可能會(huì )發(fā)生更改。下面的代碼是可能的最小 Indigo 服務(wù)，它是在 C# 中只使用 Indigo 連接器編寫(xiě)的：
using System; using System.MessageBus; class app { static void Main() { // create and open a named port Port port = new Port(new Uri("soap://localhost/simple")); port.Open(); // wait forever Console.ReadLine(); } }
此服務(wù)創(chuàng )建了一個(gè)新的命名端口，該端口的相對 URI 是“/simple”，可通過(guò)所有已安裝的傳輸來(lái)訪(fǎng)問(wèn)。Indigo 將 "soap:" URI 方案視為服務(wù)的獨立于傳輸的地址。Indigo 連接器會(huì )自動(dòng)將該地址映射到 TCP 和 HTTP 傳輸上，以便該服務(wù)可通過(guò)下面的任何 URI 尋址：
soap://localhost/simple http://localhost/simple soap.tcp://localhost/simple
除非應用程序需要顯式控制傳輸選項，否則，soap: 是首選的 URI 方案，因此，本文的其余部分均使用該方案。
剛剛顯示的服務(wù)極其靈活 — 您可以通過(guò)任何傳輸向該服務(wù)發(fā)送任何種類(lèi)的消息，它將以靜默方式輕松處理這些消息。編寫(xiě)涉及到消息的代碼還需要另外一些少量的工作。
圖 3 顯示的服務(wù)會(huì )在發(fā)送的消息內容為簡(jiǎn)單字符串時(shí)，將該字符串打印到控制臺上。此服務(wù)假設消息的主體是簡(jiǎn)單字符串，如果消息的主體是任何其他內容，此服務(wù)將總是肯定會(huì )失敗。
為了允許服務(wù)以更加面向數據的形式處理主體，Indigo 還使您能夠使用 System.Xml 將消息內容作為原始的 XML 結構數據進(jìn)行訪(fǎng)問(wèn)。
圖 4 中的服務(wù)會(huì )將每個(gè)消息的內容轉儲到 XML 文本文件中。
此程序利用如下事實(shí)：消息的主體總是可以通過(guò) XmlReader 流接口來(lái)訪(fǎng)問(wèn)。此功能對于處理大型消息非常重要，這是由于 XmlReader 的只前進(jìn)遍歷模型允許在消息數據流入內存中時(shí)進(jìn)行遞增處理。
Indigo 連接器定義了一個(gè)托管類(lèi)型的小內核來(lái)處理消息。這些類(lèi)型的最核心部分是具體的 Message 類(lèi)，如
圖 5 中所示。Message 類(lèi)維護著(zhù)一個(gè)頭的排序列表，以及一個(gè)代表消息內容的主體。為方便起見(jiàn)，Action 頭（由 WS-Addressing 以及 SOAP 的 HTTP 綁定來(lái)定義）作為可分辨屬性來(lái)調出。每個(gè)消息頭都實(shí)現 MessageHeader 抽象接口（如
圖 6 所示），該接口會(huì )公開(kāi)核心的 SOAP-ism（如 mustUnderstand 和 actor/role）。消息的主體必須實(shí)現 MessageContent 抽象接口，該接口既支持基于對象的訪(fǎng)問(wèn)，又支持基于 XML 的訪(fǎng)問(wèn)。
除了 Message 類(lèi)，最重要的消息處理類(lèi)型無(wú)疑是 IMessageHandler。IMessageHandler 接口代表一段消息處理代碼，并且有一個(gè)用于調用消息處理器的方法：ProcessMessage。
public interface IMessageHandler { bool ProcessMessage(Message msg); // async support elided for clarity }
除了主要的 ProcessMessage 方法，IMessageHandler 接口還提供了其他幾個(gè)方法，這些方法用于與執行異步方法時(shí)使用的 IAsyncResult 用語(yǔ)進(jìn)行交互。需要默認異步行為的實(shí)現（如這一部分開(kāi)頭顯示的示例）通常從 SyncMessageHandler 抽象基類(lèi)派生，并且只提供一個(gè) ProcessMessage 方法主體。
還記得嗎，消息通過(guò)消息的主體支持流 I/O，這表明遍歷主體的消息處理程序會(huì )有效地呈現以后毫無(wú)用處的消息。因此，ProcessMessage 方法會(huì )返回一個(gè)布爾值，表明消息是否已被“使用”。如果主體尚未被使用，則處理程序從 ProcessMessage 中返回真，表明該消息仍可進(jìn)行進(jìn)一步處理。如果某個(gè)處理程序使用消息主體，則必須從 ProcessMessage 返回假，而且還必須針對該消息對象調用 Close，以便釋放由該消息占用的任何基礎資源。 下例闡釋了如何通過(guò)使用一系列消息處理程序來(lái)使用消息：
static void ConsumeMessage(IList<IMessageHandler> code, Message data) { bool live = true; for (int i=0; i < code.Count && live; i++) live = code[i].ProcessMessage(data); if (live) data.Close(); }
第三個(gè)也是最后一個(gè)核心消息處理類(lèi)型就是 IMessageProducer。IMessageProducer 是一個(gè)為消息來(lái)源建立模型的簡(jiǎn)單接口，正如下面顯示的那樣，它只有一個(gè)公共成員，即 Handler 屬性：
public interface IMessageProducer { IMessageHandler Handler { get; set; } }
您已經(jīng)了解了此接口的實(shí)現方法。用在前面服務(wù)示例中的 Port.ReceiveChannel 屬性實(shí)現了 IMessageProducer 接口。對于要處理到達某個(gè)端口的消息的代碼，只需通過(guò)接收信道的 Handler 屬性將它們自身進(jìn)行附加。
到現在為止，您只了解了如何接收消息。很顯然，Indigo 還允許發(fā)送消息 — 此功能是通過(guò)端口的發(fā)送信道來(lái)呈現的。每個(gè)端口都有一個(gè)默認的發(fā)送信道（通過(guò) Port.SendChannel 屬性來(lái)呈現），使用發(fā)送信道可以發(fā)送使用 To 頭（按照 WS-Addressing 規范）顯式尋址的消息。此信道通常只用于發(fā)送由 Message.CreateReply 方法創(chuàng )建的答復消息：
static bool Process(Port port, Message request) { Message data = request.CreateReply(null, "Blue"); IMessageHandler channel = port.SendChannel; if (channel.ProcessMessage(data)) data.Close(); }
更常見(jiàn)的用法是，通過(guò)調用 Port.CreateSendChannel 方法來(lái)創(chuàng )建每地址發(fā)送信道，如下所示：
static void SendAMessage(Port source, Uri target) { { Message data = new Message(null, "Cyan"); IMessageHandler channel = source.CreateSendChannel(target); if (channel.ProcessMessage(data)) data.Close(); }
在本例中，發(fā)送信道會(huì )首先向消息中添加必需的尋址頭，然后再將它傳遞到下面的傳輸管理器。
返回頁(yè)首我們處在什么位置？
本文只是粗略概述了 Indigo 的功能和動(dòng)機。由于 Indigo 項目的范圍很廣，因此 Indigo 編程體驗的許多方面都在這篇介紹性文章中省去了。隨著(zhù) Indigo beta 版發(fā)布的臨近，請訪(fǎng)問(wèn)
MSDN? Web Services Developer Center，以便了解 Indigo 涉及的更完整內容。
Don Box 是 Microsoft 中 Indigo 項目的設計師，他致力于下一代的 Web 服務(wù)協(xié)議和設備。他的興趣包括 XML 和 Web 服務(wù)的類(lèi)型系統、元數據、發(fā)現和面向服務(wù)的軟件集成。Don 從 1998 年開(kāi)始致力于 Web 服務(wù)，他是 SOAP 規范最初的作者之一。Don 最新的一本書(shū)是《Essential .NET Volume 1: The Common Language Runtime》（Addison-Wesley 于 2002 年出版）。
轉到原英文頁(yè)面返回頁(yè)首個(gè)人信息中心 |
MSDN中文速遞郵件 |
聯(lián)系我們?2006 Microsoft Corporation. 版權所有.
保留所有權利 |
商標 |
隱私權聲明
